Je peux écrire du code… mais je ne peux pas bien concevoir. Aucune suggestion? [fermé]

83

Je sens que je suis doué pour écrire du code par morceaux, mais mes dessins sont vraiment nuls. La question est de savoir comment améliorer mes conceptions - et devenir un meilleur concepteur?

Je pense que les écoles et les collèges font un bon travail pour enseigner aux gens comment devenir bons en résolution de problèmes mathématiques, mais admettons que la plupart des applications créées à l'école mesurent généralement entre 1 000 et 2 000 lignes, ce qui signifie qu'il s'agit principalement d'un exercice académique. ce qui ne reflète pas la complexité des logiciels du monde réel - de l'ordre de quelques centaines de milliers à des millions de lignes de code.

C’est là que je pense que même des projets tels que topcoder / project euler ne seront pas d’un grand secours, ils pourraient peut-être améliorer votre capacité de résolution de problèmes mathématiques - mais vous pourriez devenir un programmeur universitaire; Quelqu'un qui est plus intéressé par les trucs gentils et propres, qui est totalement désintéressé par les trucs quotidiens et poilus que la plupart des programmeurs d'applications traitent.

Ma question est donc de savoir comment améliorer mes compétences en conception? C’est-à-dire, la capacité de concevoir des applications à petite / moyenne échelle qui iront dans quelques milliers de lignes de code? Comment puis-je acquérir des compétences de conception qui m'aideront à construire un meilleur kit d'édition HTML ou un programme graphique tel que gimp?

design skills utilisateur396089
la source
1
"admettons que la plupart des applications créées à l'école mesurent généralement entre 1 000 et 2 000 lignes, ce qui signifie qu'il s'agit principalement d'un exercice académique ne reflétant pas la complexité des logiciels du monde réel". semestre de projet logiciel dans lequel une équipe de dix étudiants a développé une application assez complexe sur une période de 6 à 8 mois. En outre, de nombreuses entreprises (du moins en Allemagne) proposent des contrats courts aux étudiants qui souhaitent s’entraîner avant la fin de leurs études.
Giorgio
la copie de ma conception proposée est généralement pire que celle de mon collègue - comment puis-je m'améliorer? et de Comment devenir bon en analyse et conception orientées objet (OOAD)?
moucheron

Réponses:

87

La seule façon de devenir vraiment bon dans quelque chose est d’essayer, d’échouer de façon spectaculaire, d’essayer à nouveau, d’échouer de nouveau un peu moins qu’avant, et de développer au fil du temps l’expérience nécessaire pour reconnaître les causes de vos échecs afin de pouvoir gérer les situations d’échec potentielles ultérieurement. C’est aussi vrai d’apprendre à jouer d’un instrument de musique, à conduire une voiture ou à gagner un âge PWN sérieux dans votre jeu de tir à la première personne préféré, tout comme l’apprentissage de n’importe quel aspect du développement logiciel.

Il n'y a pas de véritables raccourcis, mais vous pouvez faire certaines choses pour éviter que les problèmes ne vous échappent pendant que vous gagnez de l'expérience.

  • Identifiez un bon mentor . Il n'y a rien de mieux que de pouvoir parler de vos problèmes avec quelqu'un qui a déjà payé sa cotisation. L’orientation est un excellent moyen d’accélérer l’apprentissage.
  • Lisez , lisez encore, pratiquez ce que vous avez lu et répétez-le tout au long de votre carrière. Je fais ce genre de choses depuis plus de 20 ans et j'ai toujours la chance d'apprendre quelque chose de nouveau chaque jour. En savoir plus sur la conception initiale, mais aussi sur la conception émergente, les tests, les meilleures pratiques, les processus et les méthodologies. Tous ont un impact variable sur la manière dont vos conceptions vont émerger, se dessiner et, plus important encore, comment elles durent dans le temps.
  • Trouvez le temps de bricoler . Impliquez-vous dans un projet de skunkwork sur votre lieu de travail ou entraînez-vous à votre rythme . Cela va de pair avec votre lecture, en mettant vos nouvelles connaissances en pratique et en voyant comment cela fonctionnera. C’est également ce qui permet une bonne discussion avec votre mentor.
  • Impliquez- vous avec quelque chose de technique en dehors de votre lieu de travail. Cela pourrait être un projet ou un forum. Quelque chose qui vous permettra de tester vos théories et vos idées en dehors de votre cercle de pairs immédiat afin de conserver une perspective nouvelle sur les choses.
  • Sois patient . Reconnaissez que gagner de l’expérience prend du temps et apprenez à accepter le fait que vous devez vous retirer un peu afin de savoir pourquoi et où vous avez échoué.
  • Tenez un journal ou un blog de vos tâches, de vos pensées, de vos échecs et de vos succès. Cela n’est pas strictement nécessaire, mais j’ai trouvé qu’il pouvait être très utile de voir comment vous avez évolué au fil du temps, comment vos compétences se sont développées et vos pensées ont changé. Je reviens dans mes propres journaux tous les quelques mois et jette un œil à ce que j'ai écrit il y a 4-5 ans. C'est une véritable révélation de découvrir à quel point j'avais appris à cette époque. C'est aussi un rappel que je me suis trompé de temps en temps. C'est un rappel sain qui m'aide à m'améliorer.
S.Robins
la source
45
+1 pour essayer et échouer. Parce que quand vous ne comprenez pas pourquoi il y a un motif de conception, vous ne pouvez pas l'utiliser efficacement.
Mert Akcakaya
2
+1 excellente réponse, mais je trouve que c'est un peu incomplet. Je pense que la contribution la plus importante serait de loin d'avoir un très bon appétit pour le refactoring. Écrivez, regardez ce que dit la théorie (articles, livres ou mentor), refacturez / réécrivez, revenez à la théorie, refacturez / réécrivez - cela vous donnera le temps de vous concentrer sur la structure tout en travaillant avec un code familier. Soyez votre propre pire critique. Je dirais aussi qu'il est très important que vous ne perdiez jamais cet appétit pour revoir constamment votre propre travail.
vski
1
@vski Il y a de nombreux concepts que j'aurais pu inclure, mais la question est de savoir si ces concepts constitueraient en eux-mêmes un moyen raisonnable d'acquérir l'expérience nécessaire pour que le PO se considère comme un concepteur amélioré. Dans le cadre de ma réponse, je considère la refactorisation comme une pratique (conformément à mon deuxième point). Il en va de même pour Clean Code, Test First, BDD et de nombreux autres concepts. J'ai adopté l'approche selon laquelle de nombreuses compétences et expériences sont nécessaires pour évoluer à un point tel que les compétences en conception vont émerger et se développer, avec l'expérience et les connaissances acquises au fil du temps. :)
S.Robins
2
+1 pour avoir un mentor. Idéalement, demandez à votre mentor de réviser le code avec vous. Le fait de demander à quelqu'un d'autre de lire et de critiquer votre code peut vraiment vous aider pour améliorer la conception et la rendre plus propre.
Leo
2
"Jamais essayé. Jamais échoué. Peu importe. Essaie encore. Echoue encore. Echoue mieux." Samuel Beckett
Peter K.
16

Eh bien, il n’ya pas de pomme d’or dans ce genre de question, et j’estime que c’est peut-être à chaque codeur de trouver ce qui lui convient. Voici ma prise, de toute façon.

Vous pourriez lire des livres sur le sujet. Grands livres. Livres fantastiques. Mais je trouve que ces livres ne vous aident que lorsque vous avez essayé de créer et de concevoir une application - et que vous avez échoué.

Pour moi, tout est une question d'expérience. Quand j'ai commencé comme recrue, j'ai lu des livres sur la conception. Je n'ai pas beaucoup compris le contenu à l'époque. Quand j'ai commencé à travailler et que je devais concevoir des applications moi-même, je faisais des applications très compliquées. Ils travaillaient, mais ils étaient pénibles à maintenir. Ensuite, j'ai relu ces livres - et cette fois, je les ai mieux compris.

Maintenant, je continue à faire de nouvelles erreurs et à apprendre des anciennes.

Amadeus Hein
la source
10
Il y a un point important qui mérite d'être signalé: continuez à faire de nouvelles erreurs; ne continuez pas à faire les mêmes vieilles erreurs - apprenez d'eux et faites quelque chose de nouveau.
Bevan
11

Arrêtez de concevoir et apprendre à refactoriser le code. Un développement progressif avec une refactorisation continue et agressive donnera un produit final beaucoup plus propre que toute conception initiale.

Kevin Cline
la source
2
Le design émergent est une belle chose à mon humble avis, mais sans discipline, vous risquez de créer des "spaghettis émergents". Le problème avec la conception initiale, c’est que les gens la voient comme une proposition de tout ou rien, ce qui leur donne une mauvaise réputation lorsque les choses tournent mal. Cela me rappelle l'un des articles de Joel où il mentionne que le design est important. Ce dont vous avez besoin, cependant, est suffisant au départ pour qu'un dessin puisse faire la différence sans que cela ne vous prive de temps, de ressources et de votre chance de voir de magnifiques dessins de soutien émerger de manière organique grâce à un code propre.
S.Robins
@ S.Robins: Je pensais que le PO attaquait toujours des projets suffisamment petits pour être très bien terminés avec TDD et une refactorisation continue. Il peut ainsi apprendre la discipline nécessaire pour savoir combien de design est nécessaire pour des projets plus complexes.
kevin Cline
Je pensais que c'était peut-être le cas, mais j'estimais qu'il valait peut-être la peine d'ajouter un contrepoids à l'idée que "toute conception initiale" sera potentiellement pire qu'une chose purement émergente. Je conviens toutefois que pour acquérir l'expérience nécessaire recherchée par le PO, il faut au début se préoccuper moins de la conception et se concentrer sur la rédaction d'un code propre, bien factorisé. :-)
S.Robins
Je ne suis pas d'accord pour dire que la refactorisation mène toujours au meilleur design. Bien entendu, la refactorisation vous permet souvent d’explorer et de comprendre le problème, mais une bonne conception n’émerge pas toujours progressivement à travers la refactorisation. Parfois, vous voyez une bien meilleure solution et réalisez que votre code actuel en est si éloigné que la réécriture est beaucoup plus rapide que le refactoring.
Giorgio
J'ai eu cette expérience récemment: je continuais à refactoriser et à refaire et à tourner dans un cercle avec les mêmes problèmes encore et encore: j'utilisais des itérateurs pour coder quelque chose et le code continuait à devenir très complexe. Ensuite, j'ai décidé d'oublier les itérateurs et j'ai dû réécrire une grande partie du code, mais la logique est devenue beaucoup plus claire et concise qu'auparavant. Je ne sais pas si vous appelleriez cela une "refactorisation agressive": la structure globale de l'application n'a pas été modifiée, mais certaines parties fondamentales ont été simplement jetées et réécrites à partir de zéro.
Giorgio
7

Lisez sur les modèles, bien sûr, mais surtout sur les anti-modèles. Reconnaître les anti-modèles est important, et il est plus facile de comprendre pourquoi quelque chose ne devrait pas être fait de la sorte.

Voir http://sourcemaking.com/antipatterns/software-development-antipatterns par exemple.

Écrivez le code afin qu'il puisse être ajusté rapidement si les exigences changent (ce qui est très courant dans l'environnement de production).

Soyez sceptique quant à l'ajout de "juste un petit bidouillage de plus". Un de plus ici, un de plus là-bas, et le code devient immuable.

Valorisez le principe d'ouverture / fermeture .

Écrire des tests (comme dans TDD). Ils vous obligent à réfléchir à votre conception avant même de la mettre en œuvre.

Parcourez le code des projets open source (ceux de taille raisonnable). J'avais l'habitude d'être surprise - en général - de voir autant de niveaux d'abstraction. Maintenant, je comprends que ce n'est pas de l'art pour l'art, il y a une raison pour laquelle c'est fait de cette façon.

Konrad Morawski
la source
4

Un principe que je trouve très important pour une bonne conception est la décomposition: si une classe est trop grande (plus de, disons, 300 à 400 lignes de code), divisez-la en classes plus petites; si une méthode est trop grande (disons plus de 50 lignes de code), décomposez-la; si un projet contient plus de 50 classes, décomposez-le.

La clé consiste à estimer la taille de votre système et à construire plusieurs couches d'abstraction (par exemple, sous-système, application, projet, module, classe, méthode) qui vous permettent de décomposer votre code en unités compréhensibles avec des relations claires entre elles et peu de dépendances.

Giorgio
la source
1
Bien que votre suggestion soit fondée, les lignes de code importent peu, mais le comportement importe. Si votre méthode fait plus d'une chose, il est probablement temps de la refactoriser. Si cette seule chose appelle simplement des méthodes qui font une chose elles-mêmes et les assemble, c'est très bien.
Jer
1
@jer: C'est une règle de base, bien sûr. Une méthode appelant 100 autres méthodes consiste, comme vous dites, à assembler des éléments (elle appelle une liste de sous-fonctions). Je pense plus aux méthodes qui contiennent une logique réelle: c'est généralement un mauvais signe si vous devez faire beaucoup de va-et-vient pour comprendre ce qu'une méthode fait. Même chose si vous regardez une définition de classe avec beaucoup de membres (et que la classe n'est pas simplement une grande collection de propriétés plates).
Giorgio
"le projet contient plus de 50 classes, décomposez-le" n'est pas grave
dynamique
@ yes123: C'était destiné à donner une idée. Cela dépend vraiment de ce que vous développez, dans quelle langue, etc.
Giorgio
Je pense qu'il serait judicieux de noter que cela n'aidera pas la conception initiale (puisque vous êtes en train de la refactoriser), mais aidera à apprendre les modèles et les meilleures pratiques qui amélioreront vos futures conceptions.
Craig Bovis
0

C'est difficile, ce dont nous parlons vraiment, c'est d'une capacité à résumer plutôt qu'à créer un meilleur code, mais deux choses vous rendront meilleur et une chose vous rendra plus heureux:

"Mieux"

A) Trouvez le meilleur designer possible et associez un programme / une conception ensemble. Demandez-leur d’expliquer ce qu’ils pensent en résolvant le problème, ne vous contentez pas de "cela semble juste" et continuez à creuser. Ce processus aidera aussi la partie "mentoring"

B) Imaginez tout comme des acteurs individuels et des conversations entre eux. Chacun des acteurs devrait avoir un rôle / une responsabilité unique et des groupes d'entre eux gérer des systèmes différents. Si cette conversation fonctionne et que chaque acteur se sent cohérent, vous êtes sur la bonne voie.

Et "plus heureux"

C) Si vous avez fait de votre mieux et que cela ne se produit toujours pas, il n’ya rien de mal à accepter que certaines personnes ne puissent pas faire certaines choses. Vous pourriez écrire un code serré et brillant, mais ne jamais être capable de concevoir ou d'architecte. Et alors? Je ne peux pas faire de sport physique pour caramel au beurre, je ne suis pas beau et ma conduite automobile ne sera jamais meilleure que la moyenne. Revel et utiliser ce que vous êtes bon.

Stuart Muckley
la source
-1

Dans mon expérience personnelle, lire le code des autres est une bonne source "d’inspiration". Je veux dire, essayez de comprendre les conceptions des autres et demandez-vous pourquoi il / elle fait les choses de cette manière?

vous pouvez trouver beaucoup de projets open source pour la recherche.

de toute façon vous avez besoin de pratique.

PCJ
la source
-1

Ne pas vivre dans la peur

Viser la simplicité

Écoutez vos utilisateurs

Essayez beaucoup d'idées

Créer quelque chose, puis l'améliorer

Travaillez sur des choses qui ajoutent de la valeur, abandonnez des choses qui ne le font pas

erturne
la source
-1

Apprenez à poser les bonnes questions. Le plus souvent, vous améliorerez votre conception en examinant le problème sous un angle différent. Cela vous aidera en particulier à ne pas vous concentrer sur la résolution du problème mais à vous pencher davantage sur des solutions permettant de résoudre de multiples problèmes connexes.

Craig Bovis
la source