Do not write too much

Everyone thinks that a programmer writes code for most of his working time. In addition to the programmers themselves. They know that they read this code most of the time. They read, trying to understand how it works, why it was written here and what to do with it now.

The longest is to read not tricky algorithms, and not solutions with algebraic data types and monads, but huge chunks of simple code: methods for 500 lines, scripts for 1000 lines, classes for 1500 lines. They all give the industry no less a problem than the infamous NullPointerException .

In the classic book “Refactoring” by M. Fowler , only three types of “suspicious code” related to the volume are given: “Long method”, “Large class”, “Long list of parameters”. In modern realities, this list could be replenished, but even these three long-known principles are violated all the time, and large pieces of code continue to cause a lot of problems.

The first (and main) problem is the time spent . “A lot of code” is, first of all, just a lot of text to read. And no fast reading technique will help here, because every nuance is important in the code. Reading it “diagonally” means wasting your time and making false conclusions about how it works.
By misconceiving how a piece of the system works, the programmer is doomed to make a mistake when writing a new code.

Large chunks of code are difficult to test . Large methods that use heaps of data are almost impossible to cover Unit with tests, and integration tests turn out to be huge and very complex. So that fit to write tests for tests. However, you can pretend that there are no automatic tests on the project, and everything is fine. Then the book by Kamikaze by E. Yordon is very useful to you.

Large pieces of code are difficult to revise . A colleague was very productive and wrote a subsystem over the weekend? Fine, but now you need to spend a lot of man-hours reading this opus before sending it to the master! Reading through the changes in the third ten files, it will be difficult to keep in mind the changes from the very beginning, not to mention your own current task.

A large piece of code is almost impossible to reuse . It does too many things at once, and only some of them usually need to be reused. It is not always possible to improve the situation by applying the “Allocation method” and other techniques, since this huge piece is hardly well covered with tests.

Try to avoid writing code at all.

• Check if someone before you has solved the same (or very similar) problem in this project. Reuse the code, select abstractions, do not hesitate.
• Know and love the utilities and APIs of your own project. Especially if he is more than half a year. There may be pearls that will save you dozens of lines of code.
• Know and love popular libraries for your language or platform. If we talk about java, then do not be lazy to get acquainted at least with Google Guava and the Apache Commons family. Do not reinvent the wheel.

When all the same write your code.

• ( , , , ). , , . . if { … } else { … } 20 ? , . ( )? .
• - . - onSuccess() 200 400 , , . , ( onSuccess()) .
• . - (, ) ( ).

— . , . ( callback-), ( , , . .) ( ).

,

• ( ) ( ).
• .
• .
• .

, , , . , . .