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

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?

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.

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.

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.

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.

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.

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.

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.

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

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.