Quel est le problème avec le codage créatif? [fermé]

42

Je regardais Bob Ross peindre des "arbres heureux" ce soir et j'ai compris ce qui m'inquiétait pour mon code ces derniers temps.

La communauté de gens d'ici et de Stack Overflow semble rejeter toute odeur d'imperfection. Mon but est d'écrire un code respectable (et donc maintenable et fonctionnel) en améliorant mes compétences. Pourtant, je code de manière créative.

Laissez-moi vous expliquer ce que je veux dire par "coder de manière créative":

  • Mes premières étapes dans un projet consistent souvent à s'asseoir et à extraire du code. Pour les grandes choses, je prévois un peu ici et là, mais je plonge surtout dans.
  • Je ne trace aucun de mes cours, sauf si je travaille avec d'autres créateurs d'autres pièces du projet. Même alors, ce n'est certainement pas la première chose que je fais. En général, je ne travaille pas sur de gros projets et je ne trouve pas le visuel très utile.
  • Le premier cycle de code que j'écris sera réécrit plusieurs fois à mesure que je teste, simplifie, rétablis et transforme le piratage original en quelque chose de réutilisable, logique et efficace.

Pendant ce processus, je nettoie toujours. Je supprime le code inutilisé et commente tout ce qui n’est pas évident. Je teste constamment.

Mon processus semble aller à l'encontre de ce qui est acceptable dans la communauté des développeurs professionnels, et j'aimerais comprendre pourquoi.

Je sais que le problème, c'est que quelqu'un s'est retrouvé coincé dans le fouillis d'un ancien employé, ce qui a nécessité beaucoup de temps et d'argent. Ça je comprends. Ce que je ne comprends pas, c'est que mon processus est erroné, étant donné que le résultat final est similaire à ce que vous obtiendrez en planifiant tout depuis le début. (Ou du moins, c'est ce que j'ai trouvé.)

L’inquiétude que je ressens à propos de cette question a été si intense ces derniers temps que j’ai arrêté de coder jusqu’à ce que je sache tout ce qu’il ya à propos de chaque méthode pour résoudre le problème particulier sur lequel je travaille. En d'autres termes, j'ai presque complètement arrêté de coder.

J'apprécie sincèrement votre contribution, quelle que soit votre opinion sur la question.

Edit: Merci à tous pour vos réponses. J'ai appris quelque chose de chacun d'eux. Vous avez tous été des plus utiles.

Brad
la source
6
Votre façon de travailler ne vous dérange pas, vous savez ce qui est important pour le résultat final et c'est ce qui compte vraiment. C'est juste que vous pourriez avoir de la difficulté à travailler avec une grande équipe de cette façon, mais vous vous adapterez probablement si c'est le cas. On dirait vraiment que vous vous dirigez
Bjarke Freund-Hansen
39
Des mois de réécriture vous feront économiser des jours de planification!
Jonas
3
@ Jonas: Bien. Mais vous ne devriez vraiment pas sous-estimer Analysis Paralysis. Avec tous les "bons conseils" sur les méthodologies, les modèles de conception, etc. de nos jours, il est vraiment facile de donner l’impression que vous devriez planifier, analyser et concevoir pendant des jours et des jours avant même de toucher une seule ligne de code. . Et cela peut facilement devenir très contre-productif. La réalité, à mon avis, est de comprendre ce que la planification et la conception peuvent vous aider à long terme, et de savoir quand plonger pour avoir une idée de ce sur quoi vous travaillez et pour que quelque chose soit fait.
Bjarke Freund-Hansen
4
Extrait du manifeste Agile: "Le logiciel utilisé est la principale mesure de progrès."
Gary Rowe
2
C'est presque comme si le monde de la programmation était plein de primadones. Je ne peux pas vous dire à quel point il est frustrant de consulter SO et de voir une question parfaitement valide rétrograder 5 fois, parce que l'utilisateur n'écrit pas dans un anglais parfait ou que le code est considéré comme "trop ​​débutant" pour que l'élite puisse s'en occuper.
Scottie

Réponses:

29

Il n'y a rien de mal avec code-test-refactor-repeat, dites simplement aux gens que vous prototypez.

D'un autre côté, pour les projets plus importants, vous constaterez qu'une réflexion sur la conception dès le départ vous fera gagner beaucoup de temps dans la boucle de la merde!

PS: Les techniques de création de diagrammes vous aident à acquérir des techniques de réflexion visuelle, qui sont utiles même si vous ne voyez jamais vos diagrammes.

Steven A. Lowe
la source
4
"code-test-refactor-repeat" (ou une certaine permutation de celui-ci) est la façon dont nous écrivons le code. Peut-être que Superman est "codé", mais les mortels doivent itérer.
Martin Wickman
5
@Martin: il est souvent avantageux de penser d'avance dans cette boucle ;-)
Steven A. Lowe
4
aussi longtemps que vous savez combien il y en a!
Frank Shearar
Merci pour votre réponse. Je n'avais jamais pensé à ce que je faisais, c'était du prototypage, mais c'est effectivement ce que je fais. Votre réponse m'a donné une nouvelle façon de voir les choses et j'apprécie beaucoup votre réponse.
Brad
7
@ Brad, n'oubliez pas que les prototypes doivent parfois mourir au lieu d'évoluer.
21

Je préfère toujours un code clair, lisible et simple à tout code UMLed, à motif de conception, présenté visuellement, où classe / interface inclut des noms de motif tels que "ItemVisitor" (?!). Les modèles de conception, les techniques OO et tout le reste doivent formaliser les règles. Ces règles viennent du bon sens.

Il est impossible de travailler sans cette formalisation (sauf si vous travaillez seul sur votre propre projet) et la surformalisation augmente les coûts du projet. Ne négligez jamais les besoins des autres pour comprendre votre code. Le meilleur code est le plus simple.

N'hésitez jamais à ré-écrire votre code. Je vais obtenir X votes négatifs (X> = 10) pour cela, mais je vais le mettre en gras: la réutilisabilité du code n'est pas la chose la plus importante .

Avant de commencer à coder, vous devez considérer les cas d'utilisation que le code va implémenter. Parce que le logiciel doit être utilisé et non développé. La convivialité et l'utilité sont les deux cibles les plus importantes, et peu importe qui va utiliser ce logiciel - un autre développeur de parties dépendantes du projet, ou l'utilisateur final.

duros
la source
4
+1 pour "la réutilisabilité du code n'est pas la chose la plus importante". Parfois, vous avez besoin d'un couteau suisse, parfois, d'un scalpel.
mu est trop court
Merci pour vos commentaires. En ce qui concerne l’utilisation du logiciel résultant, c’est définitivement quelque chose que je garde à l’esprit tout au long du processus. Je suis d'accord, c'est la partie la plus importante. J'ai mentionné la réutilisabilité du code, car cela contribue grandement à la réalisation de cet objectif.
Brad
+1 à nouveau pour "la réutilisabilité du code n'est pas la chose la plus importante" et pas un seul vote négatif (jusqu'à présent)
Gary Rowe
Je pense que l'accent mis sur la "réutilisation" était une version approximative de Don't Repeat Yourself et l'élimination de la duplication.
Rob K
"Utiliser avant de réutiliser" en a même fait un joli petit livre: 97things.oreilly.com/wiki/index.php/…
Lovis
14

Je suis à peu près le même chemin. Écoutez quand d'autres personnes vous parlent de choses qui ont fonctionné pour elles, mais ignorez ceux qui vous disent ce que vous devriez "faire" comme s'il y avait un impératif moral. Si vous trouvez quelque chose qui fonctionne pour vous, allez-y. Je veux dire, le résultat final est ce qui est important, n'est-ce pas? Qui se soucie vraiment du chemin que vous avez pris pour y arriver?

Rappelez-vous: les gens sont différents . C'est une bonne chose. N'écoutez pas les gens qui essaient de vous faire aimer, et résistez à l'envie de faire d'autres personnes comme vous et tout ira bien.

Jason Baker
la source
Toute personne qui dit quelque chose devrait être fait un certain besoin doit avoir de bonnes raisons de le suggérer. S'ils ne peuvent pas fournir une bonne raison, claire et logique, leur "devrait" devient un "peut-être devrait".
Le Tin Man
1
@Greg - Même dans ce cas, une bonne raison, claire et logique, pourrait bien être totalement illogique pour moi.
Jason Baker
1
+1 Quiconque dit que vous devriez absolument faire cela et c'est tout simplement faux. Bien sûr, vous devez étudier et écouter les autres (en particulier les grands et les plus expérimentés), réfléchir sérieusement, essayer et comparer des approches alternatives, etc., mais à la fin, faites ce que vous trouvez juste. Si vous voulez simplement être médiocre, alors suivez le processus de conception, mais pour tout ce qui est digne d'intérêt, vous devez vous faire confiance.
Joonas Pulakka
+1 - Personnellement, je pourrais commencer par un diagramme ou le faire de manière officielle, mais c'est parce que la méthode officielle fonctionne pour moi. Vous ne pouvez pas vraiment apprendre aux gens à devenir plus intelligents ou plus créatifs. Ce sont des adultes établis dans leurs manières. Vous les embauchez ou vous ne les louez pas.
Job
6

Il semble que vous soyez:

  1. Essayer des solutions pour trouver la meilleure approche (expérimenter, conception incrémentielle)
  2. Réécrire le code pour le rendre plus propre (refactoring)
  3. Rédiger constamment des tests (développement piloté par les tests)

Ce que tu fais est génial! On dirait que vous le faites parfaitement, surtout si vous l'avez compris par vous-même et que vous ne l'avez pas appris d'un livre de programmation (agile). Il y a évidemment plus à cela, mais vous avez les valeurs clouées. Rappelez-vous simplement de refactoriser et d’améliorer la conception pendant l’ajout de code . Un BDUF ne devrait pas être nécessaire .

Avez-vous envisagé de vous concentrer sur une petite fonctionnalité à la fois et de la publier après avoir terminé chaque fonctionnalité? Cela pourrait vous aider à vous libérer de tout problème d’analyse avec lequel vous avez des difficultés et à démontrer de réels progrès pour votre employeur.

De plus, je ne sais pas de quelle "communauté de développement professionnel" vous parlez, mais si c'était votre cas, je leur dirais de retourner dans leurs tours d'ivoire pour que vous puissiez continuer votre travail!

Martin Wickman
la source
Je suis entièrement à vos côtés sur ce point, ce qui fait écho à ma propre réponse.
Eric O Lebigot
4

Brad, tu n'es pas seul. Je connais de très bons programmeurs qui travaillent exactement comme vous le décrivez. :)

Si vous nettoyez votre code et savez comment le rendre efficace et lisible, vous avez certainement compris comment écrire du code propre et efficace dès le départ.

En outre, rien ne peut être entièrement planifié à l’avance et le moyen le plus rapide de découvrir les subtilités consiste souvent à exécuter le code et à comprendre les détails négligés.

Je pense que vous vous débrouillez parfaitement bien et que le style de programmation que vous décrivez est parfaitement valide.

Eric O Lebigot
la source
4

Je pense que cela vaut la peine de compléter les réponses ci-dessus avec une citation de Alan J. Perlis, extrait de la préface du célèbre ouvrage du MIT intitulé "Structure et interprétation des programmes informatiques", communément appelé "SICP":

Chaque programme informatique est un modèle, né dans l’esprit, d’un processus réel ou mental. Ces processus, issus de l’expérience et de la pensée humaines, sont très nombreux, complexes dans le détail et, à tout moment, mal compris. Ils sont modelés à notre satisfaction permanente rarement par nos programmes informatiques. Ainsi, même si nos programmes sont des ensembles de symboles discrets, mosaïques de fonctions imbriquées, soigneusement élaborés à la main, ils évoluent en permanence: nous les modifions à mesure que notre perception du modèle s'approfondit, s'élargit, se généralise jusqu'à ce que le modèle atteigne finalement une place métastable dans un autre modèle encore. nous luttons."

Yugo Amaryl
la source
bien placé. Ce sont des modèles primitifs, des modèles humanistes et enfin des modèles surhumains, car le programmeur réfléchit de plus en plus aux actions qui se déroulent dans le code.
easymoden00b
3

Il y a Bon Clever et Bad Clever.

Good Clever - ratio élevé entre les lignes de code intelligentes et les lignes de dans une alternative non intelligente. 20 lignes de code qui vous évitent d'écrire 20000, c'est extrêmement bien. Good Clever consiste à vous sauver du travail.

Mauvais malin - faible ratio entre les lignes de code écrites écrites par rapport aux lignes de code sauvegardées. Bad Clever est une ligne de code intelligente qui vous évite d'écrire cinq lignes de code. Mauvais malin parle de "masturbation syntaxique".

Juste pour noter: Bad Clever n'est presque jamais appelé "Bad Clever"; il voyagera souvent sous les pseudonymes "beau", "élégant", "concis" ou "succinct".

utilisateur8865
la source
1
"beau", "élégant", "concis" ou "succinct". ..... Je pense avoir déjà vu cela sur la page d'accueil de Ruby on Rails. :-D
Brad
1
Peut-être que c'est juste moi, mais je pense qu'une réduction de 80% de la LOC vaut une certaine intelligence.
récursive
J'en ai trouvé beaucoup pour qualifier les choses de "masturbation syntaxique", alors qu'en fait c'est juste une question de paresseux pour apprendre la langue qu'elles utilisent ...
Svish
3

Je peux vraiment me reconnaître dans la façon dont vous décrivez votre flux de travail. Voici la chose: quand j'ai commencé à travailler dans un environnement de groupe, presque tout ce que je devais changer devait changer.

Le travail dans lequel je travaille depuis environ 8 mois est vraiment ma première expérience de travail dans une équipe de développeurs sur un seul projet. Jusqu'à présent, toute ma carrière a été littéralement une carrière de codeur de loup solitaire qui n'a pas eu à gérer tout ce que le travail d'équipe implique. Même lorsque je travaillais en groupe, c’était toujours un travail assez cloisonné - mon projet était MINE, ou une partie de celui-ci était MINE, etc. C’était une courbe d’apprentissage intéressante, car je me suis familiarisé avec une environnement de travail d'équipe réellement collaboratif.

Voici l'essentiel que j'ai compris: si ce que vous faites n'est pas évident, vous écrivez probablement le prochain mal de tête d'un collègue. La plupart des problèmes que vous voyez ici sont liés au fait que beaucoup d'entre nous ont été le collègue qui a mal à la tête. Et la plupart des théories relatives à la gestion des processus logiciels concernent la réduction de ces maux de tête.

Il faut donc planifier à l'avance un plan convenu, etc. Il s'agit d'avoir une équipe à bord et synchronisée. Si vous êtes l'équipe, vous êtes déjà synchronisé avec vous-même et ce n'est pas vraiment nécessaire.

Dan Ray
la source
2

Il n’ya rien de mal à votre approche en tant qu’art créatif. Si vous développez pour votre bénéfice personnel et que ce que vous faites fonctionne pour vous, et que vous le trouvez agréable est probablement aussi important que le résultat final que le produit lui-même.

Dans un environnement de travail professionnel, si les délais de votre projet sont courts, par exemple 2 à 3 semaines ou moins, votre approche est appelée prototypage rapide et convient parfaitement aux tâches qui vous attendent.

Cependant, sur des projets plus longs, même lorsque vous travaillez seul, une telle approche est probablement un luxe coûteux pour votre employeur. Consacrer quelques jours du budget du projet à la conception de l'architecture initiale, puis tester l'architecture par rapport à si la direction décidait de modifier la spécification de ... est normalement du temps dépensé et développera vos compétences pour devenir un programmeur / architecte plus précieux dans ta carrière.

Michael Shaw
la source
2

Deux perspectives:

  1. Personne ne doit entretenir une peinture.

  2. Quiconque a déjà vu Bob Ross peindre une peinture sait que les peintures ont une structure. Si vous vouliez retenir une leçon de Bob Ross, ce serait que la planification et le travail organisé facilitent le processus et le rendent simple.

Caleb
la source
1
Bob Ross n'a jamais peint les arbres heureux avant de peindre le ciel derrière eux.
Rob K
1

Je code à peu près de la même manière. Je vais juste commencer à écrire et quand je vois des motifs émerger, je refacture. Vous pouvez vous situer dans un coin de cette façon, vous devez savoir quand vous asseoir et réfléchir à un problème, mais vous devez parfois tenter votre chance pour bien comprendre le problème.

Mais je suis curieux à ce sujet:

La communauté de gens d'ici et de Stack Overflow semble rejeter toute odeur d'imperfection. [..] Mon processus semble aller à l'encontre de ce qui est acceptable dans la communauté des développeurs professionnels, et j'aimerais comprendre pourquoi.

Comment quelqu'un à Stack Overflow connaît-il votre processus? Et qu'entendez-vous par "rejeter"? Naturellement, le code envoyé à une communauté de programmation va faire l’objet d’un examen critique. Mais si quelqu'un repère des domaines dans lesquels votre code peut être amélioré, cela ne peut être qu'une bonne chose, non?

Espérons que lorsque vous posez une question sur Stackframe, vous nettoyez votre code et essayez de la réduire à la forme la plus simple possible, par respect pour vos lecteurs (vous résolvez parfois votre propre problème simplement en essayant de le rendre présentable aux autres), dans lequel cas, tout retour est bon. Si vous postez un code que vous savez mauvais et que vous savez pourquoi c'est mauvais avant de le poster, vous ne devriez pas le prendre personnellement si les gens remarquent que c'est mauvais.

Boue
la source
Je ne faisais référence à aucune question ou réponse que j'ai personnellement posée. Lorsque je poste des questions, je les décompose dans le cas le plus simple possible et avec mes réponses. J'ai remarqué que lorsque d'autres personnes affichent un code pas si parfait dans leurs questions, ou ne savent pas vraiment comment poser la bonne question, elles se font abattre à plusieurs reprises. Sur les cas limites où la question est proche d'une bonne question, je la modifie souvent ou j'ajoute des commentaires pour pousser le PO dans la bonne direction. Je ne pense pas que ce soit ce qui se passe normalement. [plus dans le commentaire suivant]
Brad
Quoi qu’il en soit, après avoir lu les réponses à ma question ici, j’ai le sentiment d’avoir mal interprété la communauté et d’avoir projeté des critiques sur les réponses à la critique de projets complets, qui, comme vous l’avez expliqué, sont deux choses différentes.
Brad
1

J'utilise aussi votre approche. Cela fonctionne mieux pour moi, car cela réduit le risque d'ingénierie excessive.

Ce que je fais très souvent est de résoudre un problème avec probablement le moins de code possible, ce qui conduit généralement à des dépendances apparemment inutiles ou à d'autres problèmes de conception. Ensuite, je refacture le code de travail en beau code.
Par exemple, je réduis les dépendances entre les différents modules pour créer des interfaces concises et je réfléchis à la question de savoir quelles données doivent être conservées où, jusqu'à ce que chaque module ne dépende que d'abstractions très minimalistes des autres modules. Vous pouvez dire, je reporte la décision finale, quel module devrait avoir quelle responsabilité. Je diffère l'abstraction.
Consacrer trop de temps à séparer un problème en responsabilités distinctes, en abstractions distinctes, n’est pas bon. Cela vous obligera à adapter votre implémentation à vos abstractions. Le code fonctionne s'il produit les résultats souhaités et s'il est maintenable. Une conception fonctionne si vous pouvez l'implémenter avec un bon code. Si le code ne fonctionne pas, vous le changez. Ainsi, si une conception ne fonctionne pas, vous devrez également la modifier. Vous pouvez seulement voir si un dessin fonctionne, une fois que vous l'avez implémenté.

Par conséquent, il suffit de dessiner un simple dessin avant de commencer à le concrétiser. Redesign, résumé et refactor au besoin .

back2dos
la source
1

Je pense que si vous voulez être bon en programmation, au moins parfois, il faut que ce soit amusant, et cela signifie être créatif.

Certes, lors de la programmation en groupe, il y a au moins des normes minimales à respecter, non pas pour des raisons "morales", mais pour des raisons pratiques, lorsqu'elles s'appliquent.

En dehors de cela, il est intéressant et amusant de sonder les limites pour voir ce que l'on peut y trouver. Une fois, lorsqu’on travaillait sur une Mini en langage assembleur, j’ai découvert que vous pouviez créer des co-routines pouvant basculer de l’une à l’autre avec 1 instruction. Ensuite, j'ai compris comment créer une auto-routine qui pourrait faire deux pas en avant, un pas en arrière, etc. Cela a-t-il été utile? J'en doute. Ce n'est pas le propos.

Une fois, j'ai entendu une conférence d'Edsger Dijkstra parler de la créativité dans la programmation. Il a expliqué comment un élève avait trouvé un moyen de faire pivoter un mot n + m en rotation sur n bits. Cela a été fait avec 3 bitswaps. Commencez par échanger les n bits, puis les m bits, puis les n + m entiers. Utile? Non, intelligent? Oui.

Il est bon de se sentir libre d'essayer des choses que personne ne pourrait faire.

Mike Dunlavey
la source
1

Cela peut être un cas de "taille unique ne convient pas à tous". Vous avez fait en sorte que votre style fonctionne pour les projets que vous avez réalisés, alors qui peut en discuter? Cependant, les critiques que vous lisez ici et sur SO peuvent travailler sur des projets plus importants ou sur des projets nécessitant une coordination complexe entre les membres de l'équipe.

Votre style de développement pourrait devenir un problème si vous étiez impliqué dans des projets plus importants impliquant une coopération entre plusieurs développeurs. Il est difficile de le programmer, il est difficile de suivre vos progrès, et il n’est pas possible pour vous autres programmeurs de planifier leur travail, qui dépend de la connaissance de ce que vous faites.

Vous pouvez être intéressé par la lecture de Dreaming in Code pour voir ce qui peut arriver lorsqu'un grand projet adopte un style de développement similaire au vôtre.

Charles E. Grant
la source
1
Merci pour votre réponse. Vos commentaires me sont utiles.
Brad
1

Bien rassuré sur le fait que votre méthode n'est pas fausse, laissez-moi ajouter une expérience personnelle. J'ai commencé par votre chemin, mais entre-temps, j'ai appris l'avantage de planifier à l'avance au moins une partie de la structure générale, et ce pour plusieurs raisons:

  • Le plus gros atout est qu'il est plus facile de voir quel code peut être réutilisé s'il est contourné un peu. J'écris souvent un morceau de code qui, en écrivant, semble soudainement utile pour une autre partie du schéma général accroché à côté de mon écran (dessiné sur papier dans un style uniquement lisible par moi).

  • Avoir un schéma vous permet de refactoriser non seulement le code, mais également le schéma. Parfois, je suis occupé à écrire un cours qui semble soudain utile pour une autre partie du projet. En conséquence, le schéma devient plus simple lorsque le projet est exécuté sur

  • Chaque fois, je mets à jour ce schéma avec les entrées requises et les sorties de fonctions / méthodes, et les emplacements disponibles dans les classes. Cela va plus vite pour la réutilisation de bits: je n'ai pas besoin de plonger dans le code à chaque fois pour vérifier ce qui entre et ce qui va exactement. Même si c'est dans les commentaires, il me reste à parcourir pour obtenir les commentaires

Donc en fait, j'utilise aussi votre méthode. Je viens de commencer, d’essayer, de refactoriser, d’essayer à nouveau, de changer un peu, etc., mais mon cycle inclut également le schéma. Et lorsque cela est fait, j'ajoute les informations pour le prochain qui fonctionne sur ce code.

Remarquez, ceci est pour des projets où je travaille seul. Si vous travaillez avec plus de personnes sur le même code, planifier à l'avance n'est pas seulement logique, c'est essentiel. Mais je suppose que vous le savez déjà.

Et comme d’autres l’ont dit: c’est ma façon de faire, votre kilométrage peut varier.

Joris Meys
la source