Tentations nuisibles dans la programmation
Juste curieux, quels types de tentations dans la programmation se sont avérés vraiment néfastes dans vos projets?
Comme quand vous ressentez vraiment le besoin de faire quelque chose et que vous croyez que cela va bénéficier au projet ou bien vous vous trompez simplement en le croyant, et après une semaine, vous vous rendez compte que vous n'en avez résolu aucun de vrais problèmes mais en ont créé de nouveaux ou, dans le meilleur des cas, ont fait plaisir à votre bête intérieure sans impact visible.
Personnellement, je trouve très difficile de ne pas refactoriser le mauvais code. Je travaille avec beaucoup de mauvais code hérité, et cela prend quelques respirations profondes pour ne pas le toucher quand je n'ai aucun test pour prouver que mon refactoring ne casse rien.
Un autre démon pour moi dans l'interface utilisateur, je peux littéralement passer des heures à changer la disposition de l'interface utilisateur simplement parce que j'aime le faire. Parfois, je me dis que je travaille sur la convivialité, mais la vérité est que j'adore déplacer les boutons.
Quels sont vos démons de programmation, et comment les évitez-vous?
La généralisation prématurée est mon gros bugaboo; au lieu de résoudre le problème en cours d'abord et d'attendre qu'il y ait un réel besoin de résoudre le cas général, je vais toujours après le cas général à l'avant et finissez par écrire une tonne de code plus complexe que nécessaire.
Mise à jour:
Voir " Sin # 1 - Généralisation prématurée " pour une description détaillée.
"Nous y reviendrons et le réparerons plus tard. Nous avons juste besoin qu'il fonctionne maintenant!"
La date limite est tellement éloignée, j'ai plus que suffisamment de temps pour le faire, alors pourquoi ne pas passer un peu de temps à surfer sur le web?
"Ce n'est qu'un code de preuve de concept jetable. Une fois qu'ils l'aimeront, je le rendrai vraiment bien."
- Refactoring une partie du code quelques jours avant la sortie.
- Internet: La plus grande distraction de tous.
- Nouvelle technologie: Je ne peux pas garder les mains sur les nouvelles technologies.
- Optimiser: Optimiser, Optimiser. .. et plus encore Optimiser
- Perfection: Jamais été satisfait du code.
- TODO: Manque de todos de temps qui ne seront jamais faits.
- Estimation du temps: De nombreux PM ne considèrent pas cela comme une "estimation". Ils prennent comme fait.
- Promesses: Donner trop de promesses.
Devenir la proie d'essayer de tout construire en interne, lorsqu'il existe des frameworks et des bibliothèques.
Mes démons récurrents: optimisation prématurée et ingénierie excessive.
Et je ne peux toujours pas les éviter à 100% ...
Estimations trop optimistes
Lorsque votre manager vous regarde fixement et que vous ressentez la sensation de brûlure de donner une estimation inférieure à ce que votre instinct vous dit ... ne le faites pas !
Après tout, votre instinct est probablement déjà trop bas!
Utiliser une technologie/un outil/un langage dans votre projet uniquement parce que vous venez de l'apprendre.
Pour essayer de prouver à quel point vous êtes un bon développeur.
Pour considérer que le code que vous avez écrit vous appartient.
Je vais juste faire une pause et regarder stackoverflow.com;)
La pire tentation:
Oh, eh bien ... Je suppose qu'un sale petit truc/hack/fix ne va pas faire de mal.
Devinez quoi, ça fait mal. :)
Fonction Fluage
Faites un plan, respectez-le et déployez. Et alors retournez en arrière et ajoutez ce que les gens demandent.
Je l'ai vu encore et encore. Vous vous asseyez, élaborez la conception et commencez à coder. Les utilisateurs entendent des bêtises confuses sur le fait que leur fonctionnalité préférée est "manquante" et ils commencent à faire pression pour cela. Votre patron vous demande de l'ajouter à la 11ème heure, il encrasse le déploiement, il introduit des bugs partout, et 3 mois plus tard, une fois que tout le monde s'est installé, vous êtes invité à le supprimer, car personne ne peut comprendre pourquoi vous mettez cette fonctionnalité rétro merdique en premier lieu! Ne pourriez-vous pas dire que le reste de la conception le rendait inutile?
Ajoutez plus de fonctionnalités
La compétition a cette fonctionnalité. C'est donc une fonctionnalité incontournable, donc plus de programmation que d'analyser la stratégie, le positionnement, etc.
Le concours n'a PAS cette fonctionnalité. Il s'agit donc d'une caractéristique différenciante, donc plus de programmation que d'analyser la stratégie, le positionnement, etc.
Résoudre un problème commercial avec plus de programmation. Par exemple, une meilleure expertise dans l'administration du serveur Linux sur lequel votre site Web est hébergé ne peut pas être acquise en programmant plus de fonctionnalités. Parfois, il suffit d'apprendre à résoudre le problème plutôt que de recoder le tout en C # .Net
Résoudre un problème de marketing avec plus de programmation. par exemple, abuser du concept de vache pourpre de Seth Godin selon lequel vous résolvez indirectement un problème de marketing en programmant plus de fonctionnalités dans votre produit pour en faire une "vache pourpre". Parfois, c'est juste un monstre mutant.
Résoudre un problème de productivité avec plus de programmation en vous faisant valoir que le temps passé à écrire ce script sera économisé en heures à l'avenir au lieu de réellement programmer des choses vraiment importantes
Vous prévoyez de coder mais pas encore de coder parce que vous voulez "bien faire les choses"
Coder une version sale et promettre que vous "l'améliorerez plus tard" mais ne reviendrez jamais à "l'améliorer"
Ne pas faire de maquette ou de plan du site car c'est "tellement gênant". Je peux juste faire une capture d'écran des pages des concurrents pour les maquettes et dessiner le plan du site à main levée "plus tard", ce qui n'est jamais le cas. Et puis allez directement dans la programmation de la première page que je visualise dans mon esprit.
Confession: J'ai personnellement fait des erreurs 1, 3, 7, 8. J'ai aussi fait 2, 4, 5, 6 mais je me suis souvent trompé que je n'ai pas fait.
Je corrige actuellement 9.
[~ # ~] modifier [~ # ~] Je ne savais pas que la question nous obligeait à apporter des solutions.
1) Ajoutez plus de fonctionnalités Ne le faites tout simplement pas. Travaillez avec votre entreprise, le marketing, les fondateurs, les conseillers, etc. et dépouillez votre application à une seule chose.
Allez lire sur Twitter, Groupon , etc. sur la façon dont ils réduisent les choses à une seule chose qui a conduit à leur succès.
Si vous pensez que cela ne fonctionne que si vous souhaitez créer de grandes entreprises, détrompez-vous. Ctrl + F pour cette ligne "Plus j'ajoute de fonctionnalités au logiciel, pire il se vend. (C'est, il va sans dire, très peu intuitif pour la plupart des développeurs de logiciels.)" Dans ce lien
2) Le concours a cette fonctionnalité. C'est donc une fonction indispensable
Voir la solution 1
3) Le concours N'A PAS cette fonctionnalité. C'est donc une caractéristique différenciante
Voir la solution 1
4) Résolution d'un problème commercial avec plus de programmation.
Si vous avez besoin d'embaucher quelqu'un pour vous enseigner, donner une consultation ou le faire pour vous, puis documenter comment il l'a fait, afin que vous puissiez le faire vous-même la prochaine fois. SIMPLEMENT FAIS-LE!! Ne réécrivez pas le code, ne passez pas GO, ne collectez pas 200 $.
5) Résolution d'un problème de marketing avec plus de programmation.
Si les gens ne comprennent pas ce que vous vendez, c'est IS un problème de marketing. Revenez à la solution 1 et pivotez.
6) Résolution d'un problème de productivité avec plus de programmation
Attendre.
Attendez jusqu'à ce que vous sentiez que votre productivité a souffert d'un problème de productivité particulier pendant une période supérieure à 2 semaines et que cela se produira raisonnablement pendant 2 semaines supplémentaires.
Maintenant, évaluez le temps passé à programmer un script pour résoudre ce problème. N'oubliez pas de prendre votre pire estimation et de multiplier par 2.
Multipliez votre estimation par votre taux horaire.
Examinez maintenant les solutions alternatives: externalisez, achetez une solution standard, ne faites rien, etc.
Choisissez la solution la plus rentable.
Tenez-vous-y.
7) Prévoyez de coder mais pas encore de coder parce que vous voulez "bien faire les choses"
Faites de l'exercice. Vous ressentirez une ruée d'endorphines qui motivera votre cul et vous fera planifier d'agir. Je le sais parce que je viens de faire des benchpresses 5x5 et des squats 5x5.
8) Coder une version sale et promettre que vous "l'améliorerez plus tard" mais ne reviendrez jamais à "l'améliorer"
Configurez un système de fichiers tickler dans GTD. et faire un suivi agressif. Suivez toutes les promesses faites à vous-même et aux autres.
9) Ne pas faire de maquette ou de sitemap car c'est "tellement gênant".
Allez dépenser 75 USD pour une édition de bureau de maquettes balsamiq. Je le sais car je l'ai acheté il y a 3 semaines. Cela m'a fait refaire mes maquettes parce que je me sens comme un artiste, architecte et visionnaire tout en 1 même si mon dessin dans le monde réel est nul. La police utilisée dans balsamiq vous rappelle inconsciemment qu'il ne s'agit que d'une maquette, non figée qui vous aide dans RAD.
Fin EDIT
Quelques bières m'aideront à travailler mieux et plus longtemps.
"Ouais, je peux refactoriser ce gigantesque désordre de 2000 lignes de spaghetti en une journée ..."
"Je peux me débrouiller sans test pour ça. C'est trop difficile à tester."
et c'est le mauvais frère,
"Je dois passer un test pour cela, peu importe la difficulté du test à écrire ou à comprendre."
Procrastination et estimation de tâche optimiste sont mes plus grands péchés.
Étirements, pompes ou tractions (ou tout autre exercice physique) pour la première et humeur pessimiste avant de donner une estimation pour la seconde.
"Il est beaucoup plus facile ( 'de réimplémenter la fonctionnalité à partir de zéro que de comprendre le code existant."
Une tentation massivement néfaste dont a souffert le projet sur lequel je suis est l '"effet de plate-forme intérieure". C'est une approche que les architectes, qui ont depuis longtemps disparu, ont mis en place dans leur sagesse infinie qui a créé un projet qui génère environ 20 millions de dollars par an mais coûte 60 millions à mettre à jour et à maintenir (chiffres approximatifs évidemment, mais c'est l'ampleur du problème).
NIH - Pas inventé ici
J'ai beaucoup de mal à donner aux solutions tierces une chance équitable. Tout le monde devrait naturellement être sceptique vis-à-vis des solutions tierces qui ne sont pas faites sur mesure pour eux, mais j'ai du mal à être objectif à 100%.
Le gain de temps peut être si énorme que même si 9 fois sur 10 la solution tierce doit être évitée, je dois être suffisamment objectif pour réaliser celle Ça marchera.
Le Il doit y avoir une bibliothèque qui fait ça quelque part syndrome.
étroitement liée à
Le plugin fétiche
Conception, codage et ou tests unitaires par rapport aux "données d'échantillonnage" fournies au lieu d'analyser une copie de la base de données réelle des clients. Le délai était court et ils n'arrêtaient pas de dire que ça venait mais ça ne l'a jamais fait. Lors de son déploiement, l'explosion a été spectaculaire. Vraiment, qui se serait attendu à ce qu'un client ait 3 clients parents.
Je ne recommencerai plus jamais un projet avant d'avoir une copie des données réelles.
Le perfectionnisme tue; probablement la principale raison pour laquelle les projets ne réussissent pas.
Réécriture au lieu de refactoring.
Eh bien, parfois, la programmation me pousse à la bouteille.
Penser qu'il doit y avoir une meilleure façon de le faire. Je ne vais pas me contenter de quelque chose qui pourrait être "assez bon". Je ne prends rien de moins que la perfection! Habituellement, cela est évité en parlant à d'autres personnes qui peuvent avoir un point de vue différent sur un problème ou en voyant une solution sous un angle différent.
Automatiser tout au point consacre plus de temps à la maintenance des outils qu'au travail réel.
Solution: tout comme pour l'optimisation du code, trouvez d'abord les goulots d'étranglement de la productivité et seulement après leur découverte, corrigez-les avec une bonne automatisation.
Quels sont vos démons de programmation?
En dehors de ce que certains ont mentionné.
Priorisation: Ignorer le travail hautement prioritaire en ce qui concerne le projet et travailler sur d'autres choses dans le projet d'abord parce que, elles sont plus intéressantes!
Comment les évitez-vous?
Avec un peu plus d'autodiscipline. Sérieusement, l'auto-discipline et l'auto-motivation pour faire la bonne chose aident à éviter la plupart de ces "démons".
Mon cerveau est épuisé par ce projet. Je vais juste faire une petite pause sur ce court projet pour le rajeunir.
"There must be a better solution to this."
Et vous finissez par penser et penser, et laisser votre esprit dériver vers un pays lointain jusqu'à ce que vous réalisiez que vous êtes parti depuis trop longtemps. Ça devrait aller, mais pas quand vous avez un délai.
Nous n'avons pas encore obtenu l'approbation du client mais la date limite approche donc voici quelques comps préliminaires pour que vous puissiez commencer ...
Plus tard, après avoir terminé la construction du projet pour qu'il corresponde aux compositions ...
Oh, voici les révisions du client, il veut juste changer quelques petites choses *
(* la fonctionnalité principale est entièrement différente)
Ensuite, vous continuez de refactoriser votre code d'origine, sur la base du modèle défectueux d'origine au lieu de simplement recommencer à zéro car vous êtes sous la pression d'un court délai et supposez que ce sont les dernières révisions.
Je suis toujours mordu par celui-ci. C'est difficile à éviter en tant que développeur web. Mon meilleur conseil est de pousser pour plus de temps afin que vous puissiez effectuer les changements de la bonne façon.
Écriture d'un nouveau code après la date de gel du code.
La date de gel du code doit être gravée dans la pierre. Tout nouveau code écrit après avoir été déplacé vers la future version, car il peut nécessiter toutes sortes de tests de régression.
Pour répondre à la question de les éviter: Familiarisez-vous avec Anti-Patterns pour pouvoir les appeler lorsque vous les reconnaissez.
Habileté. Bien sûr, pas toujours. Un peu d'intelligence et de concision rendra votre code très agréable et maintenable. Mais juste parce que vous pouvez faire
x=foo?true:bar?biz,FooBar(true)?!foo:baz,FooBar(false):baz;
au lieu de quelques lignes d'instructions if, ne signifie pas que vous devriez.
Btw, oui je sais qu'il y a un peu de redondance dans mon exemple ... Si tu l'as même pris toi-même :)
Tous les autres plus présentent un fluage: "Ce serait vraiment cool s'il faisait cela, et je sais que le client va l'adorer et l'aurait mis dans les spécifications s'il y avait pensé". J'essaye d'éviter cela en demandant où dans la vraie spécification existe l'exigence pour cette fonctionnalité vraiment cool.
Là encore, je n'ai pas souvent de spécifications écrites.
"ce n'est que le pilote, il n'est donc pas nécessaire de faciliter la maintenance ou l'expansion".
D'après mon expérience, il est plus courant de voir le pilote entrer en production et le produit qu'il est censé être un pilote pour être mis au rebut que pour le pilote à mettre au rebut et le produit réel développé à l'état prêt pour la production.
Passer trop de temps à modifier l'éditeur. Essayer de trouver la meilleure police et le meilleur schéma de couleurs pour la programmation.
"On m'a assigné une fonctionnalité qui s'interface avec [logiciel/par exemple: sharepoint]. Je devrais probablement tout savoir sur ce logiciel."
Ensuite, vous passez des semaines à rechercher ce produit, alors que la fonctionnalité aurait pu être écrite et testée en un jour ou deux. La faim de savoir a un ventre sombre. rawr
"Je commenterai/documenterai plus tard"
cela n'arrive jamais, l'auteur passe à autre chose, puis vous découvrez qu'il ne commente pas son code lorsque le travail vous a été attribué.
Pour commencer à attaquer un nouveau projet, sans le comprendre, et j'évite généralement cela en recherchant un peu sur le domaine du projet avant de commencer à travailler avec, juste pour avoir un bon point de départ et pour prouver que le projet est plus complexe que J'ai d'abord traversé ça.
J'ai aussi le problème que j'aime me déplacer avec des boutons, ils sont tellement cool !! Mais c'est peut-être parce que je fais des systèmes multimédias et la conception d'interfaces utilisateur ... Donc, pour moi, la solution à ce problème, était d'inclure cela dans mon programme et d'étudier quelque chose à ce sujet, afin d'avoir une excuse valable si quelqu'un le voit je joue beaucoup avec l'interface utilisateur. (Et cela inclut le fond vert, le texte orange et les icônes avec beaucoup de jaune.)
Liste très complète: anti-patterns .
/**
* Calculates the return value for humptyDumpty
*
* return int modifiedHumptyDumpty
*/
function awesomeWayToCalculateSomething(int humptyDumpty) {
..
}
TODO: J'ai besoin de documenter cela correctement.
Will _never_ arrive
Utiliser une fonction de langue, un idiome ou un modèle de conception non pas parce que c'est la meilleure solution au problème, mais uniquement pour le plaisir de l'utiliser.
Je pense que j'ai en tête que les énumérations sont beaucoup plus utiles qu'elles ne le sont vraiment en Java. J'ai tendance à essayer d'en faire trop, puis à m'enliser car ils ne supportent pas vraiment le polymorphisme.
en vous engageant à éviter le développement en interne, 90% d'une roue n'est pas mieux que d'en inventer une.
Utiliser un cadre sans le comprendre pleinement. Mais encore une fois. un cadre n'est pleinement compris que par ses créateurs (la plupart des cas). Je n'ai pas de vraie solution pour cet élément mais j'essaie de comprendre autant que possible à partir d'un cadre.
Correction d'un bug qui vous dérange parce qu'il est "si simple", mais sans jamais le dire à QC et/ou au client.
Ces correctifs bloquent toujours la production.
Quelqu'un a dit une généralisation prématurée, mais spécialisation prématurée peut être tout aussi mauvais. Avec une généralisation prématurée, vous pouvez obtenir un logiciel qui fonctionne pour 50% des cas, mais une spécialisation prématurée peut fonctionner pour 5%, voire aucune. Au final, la direction aurait préféré 50% à 5%.
Faire d'innombrables heures de travail supplémentaire pour l'entreprise pendant mon temps libre pour découvrir "ce n'était pas la direction qu'ils recherchaient".
Quels sont vos démons de programmation,
Tout ce qui a déjà été mentionné, en particulier l'envie de refactoriser comme un fou.
et comment les évitez-vous?
Avant de commencer toute modification non triviale, retirez mes mains du clavier pendant 5 secondes et pesez rapidement les résultats possibles de la modification par rapport à sa sortie. Ensuite, avant de vous engager, pesez les mêmes conséquences pendant environ une minute.
Pour trouver un canapé confortable pour travailler ou travailler allongé dans son lit.
Être "parfait"
Tout en évitant de bien faire les choses la première fois est un problème, ce n'est pas aussi mauvais qu'un accent éternel sur la perfection. Faites-le simplement, il n'y a rien de parfait, et s'il y en a, c'est purement temporel, ou déjà fait et ne vaut pas le temps de recommencer.