Things we want to do later

It is known that it is easier to prevent mistakes than to correct them and the later the error is found, the more difficult it is to correct it. Despite this, we all have managers deadlines and that piece of code that needs to be fixed after release.



It so happened that I am both a developer and a manager from time to time, and therefore I have to look at the code from two opposite points of view. As a developer, I want everything to be beautiful and work quickly, but as a manager I really want the release to be on time. That is, I somehow suffer from a slight split personality, because these two people want a little different things. And that's what I noticed. The strategy to be led by the manager works very well in the medium term and begins to pop at the seams in the long run. It was painful enough to rummage around the ticking mines that I laid several months or even years ago, so I decided to write down my short list of what should have been done right away.
')
If you do not want to walk on my rake, welcome under the cat.

Database

This is the place that will be the most painful to change. As your application grows, you will accumulate some data. And errors in the design of the database will be the most expensive, because all this data will need to be saved. The first thing you should pay attention to is the ability to scale your DB layer. Add a web server now is not a problem: the terms of the cloud and virtualization. With the database all the more difficult. First, there are two fundamentally different strategies for your choice: replication or sharding. I leave the clusters behind the scenes. That is, you can not just take and get the database server. So if there is a possibility that you will have not just a lot of data, but a lot, it’s better to think about all these questions in advance.

Indices and constraints

Traditionally, put down indexes and konstraynty somehow forgotten. Particularly forgetful neglect even foreren-keys. This is how strange errors from the db inconsistency area are obtained. The absence of constraints allows you to transfer the database to an inconsistent state, that is, to one that the developer did not anticipate. To catch and correct such errors is long and dreary.

Occasionally, there is a desire to thrust JSON or XML into the database in order to quickly transfer to the presentation layer. The idea is good in its own way, but thus the main strength of the classic SQL solutions is lost. Sooner or later you will be asked to sort the issue and it will be unpleasant. I want JSON - easily. Take Mongu or something else no-sql'noe and choose that you need more data integrity or access speed.

In addition, the database is traditionally the bottleneck in terms of performance. How will you settle it? Maybe it’s enough to slightly denormalize the database or stick CQRS or can you successfully cache everything? Silver bullets, as usual not. It all depends on the specifics of the application. All these questions are better to ask yourself in advance. I do not call to shoot from a cannon on sparrows. At the initial stage, all this may seem like a creepy overhead projector and you don't need to implement the super-architecture right away. It is much more reasonable to write a code that is quite good at this stage, but it’s still necessary to keep in mind the development plan of the application a couple of steps ahead so that it does not hurt painfully later.

Application Layers and Unit Tests

This is the place I’ll never change ... So I thought once, until somehow I didn’t have to change the fundamental logic of the application. Soft sells tickets and, in general, once had to change the logic of the institution of those same tickets. It cost me a two-week refactoring, during which I built a new layer of business logic in the application, because we tested the previous one only at the level of integration tests and locking the database was simply impossible. The DTO and Entity layers were shuffled. The impossibility of testing is not the biggest headache of strong connectedness.

The lack of order in the layers of the application indicates the absence of order in the head of the developer. Each new feature-request begins to be another hack in the most unexpected place, and now the business logic of the application is evenly spread throughout the code. This code is simply impossible to change without creating a side effect, as always unexpected, and at the most inappropriate moment. So I haven’t been writing any serious applications without tests for a long time. With the units it is simply impossible to mix layers of the application. You simply cannot write a test, and this will force a critical rethinking of the current architecture.

Null Reference or security programming

For a long time I considered “let him fall”, because I never pass on null links. And it worked for me. From time to time I noticed that in this way the code for checks on NULL starts to spread like melted cheese throughout the application. In addition, not all developers with whom I worked checked their values ​​for NULL. And that's what I noticed: writing defensive constructions is a tedious task, so I automatically began to write code so as to keep the number of these checks to a minimum. This had a positive effect on the design of the system as a whole. The code became less, the code became better structured. I look at the possibilities of AOP to make checks on NULL declarative, but so far I'm fine and so.

Application stitches and SRP

As in the case of the database application layers serve only one purpose - to enable in the future, quickly and painlessly replace part of your system. Creating an IFileStorage from a single implementation of SimpleFileStorage is much easier than combing an entire application to look for a record in the file system, because you decide to move to the cloud. With experience, you begin to feel the places that are most likely to change with intestines (or other parts of the body). Each time, breaking SRP, you save minutes or hours of your time now, which will result in days and weeks afterwards. Quickly yes, the manager is happy ... now. Then there will be questions, why make this maaaaa-little change for so long.

Web server scaling

It is impossible to constantly increase server capacity. Sooner or later you will run into the possibility of the channel. And this is where ALL static variables that you used directly pop up EXTREMELY. In general, the horizontal scaling of the system at all levels is something to think about in advance. And here again, you can still not bathe and write to static variables until exactly until you insert another server. Given one but. Do all these dirty things inside your IDataProvier or IProblemResolver. Then you have to change only one class, and not to collect changes throughout the code.

DevOps

And how will we develop it? Not well, I have everything deployed, but I will not change the computer, reinstall the OS and do other nonsense. And what about new developers? Well, they are programmers, this is their job, they have to figure it out. None of this needs to be documented, and even more so no additional effort is needed to make this easier.

Once we deployed the customer’s system for two days on our servers. Everything has gone to the course: bubuen, Tuvan folk throat singing and most importantly the Config Tool. Without this configuration, no one at all could get the application to work. And I would be happy if this tool was an installer. Unfortunately, the Config Tool was a console application that had to be run under strictly defined conditions, after which it was possible to upload archives and deploy everything on servers. However, without Config Tool, no one could configure the entire pack of applications at all. Softina dropped meaningfully with errors that did not at all reflect the essence of the problem: for example, swore at the certificate, although the problem was in authorization.

Ruby on Rails and ASP.NET have long been proposed and even impose (and rightly so) simple and cool ways of deploying applications. Use the features that your environment offers. And if you do not offer, you can always make the process of unfolding a little easier. This concerns not only the application level. It is useful to keep this in mind even before the first line of code is written. If you want to put the config into the database, add the migration so that at 2:00 AM you do not need to edit the database on production, because there (oops!) Is the old config. Other developers on your team will also be grateful if, after the next update from VCS, they don’t fall out of the fact that now our application is working with a mega-super new thing that needs to be pre-configured using tambourine, Tuvan folk throat singing and spirits.

Multithreaded programming

Are you sure that you can write multi-threaded code? Are you sure that you need it at all? Wherever it is possible not to write multi-threaded code, please do not write it. Interesting, cool yes. And even, perhaps, on some data sets on your machine, it works correctly. Multi-threaded programming is a completely separate area of ​​knowledge, and writing multi-threaded applications is much more complicated than single-threaded applications. Exactly how to debug. Take care of your nerves and your colleagues.

It would seem that things are simple. About all this talked. However, this is what gives me the most problems in my daily work.