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

16

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)?

Konrad Morawski
la source
24
"Donnez-moi six heures pour abattre un arbre et je passerai les quatre premiers à affûter la hache." --Abraham Lincoln "Aiguisez votre hache à votre rythme." - La plupart des boss
JeffO
15
Une certaine confusion ici pour moi causée par le titre, comme quand je lis 'couramment'I.ThinkOf(this).KindOfThing()
Benjol
Avez-vous demandé à ce développeur senior la raison pour laquelle il a fait ces choses? Comme vous l'avez déjà indiqué, l'application est boguée. Alors peut-être que le développeur senior était limité dans ce qu'il était capable de faire lui-même avec cette application de buggy. Si son code ne fonctionne que «la plupart du temps», il contient des bogues et doit être remplacé et / ou corrigé.
Ramhound
@Ramhound - non, car il avait quitté l'entreprise avant mon arrivée. Il était la dernière personne à y travailler avant que je ne m'en occupe. Je sais par des collègues qu'il était pressé, car la réparation de l'application était une priorité en raison de nombreuses plaintes de clients. Mais il ne faisait pas un très bon travail en termes de gestion du temps, car il franchissait de temps en temps une porte ouverte. BTW il a créé sa propre bibliothèque pour localiser les applications WPF et Winforms.
Konrad Morawski
1
hautement liés: ceci et cela . Certains (beaucoup) de gens sont bloqués à ce stade ...
BlueRaja - Danny Pflughoeft

Réponses:

22

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.

pdr
la source
1
J'ai aussi été ce type - et je ne suis pas d'accord avec la deuxième phrase. Être capable de résoudre la plupart des problèmes ne signifie pas que vos solutions sont robustes, maintenables, flexibles, évolutives ... ou même que l'implémentation initiale est développée aussi rapidement. Beaucoup des meilleures idées que vous apprenez en dehors des manuels de référence de langue / bibliothèque sont des choses qui sont "pourquoi n'y ai-je pas pensé?" simple, et aussi flexible, évolutive, etc. L' une des pires choses - se rendre compte que je suis exposé à une idée plus tôt, mais rejeté comme une absurdité académique inutile sans pratique, quand je avais besoin ...
Steve314
6
Dans certaines organisations, l'obtention de l'autorisation d' utiliser une bibliothèque tierce peut prendre six mois ou plus. Dans certains cas, vous pouvez attendre les six mois et être refusé à la fin, de toute façon. J'ai déjà créé un ORM unique juste parce que je ne voulais pas perdre de temps à gérer la bureaucratie alors que j'étais déjà sur une courte période.
Toby
2
@Toby: Juste point. Mais ces entreprises sont généralement au-delà de l'épargne de toute façon.
pdr
Sans oublier que l'US Air Force est la même que celles mentionnées par @Toby. Nous avons essayé de faire passer Ruby on Rails, mais ils n'ont pas aimé.
Travis Pessetto
@Toby il y a quelques cas où réinventer la roue est la bonne chose à faire, la clé est de s'assurer que vous comprenez pourquoi vous êtes
jk.
14

• 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.

Christopher Bibbs
la source
1
Oui en effet. Et je suppose que je serais plus opposé aux gens de ce genre si je n'avais pas bien gagné ma vie au cours des années à venir les nettoyer ... ;-)
Mike Woodhouse
4

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.

JeffO
la source
Exactement ma pensée. Si l'objectif principal de l'entreprise est de livrer le plus rapidement possible, les gens travaillent souvent tard et font des choses qu'ils ne feraient pas s'ils étaient autorisés à travailler sans pression. Vous vous sentez plus "productif" et utile si vous tapez beaucoup de code auquel vous pensez en tapant. Se pencher en arrière pour réfléchir, ou même pour discuter avec des collègues sur un problème, ce genre de choses vous donne facilement l'impression de retarder le projet. Vous pourriez coder à ce moment-là, non? ;-).
deadsven
J'ai eu de la chance. J'ai été autorisée à travailler à domicile après avoir déménagé. Tout le monde veut savoir si c'est fait et je ne travaille pas. Je ne vais pas être puni pour avoir connu la réponse.
JeffO
3

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.

l0b0
la source
1

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!" :)

Scott C Wilson
la source
1

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 '

Daniel Pereira
la source
0

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.

MPelletier
la source
comment cela répond-il à la question posée?
moucher
@gnat La question étant "Que pensez-vous de cela?", ma réponse était ce que je pensais. Je suis toujours du même avis: la maîtrise (donc pouvoir faire des solutions rapides, des hacks, etc.) peut conduire à un code nuisible à long terme. Vous ne pouvez pas simplement parler couramment une langue, vous devez savoir organiser le code.
MPelletier