Fica aqui a cheat sheet que usavamos na
finsolutia, muitos destas más praticas/padrões não são usuais ... mas outros são pão nosso de cada dia :)
1) Principles of programming
| | Description | Prefer |
| FBR | Fast Beats Right | More important to deploy something that appears to work, than to spend time ensuring "correctness" | "Continuous attention to technical excellence and good design enhances agility" - Agile Manifesto |
| FCD | Feeping Creaturitis Driven | Just when the end is in sight, someone adds just one more feature they are desperately in love with | "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to a shorter timescale." - Agile Manifesto |
| ADP | Assumption Driven Programming | Assume the user will only use your software the way you mean for them to. | Practice defensive coding. Watch how users attempt to use the software.
Treat handling the unexpected like any other feature. |
| TP | Telemarketer Principle | The best way to retain control of what your code does is to manage exactly which objects it uses and what calls it makes at all time. | The Dependency Inversion Principle can be used to correct this kind of code. |
2) Anti-Patterns
| | Description | Prefer |
| SCP | Static Cling Pattern | The easiest way to add functionality or track state is via static/global methods and objects. The Singleton Pattern is also your best friend! | Dependency Inversion Principle. Your code should depend on interfaces, not static calls which cannot be injected. Static methods are death to testable code. |
| VSP | Vestigial Structure Pattern | Don't remove code that's no longer used just in case it's needed later! If you're really brave, comment the code but leave it in there. | VSP is often a symptom of a muddled architecture, where it is difficult to tell where one feature begins and another ends. |
| FOO | Flags Over Objects | Instead of using objects, polymorphism, or delegation, it's much faster to just add a flag to a class and expose it. Who needs inheritance? | Instead of checking a flag before performing and action, tell the object what to do and let it polymorphically do so. |
| TGC | The God Class | Strive to create one class to rule them all, a master class, capable of doing anything and everything your application might require. | Follow the Single Responsibility Principle |
3) Worst Practices
| | Description | Prefer |
| FOI | Found on Internet | Search engines these days are smart; obviously the first blog post found that appears to solve the issue at hand must be the best approach based on our collective wisdom. Get it to compile and move on. | Write a spike solution to ensure you understand the code. Or be sure to write some tests that confirm the code behaves as you expect. Review other approaches - are you asking the right questions? |
| PO | Premature Optimization | All code written should be optimized for performance, even if the resulting design is less clear or elegant, or if the code is question is nowhere near the critical path for the application. | Define performance requirements. Write tests that validate these requirements are being met. Do not optimize unless these tests fails. Identify bottlenecks don't blindly make "fixes". |
| CPC | Copy-Paste-Compile | The feature you're working on is nearly identical to one already in the system. Just copy, paste, and get the code to compile and you're done! | Keep your application code DRY. Refactor common code into shared modules when it makes sense to do so (avoid introducing excessive coupling). |
| CFV | Copy Folder Versioning | When really big changes are imminent, there's nothing like creating a copy of the current code folder to reassure you that you can always roll back. | Use source control |
| GH | Golden Hammer | Your favorite language, framework, library, or tool can do anything! wield it with confidence, and ignore anybody who tells you another tool might be better suited. | Become familiar with a variety of languages, tools, and frameworks. Keep an open mind as you approach problems. |
| ST | Shiny Toy | Did you hear about the latest beta (tool/language/framework)? I'm sure it will solve all of our application's problems. | Prefer existing and well-known tools and patterns to unproven ones for production use. |
| RTW | Reinvent The Wheel | We can build it better ourselves. No matter what "it" is. We don't trust anything that was Not Invented Here. | Know and use your application framework (e.g. the .NET framework). Share knowledge within your organization. Learn to make reasonable build vs. buy decisions when appropriate. |
4) The Big Ball of Mud / Quagmires
| | Description |
| BBM | The Big Ball of Mud / Quagmires | Spaghetti code jungle. The overall structure of the system may never have been well defined.
Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.
These systems show unmistakable signs of unregulated growth, and repeated, expedient repair |
|
| | Description | Prefer |
| TC | Throwaway Code | Taking the time to write a proper, well thought out, well documented program might take more time that is available to solve a problem, or more time that the problem merits | The real problem with THROWAWAY CODE comes when it isn't thrown away. |
| SUR | Sweeping it Under the Rug | If you can't make a mess go away, ate least you can hide it. | Clean up messy code. There is a limit to how much chaos an individual can tolerate before being overwhelmed. |
| TR | Total Rewrite | Your code has declined to the point where it is beyond repair, or even comprehension. | Therefore, throw it away and start over. Doing a fresh draft is a way to overcome neglect. Issues are revisited. A fresh draft adds vigor. You draw back to leap. The quagmire vanishes. The swamp is drained. |
