Je peux écrire du code ... mais je ne conçois pas bien. Aucune suggestion?
Je sens que je suis bon pour écrire du code en morceaux, mais mes créations sont vraiment nulles. La question est de savoir comment améliorer mes créations et devenir à mon tour un meilleur designer?
Je pense que les écoles et les collèges font un bon travail pour enseigner aux gens comment devenir bon dans la résolution de problèmes mathématiques, mais admettons le fait que la plupart des applications créées à l'école sont généralement de 1000 à 2000 lignes, ce qui signifie que c'est principalement 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 crois que même des projets comme topcoder/project euler ne seront pas d'une grande aide, ils pourraient affiner 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 sympas et propres, qui n'est pas du tout intéressé par les trucs banals et poilus quotidiens avec lesquels la plupart des programmeurs d'applications traitent.
Ma question est donc de savoir comment améliorer mes compétences en conception? Autrement dit, 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 en conception qui m'aideront à créer un meilleur kit d'édition html ou un programme graphique comme 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 à nouveau un peu moins qu'auparavant et, au fil du temps, de développer l'expérience pour reconnaître les causes de vos échecs afin de pouvoir gérer les situations d'échec potentielles plus tard. Cela est aussi vrai pour 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é, que pour apprendre n'importe quel aspect du développement logiciel.
Il n'y a pas vraiment de raccourcis, mais il y a des choses que vous pouvez faire pour éviter que les problèmes deviennent incontrôlables pendant que vous gagnez en 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'aider à accélérer l'apprentissage.
- Lisez , lisez un peu plus, pratiquez ce que vous avez lu et répétez pendant toute la durée de votre carrière. Je fais ce genre de choses depuis plus de 20 ans et j'apprends toujours quelque chose de nouveau chaque jour. Apprenez non seulement sur la conception initiale, mais également sur la conception émergente, les tests, les meilleures pratiques, les processus et les méthodologies. Tous ont différents degrés d'impact sur la façon dont vos conceptions émergeront, prendront forme et, plus important encore, comment elles dureront dans le temps.
- Trouvez le temps de bricoler . Soit vous impliquer dans un projet de skunkwork à travers votre lieu de travail, soit vous exercer sur votre propre temps. Cela va de pair avec votre lecture, en mettant en pratique vos nouvelles connaissances et en voyant comment ces choses fonctionneront. C'est aussi ce qui permet une bonne discussion avec votre mentor.
- Impliquez quelque chose de technique à l'extérieur de votre lieu de travail. Cela pourrait être un projet ou un forum. Quelque chose qui vous permettra de tester vos théories et idées en dehors de votre cercle immédiat de pairs afin de maintenir une nouvelle perspective sur les choses.
- Soyez patient . Reconnaissez que gagner de l'expérience prend du temps et apprenez à accepter que vous devez vous retirer un moment pour 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. Ce n'est pas strictement nécessaire, mais j'ai constaté qu'il peut être très avantageux pour vous de voir comment vous vous êtes développé au fil du temps, comment vos compétences ont augmenté et vos pensées ont changé. Je reviens à mes propres revues tous les quelques mois et regarde 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 à l'époque. C'est aussi un rappel que je me trompais de temps en temps. C'est un rappel sain qui m'aide à m'améliorer.
Eh bien, il n'y a pas d'or Apple pour ce genre de question, et je pense que c'est peut-être pour chaque codeur lui-même de trouver ce qui lui convient. Voici ma position, 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 qu'une fois que vous avez essayé de créer et de concevoir une application - et que vous avez échoué.
Pour moi, c'est une question d'expérience. Quand j'ai commencé comme recrue, j'ai lu des livres sur la conception. Je ne comprenais pas beaucoup le contenu à l'époque. Quand j'ai commencé à travailler et que je devais concevoir des applications moi-même, j'ai fait des applications très compliquées. Ils travaillaient, mais ils étaient pénibles à maintenir. Puis 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 apprenez à refactoriser le code. Un développement progressif avec un refactoring continu et agressif se traduira par un produit final beaucoup plus propre que toute conception initiale.
Lisez à propos des modèles, bien sûr, mais d'abord et avant tout à propos des anti-modèles. Il est important de reconnaître les anti-schémas et il est plus facile de comprendre pourquoi quelque chose ne devrait pas être fait de cette manière que pourquoi.
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 super sceptique quant à l'ajout d'un "petit hack de plus". Un de plus ici, un de plus là-bas, et le code devient impossible à gérer.
Valeur le principe ouvert/fermé .
É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, c'est-à-dire). J'étais surpris de voir - habituellement - 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) la décomposer; si un projet contient plus de 50 classes, décomposez-le.
La clé est d'estimer la taille de votre système et de 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é d'abstraire plutôt que de créer un meilleur code, mais deux choses vous rendront meilleur et une chose vous rendra plus heureux:
"Meilleur"
A) Trouvez le meilleur concepteur possible et associez programme/conception ensemble. Demandez-leur d'expliquer ce qu'ils pensent lorsqu'ils abordent le problème, ne vous contentez pas de "ça fait juste du bien" et continuez à creuser. Ce processus aidera également la partie "mentorat"
B) Imaginez tout en tant qu'acteurs individuels et conversations entre eux. Chacun des acteurs devrait avoir un rôle/responsabilité unique et des groupes d'entre eux gèrent différents systèmes. Si cette conversation fonctionne et que chaque acteur se sent cohérent et cohésif, alors 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'y a rien de mal à accepter que certaines personnes ne puissent pas faire certaines choses. Vous pouvez écrire du code serré et brillant, mais ne jamais être capable de concevoir ou d'architecturer. Et alors? Je ne peux pas faire de sport physique pour le caramel, je ne suis pas beau et ma conduite automobile ne sera jamais meilleure que la moyenne. Délectez-vous et utilisez ce que vous êtes bon.