Loi de l'instrument et malédiction du programmeur

Si vous n'êtes pas familier avec le Loi de l'instrument, autrement connu comme le marteau / marteau de Maslow, ou le marteau d'or, il est souvent exprimé comme

Si votre seul outil est un marteau, vous traitez tout comme un clou.

Je crois comprendre que la loi de l'instrument signifie que vous êtes limité par des instruments ou des outils que vous savez utiliser. Par exemple, si vous avez une vis, du bois et un marteau, vous pourriez réussir à insérer la vis dans le bois, mais un tournevis serait une meilleure alternative.

La loi de l'instrument signifie également une obsession de la perfection des instruments que vous connaissez. Je me souviens de l'époque où j'étais convaincu qu'il n'y avait aucune raison de s'embêter avec d'autres langages de programmation parce que Delphi était le meilleur. Maintenant, j'ai passé du temps à utiliser beaucoup d'autres langages de programmation, et je peux donc affirmer avec confiance que Delphi est le meilleur, tout en voyant la valeur et l'utilisation d'autres langages de programmation.

Je pense qu'il vaut la peine de se renseigner sur les nouvelles technologies, cadres, langages ou méthodologies. Ensuite, vous pouvez choisir le bon pour le travail. Cela ne signifie pas que vous devez être un expert dans chacun d'entre eux, mais vous devez en savoir suffisamment pour être sûr de votre choix.

L'inverse est l'obsession de rechercher de nouvelles technologies passionnantes et de recréer des choses toutes les quelques années. Cela divertit les développeurs, mais n'apporte pas vraiment de valeur commerciale. Encore une fois, je pense que Delphi fait du bon travail avec cela car il respecte votre code existant tout en progressant vers de nouvelles plates-formes, fonctionnalités et cadres.

Alors quel est le Malédiction du programmeur?

Quand je parle à d'autres programmeurs, je vois deux comportements. Le premier est, à chaque problème qu'ils rencontrent dans la vie (au travail et au-delà), ils répondent avec "Je pourrais écrire un programme pour faire ça», Ou une variante. Par extension, ils jettent également un œil critique sur tout système logiciel (même ceux développés par eux-mêmes) pour voir comment les faire mieux. Cela se traduit par un énorme arriéré de projets qu'ils créent pour résoudre des problèmes, mieux résoudre un problème ou simplement par curiosité pour voir s'ils le peuvent.

Ceci est similaire à la loi de l'instrument, mais je le vois davantage que votre apprentissage de la flexibilité et de la puissance de la programmation vous permet de voir de nombreuses opportunités de l'appliquer. J'ai parlé à des gens d'autres industries et je pense que la tendance générale est assez universelle, c'est juste que la programmation est (à mon avis) beaucoup plus puissante et flexible que de nombreuses autres technologies appliquées.

Le deuxième comportement, dans lequel il faut être plus prudent de tomber, est le envie de créer un "bibliothèque" ou "cadre»Au lieu de terminer le programme en cours. Par exemple, vous créez un programme pour résoudre un problème et, ce faisant, vous créez une série de bibliothèques juste au cas où vous auriez besoin de résoudre des problèmes similaires.

Il est utile d'avoir des bibliothèques, des fonctions, des composants et des frameworks réutilisables. L'astuce est de ne pas laisser leur création gêner l'expédition. Le meilleur moyen que j'ai trouvé pour résoudre ce problème est de ne créer la bibliothèque que lorsque vous en avez besoin. Écrivez votre code avec le niveau de couplage approprié pour résoudre le problème à résoudre. Lorsque vous avez besoin d'en réutiliser un peu ailleurs, envisagez de le refactoriser en quelque chose de réutilisable. Ensuite, au fur et à mesure que vous l'utilisez dans plus d'endroits, vous pouvez continuer à le refactoriser et à l'étendre jusqu'à ce que vous ayez un cadre complet.

Comment voyez-vous la malédiction du programmeur dans votre vie? Qu'utilisez-vous pour empêcher chaque projet de générer une série de frameworks réutilisables?

La source:http://delphi.org/2018/01/curse-of-the-programmer/