Pourquoi les projets sont réécrits et pourquoi ils échouent

Le thème séculaire - pouvez-vous ou ne pouvez-vous pas réécrire un grand produit fonctionnel avec une base d'utilisateurs active? La réponse, en général, sera - oui, vous pouvez. La seule question est comment? Ayant vu plusieurs tentatives de ce type dans le passé (à la fois réussies et non), cet article est le point de vue de l'auteur sur ce problème.

Un mauvais code, un processus de construction trop compliqué, des technologies obsolètes, un langage de programmation épouvantable - tous ces problèmes, et bien d'autres, accompagnent chaque grand projet suffisamment réussi, tout processus de développement logiciel dans n'importe quelle organisation. Comme le montre la pratique, dans la plupart des cas, la situation ne fait que s'aggraver avec le temps - des inconvénients mineurs se transforment en «caractéristiques de notre travail» désagréables, les scores augmentent constamment lors de la planification des tâches et la qualité du produit fini commence à en souffrir. La touche finale à cette image est le non-respect des délais et des plans en raison de l'impossibilité de déboguer la fonctionnalité ou même de la livrer à l'environnement de travail. Souvent, dans de telles situations, on dit que la dette technique s'est accumulée.

Cette dette naît de manière tout à fait naturelle et poursuit tous les systèmes, quel que soit leur succès, quand il y a le produit lui-même, ses utilisateurs, les canaux de communication avec eux. Peu importe que le produit soit vendu directement ou qu'il s'agisse d'un élément auxiliaire de l'activité de l'entreprise, il est important qu'il soit en activité depuis longtemps. Les utilisateurs veulent obtenir de nouvelles fonctionnalités (peut-être même paieront-ils pour cela), la direction veut les fournir aux utilisateurs le plus tôt possible, car le service de développement, sous la pression des délais, met en œuvre les changements nécessaires. Le processus est répété plusieurs fois, et tôt ou tard, quelqu'un dira haut et fort: «il semble que nous ayons une dette, peut-être technique!

Tout le monde a commencé à noter que chaque nouvelle tâche est plus difficile que la précédente, et ce n'est plus un accident, la complexité croît de façon exponentielle. Il y a des endroits «fragiles» dans le code qu'il vaut mieux ne pas toucher, le plus souvent les défauts des utilisateurs et les alarmes du système de surveillance de l'environnement de travail «arrivent». Tout d'abord, les initiatives visant à introduire de nouvelles technologies et pratiques destinées à améliorer la qualité du produit dans son ensemble sont reportées, puis complètement oubliées. Une idée générale se forme que quelque chose ne va pas, la recherche des raisons de ce qui se passe et de qui est à blâmer commence. Bien sûr, il n'y a rien de bon dans cet état de fait, encore plus - le négatif commence à empoisonner l'atmosphère de l'équipe.

, , — , , , , , , , , , , .

, , , , , , . , — , ? , .

, . , . , , , - — , ? , ? ? , ? . , , , , — , . — .

— , , , , . , , . — . , IDE , , . .

— , :

• , ? - , .
• - , - , .
• , , .
• , .
• , , , , .
• - , , .
• , - , .

, — , , . . , — , , . , — , , .

. , , . — , . — . — ? .

“ ?”. ! , 100% — , - , , . , , , — 50/50, 60/40, . — , , .

, , — , , . ! ! ! — . .

, , — , .

, — , , , — . , — ? , , . , Flash — , , . , , — . , , , .

. — , , — , . , , . , … , .

, . , , , , , . , , - . , , , — , , , , “ ”, . ? , , . , , , — .

? — . , — . , , , . , .

— , : , , , .. , , . , , , . . , , , , , — , . , — , . — , . — , , , , .

— , , , . . , , , . , , , , — .

, , . — , , , . , . - Terra incognita, . - - , , , - ( ) . - , - , . , , .

, , . . , . , API. http- . — , - , offline-, - Selenium-, UI, . , API.

, , . — . , . API , , -, ? , ? , , — , — .

. , , , , — . , , — . , :

1. ,

- ? - — . — , . “, ”: “ , , , , ”. , , “ ” , , , — , “” , . , ?

, — , API, .. — , - . . , , , , , , . , , .

, . — , , , . , , , , , , , , . , — , . , , - , , , , . , , , , , , — , . .

— , , . , , , , : , , . — , .

, , , , — , . , — , .

, , - . . — “”, “”. , , .

, , , . , , web-, , — , . , , , — “”? ? , ? , . , , ?

, , , — . Twitter, , , , , . , , . , Ruby on Rails, JVM, . .

, — , . , , , . , , , , . , (-, ) . , . , .

. , , . — , , , , . , . — , , — .

P.S.

Tout ce qui est écrit ci-dessus s'applique, bien entendu, aux gros produits logiciels fonctionnels avec une base d'utilisateurs active. Et seulement pour les cas où il est impossible de simplement publier une nouvelle version du produit avec l'ancienne, comme c'était le cas, par exemple, avec Basecamp et comme c'est le cas avec tous les soi-disant. Logiciel "Boxed".