Dans le domaine du développement de logiciels, il y a souvent des thèses comme «
Personne ne se soucie de votre code » (traduction - «
Votre code n'intéresse personne »), «Le code n'est qu'un outil» et des situations d'incompréhension totale de la part des entreprises pourquoi nous devrions prendre du temps et de l'argent pour une sorte de "refactoring" du code qui fonctionne déjà.
Je veux vous dire à quoi «l'accent mis sur les caractéristiques» peut conduire, au lieu de se soucier de la qualité du code, et pourquoi non seulement les programmeurs ont besoin d'un bon code.
Le soutien
La thèse principale, sans laquelle l'article actuel, en principe, n'aurait pas de sens:
Ce qui se passe dans le monde de la programmation depuis des décennies, pour le plaisir de créer des langages, des paradigmes et des approches plus avancés, pour lesquels ils distinguent divers modèles et prennent en charge la conception du code sont, en fait, deux choses - Augmenter la vitesse de développement et faciliter le support de la base de code (qui essentiellement la vitesse de développement de nouvelles fonctionnalités).
Et ce sont les choses dont les entreprises ont besoin.
Bien sûr, on peut affirmer qu'ils ont eux-mêmes besoin des méthodologies qui augmentent l'efficacité du travail des programmeurs afin de vendre leur travail plus cher, étant en mesure de faire plus par unité de temps, mais parce que la situation lorsque les programmeurs commandent un grand projet fini immédiatement sans besoin de soutien supplémentaire est très C'est rare, et généralement la fonctionnalité est ordonnée progressivement, au début du projet vous ne ressentirez pas les effets néfastes d'une mauvaise conception, c'est plutôt un investissement dans le futur.
Il y a une image du
blog de Martin Fowler à ce sujet, montrant la vitesse à laquelle de nouvelles fonctionnalités sont introduites dans un projet en fonction de sa durée d'existence (c'est-à-dire de sa taille).
L'axe horizontal est la durée de vie du projet, l'axe vertical est la fonctionnalité d'agrégation.
La ligne rouge illustre la vitesse de développement d'un projet avec une bonne conception, et la ligne bleue illustre un projet qui est écrit sans aucune restriction sous la forme d'exigences pour la qualité du code.
Ainsi, si vous pensez que votre application est vouée à l'échec et ne se développera pas, ou se prépare exclusivement à un événement à venir, vous n'avez pas besoin de penser à la conception du système. Dans la situation opposée, une bonne conception est susceptible de porter ses fruits et de porter ses fruits plusieurs fois.
Parfois, vous pouvez entendre l'opinion qu'au début d'un projet, vous n'avez pas à penser à la qualité du code et à le réécrire après une présentation réussie aux clients / investisseurs, mais dans la grande majorité des cas, c'est une erreur de démarrage de projets, et le moyen le plus simple de gagner de
la dette technique pour les années à venir.
Le code n'est pas un outil; le code est un produit final
Une
société de logiciels n'utilise pas le code comme outil. C'est le produit principal de l'entreprise, c'est le code final du programme qui détermine sa qualité, sa rapidité, sa conformité aux exigences de fonctionnalité. Il ne peut pas être simplement pris et complètement remplacé sans subir de pertes temporaires et matérielles, comme cela pourrait être fait avec les méthodologies de développement informatique / IDE, qui seront essentiellement des outils pour créer un produit.
À propos de "Focus on performance"Dans l'article auquel j'ai fait référence, la pensée suivante a été exprimée: vous devez communiquer avec le client / chef de projet au niveau de la préparation du projet, et l'exemple suivant était le contraire:
Imaginez que le concepteur commence à vous parler des calques qu'il a utilisés dans Photoshop, du nombre d'objets qu'il contient, des dégradés utilisés sur quels pinceaux et des scripts d'animation sympas qu'il a écrits. Cela ne vous intéresse pas. Êtes-vous intéressé à savoir s'il est déjà possible de prendre des photos?
Alors voilà. Il y a une différence à cause de laquelle il
ne peut pas simplement être projeté sur la situation avec le support d'un produit logiciel - tous ces calques et pinceaux dans Photoshop deviennent inutiles pour quiconque juste après le résultat du travail (images), et tout de même sont un outil pour atteindre le résultat , pas le produit final.
Ainsi, lors de l'élaboration des exigences pour les photos finales, le client ne peut pas se soucier de ce qui sera utilisé dans le processus. Dans le cas du logiciel, si le client (entreprise) ne demande que des fonctionnalités à l'application, il court le risque d'obtenir exactement ce qu'il voulait - de nouvelles fonctionnalités, mais il ne fait aucun doute qu'il faudrait les maintenir et les développer.
Malheureusement, il s'agit d'un problème assez courant d'externalisation, lorsqu'une entreprise ne vend que le temps de ses développeurs et que les clients ne peuvent pas évaluer objectivement la qualité du système et le temps nécessaire pour résoudre ses problèmes. Lorsque le coût de la modification du code augmente de façon exponentielle, cela ne profitera qu'à l'entreprise elle-même - plus d'heures humaines peuvent être monétisées, et la société qui commande le produit sera déjà sur le crochet - il est trop tard pour réécrire le système encombrant et peu pratique, car cela nécessite des investissements énormes et l'arrêt de la livraison de nouvelles fonctionnalités cela ne peut pas être autorisé.
Code - lieu de travail du programmeur
Pendant tout le temps que l'article était en ébauches, j'ai beaucoup réfléchi à la question de savoir si ce point devait y être inclus, mais après un petit constat des priorités des candidats à la recherche de travail, j'ai réalisé que ce moment était vraiment important.
Le code est quelque chose avec lequel un programmeur devra travailler chaque jour, son produit créatif, ce qu'il crée, mais en crée non pas un, mais en équipe et, souvent, pas à partir de zéro. Il doit accepter la partie déjà existante du projet, la développer en fonction de la fonctionnalité qui a été écrite avant. Un employé sera très probablement désagréable de travailler dans un produit mal créé.
En premier lieu, à mon avis, c'est l'équipe qui travaille ensemble sur le projet. La qualité du produit résultant dépend directement de la façon dont le travail d'équipe est construit, des règles internes et des exigences établies à l'intérieur.
En deuxième place, la technologie. Un cadre gênant choisi ou hérité irréfléchi, des outils obsolètes et de mauvaise qualité, des bibliothèques clouées sur le lieu du projet avec toutes leurs béquilles et bogues que vous devez supporter, et le manque de personnes ayant les compétences suffisantes et le temps nécessaire pour éliminer les approches héritées peut facilement effrayer de nouveaux potentiels les travailleurs. En plus des raisons énoncées ci-dessus, il s'agit également d'un plus petit nombre de perspectives et d'opportunités pour le développement de programmeurs, car au lieu d'étudier les outils modernes et les plus efficaces, il est nécessaire de développer des accessoires pour adapter les solutions aux problèmes actuels pour des raisons historiques.
Pourquoi est-ce tout
Malheureusement, les exigences pour les applications réelles peuvent rarement être formées à 100% et ne nécessitent pas de révision pendant le développement. De plus, la situation est presque impossible lorsque le projet n'a pas à être adapté aux nouvelles exigences après son lancement. L'entreprise se développe, se développe, nécessite des fonctionnalités qui n'ont pas été discutées auparavant, pénètre de nouveaux marchés.
Il est presque impossible de construire une architecture idéale et pensée dans les moindres détails dans de telles conditions, et, souvent, cela n'est pas nécessaire, car son coût dans ce cas est déraisonnablement élevé pour la phase initiale du projet.
Certes, écrire du bon code ne devrait pas être un casse-tête pour ceux qui commandent des logiciels à des programmeurs, et il est peu probable que quiconque ne peut pas l'écrire puisse le vérifier.
Néanmoins, une entreprise développant un produit logiciel, si elle veut le faire qualitativement, doit comprendre qu'une partie aussi importante du produit que son code source affecte directement son succès, et des choses telles que la refactorisation du code source et la modification de l'architecture aux nouvelles exigences devraient également être un budget, du temps devrait être alloué aux programmeurs. Si quelqu'un s'intéresse à la qualité du produit, bien sûr.
Cependant, l'industrie informatique se développe, les produits, les entreprises, les outils se développent, les utilisateurs deviennent plus sélectifs, la concurrence s'intensifie et il y a de l'espoir que l'avenir sera toujours avec des produits de haute qualité.
Conclusion
En fait, le sujet de l'article est, bien sûr, très controversé.
Le graphique ci-dessus ne répond pas à la question de savoir à quel moment la conception du système commence à porter ses fruits.
La dette technique pour cela et la dette, qui vous permet d'obtenir un peu plus de temps maintenant et de la restituer avec intérêt plus tard, et son principal problème est extrêmement simple, et ressemble fortement à un phénomène similaire dans l'économie, est l'incapacité à rembourser les dettes et l'incapacité d'estimer avec précision les revenus futurs.
La qualité du code est également une chose très subjective et, malheureusement, pratiquement non formalisée, sinon les programmeurs pourraient déjà être remplacés par des robots.
Dans tous les cas, le plus important est de parvenir à des compromis compétents et de trouver ce terrain d'entente, ce qui nous permettra de ne pas noyer le projet dans le gouffre de la dette technique à la recherche de fonctionnalités, et de ne pas céder une niche intéressante aux concurrents, en faisant la conception du système au lieu de la fonctionnalité.