├── README.md ├── README.fr.md └── README.es.md /README.md: -------------------------------------------------------------------------------- 1 | # Programming Best Practices Tidbits 2 | ### A Collection of quotes and paraphrases for developers from around the web. 3 | 4 | Use your own judgment in their application[.](http://www.reddit.com/r/programming/comments/1bcebh/programming_best_practices/c95y6la) 5 | 6 | * * * 7 | 8 | ## Never build Large Apps 9 | 10 | The secret to building large apps is never build large apps. Break your applications into small pieces. Then, assemble those testable, bite-sized pieces into your big application. 11 | 12 | – Justin Meyer, author JavaScript MVC 13 | 14 | [Source](http://bitovi.com/blog/2010/11/organizing-a-jquery-application.html) 15 | 16 | ## Quality Matters 17 | 18 | When I hear "JUST BANG OUT CODE THAT WORKS" I think of all the apps I don't use anymore because they gradually lost the ability to iterate. 19 | 20 | – Avdi Grimm 21 | 22 | [Source](https://twitter.com/#!/avdi/status/180747721852985344) 23 | 24 | ## Don't Write Code 25 | 26 | Don’t write code (write new code only when everything else fails) is the single most important lesson every developer needs to learn. The amount of duplicate, crappy code (across projects) that exists today is overwhelming. In a lot of cases developers don’t even bother to look around. They just want to write code. 27 | 28 | [Source](http://blogs.agilefaqs.com/2009/10/19/biggest-stinkers/) 29 | 30 | #### Reducing the amount of code in your product should be a goal. 31 | 32 | "I hate code, and I want as little of it as possible in our product." 33 | – Jack Diederich 34 | 35 | [Source](http://pyvideo.org/video/880/stop-writing-classes) 36 | 37 | #### Keep Lean Dependencies 38 | The old adage "don't reinvent the wheel" doesn't apply when the wheel comes attached to a locomotive engine. 39 | 40 | [Source](http://www.reddit.com/r/programming/comments/1bcebh/programming_best_practices/c9616mn) 41 | 42 | #### Don't expect a rewrite to do better than the original 43 | It's important to remember that when you start from scratch there is absolutely no reason to believe that you are 44 | going to do a better job than you did the first time. First of all, you probably don't even have the same 45 | programming team that worked on version one, so you don't actually have "more experience". You're just going to make 46 | most of the old mistakes again, and introduce some new problems that weren't in the original version. 47 | 48 | – Joel Spolsky 49 | 50 | [Source](http://www.joelonsoftware.com/articles/fog0000000069.html) 51 | 52 | ## Stop Writing Classes 53 | 54 | The signature of "this shouldn't be a class" is when the class has two methods, and one of them is the constructor. 55 | Any time you see these signs, you probably should have just written a function. 56 | 57 | – Jack Diederich 58 | 59 | [Source](http://pyvideo.org/video/880/stop-writing-classes) 60 | 61 | ## Forget new features, Just do the same stuff better. 62 | 63 | The problem: it is too easy to lose sight of what users often care about more, which is the performance and usability of the applications and features they already use most often. 64 | 65 | – Tim Anderson 66 | 67 | [Source](http://www.itjoblog.co.uk/2011/06/making-better-software.html) 68 | 69 | ## Reinvent the Wheel 70 | Inventing your own wheels gives you a deep appreciation and understanding of how wheels work and what makes a good one. 71 | 72 | [Source](http://nodejs.debuggable.com/2011-02-26.txt) 73 | 74 | ## Don't do hard things, do easy things. 75 | 76 | * Simple is better than complex. 77 | * Complex is better than complicated. 78 | * Flat is better than nested. 79 | * Readability counts. 80 | * If the implementation is hard to explain, it's a bad idea. 81 | * If the implementation is easy to explain, it may be a good idea. 82 | 83 | – The Zen of Python 84 | 85 | [Source](http://www.python.org/dev/peps/pep-0020/) 86 | 87 | Shortlist cut from [Jack Diederich's "Stop Writing Classes" talk](http://pyvideo.org/video/880/stop-writing-classes) 88 | 89 | ## Rewriting > Refactoring 90 | If you are changing more than 25% of a class or method, consider simply rewriting it. You will write the code more cleanly. 91 | 92 | ## Refactoring > Rewriting 93 | 94 | #### Common Excuses For A Software Rewrite 95 | 1. The Code Sucks 96 | 2. "We're So Much Smarter Now" 97 | 3. We Picked The Wrong Platform/Language 98 | 99 | #### Why Rewriting Is (Almost) Never A Good Idea 100 | 1. [It Always Takes Longer Than You Expect](http://en.wikipedia.org/wiki/Hofstadter's_law) 101 | 2. Markets Change 102 | 2. Existing Customers Become Frustrated 103 | 3. Refactoring Can Cleanup The Code 104 | 4. You Don't Control The Rewrite, It Controls You 105 | 106 | [Source](http://onstartups.com/tabid/3339/bid/2596/Why-You-Should-Almost-Never-Rewrite-Your-Software.aspx) 107 | 108 | 109 | ## Accept that you have no idea how this will grow 110 | 111 | The key is to acknowledge from the start that you have no idea how this will grow. When you accept that you don't know everything, you begin to design the system defensively... You should spend most of your time thinking about interfaces rather than implementations. 112 | 113 | – Nicholas Zakas, author "High-performance JavaScript websites" 114 | 115 | [Source](http://radar.oreilly.com/2011/06/big-javascript-apps-teams.html) 116 | 117 | [Acknowledgement to Addy Osmani](http://addyosmani.com/largescalejavascript/) 118 | 119 | ## Avoid Code Smells 120 | 121 | [Source](http://www.codinghorror.com/blog/2006/05/code-smells.html) 122 | [Source](http://web.archive.org/web/20120130234037/http://stackoverflow.com/questions/114342/what-are-code-smells-what-is-the-best-way-to-correct-them) 123 | 124 | 125 | ## Write unit tests. 126 | Every programmer knows they should write tests for 127 | their code. Few do. The universal response to "Why not?" is "I'm 128 | in too much of a hurry." This quickly becomes a vicious cycle- the more pressure you feel, the fewer tests you write. The fewer tests you write, the less productive you are and the less stable your code becomes. The less productive and accurate you are, the more pressure you feel. 129 | Programmers burn out from just such cycles. 130 | Breaking out requires an outside influence. We found the outside influence we needed in a simple testing framework that lets us do a little testing that 131 | makes a big difference. 132 | 133 | [Source](http://junit.sourceforge.net/doc/testinfected/testing.htm) 134 | 135 | 136 | #### [Without unit tests] You're not refactoring, you're just changing shit. — Hamlet D'Arcy 137 | 138 | ## To write effective unit tests, you need to write testable code 139 | 140 | ### Flaw #1: Constructor does Real Work 141 | #### Warning Signs 142 | * new keyword in a constructor or at field declaration 143 | * Static method calls in a constructor or at field declaration 144 | * Anything more than field assignment in constructors 145 | * Object not fully initialized after the constructor finishes (watch out for initialize methods) 146 | * Control flow (conditional or looping logic) in a constructor 147 | * Code does complex object graph construction inside a constructor rather than using a factory or builder 148 | * Adding or using an initialization block 149 | 150 | ### Flaw #2: Digging into Collaborators 151 | #### Warning Signs 152 | * Objects are passed in but never used directly (only used to get access to other objects) 153 | * Law of Demeter violation: method call chain walks an object graph with more than one dot (.) 154 | * Suspicious names: context, environment, principal, container, or manager 155 | 156 | ### Flaw #3: Brittle Global State & Singletons 157 | #### Warning Signs 158 | * Adding or using singletons 159 | * Adding or using static fields or static methods 160 | * Adding or using static initialization blocks 161 | * Adding or using registries 162 | * Adding or using service locators 163 | 164 | ### Flaw #4: Class Does Too Much 165 | #### Warning Signs 166 | 167 | * Summing up what the class does includes the word “and” 168 | * Class would be challenging for new team members to read and quickly “get it” 169 | * Class has fields that are only used in some methods 170 | * Class has static methods that only operate on parameters 171 | 172 | [Source](http://misko.hevery.com/code-reviewers-guide/) 173 | 174 | [Source](http://misko.hevery.com/presentations/) 175 | 176 | ## Test-Driven Development with Inversion of Control. 177 | 178 | Even if you aren't testing your code, you should write testable code. IoC enables testable code. Inject test-friendly dependencies or mocks at test time, to isolate the unit-under-test. 179 | 180 | ## Avoid mixing Object Creation with Application Logic 181 | 182 | [Source](http://misko.hevery.com/2008/09/30/2008/07/08/how-to-think-about-the-new-operator/) 183 | 184 | ## Avoid creating technical debt. 185 | 186 | "Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. ... A little debt speeds development so long as it is paid back promptly with a rewrite ... *Every minute spent on not-quite-right code counts as interest on that [debt](http://en.wikipedia.org/wiki/Technical_debt 187 | ).* Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation ...” 188 | (Emphasis mine) 189 | 190 | [Source](http://c2.com/doc/oopsla92.html) 191 | 192 | 193 | ## Premature optimisation is the root of all evil 194 | 195 | "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." 196 | 197 | [Source](http://c2.com/cgi/wiki?PrematureOptimization) 198 | 199 | ## Plan, Plan, Plan. 200 | 201 | It is much cheaper to do it correctly the first time than to redo it later on. 202 | The sooner a problem is identified and fixed, the cheaper it is to do so. 203 | 204 | "The general who wins a battle makes many calculations in his temple before the battle is fought. The general who loses a battle makes but few calculations beforehand. Thus do many calculations lead to victory, 205 | and few calculations to defeat: how much more no calculation at all! It is by attention to this point that I can foresee who is likely to win or lose." 206 | 207 | #### "Plans are worthless, planning is invaluable."- Sir Winston Churchill 208 | 209 | For this to work, everyone involved has to listen, everyone has to be open, everyone has to be responsive. Or we could keep flailing away with the fucked up attitude that “it has to be this way” because the sacred project plan says it’s this way. Because that really is a lot of fun, isn’t it? 210 | 211 | ## Programming is also Teaching your team 212 | ... a team of mediocre, inexperienced coders who work together and write for the benefit of the team has the capability to become a great team, and they can take that learning approach to create other great teams. *It all comes down to whether the team sees its work as simply writing code... or writing with the goal of both code and learning*" 213 | (Emphasis mine) 214 | 215 | – Reginald Braithwaite 216 | 217 | [Source](http://www.theserverside.com/tt/articles/article.tss?l=ProgrammingisAlsoTeachingYourTeam) 218 | 219 | ### "The most important element of successful software development is learning." 220 | When the entire team meets a certain standard for competence, there is a very large learning surface exposed and the team is able to absorb more information. 221 | 222 | [Source](http://weblog.raganwald.com/2007/06/which-theory-first-evidence.html) 223 | 224 | ## "...there are lies, damned lies, and software development estimates." 225 | 226 | Software can only partially be designed in advance. ... requirements suffer from observation, that the act of building software causes the requirements to change. ...technical factors cannot be perfectly understood, that only the act of trying to build something with specific components will reveal all of the gotchas and who-knews associated with a chosen technology strategy. ...software design is an iterative process, starting with a best guess that is continually refined with experience. 227 | the normal case for software projects is that tasks are rarely completed exactly as estimated, but that as a project progresses, the aggregate variance from estimates falls. 228 | 229 | [Source](http://weblog.raganwald.com/2007/06/which-theory-first-evidence.html) 230 | 231 | Nobody likes to look stupid. If you’re a professional and someone puts you on the spot to answer “how long will this take?” it’s only human to want to provide an answer. Whether you call it professional pride or ego, it’s a powerful driver. 232 | Good IT workers really don’t like saying “I don’t know.” If they say it, they probably mean it. So stop pushing for a definitive answer when one doesn’t exist.It’s perfectly reasonable to want some sort of plan up front. I’m actually one of those funny types who believe up front planning is a necessity. So long as everyone understands an estimate is just that: an estimate. You learn as you go along and discover more detail. So you revise the estimate accordingly. 233 | 234 | [![The mess we're in](https://cloud.githubusercontent.com/assets/43438/4344401/0ddd5fc8-408f-11e4-8887-b0bfbce91dc7.png)](https://www.youtube.com/watch?v=lKXe3HUG2l4) 235 | 236 | – Joe Armstrong, author Erlang 237 | 238 | ## Your architecture should resemble your domain 239 | 240 | So what does the architecture of your application scream? When you look at the top level directory structure, and the source files in the highest level package; do they scream: health care system, or accounting system, or inventory management system? Or do they scream: rails, or spring/hibernate, or asp? 241 | 242 | Architectures should not be supplied by frameworks. Frameworks are tools to be used, not architectures to be conformed to. If your architecture is based on frameworks, then it cannot be based on your use cases. 243 | 244 | – Uncle Bob Martin, "Screaming Architecture" 245 | 246 | [Source](http://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Architecture.html) 247 | 248 | ## Follow the principles of X 249 | 250 | * Do not add new functionality unless you know of some real application that will require it. 251 | * It is as important to decide what a system is not as to decide what it is. Do not serve all the world's needs; rather, make the system extensible so that additional needs can be met in an upwardly compatible fashion. 252 | * The only thing worse than generalizing from one example is generalizing from no examples at all. 253 | * If a problem is not completely understood, it is probably best to provide no solution at all. 254 | * If you can get 90 percent of the desired effect for 10 percent of the work, use the simpler solution. (See also Worse is better.) 255 | * Isolate complexity as much as possible. 256 | * Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands. 257 | 258 | [Source](http://en.wikipedia.org/wiki/X_Window_System_protocols_and_architecture#Design_principles) 259 | 260 | 261 | ## Follow the principles of Unix 262 | 263 | "This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface" - Doug McIlroy, quoted in A Quarter Century of Unix [Salus]. Addison-Wesley. 1994. ISBN 0-201-54777-5. 264 | 265 | * Rule of Modularity: Write simple parts connected by clean interfaces. 266 | * Rule of Clarity: Clarity is better than cleverness. 267 | * Rule of Composition: Design programs to be connected to other programs. 268 | * Rule of Separation: Separate policy from mechanism; separate interfaces from engines. 269 | * Rule of Simplicity: Design for simplicity; add complexity only where you must. 270 | * Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do. 271 | * Rule of Transparency: Design for visibility to make inspection and debugging easier. 272 | * Rule of Robustness: Robustness is the child of transparency and simplicity. 273 | * Rule of Representation: Fold knowledge into data so program logic can be stupid and robust. 274 | * Rule of Least Surprise: In interface design, always do the least surprising thing. 275 | * Rule of Silence: When a program has nothing surprising to say, it should say nothing. 276 | * Rule of Repair: When you must fail, fail noisily and as soon as possible. 277 | * Rule of Economy: Programmer time is expensive; conserve it in preference to machine time. 278 | * Rule of Generation: Avoid hand-hacking; write programs to write programs when you can. 279 | * Rule of Optimization: Prototype before polishing. Get it working before you optimize it. 280 | * Rule of Diversity: Distrust all claims for “one true way”. 281 | * Rule of Extensibility: Design for the future, because it will be here sooner than you think. 282 | 283 | – Eric S. Raymond, "The Art of Unix Programming" 284 | 285 | [Source](http://www.catb.org/esr/writings/taoup/html/ch01s06.html) 286 | 287 | 288 | [![Bitdeli Badge](https://d2weczhvl823v0.cloudfront.net/timoxley/best-practices/trend.png)](https://bitdeli.com/free "Bitdeli Badge") 289 | 290 | -------------------------------------------------------------------------------- /README.fr.md: -------------------------------------------------------------------------------- 1 | # Bonnes pratiques de programmation - Tidbits 2 | ### Une liste de citations et paraphrases de développeurs à travers le web. 3 | 4 | Utilisez votre propre jugement sur leur application[.](http://www.reddit.com/r/programming/comments/1bcebh/programming_best_practices/c95y6la) 5 | 6 | * * * 7 | 8 | ## Ne jamais créer de grosses applications 9 | 10 | Le secret pour créer de grosses applications est de ne jamais en créer de grosses. Décomposez votre application en petites parties. Puis, assemblez celles qui peuvent être testées, de petite taille, sur votre grosse application. 11 | 12 | – Justin Meyer, auteur de JavaScript MVC 13 | 14 | [Source](http://bitovi.com/blog/2010/11/organizing-a-jquery-application.html) 15 | 16 | ## La qualité compte 17 | 18 | Quand j'entends "BALANCE JUSTE DU CODE QUI MARCHE" je pense à toutes ces applications que je n'utilise plus parce qu'elles ont progressivement perdu la capacité d'évoluer. 19 | 20 | – Avdi Grimm 21 | 22 | [Source](https://twitter.com/#!/avdi/status/180747721852985344) 23 | 24 | ## N'écrivez pas de code 25 | 26 | Ne pas écrire de code (n'en écrire que quand tout le reste a échoué) est l'unique leçon la plus importante que chaque développeur devrait apprendre. La quantité de code dupliqué, sale (à travers les projets) qui existe aujourd'hui est énorme. La plupart du temps les développeurs ne prennent même pas la peine de regarder autour d'eux. Ils veulent juste écrire du code. 27 | 28 | [Source](http://blogs.agilefaqs.com/2009/10/19/biggest-stinkers/) 29 | 30 | #### Réduire la quantité de code dans votre projet devrait être un objectif. 31 | 32 | "Je déteste le code, et je n'en veux que le moins possible dans notre produit." 33 | – Jack Diederich 34 | 35 | [Source](http://pyvideo.org/video/880/stop-writing-classes) 36 | 37 | #### Gardez de faibles dépendances 38 | Le vieil adage "ne réinventez pas la roue" ne s'applique pas quand la roue est livrée avec le moteur de locomotive. 39 | 40 | [Source](http://www.reddit.com/r/programming/comments/1bcebh/programming_best_practices/c9616mn) 41 | 42 | ## Arrêtez d'écrire des classes 43 | 44 | L'indication "ceci ne devrait pas être une classe" intervient lorsque la classe a deux méthodes, et que l'une d'elles est le constructeur. 45 | À chaque fois que vous voyez ces signes, vous devriez probablement simplement écrire une fonction. 46 | 47 | – Jack Diederich 48 | 49 | [Source](http://pyvideo.org/video/880/stop-writing-classes) 50 | 51 | ## Oubliez les nouvelles fonctionnalités, faîtes la même chose en mieux. 52 | 53 | Le problème : il est vite arrivé que l'on perde de vue ce à quoi les utilisateurs tiennent le plus, qui sont la facilité d'utilisation des applications et les fonctionnalités qu'ils utilisent déjà le plus souvent. 54 | 55 | – Tim Anderson 56 | 57 | [Source](http://www.itjoblog.co.uk/2011/06/making-better-software.html) 58 | 59 | ## Réinventez la roue 60 | Créer vos propres roues vous donne une profonde appréciation et compréhension de comment les roues "roulent" et ce qui fait une bonne roue. 61 | 62 | [Source](http://nodejs.debuggable.com/2011-02-26.txt) 63 | 64 | ## Ne faîtes pas de choses difficiles, faîtes-en des faciles. 65 | 66 | * Simple est mieux que complexe. 67 | * Complexe est mieux que compliqué. 68 | * Applati est mieux qu'imbriqué. 69 | * La lisibilité compte. 70 | * Si l'implémentation est dure à comprendre, c'est une mauvaise idée. 71 | * Si l'implémentation est facile à comprendre, ça peut être une bonne idée. 72 | 73 | – The Zen of Python 74 | 75 | [Source](http://www.python.org/dev/peps/pep-0020/) 76 | 77 | Présélection de la [présentation de Jack Diederich "Arrêtez d'écrire des classes"](http://pyvideo.org/video/880/stop-writing-classes) 78 | 79 | ## Réécrire > Factoriser 80 | Si vous changez plus de 25% de votre classe ou votre méthode, envisagez plutôt de la réécrire. Vous écrirez le code plus clairement. 81 | 82 | ## Factoriser > Réécrire 83 | 84 | #### Raisons fréquentes pour réécrire un logiciel 85 | 1. Le code est mauvais 86 | 2. "Nous sommes tellement plus intelligents à présent" 87 | 3. Nous avons choisi le/la mauvais(e) langage/plate-forme 88 | 89 | #### Pour la réécriture n'est (presque) jamais une bonne idée 90 | 1. [Ça prend plus de temps qu'on ne le croit](http://en.wikipedia.org/wiki/Hofstadter's_law) 91 | 2. Le marché évolue 92 | 2. Les clients existants deviennent frustrés 93 | 3. Factoriser peut nettoyer le code 94 | 4. Vous ne contrôlez pas la réécriture, c'est elle qui vous contrôle 95 | 96 | [Source](http://onstartups.com/tabid/3339/bid/2596/Why-You-Should-Almost-Never-Rewrite-Your-Software.aspx) 97 | 98 | 99 | ## Acceptez que vous n'avez aucune idée de comment cela va évoluer 100 | 101 | La clé est de reconnaître dès le début que vous n'avez aucune idée de comment cela va évoluer. Lorsque l'on accepte que l'on ne sait pas tout, on commence à concevoir le système sur la défensive... Il faudrait passer plus de temps à réfléchir aux interfaces plutôt qu'aux implémentations. 102 | 103 | – Nicholas Zakas, auteur de "High-performance JavaScript websites" 104 | 105 | [Source](http://radar.oreilly.com/2011/06/big-javascript-apps-teams.html) 106 | 107 | [Renvoi vers Addy Osmani](http://addyosmani.com/largescalejavascript/) 108 | 109 | ## Évitez le code sale 110 | 111 | [Source](http://www.codinghorror.com/blog/2006/05/code-smells.html) 112 | [Source](http://web.archive.org/web/20120130234037/http://stackoverflow.com/questions/114342/what-are-code-smells-what-is-the-best-way-to-correct-them) 113 | 114 | 115 | ## Écrivez des tests unitaires. 116 | 117 | Tous les programmeurs savent qu'ils devraient écrire des tests pour leur code. Peu le font. La réponse universelle à "Pourquoi pas ?" est "Je suis à la bourre." Cela devient rapidement un cercle vicieux -plus la pression augmente, moins on écrit de tests. Moins on écrit de tests, moins on est productif et moins stable devient notre code. Moins on est productif et précis, plus on a la pression. Les programmeurs s'épuisent dans de tels cycles. S'en sortir demande une aide extérieure. On trouve cette aide extérieure dont on a besoin dans un simple framework de test qui nous permet d'écrire un peu tests qui font un grande différence. 118 | 119 | [Source](http://junit.sourceforge.net/doc/testinfected/testing.htm) 120 | 121 | 122 | #### [Sans tests unitaires] Vous ne factorisez pas, vous remuez juste la merde. — Hamlet D'Arcy 123 | 124 | ## Pour écrire des tests unitaires efficaces, vous avez besoin d'écrire du code qui peut être testé 125 | 126 | ### Premier défaut : Le constructeur fait du vrai boulot 127 | #### Signaux d'avertissement 128 | * Nouveau mot clé dans un constructeur ou dans un champ de déclaration 129 | * Appels à une méthode statique dans un constructeur ou dans un champ de déclaration 130 | * N'importe quoi plus gros qu'un champ d'assignement dans les constructeurs 131 | * Un objet avec initialisation incomplète après que le constructeur ait fini (faîtes attention aux méthodes d'initialisation) 132 | * Flux de contrôle (logique conditionnelle ou boucle) dans un constructeur 133 | * Le code fait un graphe de construction d'objet complexe à l'intérieur du constructeur plutôt qu'utiliser une fabrique ou un monteur 134 | * Ajouter ou utiliser un bloc d'initialisation 135 | 136 | ### Deuxième défaut : Creuser dans les collaborateurs 137 | #### Signaux d'avertissement 138 | * Les objets sont transmis mais jamais utilisés directement (utilisés seulement pour accéder à d'autres objets) 139 | * Violation de la loi de Déméter : la chaîne d'appel de méthode crée un graphe d'objet avec plus d'un point (.) 140 | * Noms suspects : contexte, environnement, principal, conteneur ou gestionnaire *(voir leur traduction anglaise)* 141 | 142 | ### Troisième défaut : État global et singleton fragiles 143 | #### Signaux d'avertissement 144 | * Ajouter ou utiliser des singletons 145 | * Ajouter ou utiliser des champs statiques ou des méthodes statiques 146 | * Ajouter ou utiliser des blocs d'initialisation statiques 147 | * Ajouter ou utiliser des registres 148 | * Ajouter ou utiliser des repères de service 149 | 150 | ### Quatrième défaut : Les classes en font trop 151 | #### Signaux d'avertissement 152 | * Résumer ce que la classe fait en incluant le mot "et" 153 | * La classe est difficile à lire et à comprendre rapidement pour les nouveaux membres de l'équipe 154 | * La classe a des champs qui ne sont utilisés que dans certaines méthodes 155 | * La classe a des méthodes statiques qui ne fonctionnent qu'avec des paramètres 156 | 157 | [Source](http://misko.hevery.com/code-reviewers-guide/) 158 | 159 | [Source](http://misko.hevery.com/presentations/) 160 | 161 | ## Développement piloté par les tests avec Inversion de contrôle. 162 | 163 | Même si vous ne testez pas votre code, vous devez écrire du code capable d'être testé. L'Inversion de contrôle permet d'écrire du code testable. Injectez des dépendances favorables aux tests ou des objets factices durant la période de test, pour isoler les parties en cours de test. 164 | 165 | ## Évitez de mélanger la création d'objet avec la logique de l'application 166 | 167 | [Source](http://misko.hevery.com/2008/09/30/2008/07/08/how-to-think-about-the-new-operator/) 168 | 169 | ## Éviter de créer une dette technique. 170 | 171 | Bien que du code immature puisse fonctionner et être parfaitement acceptable pour le client, en abuser rendra un programme incontrôlable. ... Une petite dette accélère le développement jusqu'à ce qu'elle doive être rapidement remboursée par une réécriture ... *Chaque minute passée sur du code "pas tout à fait correct" s'ajoute aux intérêt de cette [dette](http://en.wikipedia.org/wiki/Technical_debt).* Des organisations d'ingénieurie toutes entières peuvent être bloquées sous le poids d'une dette d'implémentation non consolidée. ..." (Souligné par l'auteur) 172 | 173 | [Source](http://c2.com/doc/oopsla92.html) 174 | 175 | 176 | ## Une optimisation prématurée est la racine du mal 177 | 178 | "Les programmeurs perdent énormément de temps à réfléchir ou à se préoccuper de la rapidité de parties non critiques de leurs programmes, et ces tentatives d'efficacité ont en réalité un impact très négatif lorsque le debug et la maintenance sont pris en compte. Nous devrions abandonner les petites améliorations environ 97% du temps : une optimisation prématurée est la racine du mal. Encore faut-il ne pas laisser filer l'opportunité dans les 3% critiques." 179 | 180 | [Source](http://c2.com/cgi/wiki?PrematureOptimization) 181 | 182 | ## Planifiez, planifiez, planifiez. 183 | 184 | Il est moins coûteux de faire correctement la première fois que le refaire plus tard. 185 | Plus tôt un problème est identifié et corrigé, moins il sera nécessaire de s'investir dessus. 186 | 187 | "Que chacun se représente les évaluations faites dans le temple, avant les hostilités, comme des mesures : elles disent la victoire lorsqu'elles démontrent que votre force est supérieure à celle de l'ennemi; elles indiquent la défaite lrsqu'elles démontrent qu'il est inférieur en force. Considérez qu'avec de nombreux calculs on peut remporter la victoire, redoutez leur insuffisance. Combien celui n'en fait point a peu de chances de gagner ! C'est grâce à cette méthode que j'examine la situation, et l'issue apparaîtra clairement." (*The Art of War* by Sun Tzu) 188 | 189 | #### "Les plans sont sans valeur, la préparation est inestimable."- Sir Winston Churchill 190 | 191 | Pour que cela marche, toutes les personnes concernées doivent écouter, tout le monde doit être ouvert et réactif. Ou nous pouvons continuer à aller dans le mur en nous répétant "ça doit être comme ça" parce que le plan *sacré* du projet dit que c'est ainsi. Parce que c'est vraiment éclatant, n'est-ce pas ? 192 | 193 | ## La programmation c'est aussi apprendre à votre équipe 194 | ... Une équipe de développeurs incompétents, inexpérimentés qui travaillent ensemble et écrivent pour le bien de l'équipe, a la capacité de devenir une grande équipe et ils peuvent itiliser cette méthode d'apprentissage pour créer d'autres bonnes équipes. *Cela résulte du fait que l'équipe voir son travail grâce à une simple écriture de code... Ou bien avec l'objectif du code et de lapprentissage*" 195 | (Souligné par l'auteur) 196 | 197 | – Reginald Braithwaite 198 | 199 | [Source](http://www.theserverside.com/tt/articles/article.tss?l=ProgrammingisAlsoTeachingYourTeam) 200 | 201 | ### "L'élément le plus important dans la réussite du développement d'un programme est l'apprentissage" 202 | Quand l'équipe toute entière rencontre un certain standard de compétence, alors apparait une très grande surface d'apprentissage et l'équipe est capable d'absorber plus d'informations. 203 | 204 | [Source](http://weblog.raganwald.com/2007/06/which-theory-first-evidence.html) 205 | 206 | ## "...il y a des mensonges, de lourds mensonges et des estimations de développement de logiciel." 207 | 208 | Un logiciel ne peut être conçu à l'avance que partiellement. ... Les besoins souffrent de l'observation que le fait de créer le logiciel les amènent à changer. ...Les facteurs techniques ne peuvent pas être parfaitement compris, c'est seulement en essayant de créer quelque chose avec des composants spécifiques que l'ont découvre tous les défauts imprévus associés à une stratégie technique définie. ...la conception de logiciel est un processus itératif, commençant par une meilleure déduction possible qui est ensuite constamment affinée avec l'expérience. Le cas normal pour des projets logiciels est les tâches s'effectuent rarement telles qu'elles le devaient, mais au fur et à mesure que le projet avance, le total de variations des estimations s'amenuise. 209 | 210 | [Source](http://weblog.raganwald.com/2007/06/which-theory-first-evidence.html) 211 | 212 | Personne n'aime avoir l'air idiot. Si vous êtes un professionnel et que quelqu'un vous met dans l'embarras en vous demandant "combien de temps ça prendra ?", c'est humain de vouloir être capable de répondre. Que vous appeliez cela de la fierté professionnelle ou de l'égo, c'est un puissant conducteur. 213 | Les informaticiens talentueux n'aiment vraiment pas dire "je ne sais pas". S'ils le disent, ils le pensent très certainement. Alors arrêtez d'exiger une réponse définitive lorsqu'il n'en existe pas. C'est tout à fait raisonnable de vouloir un plan de départ. En réalité je suis moi-même un de ces types qui pensent qu'un plan de départ est nécessaire. Tant que tout le monde comprend ce que représente une estimation : une estimation. Vous apprendrez au fur et à mesure et découvrirez davantage de détails. Vous pourrez alors corriger l'estimation en fonction. 214 | 215 | 216 | ## Votre architecture doit ressembler à votre domaine 217 | 218 | Qu'est-ce que l'architecture de votre application vous crie ? Lorsque vous regardez la structure du dossier le plus haut, et les fichiers sources dans le package le plus haut; est-ce qu'ils vous crient système de santé, ou système comptable, ou système de gestion d'inventaire ? Ou crient-ils rails, ou spring/hibernate, ou asp ? 219 | 220 | Les architectures ne doivent pas être fournies par les frameworks. Les frameworks sont des outils à utiliser, pas des architectures auxquelles se conformer. Si votre architecture est basée sur des frameworks, alors elle ne peut pas être basée sur votre cas d'utilisation. 221 | 222 | – Uncle Bob Martin, "Screaming Architecture" 223 | 224 | [Source](http://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Architecture.html) 225 | 226 | ## Suivez le principe de X 227 | 228 | * N'ajoutez pas de nouvelle fonctionnalité à moins que vous connaissiez une vraie application qui en aura besoin. 229 | * Il est tout aussi important de décider de ce qu'un système n'est pas que de décider de ce qu'il est. Ne répondez pas aux besoins de la terre entière; plutôt, faîtes un système souple pouvant accueillir des besoins additionnels en toute compatibilité. 230 | * La seule chose pire que la généralisation depuis un seul exemple est la généralisation depuis aucun exemple du tout. 231 | * Si un problème n'est pas totalement compris, il vaudrait probablement mieux ne pas lui fournir de solution du tout. 232 | * Si vous pouvez obtenir 90% des effets désirés avec 10% de travail, utilisez la solution la plus simple. (Voir aussi *Le pire est mieux.*) 233 | * Isolez le plus possible la complexité. 234 | * Fournissez des mécanismes plutôt des politiques. En particulier, déléguez au client la politique d'interface. 235 | 236 | [Source](http://en.wikipedia.org/wiki/X_Window_System_protocols_and_architecture#Design_principles) 237 | 238 | 239 | ## Suivez les principes d'Unix 240 | 241 | "Voici la philosophie d'Unix : écrire des programmes qui font une chose correctement. Écrire des programmes qui fonctionnent ensemble. Écrire des programmes qui gèrent des flux de texte, parce que c'est une interface universelle" - Citation de Doug McIlroy dans Un Quart de Siècle d'Unix [Salus]. Addison-Wesley. 1994. ISBN 0-201-54777-5. 242 | 243 | * Règle de la Modularité : écrire des parties simples connectées par des interfaces propres. 244 | * Règle de la Clarté : la clarté est meilleure que l'intelligence. 245 | * Règle de la Composition : concevoir des programmes pouvant être connectés à d'autres programmes. 246 | * Règle de la Séparation : séparer la politique du méchanisme; séparer les interfaces des moteurs. 247 | * Règle de a Simplicité : concevoir pour la simplicité; ajouter de la complexité seulement où il le faut. 248 | * Règle de la Parsimonie : écrire un gros programme seulement quand il est prouvé que rien d'autre ne sera fait. 249 | * Règle de la Transparence : concevoir pour la visibilité et ainsi rendre l'inspection et le debug plus aisés. 250 | * Règle de la Robusticité : la robusticité est l'enfant de la transparence et de la simplicité. 251 | * Règle de la Représentation : inclure la connaissance dans les données pour que la logique du programme puissent être bête et robuste. 252 | * Règle de la Surprise : dans la conception d'interface, toujours faire le moins surprenant possible. 253 | * Règle du Silence : quand un programme n'a rien d'intéressant à dire, il devrait ne rien dire du tout. 254 | * Règle de la Réparation : lorsque vous devez échouer, échouez bruyamment et aussi vite que possible. 255 | * Règle de l'Économie : le temps d'un programmeur vaut cher, le transformer de préférence en temps machine. 256 | * Règle de la Génération : éviter le *fait à la main*, écrire les programmes pour écrire des programmes dès que possible. 257 | * Règle de l'Optimisation : prototyper avant de polir. Faire marcher avant d'optimiser. 258 | * Règle de la Diversité : détruire toutes les reventications de "une seule vraie façon de faire". 259 | * Règle de l'Extensibilité : concevoir pour le futur, parce que ça arrivera plus vite qu'on ne le pense. 260 | 261 | – Eric S. Raymond, "L'Art de la Programmation Unix" 262 | 263 | [Source](http://www.catb.org/esr/writings/taoup/html/ch01s06.html) 264 | -------------------------------------------------------------------------------- /README.es.md: -------------------------------------------------------------------------------- 1 | # Mejores Prácticas de la Programación - Tidbits 2 | ### Una colección de citas y frases obtenidos de la web para programadores 3 | 4 | Utilice su propio juicio en su aplicación. 5 | 6 | * * * 7 | 8 | ## Nunca construyas aplicaciones grandes 9 | 10 | El secreto para construir aplicaciones grandes es nunca construir aplicaciones grandes. Divide tus aplicaciones en piezas más pequeñas. Entonces, ensambla esas piezas del tamaño de un mordizco que pueden ponerse a prueba, dentro de tu aplicación grande. 11 | 12 | *Justin Meyer, autor de JavaScriptMVC*. 13 | 14 | [Fuente](http://bitovi.com/blog/2010/11/organizing-a-jquery-application.html). 15 | 16 | ## La calidad importa 17 | 18 | Cuando escucho "¡SÓLO LIBERA DE UNA VEZ EL CÓDIGO QUE YA FUNCIONA!" pienso en todas las aplicaciones que dejé de usar porque gradualmente perdieron la habilidad de iterar. 19 | 20 | *Avdi Grimm* 21 | 22 | [Fuente](https://twitter.com/#!/avdi/status/180747721852985344). 23 | 24 | ## No escribas código 25 | 26 | No escribas código (escribe nuevo código solamente cuando todo lo demás falle) es la lección más importante que todo desarrollador debería aprender. La cantidad de código duplicado y basura que existe (en todos los proyectos) es abrumadora. En muchos casos los desarrolladores ni se molestan en echar un vistazo. Lo único que quieren es escribir código. 27 | 28 | [Fuente](http://blogs.agilefaqs.com/2009/10/19/biggest-stinkers) 29 | 30 | #### Reducir la cantidad de código en tu producto debería ser una meta 31 | 32 | "Odio el código, y quiero tan poco código como sea posible en nuestro producto." 33 | 34 | *Jack Diederich* 35 | 36 | [Fuente](http://pyvideo.org/video/880/stop-writing-classes) 37 | 38 | #### Mantén las dependencias al mínimo 39 | 40 | El viejo dicho "No reinventes la rueda" no aplica cuando la rueda es del motor de una locomotora. 41 | 42 | [Fuente](http://www.reddit.com/r/programming/comments/1bcebh/programming_best_practices/c9616mn) 43 | 44 | ## Deja de escribir clases 45 | 46 | La señal de que "esto no debería ser una clase" es cuando la clase tiene dos métodos, y uno de ellos es el constructor. Cuando quiera que veas estas señales, significa que probablemente deberías haber escrito sólo una función. 47 | 48 | *Jack Diederich* 49 | 50 | [Fuente](http://pyvideo.org/video/880/stop-writing-classes) 51 | 52 | ## Olvida nuevas funcionalidades, simplemente haz lo mismo pero mejor 53 | 54 | El problema: es muy fácil perder de vista lo que más importa a los usuarios, que es el rendimiento y la usabilidad de las aplicaciones y las funcionalidades que usan más a menudo. 55 | 56 | *Tim Anderson* 57 | 58 | [Fuente](http://www.itjoblog.co.uk/2011/06/making-better-software.html) 59 | 60 | ## Reinventa la rueda 61 | 62 | Inventar tus propias ruedas te da un mayor aprecio y entendimiento de cómo funcionan las ruedas y qué hace que una sea buena. 63 | 64 | [Fuente](http://nodejs.debuggable.com/2011-02-26.txt) 65 | 66 | ## No hagas cosas difíciles, haz cosas sencillas 67 | 68 | * Simple es mejor que complejo. 69 | * Complejo es mejor que complicado. 70 | * Plano es mejor que anidado. 71 | * La legibilidad cuenta. 72 | * Si la implementación es difícil de explicar, es una mala idea. 73 | * Si la implementación es fácil de explicar, puede que sea una buena idea. 74 | 75 | *El Zen de Python* 76 | 77 | [Fuente](http://www.python.org/dev/peps/pep-0020/) 78 | 79 | ## Reescribir > Refactorizar 80 | 81 | Si vas a cambiar más del 25% de una clase o método, considera simplemente reescribirlo. Escribirás código más limpio. 82 | 83 | ## Refactorizar > Reescribir 84 | 85 | #### Excusas comunes para reescribir software 86 | 87 | 1. El código apesta 88 | 2. "Ahora somos mucho más listos" 89 | 3. Escogimos la plataforma y/o lenguaje equivocado 90 | 91 | #### Por qué (casi) nunca es buena idea reescribir 92 | 93 | 1. [Tardará más de lo que piensas](http://en.wikipedia.org/wiki/Hofstadter's_law) 94 | 2. Los mercados cambian 95 | 2. Los clientes existentes se frustran 96 | 3. Puedes limpiar el código refactorizando 97 | 4. No controlas la reescritura, ella te controla a ti 98 | 99 | [Fuente](http://onstartups.com/tabid/3339/bid/2596/Why-You-Should-Almost-Never-Rewrite-Your-Software.aspx) 100 | 101 | ## Acepta que no tienes idea de cómo esto va a crecer 102 | 103 | La clave es reconocer desde el principio que no tienes idea de cómo esto va a crecer. Cuando aceptes que no lo sabes todo, empezarás a diseñar el sistema defensivamente... Deberías invertir la mayor parte de tu tiempo en pensando en interfaces en vez de implementaciones. 104 | 105 | *Nicholas Zakas, autor de "High-performance JavaScript websites"* 106 | 107 | [Fuente](http://radar.oreilly.com/2011/06/big-javascript-apps-teams.html) 108 | 109 | [Reconocimiento a Addy Osmani](http://addyosmani.com/largescalejavascript/) 110 | 111 | ## Evita código que apesta 112 | 113 | [Fuente](http://www.codinghorror.com/blog/2006/05/code-smells.html) 114 | 115 | [Fuente](http://web.archive.org/web/20120130234037/http://stackoverflow.com/questions/114342/what-are-code-smells-what-is-the-best-way-to-correct-them) 116 | 117 | ## Escribe pruebas unitarias 118 | 119 | Todo programador sabe que debería escribir tests para su código. Pocos lo hacen. La respuesta universal al "¿Por qué no?" es "Tengo mucha prisa." Rápidamente esto se convierte en un círculo vicioso. Cuanta más presión sientas, menos pruebas escribirás. Entre menos pruebas escribas, serás menos productivo y tu código se volverá menos estable. Entre menos productivo seas, mayor presión sentirás. Los programadores se desgastan con esos ciclos. Romperlos requiere de una influencia externa. Encontramos esa influencia externa en un simple framework de pruebas que nos deja hacer pequeñas pruebas que hacen una gran diferencia. 120 | 121 | [Fuente](http://junit.sourceforge.net/doc/testinfected/testing.htm) 122 | 123 | #### [Sin las pruebas unitarias] no estás refactorizando, sólo estás cambiando porquería. — Hamlet D'Arcy 124 | 125 | ## Para escribir pruebas unitarias efectivas, debes escribir código que se pueda probar 126 | 127 | ### Falla #1: El constructor hace trabajo real 128 | #### Señales de alerta 129 | 130 | * Existe `new` en un constructor o en la declaración de un atributo. 131 | * Static method calls in a constructor or at field declaration 132 | * Se hace algo más que solo asignar en los constructores. 133 | * El objeto no esta completamente inicializado cuando el constructor termina (cuidado con los métodos 'para inicializar') 134 | * Control de flujo en un constructor (existe un condicional o un bucle) 135 | * Code does complex object graph construction inside a constructor rather than using a factory or builder 136 | * Adding or using an initialization block 137 | 138 | ### Falla #2: Digging into Collaborators 139 | #### Señales de alerta 140 | 141 | * Objects are passed in but never used directly (only used to get access to other objects) 142 | * Law of Demeter violation: method call chain walks an object graph with more than one dot (.) 143 | * Suspicious names: context, environment, principal, container, or manager 144 | 145 | ### Falla #3: Brittle Global State & Singletons 146 | #### Señales de alerta 147 | 148 | * Adding or using singletons 149 | * Adding or using static fields or static methods 150 | * Adding or using static initialization blocks 151 | * Adding or using registries 152 | * Adding or using service locators 153 | 154 | ###Falla #4: La clase hace demasiado 155 | #### Señales de alerta 156 | 157 | * Al resumir lo que hace la clase se incluye el conector "y". 158 | * La clase sería difícil de leer y captar para nuevos miembros del equipo. 159 | * La clase tiene atributos que son utilizados sólo en algunos métodos. 160 | * La clase tiene métodos estáticos que sólo operan sobre párametros 161 | 162 | [Fuente](http://misko.hevery.com/code-reviewers-guide/) 163 | 164 | [Fuente](http://misko.hevery.com/presentations/) 165 | 166 | ## Desarrollo guiado por pruebas con Inversión de Control 167 | 168 | Incluso si no estás probando tu código, deberías escribir código que pueda probarse. IoC permite código "testeable". Inyecta dependencias que faciliten las pruebas o "mocks" al tiempo de probar a fin de aislar la unidad bajo prueba. 169 | 170 | ## Evita mezclar la creación de objetos con la lógica de aplicación 171 | 172 | [Fuente](http://misko.hevery.com/2008/09/30/2008/07/08/how-to-think-about-the-new-operator/) 173 | 174 | ## Evita crear deuda técnica 175 | 176 | "Aunque el código inmaduro funcione bien y sea totalmente aceptable al cliente, cantidades excesivas del mismo harán que un programa sea indomable, conduciendo a programadores extremadamente especializados y, finalmente, a un producto inflexible. [...] Un poco de deuda acelera el desarrollo siempre y cuando se pague prontamente con una reescritura. [...] *Cada minuto que se gasta en código no muy bien escrito cuenta como interés en esa [deuda](http://en.wikipedia.org/wiki/Technical_debt)*. Organizaciones enteras de ingeniería pueden detenerse bajo la deuda de implementación sin consolidar" 177 | (Cursivas mías) 178 | 179 | [Fuente](http://c2.com/doc/oopsla92.html) 180 | 181 | ## La optimización prematura es la raíz de todos los males 182 | 183 | "Los programadores desperdician mucha cantidad de tiempo pensando o preocupándose sobre el rendimiento de partes del programa que no son críticas y estos intentos realmente tienen un poderoso impacto negativo cuando consideramos el mantenimiento y la depuración. Deberíamos olvidarnos de las pequenas optimizaciones, digamos el 97% del tiempo: la optimización prematura es la raíz de todos los males" 184 | 185 | [Fuente](http://c2.com/cgi/wiki?PrematureOptimization) 186 | 187 | ## Planifica, Planifica, Planifica 188 | 189 | Es mucho más barato hacerlo correctamente la primera vez que rehacerlo posteriormente. Mientras más pronto se identifica y soluciona un problema, es más barato hacerlo. 190 | 191 | "El general que gana una batalla hace muchos cálculos en su templo antes del fragor la batalla. 

El general que pierde una batalla hace pocos cálculos con antelación. Hacer muchos cálculos lleva a la victoria y pocos cálculos a la derrota: ¡cuánto más ningún cálculo en absoluto! Por dar atención a este punto yo puedo preveer quien es probable que gane o pierda" 192 | 193 | #### "Los planes son inútiles, pero la planificación lo es todo" - Sir Winston Churchill 194 | 195 | For this to work, everyone involved has to listen, everyone has to be open, everyone has to be responsive. Or we could keep flailing away with the fucked up attitude that “it has to be this way” because the sacred project plan says it’s this way. Because that really is a lot of fun, isn’t it? 196 | 197 | ## Programar también envuelve enseñar a tu equipo 198 | 199 | ... un equipo de programadores mediocres, sin experiencia que trabajan juntos y escriben para el beneficio del equipo tiene la capacidad de convertirse en un gran equipo, y pueden tomar este enfoque para crear otros grandes equipos. *Todo se resume en si el eqiupo ve su trabajo como sólo escribir código, o escribir con el objetivo de tanto codificar como aprender*" 200 | (Cursivas mías) 201 | 202 | *Reginald Braithwaite* 203 | 204 | [Fuente](http://www.theserverside.com/tt/articles/article.tss?l=ProgrammingisAlsoTeachingYourTeam) 205 | 206 | ### "El elemento más importante del desarrollo de software con éxito es aprender" 207 | 208 | Cuando todo el equipo alcanza un cierto nivel de competencia, existe una superficie expuesta de aprendizaje muy grande y el equipo es capaz de absorber más información. 209 | 210 | [Fuente](http://weblog.raganwald.com/2007/06/which-theory-first-evidence.html) 211 | 212 | ## "...hay mentiras, mentiras descaradas, y estimaciones de desarrollo de software" 213 | 214 | Software can only partially be designed in advance. ... requirements suffer from observation, that the act of building software causes the requirements to change. ...technical factors cannot be perfectly understood, that only the act of trying to build something with specific components will reveal all of the gotchas and who-knews associated with a chosen technology strategy. ...software design is an iterative process, starting with a best guess that is continually refined with experience. 215 | the normal case for software projects is that tasks are rarely completed exactly as estimated, but that as a project progresses, the aggregate variance from estimates falls. 216 | 217 | [Fuente](http://weblog.raganwald.com/2007/06/which-theory-first-evidence.html) 218 | 219 | Nobody likes to look stupid. If you’re a professional and someone puts you on the spot to answer “how long will this take?” it’s only human to want to provide an answer. Whether you call it professional pride or ego, it’s a powerful driver. 220 | Good IT workers really don’t like saying “I don’t know.” If they say it, they probably mean it. So stop pushing for a definitive answer when one doesn’t exist.It’s perfectly reasonable to want some sort of plan up front. I’m actually one of those funny types who believe up front planning is a necessity. So long as everyone understands an estimate is just that: an estimate. You learn as you go along and discover more detail. So you revise the estimate accordingly. 221 | 222 | [![The mess we're in](https://cloud.githubusercontent.com/assets/43438/4344401/0ddd5fc8-408f-11e4-8887-b0bfbce91dc7.png)](https://www.youtube.com/watch?v=lKXe3HUG2l4) 223 | 224 | *Joe Armstrong, autor de Erlang* 225 | 226 | ##Your architecture should resemble your domain 227 | 228 | So what does the architecture of your application scream? When you look at the top level directory structure, and the source files in the highest level package; do they scream: health care system, or accounting system, or inventory management system? Or do they scream: rails, or spring/hibernate, or asp? 229 | 230 | La arquitectura no debería ser dada por el framework. Los frameworks son herramientas para utilizarlas, no arquitecturas a las que haya que conformarse. Si tu arquitectua está basada en frameworks, entonces no puede estar basado en tus casos de uso. 231 | 232 | *Uncle Bob Martin, "Screaming Architecture"* 233 | 234 | [Fuente](http://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Architecture.html) 235 | 236 | ## Sigue los principios de X 237 | 238 | * No añadir nueva funcionalidad a menos que un desarrollador no pueda completar una aplicación real sin ella. 239 | * Es tan importante decidir qué no es parte del sistema, como decidir que sí lo es. No respondas a las necesidades de todo el mundo; en lugar de eso, haz el sistema extensible para que las necesidades adicionales puedan cubrirse de una manera compatible ascendente. 240 | * La única cosa peor que generalizar a partir de un ejemplo, es generalizar a partir de ningún ejemplo. 241 | * Si un problema no es comprendido completamente, probablemente es mejor no proporcionar ninguna solución. 242 | * Si puedes conseguir el 90 por ciento del efecto deseado para el 10 por ciento del trabajo, utiliza la solución más simple. 243 | * Aísla la complejidad tanto como sea posible. 244 | * Proporcionen un mecanismo en vez de una política. En particular, pongan la interfaz de política en las manos de los clientes. 245 | 246 | [Fuente](http://en.wikipedia.org/wiki/X_Window_System_protocols_and_architecture#Design_principles) 247 | 248 | ## Sigue los principios de Unix 249 | 250 | "Esta es la filosofía de Unix: escribe programas que hagan una sola cosa y la hagan bien. Escribe programas para trabajar colectivamente. Escribe programas para manejar flujos de texto, porque esta es una interfaz universal." 251 | 252 | *Doug McIlroy, citado en "A Quarter Century of Unix" [Salus]. Addison-Wesley. 1994. ISBN 0-201-54777-5.* 253 | 254 | * Regla de Modularidad: Escribe partes simples conectadas por interfaces limpias. 255 | * Regla de Claridad: La claridad es mejor que la habilidad y el ingenio. 256 | * Regla de Composición: Diseña programas para ser conectados a otros programas. 257 | * Regla de Separación: Separa la política del mecanismo; separa las interfaces de los motores. 258 | * Regla de Simplicidad: Diseña pensando en la simplicidad; agrega complejidad solamente donde debas. 259 | * Regla de Parsimonía: Escribe un programa grande solamente cuando es claro por demostración que ninguna otra cosa funcionará. 260 | * Regla de Transparencia: Diseña pensando en la visibilidad para hacer la inspección y la depuración más fácil. 261 | * Regla de Robustez: La robustez es la hija de la transparencia y la simplicidad. 262 | * Regla de Representación: Pliega el conocimiento dentro de los datos de tal manera que la lógica del programa pueda ser estúpida y robusta. 263 | * Regla de la Mínima Sorpresa: En el diseño de interfaces, siempre has la cosa menos sorprendente. 264 | * Regla del Silencio: Cuando un programa no tiene nada sorprendente que decir, no debería decir nada. 265 | * Regla de Reparación: Cuando debas fallar, falla ruidosamente y tan pronto como sea posible. 266 | * Regla de Economía: El tiempo del programador es costoso; consérvalo en preferencia al tiempo de máquina. 267 | * Regla de Generación: Evita el hackeo manual; escribe programas para escribir programas cuando puedas. 268 | * Regla de Optimización: Haz prototipos antes de pulir. Haz que funcione antes que lo optimices. 269 | * Regla de Diversidad: Desconfía de todas las pretensiones para "una vía verdadera". 270 | * Regla de Extensibilidad: Diseña para el futuro, porque estará aquí más pronto de lo que piensas. 271 | 272 | *Eric S. Raymond, "The Art of Unix Programming"* 273 | 274 | [Fuente](http://www.catb.org/esr/writings/taoup/html/ch01s06.html) 275 | 276 | [![Bitdeli Badge](https://d2weczhvl823v0.cloudfront.net/timoxley/best-practices/trend.png)](https://bitdeli.com/free "Bitdeli Badge") 277 | --------------------------------------------------------------------------------