Bad code, overly complicated build process, outdated technologies, terrible programming language - all these problems, and many others, accompany every sufficiently successful large project, any software development process in any organization. As practice shows, in most cases the situation only gets worse over time - minor inconveniences develop into unpleasant “peculiarities of our work”, scores are constantly increasing when planning tasks, and the quality of the finished product begins to suffer. The final touch to this picture is the failure to meet deadlines and plans due to the impossibility of either debugging functionality, or even delivering it to the working environment. Often, in such situations, we say that technical debt has accumulated.
This debt arises in a completely natural way and pursues all systems, no matter how successful, when there is the product itself, its users, channels of communication with them. It does not matter whether the product is sold directly, or whether it is an auxiliary part of the company's business, what matters is that it has been in operation for a long time. Users want to get new functionality (perhaps they will even pay for it), management wants to provide users with it as soon as possible, because the development department, under pressure from deadlines, implements the necessary changes. The process is repeated many times, and sooner or later someone will loudly say - “it seems we have a debt, perhaps a technical one!”
Everyone began to note that each new task is more difficult than the previous one, and this is no longer an accident, the complexity is growing exponentially. There are “fragile” places in the code that are better not to touch, more often defects from users and alarms from the system for monitoring the working environment “arrive”. First, initiatives to introduce new technologies and practices designed to improve the quality of the product as a whole are postponed, and then completely forgotten. A general idea is formed that something is going wrong, the search for the reasons for what is happening and who are to blame begins. Of course, there is nothing good in this state of affairs, even more so - the negative begins to poison the atmosphere of the team.
, , — , , , , , , , , , , .
, , , , , , . , — , ? , .
, . , . , , , - — , ? , ? ? , ? . , , , , — , . — .
— , , , , . , , . — . , IDE , , . .
— , :
- , ? - , .
- - , - , .
- , , .
- , .
- , , , , .
- - , , .
- , - , .
, — , , . . , — , , . , — , , .
. , , . — , . — . — ? .
“ ?”. ! , 100% — , - , , . , , , — 50/50, 60/40, . — , , .
, , — , , . ! ! ! — . .
, , — , .
, — , , , — . , — ? , , . , Flash — , , . , , — . , , , .
. — , , — , . , , . , … , .
, . , , , , , . , , - . , , , — , , , , “ ”, . ? , , . , , , — .
? — . , — . , , , . , .
— , : , , , .. , , . , , , . . , , , , , — , . , — , . — , . — , , , , .
— , , , . . , , , . , , , , — .
, , . — , , , . , . - Terra incognita, . - - , , , - ( ) . - , - , . , , .
, , . . , . , API. http- . — , - , offline-, - Selenium-, UI, . , API.
, , . — . , . API , , -, ? , ? , , — , — .
. , , , , — . , , — . , :
- ,
- ? - — . — , . “, ”: “ , , , , ”. , , “ ” , , , — , “” , . , ?
, — , API, .. — , - . . , , , , , , . , , .
, . — , , , . , , , , , , , , . , — , . , , - , , , , . , , , , , , — , . .
— , , . , , , , : , , . — , .
, , , , — , . , — , .
, , - . . — “”, “”. , , .
, , , . , , web-, , — , . , , , — “”? ? , ? , . , , ?
, , , — . Twitter, , , , , . , , . , Ruby on Rails, JVM, . .
, — , . , , , . , , , , . , (-, ) . , . , .
. , , . — , , , , . , . — , , — .
P.S.
Everything written above applies, of course, to large, working software products with an active user base. And only for those cases when it is impossible to simply release a new version of the product along with the old one, as was the case, for example, with Basecamp and as it is with all the so-called. "Boxed" software.