397 liens privés
"""
Ultimately, your job is to help management meet expectations for the next quarter. This means that most of your time will be spent fighting fires lit from the previous quarters, hunting bugs that could have been easily prevented, or refactoring several unrelated pieces of code just enough implement the next broken feature.
"""
Oh, il semblerait que ce magnifique paragraphe exprime une légère frustration, face à la dette technique non traitée, par exemple.
Très bon article, du reste :)
TL;DW; ? Ce que je retiens:
"""
Avoid Technical Debt
- use a framework
- be open to new technologies
- unit tests
- loosely coupled code
- code reusability (modularize the code)
- reduce code complexity
- code reviews and feedback
- coding standards (promote good architecture)
- design patterns
- general best practices
- static code analysis
- continuous integration tools
- configuration management tools
Pay off Debt
- Make a plan
- Set goals
- Stay inside your budget
- Consistency
- Pay off some debt each sprint on regular interval
"""
"""
C’est pour cette raison que les livreurs de code, même excellents, ne sont bons au final, qu’a produire de la dette technique car plus intéressés par la beauté d’un code que de trouver une finalité utile à celle ci.
"""
et bim.
J'aime ce passage:
"""
La dette technique est donc un facteur largement négligé dans les décisions quand il n’est pas complètement ignoré. Très souvent dans notre métier, les décisions sont prises avec une vision très court terme, sans trop penser aux conséquences sur le long terme. Or, ce qui est intéressant sur du court terme l’est rarement sur du long terme, et ça s’exprime notamment à travers la dette technique.
Lorsque la pression économique nécessite de s’endetter, le bon sens voudrait que cette dette soit remboursée dès que la période critique est passée. On emploie souvent dans cette situation l’expression « nous le ferons plus tard ». Mais « plus tard » signifie bien souvent « jamais ». Les décideurs ont en effet toujours besoin de choses plus prioritaires (à leurs yeux en tout cas) que de rembourser la dette technique. C’est ainsi que la dette s’accumule, petit à petit.
"""
Oui, la tentation du surendettement est grande.
Faire un truc vite fait mal fait, qui fait le taff mais qui te pétera à la gueule ou qui te ralentira dans ton travail plus tard. C'est comme construire une maison sur des fondations en polystyrene. C'est d'autant plus chaud sur du code d'infrastructure. Car remettre en cause du code qui tourne en production exige de faire des migrations, elles-mêmes dangereuses et chronophages. Le produit c'est avant-tout une infra qui fonctionne et qui est robuste, rien d'autre.
Il faut réussir à avancer relativement rapidement (avec de l'intégration continue) tout en se projetant sur le long terme. Il y a un juste milieu à trouver.
Lien via http://geekandtips.com/links/?kyw5Xg
"""
Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design.
"""