Skip to content
No description, website, or topics provided.
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
LICENSE
README.md

README.md

Manifesto

Git

  • 1 commit per change, do squash on merge
    • you can easily work with changes
  • there might be few (already squashed) commits in a pull request
    • don't make huge changes they will bury the truth
  • touch few things at once
    • it's kinda obvious
  • rebase instead of merge
    • no merge commits, cleaner git history
  • pull request must have at least 1-2 approvals
    • changes must be visible to the team members
  • master is read-only
    • it's a rule. Always. No exceptions.
  • delete branches after a merge
    • better navigation and git performance
  • use SemVer as a standard for versioning
    • do not reinvent the wheel
  • release tags
    • tracking releases/deployments are simpler
  • omit release branches for patches (aka 0.1.x)
    • use release tags for that
  • no global history changes
    • prevents git history misuse
  • commit message format
    • clear, well explanatory, structured
  • no big binary files inside a repo
    • slowdowns without a reason
  • have a meaningful README
    • so everyone can quickly get an overview of the repo

CI

  • auto-revert on failure
    • rollback changes, no broken code in the master
  • run at any commit
    • the obvious ability for CI
  • CI plan in git
    • know all plan changes and have consistency
  • warn about formatting verification
    • no developer disruption in the future
  • warn about coverage illness
    • coverage is a quite important thing
  • track test failures and flakiness
    • statistics, hints, conclusions
  • store build logs for 3+ months
    • having analytics and working links to them
  • do not remove builds/PR/issues
    • unexpected 404 will help no one, will not save disk space also
  • docs are generated from the code
    • end-user changes must be explicit
  • locally reproducible builds
    • re-run part of a job on my local machine
  • use Makefile, Bash
    • simple, easy, well known
  • ability to start/stop a job on CI
    • waiting for an approval to make this action is a horrible bottleneck

Deploy

  • configuration files must be validated before a start
    • unless difficult debug is your goal
  • store config in the same repo as a code
    • this prevents 'the chick or the egg' problem
  • all features must be protected by feature flag
    • in case of an accident, it will(might) be enough to turn it off
  • deployment of a new config must be isolated
    • to separate different machines/containters/storages from each other
  • deploy must go from a (git-)tag or release, not from the master
    • this restricts a changeset which will be deployed

Code health

  • leave your code better than you found it
  • document your code
    • giving a small context for API will save a lot of time
  • use linters and code analysis all the time
    • the best handling for the best code
  • touch legacy, often
    • it becomes non-legacy faster
  • remove deprecated stuff
    • having a bloated dead code is a mistake
  • also remove old code
    • it adds even fewer reasons to the new code
  • use TODO, BUG, XXX in code
    • jumping to the issue tracker can be minimised
  • no experiments in the master
    • use your 20% time as a playground, please
  • allow changing log-level on the fly
    • this will simplify production's debug routine
  • limit your log file, 'cause it might grow unlimited
    • this might cause troubles to your app, be careful
  • store your config in /etc/myapp and logs in /var/log/myapp
    • this will make everything more structured and well defined
  • all modules must have the same structure
    • similar environment everywhere is a good idea
  • if you can’t show a bottleneck, don’t start to optimise it
    • it might be interesting and challenging, but useless
  • check back compatibility before the new releases
    • make it explicit and obvious (+doc how to port)

Database

  • think about your data
    • don't use SQL/NoSQL without a reason
  • keep models normalized
    • less storage, better performance
  • but don't normalize without a reason
    • everything is a trade off
  • use timestamp to store a date/time
    • this will save you from formatting hell
  • log slow queries
    • see what is happening in a database and who is too greedy
  • don't put business logic into DB or at least make it loosely coupled
    • this will give you an easy migration to another DB

Dependencies

  • wrap any dependency with an interface(or analogue)
    • this will prevent a vendor lock on it
  • bump libs on a permanent basis
    • the new version is expected to be better
  • have a local cache-server with dependencies
    • adds stability to the infrastructure
  • pin your dependencies to a specific version
    • accidental commit to dependency's master will break nothing
  • prefer mature technology, rather than a hyped one
    • mature will die slower, then hyped
  • fork instead of hack
    • it might be better to fix a lib instead of wrapping for the desired behaviour

Tests

  • use one test framework
    • a similar environment is better
  • show results, not just stack traces
    • some failures are obvious with visible result
  • isolated tests
    • use beforeTest and afterTest aggressively
  • TDD
    • it really works
  • measure a code coverage
    • a quick and easy way to eliminate bugs
  • test your backups
    • they might be broken
  • do not hard code ports in tests
    • unless you're interested in random flaky tests

Team

  • pairing, 50% and more
    • you're doing better, you're not bored
  • high-level stand-ups, time bounded
    • less info about irrelevant stuff
  • 2-3 week sprints
    • have an achievable sprint goal
    • UPD: depends on team/project, might be unuseful
  • per sprint roles
    • it's quite comfortable time bounds
  • only urgent topics are face-to-face
    • fewer distractions for unimportant things
  • friendly atmosphere
    • no insulting environment, respectful trolling
  • 'coding rockstar'
    • it is a demotivation, not an inspiration
  • if you're on the vacations - specify a date range
    • it'll be easier to find someone else or postpone the question
  • FAQ for newcomers
    • 30-day plan with all stuff that they should accomplish
  • document solved and unresolved problems
    • team members will be aware of some problems and it will be resolved much faster
  • every ticket in progress must have an assignee
    • this prevents doing same work on one task
  • there must be a run book or guide for every responsibility
    • 30/60/90 days plan for newcomers, guide for on call, support

Meetings

  • I can skip if I'm out of scope
    • do not waste team and own time
  • if you're organising a meeting - prepare an agenda
    • to have a way how to drive a meeting
  • action points after the meeting
    • who does what and when
  • avoid bus factor as much as possible
    • moving/cancelling an unimportant meeting because 1 person is a bad sign

Communications

  • use the best apps
    • fast, flexible, pleasurable
  • outcomes of important discussions should be on a wiki
    • better visibility for outcomes
  • only important notifications
    • @all should be rare for irrelevant updates
  • easy access to any team room
    • that's obvious, hey
  • do not delete personal chats with inactive users
    • some chats contain interesting ideas
  • closed ticket must contain a link to the changes
    • every change must be easily accessible and visible for others

Permissions

  • Git, CI, SSH read-access to everything
    • reading server logs cannot cause troubles
  • SSO to anything
    • better organisation of credentials
  • each office should have global admin
    • different time zones are a bottleneck

Space

  • engineers apart from non-engineers
    • fire & ice
  • quiet open-space
    • someone might be sensitive to noise...
  • quiet zones
    • ...really sensitive
  • the kitchen isn't for chill-out
    • the playroom is a thing
  • nothing smelly near working area
    • even coffee/cinnamon/mowed grass might irritate

Network

  • VPN access from home
    • work from home is a cool thing
  • Wifi must work all the time
    • obvious
  • LAN must be even more stable
    • uber-obvious

Life

  • how often should my salary be reviewed?
    • worth asking
  • work from home is a must have
    • family, health, even weather might be a reason
  • educational budget to anything related to dev stuff
    • I would like to learn new technologies, why not?
  • allow committing to the open-source
    • company_karma++
  • skipping team events must be acceptable
    • well...obvious
  • 20% time is a vacation like time
    • creating anything that might help someone is awesome
  • brown bags sessions must be rewarded
    • sharing knowledge is the best way to inspire
  • monthly geek swag <3
    • t-shirts, hoodies and all other stuff
  • health food in the kitchen
    • candies are cool, but I would like to live longer
You can’t perform that action at this time.