Programming philosophy. Some principles of learning

Preamble

Good day% user_name%. Over the years of accumulated programming experience, I have accumulated some observations that deserve to be structured. Today I will talk about that part of the work of a programmer where he comes into contact with the need for training. I will try to outline some ambiguous principles, and oh, how many of these are in programming!


')
1. Program as much as possible!

Encode, encode and re-encode. This is something that more mature developers often advise beginners. And it seems that this advice is effective. So it is, but not quite. True much deeper.

For a company, it is important that each programmer master the tools used in production and, if possible, the one that will potentially be used. Many of the novice programmers buy thick books on Android, Java EE, Qt or something else that they use in practice. I think everyone understands that from these books only the part that they really test by practice in their projects is assimilated.

Having gained some knowledge, programmers sometimes start to amuse themselves with their own tasks and all of them are formed as follows: “to choose something that can potentially be done by the means that I know and put into practice”. This approach is 90 percent of the younger generation. Which begin to sharpen with time their knowledge of the area with which they work and VERY slow their growth as a professional.

Few people have studied the work of SQLite in Android begins to study the ORM in conjunction with the ORMlite if it is not in his project on which it is involved. Of course, his code with each new project becomes more and more better but ... From the moment when the programmer learned to write a stream-protected singelton every next initiative project in which he creates it will simply waste his time in idle (maybe somewhere on really need to use a static factory?!?).

Today there is a whole army of programmers with experience in Java who devote a lot of time to self-development and are rather superficially familiar with multithreading in practice, because in their specific tasks this was not required!

In order to actively grow over yourself a little to write a lot, you need to write a variety of. And yes, this is connected with the fact that instead of a beaten path that a programmer can realize with his eyes closed, it is necessary to choose something unexplored, less clear and not always even carrying an applied benefit (in any particular case). Is it profitable for the company? NOT! Of course not, because such a programmer can overwhelm the deadlines, create potential problems and generally lead to the state when part of the code will have to be rewritten again!

Is it profitable for a programmer? I can safely say that having a light head on your shoulders you can easily jump from the middle (and sometimes djuna) to the blue man in one or two years! Yes, this is a risk, but it is worth it, and ultimately it must be remembered that every programmer works for himself and for companies that want to take an intelligent employee always a lot.

2. Keep within deadlines

Timing is important campaign. They are important to managers who are not always well versed in programming. In large international companies, programmers often complain that they are faced with the fact that the deadlines are generally made up of purely “businesses” without regard to the developers. It is difficult for the latter to explain why testing has been included in the software development phase, without which, it seems to them, the process will become faster ...

Despite the position of the manager / company / boss, the code must be tested! Unit tests are not a panacea, but it’s impossible to say that the case has already been completed, as long as the code is not covered by tests. The work of the programmer is completed not when “it worked”, but when the programmer provides the following data together with the PP:
- how much and under what input parameters the software works;
- under what types of input parameters the correct result is guaranteed at the output;
- what behavior will be with incorrect parameters served on any (main) module of the program.

Without this, it’s possible that you’ll meet the deadlines, but you need to understand that the program will be released to release with much more delay than it was originally planned, because bypassing the tests you win the battle, but you definitely merge the war ...

3. Create at the stage of creating architecture

Want to write good programs, learn UML. The best software that has ever been born from under my keyboard was well designed. The written architecture must be scalable to easily incorporate potential changes (new customer requirements) without changing the architecture (or with minimal changes). Also, a high-quality architecture allows, at a very early stage, to create key program characteristics and formulate requirements for the final product (in terms of performance or functionality, etc.). This is where all TDD tests can be compiled.

Having developed the architecture, it is necessary to determine the technologies that will be used. After we proceed to coding, where a lot of time will have to be spent on studying (see point 1), but NOT creativity! Of course, some things can be implemented in different ways, and this is also creativity, but I still understand what I’m talking about now. They invented another “zagulina” and I want to immediately introduce it - late, wait for the moment when you will again create new software concepts, or a new version. At the development stage, there are enough risks associated with the implementation of concepts using new technologies or solutions.

4. Always solve the problem.

Very often, programmers put a test for null / NULL / 0 / etc in place of what to spend time and understand why the standard system function returned this null value while it shouldn't have! It is important to know the essence, always, and not to deal with the consequences. Yes, sometimes decisions require now, and do not give time for learning and improving the mat. parts. In this case, it is better to sit longer in the position of June to have more time to solve complex problems, but still learn and study again! Only when the programmer knows why his application is predictable, he can be calm. You should always remember that between knowing that software is predictable and knowing why it is predictable to disappear into hundreds of hours of training!

Afterword

Much has been said in many will cause a feeling of no agreement. First of all, in the matter of the fact that all these principles should be implemented on workers, combat projects. I have heard from many opponents of the point of view in style: all this is yes but applicable only on educational projects and in no case not real where there are clear terms, requirements, limits. And in a certain sense they are right, with one reservation, if you don’t start using it all on all your projects (both working and educational), then the growth rate as a specialist will decrease dramatically. For personal and free time is not more like a work week and the exception is those who have no need to work, life has given them the most valuable resource - time that you can spend in a workplace on self-development and creativity that develops into a wonderful FrameWork, start-up, project ... But All this is the topic of another article.