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

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.

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.

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.

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.

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!

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.

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."

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".

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.

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.

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.

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.

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 .

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.

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.

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.