Meilleure réponse
Question intéressante. Pour moi, le terme «artisanat» implique quelque chose sur la façon dont le code réel est écrit, plutôt que sur la conception du système de niveau supérieur. Je dirais quun code bien conçu fait ce qui suit:
- Suit des normes externes
- Suit des normes internes
- Utilise de bons modèles
- Est lisible
Suit des normes externes. Si votre groupe a des normes de codage, respectez-les. Si vous ne le faites pas » Comme les normes, suivez-les toujours.
Suit les normes internes. Cela signifie que le code doit être cohérent en interne. Les méthodes qui font des choses similaires doivent être présentées de la même manière. Si une méthode suit le modèle:
if (success) {
doSomething();
} else {
handleError();
}
n « ai pas d » autre méthode qui commence:
if (!success)
{
handleError();
Utilise de bons modèles. Jentends par là des modèles de codage plutôt que des modèles de conception. Votre code doit utiliser des idiomes appropriés pour le langage. (Utilisez scoped\_ptrs pour la gestion de la mémoire en C ++, par exemple). objets qui ne sont pas utilisés dans tous les chemins de code.
Est lisible. Dautres ingénieurs liront votre code et vous relirez dans un an. Le code doit être aussi simple que possible à comprendre. Tous les éléments mentionnés ci-dessus concernent principalement la lisibilité et la minimisation des éléments inattendus dans le code. Vos lecteurs doivent se préoccuper de la logique de votre code, et non pas essayer de comprendre pourquoi une construction non standard a été utilisée. Sil existe une construction non standard, vos lecteurs doivent savoir quelle existe pour une raison, pas parce que vous avez fait une erreur. (Considérez votre code comme un meuble. La surface doit être lisse, et vous ne devriez pas attraper un éclat si vous passez la main dessus. Toute irrégularité doit être là pour une raison.)
La lisibilité est également améliorée par des méthodes sensées et des noms de variables, et par des commentaires appropriés. Nallez pas trop loin dans les commentaires. Si cest évident, ne vous donnez pas la peine de lexpliquer. Mais ayez une sorte de vue densemble pour que le lecteur connaisse le contexte. (Il peut être évident que le code transforme lentrée X en sortie Y, mais cela aide si le lecteur a une idée de pourquoi cela est nécessaire.)
Réponse
Les gestionnaires sont comme les tout-petits. Ils veulent ce quils veulent et ils le veulent MAINTENANT ! Mais contrairement aux tout-petits, les responsables se souviennent à moitié des articles de Harvard Business Review quils citent (sans fournir de références) pour justifier leurs demandes. Ils ont appris un ensemble darguments qui déconcertent certains développeurs.
Ils disent: « Nous ne pouvons nous permettre de bien faire les choses. Nous devons lobtenir sur le marché MAINTENANT ! ». Ce n’est pas vrai, vous savez. Sils précipitent leur code spaghetti en production, ils ont une chance dénerver leurs clients de lancement maintenant, mais le code ne peut pas évoluer. Cela signifie simplement que leur entreprise va mal pendant un certain temps avant de seffondrer.
Ils disent: « Nous publierons une version bêta pour nos clients de lancement. » Ce quils veulent dire, cest quils veulent que vous publiiez un code parfait et agréable pour le client plus tôt que vous ne le feriez autrement, simplement parce quils ont accepté de lappeler un programme de test bêta. Cest une pensée magique, comme croire au Père Noël.
Ils disent: « Je vous promets que nous réécrirons le code plus tard si vous publiez votre code merdique à moitié fini MAINTENANT ! » Cela ne ressemble-t-il pas à « Je vais nettoyer ma chambre plus tard papa, si je peux regarder la télévision et manger des collations sucrées MAINTENANT ? » Le problème est que plus tard ne vient jamais. Chaque jour, le gestionnaire a le choix dajouter de nouvelles fonctionnalités ou de nettoyer la pièce en désordre qui est sa base de code. Devinez à qui ils donnent la priorité. Et devinez quoi, la pièce devient de plus en plus désordonnée, de sorte quil faudra de plus en plus de temps à nettoyer. Il est également plus difficile de travailler (pour créer de nouvelles fonctionnalités) à cause de tout le désordre.
Finalement, ils disent: «Nous avons trop investi dans cette base de code. La réécriture prendra trop de temps. Nous avons besoin de fonctionnalités MAINTENANT ! » Seule chaque fonctionnalité prend deux ou trois fois plus de temps à coder, à cause de la salle désordonnée que les développeurs de logiciels appellent la dette technique.
Les bons développeurs, comme des parents patients et aimants, doivent arrêter la folie. Ils doivent insister fermement: « Désolé mon amour, mais votre article de HBR dit: » Les revenus plus tôt, cest mieux, toutes choses étant égales par ailleurs . »Vous devez le lire plus attentivement.Toutes les autres choses ne sont pas égales si vous accumulez des dettes techniques. Que diriez-vous si nous accordons la priorité aux fonctionnalités, et peut-être quil y aura quelque chose à vendre plus tôt. »
Vous devez être un adulte et leur dire quil ny a pas de Père Noël, et non comme un code parfait et agréable pour le client jusquà ce que tous les bogues soient supprimés et que toutes les fonctionnalités soient implémentées.
Vous devez leur dire: « Nous ne pouvons pas nous permettre ne pas utiliser de bonnes pratiques. Nous vivons, ou nous mourons, mais nous devons faire certaines choses pour vivre, comme écrire des tests et de la documentation. Ce n’est pas une option. »
Vous devez sourire et dire:« Nous ne réécrirons jamais ce code. Je sais que vous voulez bien dire, mais quand il sagit de corriger le code ou dajouter de nouvelles fonctionnalités, je sais ce que vous allez dire. Cest ce que vous toujours dites. «
En étant un parent ferme, vous aidez votre responsable à devenir le genre de chef dentreprise que vous voudrait travailler pour.