Si un codeur parlant couramment ne tient pas compte des bonnes pratiques, sa maîtrise ne fonctionne-t-elle pas contre lui? [fermé]

Je travaille sur une application assez grande et boguée - et en raison de la façon dont elle est écrite (je vais vous épargner des détails, mais elle viole les règles dans la plupart des domaines auxquels vous pouvez penser), il est presque impossible de la développer sans refactoring majeur.

Une partie importante de l'application a été créée par des stagiaires, n00bs, etc.; mais il y a aussi eu un programmeur au rang de maître développeur, et en toute humilité, le code qu'il a laissé est également douteux, d'une manière différente peut-être mais toujours.

Certes, son code a tendance à faire le travail - la plupart du temps - mais il est généralement cryptique, réinventant la roue (par exemple, une grande méthode personnalisée accomplissant une sauvegarde SQL de base de données plutôt ordinaire), etc. Fondamentalement, confusion inutile et beaucoup de suringénierie

Et cela m'a fait penser qu'être un codeur hautement qualifié (je n'utilise pas délibérément le mot "développeur", en supposant qu'il indique un ensemble plus large de compétences), s'il n'est pas accompagné d'autres qualités, peut en fait être un peu toxique.

En supposant que c'est vrai, certaines des raisons pour lesquelles je pourrais penser sont:

• si vous codez facilement, il vous semble (ou en fait, à court terme) juste plus rapide d'extraire vos propres solutions sur place, sans vous tourner vers des bibliothèques, des fonctionnalités préexistantes, etc.
• si l'on est suffisamment expérimenté pour maintenir facilement une image mentale d'un programme complexe, on est moins enclin à le diviser en modules, couches, etc.

Donc, mon point est que si un codeur fluide se trouve être un mauvais développeur, leur maîtrise non seulement ne compense pas ce dernier, mais il fait en fait encore plus de mal à la place.

Que penses-tu de cela? Est-ce vrai (dans quelle mesure si c'est le cas)?

si vous codez facilement, il vous semble (ou en fait, à court terme) juste plus rapide d'extraire vos propres solutions sur place, sans vous tourner vers des bibliothèques, des fonctionnalités préexistantes, etc.

Oui. Je suis ce mec. Et j'ai appris que c'est une chose terrible.

C'est très bien pour vous, vous n'avez pas à apprendre quelque chose de nouveau.

Mais qu'en est-il du reste de votre équipe? Ils deviennent très dépendants de vous. Ils ne peuvent pas rechercher sur Google "Quickive ORM de Clive" pour obtenir de l'aide sur le mappeur relationnel-objet que vous avez écrit.

Et puis vient le jour où ils ont besoin d'embaucher quelqu'un de nouveau et ils ne peuvent pas rechercher des personnes ayant de l'expérience dans l'ORM Quicky de Clive.

Et vient enfin le jour où vous partez et que quelqu'un remarque un bug dans votre ORM. Et il sera là, car vous n'avez pas toute une communauté de personnes qui testent et réparent votre produit.

Oui, apprendre Hibernate aurait pris plus de temps que d'écrire quelque chose de léger. Mais l'avantage de le faire est beaucoup trop grand pour être ignoré, à mon humble avis.

• si vous codez facilement, il vous semble (ou en fait, à court terme) juste plus rapide d'extraire vos propres solutions sur place, sans vous tourner vers des bibliothèques, des fonctionnalités préexistantes, etc.

Compétent dans la langue mais pas dans les outils. Ce n'est même pas vraiment un bon codeur. Il s'agit simplement de polir une compétence (connaissance de la langue) et de permettre à une autre de rouiller (connaissance de la bibliothèque). L'inverse est tout aussi mauvais, mais plus facile à repérer.

• si l'on est suffisamment expérimenté pour maintenir facilement l'image mentale d'un programme complexe, on est moins enclin à le diviser en modules, couches, etc.

C'est juste de la paresse déguisée en compétence. Il ne faut pas beaucoup d'efforts pour garder ce que vous travaillez activement dans votre tête. Il faut de l'habileté pour trouver les coutures appropriées et diviser le code le long de celles-ci. Les codeurs qui disent qu'il était plus rapide ou préférable de tout laisser au même endroit ne voient souvent pas les éléments à répartir.

Assurez-vous simplement que ce n'est pas le cas car il travaille dans un environnement "Si votre clavier ne clique pas, vous ne travaillez pas". Nous regardons tous en arrière sur le code et nous nous demandons à quoi nous pensions. De plus, cette boutique a-t-elle l'habitude de refactoriser son code? C'était peut-être un luxe qui ne lui était pas accordé.

Cependant, nous devons rompre avec notre première idée (celle que vous pouvez simplement vous asseoir et marteler) et faire un peu plus de planification, de recherche, de réflexion. La tentation d'éliminer chaque petit problème est tentante et l'ensemble du projet est jonché de cette pratique. Personne ne veut payer des gens pour réparer des choses qui "ne sont pas cassées", alors pourquoi refactoriser.

Edit: Assurons-nous de ne pas punir ceux qui connaissent les réponses. Il y a ceux qui parlent couramment et écrivent du bon code avec rapidité. La clé n'est pas d'aborder tous les problèmes de cette façon.

100%.

La manière cynique d'envisager cela serait que ces types de codeurs maintiennent en fait la majorité des développeurs au travail, corrigeant des bogues qui sont si fondamentaux que vous pouvez y consacrer des milliers d'heures de développement sans arriver à mi-chemin à un système stable, flexible et sécurisé. , modulaire ou [votre propriété logicielle préférée]. Ces systèmes ont tellement d'idiosyncrasies que l'idée même de migrer vers quelque chose d'autre, même avec 95% des fonctionnalités déjà en place et une communauté dynamique derrière, est considérée quelque part entre ridicule et motif de licenciement.

En bref, les codeurs qui parlent couramment peuvent faire plus de dégâts qu'une horde de concurrents, mais le prix est généralement payé sur plusieurs années. Et ils faisaient généralement simplement leur travail (tel que défini par quelqu'un d'autre).

Comment savoir si vous êtes développeur ou codeur? Je suppose que c'est impossible, mais chaque fois que vous trouvez un moyen de simplifier votre code sans réduire la qualité, vous avez franchi une nouvelle étape vers l'illumination.

Le problème que vous avez décrit était essentiellement NIH ("non inventé ici") - y a-t-il d'autres symptômes?

Parfois, le NIH, en particulier s'il est isolé pour une ou deux personnes, peut être traité dans une discussion de groupe ("Joe ici a une certaine expérience dans la réalisation de sauvegardes SQL à l'aide de bibliothèques standard - qu'en pensez-vous, Joe?"). Cela pourrait être moins conflictuel que d'aller directement à la personne et de lui dire "Hé! Utilisez la bibliothèque standard, mannequin!" :)

Ayant été à la fois dans votre situation et ayant causé des situations similaires, je comprends votre frustration, mais je pense que la réponse à votre question est un «non» catégorique. La fluidité ne garantit pas qu'un programmeur va produire du code maintenable. Souvent, les organisations obligent les programmeurs à fournir des logiciels mal conçus et mis en œuvre en raison de contraintes budgétaires et temporelles ridicules. Il est possible que le programmeur courant coupe les coins ronds, seuls les programmeurs se soucient de fournir quelque chose qui intéresse les clients. Évidemment, ce n'est pas bon dans la pratique, mais malheureusement une réalité que la plupart des programmeurs doivent gérer à un moment donné de leur carrière. Il y a aussi la possibilité que le programmeur fluide soit juste paresseux ou complaisant. Je peux parler un anglais parfait, mais c'est plus facile et plus amusant d'utiliser l'argot.

En ce qui concerne l'utilisation du code des autres ou le déploiement de votre propre argument, je pense que cela dépend vraiment de ce qui fait le mieux le travail. Parfois, «meilleur» ne tient pas compte de choses comme le style et la maintenabilité si «meilleur» signifie livrer un projet de six semaines en deux semaines. C'est pourquoi nous refactorisons et affinons. De plus, le développeur doit être conscient de ce qui est disponible en termes de code tiers et il doit savoir comment l'utiliser et avoir confiance qu'il fonctionnera et sera correctement pris en charge / maintenu. Étant donné qu'il existe des milliers de cadres optionnels, de bibliothèques et d'API pour tout paradigme de développement populaire, l'utilisation de telles choses peut finir par coûter plus de temps, d'énergie et de stress que de simplement rouler le vôtre. En outre, je trouve des cas où le code tiers ne fait tout simplement pas exactement ce dont j'ai besoin - c'est quand il '

Je suis dans ce bateau (ancien code écrit couramment) et j'ai été du type couramment pendant un certain temps.

Le plus grand obstacle aux solutions «rapides et sales» est toujours lorsque vous devez en ajouter plus tard. Lorsque vous avez besoin de plus de fonctionnalités. Vous ne pouvez pas faire grand-chose sans structure. Après cela, il casse, et il est coûteux de le réorganiser (encore satisfaisant, mais pas vraiment apprécié).

Fondamentalement, vous devez vous prémunir contre tout piratage qui pourrait potentiellement devenir une "solution viable", prête à être vendue par un vendeur avide. C'est l'ancien "Ce n'est pas prêt! - Mais ça marche, non?" énigme.