Comment incitez-vous les gens à valoriser l'abstraction et la flexibilité plutôt que de «simplement le faire»?

Question

J'ai parfois des difficultés avec les autres personnes qui souhaitent résoudre un problème lorsqu'elles souhaitent ignorer les interfaces officielles et accéder directement aux détails de la mise en œuvre sous-jacente.

Ils soutiennent que cela leur permettra de résoudre le problème plus rapidement. Je soutiens que cela entraînera un couplage plus étroit de notre architecture et une modification difficile du fait de l’apparition de nouvelles exigences.

Je signale tous les travaux menés dans la conception actuelle, la philosophie de conception et la valeur de la flexibilité, les coûts liés à la maintenance et à la modification du code fragile, la valeur de l'encapsulation et du masquage des données et des architectures en couches, être robuste, de sorte que de petits changements dans les spécifications entraînent de petits changements dans le code. Et ils disent: "Mais ce serait plus facile."

Comment gérez-vous ces personnes?

Answer 1

Les convaincre que prendre des raccourcis est une fausse économie.

Expliquez que l'effort initial de codage représente moins de 30% de l'effort de développement initial et moins de 10% (selon mon expérience) de l'effort global du projet (maintenance comprise).

S'ils ne sont pas convaincus et que vous en avez l'autorité, dites-leur de le faire à votre façon. Si vous n'avez pas l'autorité, alors ne faites rien d'autre. Finalement, votre superviseur, s’il vaut quelque chose, le reconnaîtra et vous serez alors en position d’autorité.

Answer 2

Demandez-leur de travailler sur un code hérité qui corrige les bugs qu’il contient. C’est à peu près ce que la plupart des gens que je connais ont appris ces leçons vraiment utiles… à la dure.

Answer 3

" Plus facile " quand? Maintenant, quand tout n'est pas en mutation? Ou trois mois à partir de maintenant, lorsque les exigences du client ont changé et qu'il dispose d'une "solution" qui n'est plus une solution?

Je ne suis pas très motivé par la structure et les règles mais par les raisons de savoir A) qui conduit le bateau B) quelles sont les règles et C) pourquoi nous avons choisi de le faire de cette façon .

Dans mon magasin, nous n'aimons pas avoir à réécrire du code car nous avons gâché et codé en dur un tas de choses ou créé une "solution" fragile au problème. Il n’est pas plus difficile de suivre l’approche plus souple une fois que les gens se rendent compte que cela atténuera les frustrations plus tard lorsque tout sera bouleversé par toute une série de changements d’exigences. Nous codons pour le "long courrier" et non pour le "besoin d'aujourd'hui", donc le design est créé pour une raison et le design est suivi pour la même raison. .

J'ai passé une semaine de ma vie (7 jours consécutifs) à réécrire un module parce que j'étais en mode "faites-le vite". Sept jours de jeu épuisant, 10-12 heures par jour à faire correctement, tard dans le match, alors que j'aurais pu regarder le Super Bowl. Ce puant. J'ai appris une leçon là-bas. Peut-être que vos "amis" devront eux aussi faire l'expérience de cette révélation.

Bonne chance!

Answer 4

Je déteste vraiment prendre l'opinion dissidente à ce sujet, mais ...

Pour citer Van Halen (citant le cliché), "il existe une heure et un lieu pour tout". Bien que je ne recommande certainement pas mal d'écrire, jamais, parfois, vous devez simplement le faire, et trouver ce juste milieu entre robuste / endurant et piraté / documenté. (La partie documentée est particulièrement importante sur deux fronts: premièrement, vous indiquez clairement que tout ce que vous faites est fait simplement dans le but de le faire et prend certains raccourcis; et, deuxièmement, une idée approximative quant à la manière la plus correcte d’aborder le problème.

En tant que programmeurs, nous nous efforçons souvent d’écrire le code parfait (enfin, certains d’entre nous), et nous perdons parfois de vue la situation dans son ensemble. rapide avec le code, tout en minimisant l’impact que cela aura sur la route.

Veuillez ne pas utiliser ceci comme justification - la règle des 80/20 s'applique ici, bien sûr. La plupart du temps, vous voulez absolument écraser les raccourcis le long de ces lignes; mais parfois ...

Answer 5

Montrez-les! Laissez-les faire un petit module dans " Mais ce serait plus facile. & Quot; style tout en le faisant de la bonne façon. Puis, demandez-leur d’apporter 2 à 5 modifications aux exigences (il s’agit des modifications) et d’avoir un concours chronométré pour l’application des modifications. Cela peut prendre un jour ou deux, mais ils l'obtiendront. Sinon, vous aurez la même discussion pour chaque nouveau projet ou nouvelle tâche.

Answer 6

Vous pouvez essayer une analogie sur eux ....

Les règles des échecs sont assez simples. Vous pouvez leur apprendre à un enfant: "le cheval se déplace comme ça", "le château se déplace comme ça", etc.

Si c'est tout ce que vous savez, vous pouvez jouer aux échecs et probablement passer un bon moment, mais une personne ayant une connaissance approfondie du jeu va effacer le tableau avec vous à chaque fois. Vous serez battu si fort que ce ne sera même plus amusant, parce que vous ne saurez pas comment ils le feront.

Le même principe s'applique à la programmation. Connaître la syntaxe du langage et quelques structures de données simples suffit pour obtenir un programme fonctionnel, mais vous n'aurez pas beaucoup de chance avec une application à grande échelle qui doit survivre à plusieurs cycles de publication.

Les échecs ont défini des ouvertures, des stratégies d'attaque, etc. Nous avons des modèles de conception.

Answer 7

La meilleure chose à faire est probablement de les promouvoir à la direction afin qu’ils ne puissent pas faire autant de dégâts.

Answer 8

Le problème est que la plupart des gens ne connaissent même pas la conception de logiciels autres que les concepts les plus fondamentaux et le développement de styles par glisser-déposer. Pour chaque développeur qui fait des recherches et s’instruit sur les meilleurs nouveaux concepts et technologies, il y en a dix qui rentrent chez eux et ne regardent pas un PC. Vous devez leur apprendre.

Answer 9

J'ai conçu un système complexe et complexe il y a environ cinq ans. J'ai passé les cinq années suivantes à m'injecter dans chaque projet qui affectait "mon" système pour empêcher les barbares de souiller mon architecture. Tant que j'ai appliqué une pression constante et sans faille, j'ai pu garder l'architecture propre, mais je livrais une bataille perdue d'avance. Voici pourquoi:

1) La plupart des gens sont jugés sur le fait qu'ils aient ou non accompli le travail aujourd'hui . Personne n'a jamais été réprimandé parce qu'il y a trois ans, ils ont pris le temps de lancer un projet à temps. D'autre part, de nombreuses personnes ont été réprimandées pour ne pas avoir mis les projets à exécution à temps.

2) Vous voudrez peut-être garder le système en ordre parce que vous avez un sentiment de propriété sur le code, l'application, les utilisateurs, etc. Beaucoup de gens n'auront pas de sentiment de propriété et sont donc trop heureux de pirater quelque chose afin qu'ils puissent être fait avec elle. Vous pouvez conduire un cheval à l’eau, mais vous ne pouvez pas lui faire prendre soin de lui.

3) Si vous réussissez à convaincre tout le monde de maintenir le code correctement, de nouvelles personnes se joignent à vous et ont besoin d'apprendre à bien faire les choses. Ainsi, même si vous réussissez, vous pouvez avoir l’impression que vous échouez, car vous livrez toujours le même combat à de nouveaux adversaires.

4) Vous pourriez vous tromper. Est-il judicieux sur le plan financier pour Microsoft de passer deux fois plus d'heures de programmation pour rendre MS-Paint robuste et facile à maintenir? Parfois, un système très mal organisé est assez bon. La plupart des bons programmeurs ont du mal à comprendre cela, mais c'est généralement parce qu'ils sont de bons programmeurs.

5) Je jure qu'il y a des gens qui prennent un plaisir pervers à pirater des choses ensemble, soit parce qu'ils peuvent le faire plus rapidement, soit ils seront les seuls à le comprendre, soit ils auront un besoin enfantin d'enfreindre les règles. Vous ne pouvez pas raisonner avec ces personnes, et plus vous passez de temps à vous disputer avec elles, plus la date butoir du projet approche, ce qui vous obligera de toute façon à pirater quelque chose.

6) Vous avez de bonnes chances de comprendre le système mieux qu’eux. Ce qui vous ressemble pourrait ressembler à "ronger légèrement". à une personne qui n'est pas aussi familière avec le système. Ou l'effort supplémentaire de rendre le code robuste protégera le programmeur contre un problème qu'il n'a jamais eu auparavant et qu'il ne peut donc pas régler. Vous n’apprenez pas à vérifier les codes de retour tant que quelque chose ne va pas, car vous n’avez pas vérifié un code de retour. À ce stade, il cesse d'être un "travail supplémentaire". et commence à être "un travail requis".

Si vous avez une petite équipe de développement étroite, c'est possible. Mais plus l'organisation est grande, moins vous avez de chances de réussir. Si vous réussissez à convaincre un magasin informatique de 250 personnes de bien faire les choses bien avant de faire vite, votre pouvoir de persuasion est légendaire.

Answer 10

http://catb.org/jargon/html/L/LART.html SCNR, etc. pp;)

Answer 11

Dites-leur de lire (ce qu’ils ne liront jamais) La théorie de l’encapsulation: http://www.edmundkirwan.com/