After some project kinda failed, I decided to save some impressions that I consider important about problems I consider evident:
- Fuck unit tests. It's bullshit on most applied projects, especially if same "high quality coding standards" are applied to tests as for app code. If you deal with science,calculations or at least accounting - create tests, use TDD or whatever. It's obvious for amounts of data or operations unsuitable for manual testing. Otherwise, spending time on manual functional testing is much more useful. And of course, autotests and integration tests are much more useful at least for smoke testing when you don't need 1.5x+ amount of code to cover by smoke and 20x for kinda functional unit testing that looks like documenting. If someone has documented reason for change, he'll just change broken tests too.
- Fuck perfectionism. Remember that while you are trying to make code beautiful, others compete with you having working production nevertheless it's pile of sticks and shit. Actually, inspite of all time-consuming efforts in some time you'll understand that your codebase is same pile of sticks and shit. Is it really possible that customer will order codebase audit? You will never got to this phase if major UI bugs are not fixed for months - customer sees UI 1st.
- Heavily enforce standard approaches, knowledge sharing, commenting and responsibility areas. The less are exceptions from rules the easier are they to follow. Collective code ownership is another bullshit. People are rarely hit by buses, and vacations are short.
- Test on approximately real data. Test early. If there is paging on UI, test it immediately and don't wait when someone manually submit enough data for 2nd+ page to appear. You should not refactor or reimplement after separate perfomance testing on project mature stage. Do things right way initially.
- Remember about probabilities. Many arguments for "better" design starts with "if". Refactor if this "if" happens. Mind schedule and don't do things in advance.
- Fuck unit tests. It's bullshit on most applied projects, especially if same "high quality coding standards" are applied to tests as for app code. If you deal with science,calculations or at least accounting - create tests, use TDD or whatever. It's obvious for amounts of data or operations unsuitable for manual testing. Otherwise, spending time on manual functional testing is much more useful. And of course, autotests and integration tests are much more useful at least for smoke testing when you don't need 1.5x+ amount of code to cover by smoke and 20x for kinda functional unit testing that looks like documenting. If someone has documented reason for change, he'll just change broken tests too.
- Fuck perfectionism. Remember that while you are trying to make code beautiful, others compete with you having working production nevertheless it's pile of sticks and shit. Actually, inspite of all time-consuming efforts in some time you'll understand that your codebase is same pile of sticks and shit. Is it really possible that customer will order codebase audit? You will never got to this phase if major UI bugs are not fixed for months - customer sees UI 1st.
- Heavily enforce standard approaches, knowledge sharing, commenting and responsibility areas. The less are exceptions from rules the easier are they to follow. Collective code ownership is another bullshit. People are rarely hit by buses, and vacations are short.
- Test on approximately real data. Test early. If there is paging on UI, test it immediately and don't wait when someone manually submit enough data for 2nd+ page to appear. You should not refactor or reimplement after separate perfomance testing on project mature stage. Do things right way initially.
- Remember about probabilities. Many arguments for "better" design starts with "if". Refactor if this "if" happens. Mind schedule and don't do things in advance.
No comments:
Post a Comment