Inom TurdikulovProgramming principles and design patterns
List of programming principles aviable at Wikipedia 1.
DRY
Don’t Repeat Youself. Avoid writing the same code in multiple places.
This principle make your code more maintainable when you need to change it.
Why repeating code is bad or can be bad?
- If you need to change it, you have to change it in multiple places.
- If you forget to change it in one place, you’ll have a new bug.
- It’s more work to write it over and over again and maintain it.
KISS:
YAGNI:
SOLID
Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation,
Dependency Inversion.
Programming principles are required to write “good code”. If you follow them usually you receive good codebase which can be easily maintained and extended.
High-level principles:
- Gathering problems and requirements is first step, and it’s important.
- Architecture planning and discussion required to make decisions and deeply understand the problem.
- Need to write maintainable code for people, DRY, KISS, YAGNI, need to avoid neurosis and excessive perfectionism.
- Write simple self-documenting code that explains its logic, comments
should be up-to-date and do not contain unnecessary information (explain what is
not clear or why it was done that way):
- I avoid deep abstractions and always prefer composition to inheritance or impurity.
- I prefer flat data structures whenever possible.
- I introduce external dependencies to a minimum (ideally without them at all).
- I design modules with clear APIs, but almost never translate them into microservices.
- To understand legacy code, I draw dependency graphs and sequence diagrams.
- I write examples - lots of examples. Some of them are even interactive.
- Several levels of testing, with the help of “tools” (debugger, linter, etc.) and automatic testing greatly help to detect bugs and issues.
- Working with team, helping others and myself (documentation, training, reviews) significantly improve quality of any project.
- I listen to the opinion of older comrades, experience is very expensive and useful.
- I do refactor my code if something is unclear and needs to be improved.
Learning path
-
Winter and Manshreck and Wright - Software Engineering at Google
-
Spolsky - The Best Software Writing I
-
How to Design Programs. Как проектировать программы: Фелляйзен, Финдлер, Флэтт
-
👍 12factor app - Intersting high-level overview of “good” applications development practicies.
-
solid note research, part 2.
-
Refactoring: Improving the Design of Existing Code, read and take notes.
-
Domain-Driven Design Distilled, read and take notes.
-
Data-Oriented Demo: SOA, composition - YouTube, research video.
-
Beyond the Twelve-Factor App, read and take notes.
-
OOP - research note.
-
⬛ McConnell - Code complete, read and take notes.
-
How to “think” (and design) like a Software Architect at Silicon Valley