Passing the project: howto

Much has been said in this world that the code should be written in such a way that it can be easily supported by any other developer and that the project can be transferred to other people for support at any time. But how does it feel to transfer a project with which I lived for several years into completely different hands? Who will be for the project its new leader - the second father or evil stepfather (dear readers, I remember your existence, but you are in the minority)? Will our child develop and gain strength, or die, giving way to something much less beautiful, obviously not so high-quality (we understand who is the coolest professional here) and absolutely stranger? For those who really care about his future, and this article is written. I note that in ABBYY I worked in several projects, I left them for various reasons. Most of the projects are tasks without a clear solution (recognition, search for various informally described objects, etc.).

So, what should be done so that you can leave the project at any time, without fear for its future. In addition to high-quality code, clear interfaces and comprehensive documentation (at least in the form of comments to the code), a testing system is absolutely necessary. Moreover, one that can itself measure the quality and speed of your project, giving an unambiguous answer, which of the two versions is better. If such a system is possible - very well, create it. If not, consider how you can get closer to this solution. Some kind of testing system will be absolutely necessary for you to develop, but if you force it to give unambiguous answers, such as it became better or worse, you can avoid damage to your project, with such phrases as “I feel it became better”, showing the true price. these "sensations."

The testing system must be understandable and extensible. If possible, write unit tests; if difficult, do general project tests with specific examples. If there are simple execution tests that can either be passed or not passed, this is good. In cases where it is possible to measure how good your program is, you should do comparative testing of the two versions. Moreover, it would be good if these tests were arranged in such a way - we run the program, it leaves the log of its work, and comparing the two logs it is easy to understand which of the two versions of the program is better on each of the test examples. If the estimates turned out to be additive - fine, you still have the result on a group of examples. If you fail, think how to make these estimates additive.
')
Say, if you are looking for barcodes in an image, you need a bunch of images that have barcodes, and another heap that doesn’t have barcodes. The tester should show how many bar codes (well, more precisely, objects interpreted as a bar code) in each of the heaps were found and how much time was spent on it. This is the simplest minimal test, if you are seriously involved in the project, then you also need to mark all the images, indicating which barcode and exactly where you expect to find it. I repeat once again: you need the test system itself at the time of development, but the clarity and unambiguity of its answer will be required, first of all, by your successor.

Another important point - minor flaws. When it seems to you that you will be engaged in a project for a long time, there is a temptation not to write bug reports about various trifles, but to fix it as soon as your hands reach ... Even if you have a phenomenal memory and your hands always reach the right things, you still need to write bug reports Because just the knowledge of minor flaws is lost in the transfer of cases and the phrases of users appear in the forums, that "these idlers already several versions can not correct such a simple mistake."

Always leave comments in the code about unsuccessful attempts to do something. Feel free to write: here I tried to use the Danzig algorithm, but this workaround on average turned out to be more efficient, especially in the case of such and such. While we are working on the project ourselves, we remember our failures, their reasons, but how will the new owners of the project learn about them? The same goes for data structures. If there are several options for presenting your data, feel free to describe why you chose this one - perhaps your successor will think about whether something should be changed here.

Never, I emphasize, never write in your code those words that says marketing, convincing customers to buy a new version. Not “more convenient interface”, but “interface in the form of tables”, not “improved appearance”, but “colors closer to the original”. Moreover, in no case do not combine into a single interface functions that are connected only by the fact that it was so convenient to sell them. Remember that when the client to whom it is sold goes away satisfied, your successor will boldly throw out all this interface and everything connected with it from the code, without thinking how valuable what it throws out.

So you leave the project ...

Who is your successor? If the best programmer from your team, do not be afraid of anything anymore. This is the best possible scenario. Best not only for the project, but for you. You did everything you could, the successor will accurately cope, who, if not him, can finish what you did not have time. All you have to do is write a document with your ideas that you were going to realize in the next year or two, and hand over to a new leader. Most likely, your thoughts will coincide - no wonder you worked for so many years side by side. Write a document, pass the successor and leave. Do not forget only then to enjoy the success of the project without you: remember that it was you who gave him the impetus to develop in the right direction.

If it turned out that your successor is not at all the one with whom you learned to understand each other perfectly, but the person “from the outside”, with his (clearly wrong) ideas about the world, the matter is somewhat worse. Undoubtedly, a document describing ideas and directions for development is needed, but first you need to bring your successor to these ideas. So, what you really need:

• Document all the functionality. All the details. Not limited to common words, write a list of what your program can do. And to do it in such a way that no one has any doubts about the fact that your product can do what it can. And write it several times: in the daddy with the documentation, in the letter about the transfer of cases, in the comments to the main heading.
• Honestly write that your product knows how well, and what is not. On which examples works flawlessly, on which refinement is required. Which of these is a problem (from your point of view).
• Explain all architectural solutions. Why did you develop the architecture in such a way, and not otherwise, what kind of development of the project did you envision.
• Save all your test bases in a public place. Demonstrate to the successor how your test system works and how it evaluates performance.
• Write the documentation for the code itself ... But if you don’t know this without me (which is unlikely), you will still be forced to do it.

After you do all this, as well as the things that the successor asks for, you can say goodbye to the project. We'll have to come to terms with the idea that you are not his master now. But if you take care of the transfer of cases well, you probably will not have to observe senseless destruction with slogans about a new order.

Dmitry Deryagin,
Technology Development Department