├── LICENSE └── README.md /LICENSE: -------------------------------------------------------------------------------- 1 | This is free and unencumbered software released into the public domain. 2 | 3 | Anyone is free to copy, modify, publish, use, compile, sell, or 4 | distribute this software, either in source code form or as a compiled 5 | binary, for any purpose, commercial or non-commercial, and by any 6 | means. 7 | 8 | In jurisdictions that recognize copyright laws, the author or authors 9 | of this software dedicate any and all copyright interest in the 10 | software to the public domain. We make this dedication for the benefit 11 | of the public at large and to the detriment of our heirs and 12 | successors. We intend this dedication to be an overt act of 13 | relinquishment in perpetuity of all present and future rights to this 14 | software under copyright law. 15 | 16 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 17 | EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 18 | MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. 19 | IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR 20 | OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 21 | ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR 22 | OTHER DEALINGS IN THE SOFTWARE. 23 | 24 | For more information, please refer to 25 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Manifesto 2 | 3 | ### Git 4 | - [ ] 1 commit per change, do squash on merge 5 | - you can easily work with changes 6 | - [ ] there might be few (already squashed) commits in a pull request 7 | - don't make huge changes they will bury the truth 8 | - [ ] touch few things at once 9 | - it's kinda obvious 10 | - [ ] rebase instead of merge 11 | - no merge commits, cleaner git history 12 | - [ ] pull request must have at least 1-2 approvals 13 | - changes must be visible to the team members 14 | - [ ] master is read-only 15 | - it's a rule. Always. No exceptions. 16 | - [ ] delete branches after a merge 17 | - better navigation and git performance 18 | - [ ] use SemVer as a standard for versioning 19 | - do not reinvent the wheel 20 | - [ ] release tags 21 | - tracking releases/deployments are simpler 22 | - [ ] omit release branches for patches (aka 0.1.x) 23 | - use release tags for that 24 | - [ ] no global history changes 25 | - prevents git history misuse 26 | - [ ] commit message format 27 | - clear, well explanatory, structured 28 | - [ ] no big binary files inside a repo 29 | - slowdowns without a reason 30 | - [ ] have a meaningful README 31 | - so everyone can quickly get an overview of the repo 32 | 33 | ### CI 34 | - [ ] auto-revert on failure 35 | - rollback changes, no broken code in the master 36 | - [ ] run at any commit 37 | - the obvious ability for CI 38 | - [ ] CI plan in git 39 | - know all plan changes and have consistency 40 | - [ ] warn about formatting verification 41 | - no developer disruption in the future 42 | - [ ] warn about coverage illness 43 | - coverage is a quite important thing 44 | - [ ] track test failures and flakiness 45 | - statistics, hints, conclusions 46 | - [ ] store build logs for 3+ months 47 | - having analytics and working links to them 48 | - [ ] do not remove builds/PR/issues 49 | - unexpected 404 will help no one, will not save disk space also 50 | - [ ] docs are generated from the code 51 | - end-user changes must be explicit 52 | - [ ] locally reproducible builds 53 | - re-run part of a job on my local machine 54 | - [ ] use Makefile, Bash 55 | - simple, easy, well known 56 | - [ ] ability to start/stop a job on CI 57 | - waiting for an approval to make this action is a horrible bottleneck 58 | - [ ] CI jobs should be runned periodically 59 | - to reduce possible errors due to hidden dependecies 60 | 61 | ### Deploy 62 | - [ ] configuration files must be validated before a start 63 | - unless difficult debug is your goal 64 | - [ ] store config in the same repo as a code 65 | - this prevents 'the chick or the egg' problem 66 | - [ ] all features must be protected by feature flag 67 | - in case of an accident, it will(might) be enough to turn it off 68 | - [ ] deployment of a new config must be isolated 69 | - to separate different machines/containters/storages from each other 70 | - [ ] deploy must go from a (git-)tag or release, not from the master 71 | - this restricts a changeset which will be deployed 72 | 73 | ### Code health 74 | - [ ] leave your code better than you found it 75 | - [ ] document your code 76 | - giving a small context for API will save a lot of time 77 | - [ ] use linters and code analysis all the time 78 | - the best handling for the best code 79 | - [ ] touch legacy, often 80 | - it becomes non-legacy faster 81 | - [ ] remove deprecated stuff 82 | - having a bloated dead code is a mistake 83 | - [ ] also remove old code 84 | - it adds even fewer reasons to the new code 85 | - [ ] use TODO, BUG, XXX in code 86 | - jumping to the issue tracker can be minimised 87 | - [ ] no experiments in the master 88 | - use your 20% time as a playground, please 89 | - [ ] allow changing log-level on the fly 90 | - this will simplify production's debug routine 91 | - [ ] limit your log file, 'cause it might grow unlimited 92 | - this might cause troubles to your app, be careful 93 | - [ ] store your config in /etc/myapp and logs in /var/log/myapp 94 | - this will make everything more structured and well defined 95 | - [ ] all modules must have the same structure 96 | - similar environment everywhere is a good idea 97 | - [ ] if you can’t show a bottleneck, don’t start to optimise it 98 | - it might be interesting and challenging, but useless 99 | - [ ] check back compatibility before the new releases 100 | - make it explicit and obvious (+doc how to port) 101 | 102 | ### Database 103 | - [ ] think about your data 104 | - don't use SQL/NoSQL without a reason 105 | - [ ] keep models normalized 106 | - less storage, better performance 107 | - [ ] but don't normalize without a reason 108 | - everything is a trade off 109 | - [ ] use timestamp to store a date/time 110 | - this will save you from formatting hell 111 | - [ ] log slow queries 112 | - see what is happening in a database and who is too greedy 113 | - [ ] don't put business logic into DB or at least make it loosely coupled 114 | - this will give you an easy migration to another DB 115 | 116 | ### Dependencies 117 | - [ ] wrap any dependency with an interface(or analogue) 118 | - this will prevent a vendor lock on it 119 | - [ ] bump libs on a permanent basis 120 | - the new version is expected to be better 121 | - [ ] have a local cache-server with dependencies 122 | - adds stability to the infrastructure 123 | - [ ] pin your dependencies to a specific version 124 | - accidental commit to dependency's master will break nothing 125 | - [ ] prefer mature technology, rather than a hyped one 126 | - mature will die slower, then hyped 127 | - [ ] fork instead of hack 128 | - it might be better to fix a lib instead of wrapping for the desired behaviour 129 | 130 | ### Tests 131 | - [ ] use one test framework 132 | - a similar environment is better 133 | - [ ] show results, not just stack traces 134 | - some failures are obvious with visible result 135 | - [ ] isolated tests 136 | - use beforeTest and afterTest aggressively 137 | - [ ] TDD 138 | - it really works 139 | - [ ] measure a code coverage 140 | - a quick and easy way to eliminate bugs 141 | - [ ] test your backups 142 | - they might be broken 143 | - [ ] do not hard code ports in tests 144 | - unless you're interested in random flaky tests 145 | 146 | ### Team 147 | - [ ] pairing, 50% and more 148 | - you're doing better, you're not bored 149 | - [ ] high-level stand-ups, time bounded 150 | - less info about irrelevant stuff 151 | - [ ] 2-3 week sprints 152 | - have an achievable sprint goal 153 | - UPD: depends on team/project, might be unuseful 154 | - [ ] per sprint roles 155 | - it's quite comfortable time bounds 156 | - [ ] only urgent topics are face-to-face 157 | - fewer distractions for unimportant things 158 | - [ ] friendly atmosphere 159 | - no insulting environment, respectful trolling 160 | - [ ] 'coding rockstar' 161 | - it is a demotivation, not an inspiration 162 | - [ ] if you're on the vacations - specify a date range 163 | - it'll be easier to find someone else or postpone the question 164 | - [ ] FAQ for newcomers 165 | - 30-day plan with all stuff that they should accomplish 166 | - [ ] document solved and unresolved problems 167 | - team members will be aware of some problems and it will be resolved much faster 168 | - [ ] every ticket in progress must have an assignee 169 | - this prevents doing same work on one task 170 | - [ ] there must be a run book or guide for every responsibility 171 | - 30/60/90 days plan for newcomers, guide for on call, support 172 | 173 | ### Meetings 174 | - [ ] I can skip if I'm out of scope 175 | - do not waste team and own time 176 | - [ ] if you're organising a meeting - prepare an agenda 177 | - to have a way how to drive a meeting 178 | - [ ] action points after the meeting 179 | - who does what and when 180 | - [ ] avoid bus factor as much as possible 181 | - moving/cancelling an unimportant meeting because 1 person is a bad sign 182 | 183 | ### Communications 184 | - [ ] use the best apps 185 | - fast, flexible, pleasurable 186 | - [ ] outcomes of important discussions should be on a wiki 187 | - better visibility for outcomes 188 | - [ ] only important notifications 189 | - @all should be rare for irrelevant updates 190 | - [ ] easy access to any team room 191 | - that's obvious, hey 192 | - [ ] do not delete personal chats with inactive users 193 | - some chats contain interesting ideas 194 | - [ ] closed ticket must contain a link to the changes 195 | - every change must be easily accessible and visible for others 196 | 197 | ### Permissions 198 | - [ ] Git, CI, SSH read-access to everything 199 | - reading server logs cannot cause troubles 200 | - [ ] SSO to anything 201 | - better organisation of credentials 202 | - [ ] each office should have global admin 203 | - different time zones are a bottleneck 204 | 205 | ### Space 206 | - [ ] engineers apart from non-engineers 207 | - fire & ice 208 | - [ ] quiet open-space 209 | - someone might be sensitive to noise... 210 | - [ ] quiet zones 211 | - ...really sensitive 212 | - [ ] the kitchen isn't for chill-out 213 | - the playroom is a thing 214 | - [ ] nothing smelly near working area 215 | - even coffee/cinnamon/mowed grass might irritate 216 | 217 | ### Network 218 | - [ ] VPN access from home 219 | - work from home is a cool thing 220 | - [ ] Wifi must work all the time 221 | - obvious 222 | - [ ] LAN must be even more stable 223 | - uber-obvious 224 | 225 | ### Life 226 | - [ ] how often should my salary be reviewed? 227 | - worth asking 228 | - [ ] work from home is a must have 229 | - family, health, even weather might be a reason 230 | - [ ] educational budget to anything related to dev stuff 231 | - I would like to learn new technologies, why not? 232 | - [ ] allow committing to the open-source 233 | - company_karma++ 234 | - [ ] skipping team events must be acceptable 235 | - well...obvious 236 | - [ ] 20% time is a vacation like time 237 | - creating anything that might help someone is awesome 238 | - [ ] brown bags sessions must be rewarded 239 | - sharing knowledge is the best way to inspire 240 | - [ ] monthly geek swag <3 241 | - t-shirts, hoodies and all other stuff 242 | - [ ] health food in the kitchen 243 | - candies are cool, but I would like to live longer 244 | --------------------------------------------------------------------------------