Готово!
Скоро материал придет на указанную электронную почту. Также подписывайте на нас в Facebook
Ok
Writing a maintainable code
By a happy coincidence, a maintainable and easy to support code is also easy for (unit-) testing and easy for mastering by new team members, etc. This is likely due to the fact that in order to create a maintainable code you have to possess a good architecture project and some good habits.
The main principle of the program division into high level parts has not changed for decades: Data access layer, Business (logic) layer and Presentation layer. Moreover, it is obvious that the layer which reflects the essence and the general value of our application is the Business layer, while DAL and PL are kind of supporting layers. All these abbreviations on the letter «M» are architectural patterns which describe the way the Presentation layer is organized in programs, and no more.
And since I promised to talk about habits, let me define the first one: in the race for fashionable data storage technologies or their presentation to the user we should not forget that your application is your Business layer, and the rest is temporary and changing over time.
And the second good habit goes immediately and without preamble: SOLID. I do not know about other things in SOLID, but the importance of the Single responsibility principle can not be overestimated. I would call it a necessary and sufficient condition for a good code. Any bad code always has a class that makes more than one function (consisting of thousands of lines Form1.cs or index.php which each of us probably saw or even wrote). The rest principles of the SOLID are not so important for me and, by the way, recently Habrahabr had a good article on this subject, which you can read. I largely agree with the written there and thank the author of this article for not having to explain it by myself.
The Single responsibility principle (hereafter «S principle») literally makes writing a quality code, and many, many techniques are merely a tool for writing a code that would meet this principle. An example is what I call the third good habit: Dependency Injection (DI). I can hardly imagine a more or less large project which uses the S principle without the DI. I promised to give examples, and here is a good point to start it. Regular class, which is the logic of the order processing of any online store.
The most highly rated article of our blog is continued on Habrahabr.