Mastery basics

Fight the complexity

As you know, the human brain can simultaneously consider 7 ± 2 elements. Therefore, it is very important to strive to reduce software complexity. Here are some specific recommendations:

• Split the system into subsystems at the architecture level in order to concentrate at a particular time on the smaller part of the system.
• Define class interfaces carefully so that they can be ignored.
  internal structure of classes.
• Support the abstraction that the class interface forms so that
  memorize unnecessary details.
• Avoid global data, because using it greatly increases the percentage of code you need to keep in mind at any moment.
  of time.
• Avoid deep inheritance hierarchies, because they impose
  high demands on intelligence.

• Avoid deep nesting of loops and conditionals, because
  they can be replaced by simpler control structures that allow
  more careful use of mental resources.
• Avoid goto statements, since they introduce non-linearity into the program, for
  which most people find difficult to follow.
• Carefully determine the approach to error handling, instead of using an arbitrary combination of different techniques.
• Systematically use the built-in exception mechanism, since it
  can become a non-linear control structure, which in an undisciplined application is almost as difficult to understand as goto operators.
• Don't let classes turn into monsters reaching the size of whole
  programs.
• Keep the methods short.
• Use clear, obvious variable names to not recall details like “xx is the account index, and yy the client index or vice versa?”.
• Minimize the number of parameters passed to the method, or, more importantly, transfer only those parameters that are needed to support the abstraction generated by the interface of the method.
• Use conventions to not remember arbitrary, insignificant differences between different code fragments.

Analyze the development process

In projects implemented with the participation of more than one programmer, the more important
role is played by organizational characteristics, not individual skills. Even
if you have a great group, its collective ability is not equivalent to the sum
abilities of individual members. The process used by the group is what determines whether the work of a particular programmer will increase or decrease the effectiveness of the work of the other members of the group.

The development process is important primarily because quality must be embedded in software from the very beginning. This contrasts with the long-standing "wisdom", according to which you can write an arbitrarily bad code and eliminate all errors during the testing phase. It's a delusion. Testing can only point to individual
defective areas of the program - it will not make your program easier to use, faster, more compact, readable or expandable.

Premature optimization is another flaw in the development process. An effective process means that you perform rough work at the beginning and fine
in the end. If you were a sculptor, you would give the composition a general shape.
and only then would they start working on individual details. By prematurely performing optimization, you spend time polishing code fragments,
which do not need to polish. Always ask yourself: “Am I doing it in the right order? What would change if you change the order?
')

Write programs primarily for people and only secondly for computers.

Computers don't care how readable your code is. They generally read binary commands better than high-level language operators. The readable code needs to be written in order that it was clear to people. Readability
positively influences such aspects of the program as:

• clarity;
• ease of review;
• error level;
• debugging convenience;
• ease of change;
• development time - a consequence of all of the above;
• external quality - a consequence of all of the above.

It is no longer any longer to write readable code than tangled - at least in the long run.

Program using language, not language

Do not limit your thinking to only those concepts that are directly supported by the language. The best programmers think about what they want to do, and then determine how to achieve these goals using the programming tools at their disposal.

Focus on agreements

General benefits of the agreement:

• Agreements save programmers from having to answer the same questions again and again and make the same arbitrary decisions.
• The convention concisely communicates important information.
• Agreements protect against known hazards.
• Agreements make low-level tasks more predictable.
• Agreements can compensate for the disadvantages of languages.

Program in terms of the problem area.

Another specific method of dealing with complexity is to work at the highest possible level of abstraction. One way to achieve this goal is to work in terms of the programming problem, not its computer solution.

High-level code should not include details about files, stacks, queues, arrays, characters, and similar objects that have names like
i, j and k. High level code should describe the problem to be solved. He must
be filled with descriptive class names and method calls that clearly describe the actions performed, rather than the details that the file
opens in read-only mode. High level code should not be
It is cluttered with comments saying that “here the variable i represents
an index of a record from a file about employees, and a little later it is used to index a file of customer accounts. ”

This is an awkward programming technique. At the highest level of the program
You do not need to know that employee data is presented in the form of records or stored in a file. Information relating to this level of detail should be hidden. At the highest level, you should not have a clue about how data is stored. You should not read comments explaining the role of the variable / and that it is used for a dual purpose. Instead, you should see two variables with expressive names, such as Customerelndex and clientlndex.

The division of the program into levels of abstraction

Obviously, at some level it is necessary to work in terms of implementation, but
You can isolate these parts of the program from parts developed in terms of the problem area. When designing a program, consider the levels of abstraction:

• features of the operating system and machine commands;
• structures and means of a programming language;
• low-level implementation structures;
• low-level elements of the problem area;
• high-level elements of the problem area.

Beware of falling stones

Whatever programming is - art, craft
or engineering discipline, creating a working program requires a fair amount of
share of judgment. And for this you need to pay attention to a wide range of warning signs - subtle hints of problems in your program. Warning signs in programming indicate possible problems, but usually they are not as obvious as a road sign warning of rock falls.

If you want to take full advantage of warning signs, program to create your own warnings. This is useful because, even if you know the warning signs, they are surprisingly easy to lose sight of.

Iterate, iterate, and iterate

Iteration is useful at many stages of software development. When developing the initial system specification, you make several versions of the requirements with the customer until you reach agreement. This is an iterative process. A flexible development process involving the creation and delivery of a system in parts is also iterative. Prototyping, which aims to quickly and cheaply develop preliminary solutions, is another form of iteration. Iterative development of requirements is probably no less important than any other aspect of the software development process. Projects fail because developers start to solve the problem without examining alternatives. Iteration allows you to better know the system before creating it.

The timing of the initial project planning can vary greatly depending on the assessment methodology used. The iterative approach provides a more accurate estimate than the single technique.

Software design is a heuristic process and, like all heuristic processes, allows iterative revisions and improvements. The correctness of the software is usually checked, not proven, and therefore it is tested and developed iteratively,
until all questions are answered correctly. And high-level, and
low-level design attempts should be repeated. The first attempt may lead to a workable solution, but it is unlikely to be the best.
Repeated use of different approaches allows you to learn about the problem a lot
such that escapes when using the only approach.

The whole development process is covered by reviews, which builds an iteration into any
the stage at which they are held. The purpose of the review is to check the quality of the work done at the moment. If the system does not pass the review, it is returned for recycling. If the review is successful, no further iteration is needed.

They say engineering is the ability to do for 10 cents what anybody can do for a dollar. Iteration at later stages is a waste of two dollars on what anyone can do for one. Fred Brooks advises "to plan to throw out one version of the program, because it will have to be done anyway." The trick to software development is to create discarded parts as quickly and cheaply as possible - this is the essence of iteration in the early stages of development.

Steve mcconnell