Que dois-je faire lorsque mon code sent?

Je suis un programmeur débutant et souvent lorsque je travaille sur mes propres projets, j'ai toujours l'impression que la conception de mon code n'est pas la meilleure possible, et je déteste ce sentiment. Je finis par passer du temps à chercher des choses, mais ensuite je suis submergé facilement par de nombreux détails, tels que les modèles de conception à choisir et quand utiliser une classe abstraite ou une interface. Suis-je censé essayer d'apprendre un peu tout en même temps?

Quelques suggestions:

1. Utilisez l' encapsulation pour gérer la complexité en séparant les fonctionnalités en blocs de construction distincts. Prouvez que chaque bloc fonctionne (via des tests unitaires), et vous pouvez l'utiliser sans vous soucier de ses détails intérieurs.

2. Apprenez et étudiez les modèles de logiciels . Les modèles de logiciels sont des méthodes éprouvées pour effectuer certaines tâches courantes et bien connues.

3. Étudiez et comprenez les structures de données. Découvrez les utilisations et les caractéristiques de performance appropriées pour chaque type de structure de données.

4. Connaissez bien votre langage de programmation, ses forces et ses faiblesses et la meilleure façon d'utiliser ses fonctionnalités.

Vous ne devez pas savoir tout cela à la fois, mais vous devriez étudier tout cela au fil du temps.

Mon conseil est: arrêtez de vous inquiéter.

L'expérience est le meilleur professeur, et vous n'obtenez pas d'expérience si vous n'écrivez pas de code. En outre, un code mal conçu qui est écrit est meilleur qu'un excellent design qui ne l' est pas .

Alors, écrivez plus de code. Terminez vos projets. Ce sentiment que le code n'est pas idéal est probablement juste. Et vous aurez probablement des problèmes avec ce code. Et quand vous avez ces problèmes, alors vous apprenez pourquoi exactement c'était mauvais. Vous en apprendrez beaucoup plus par expérience de première main que par «recherche de choses».

N'espérez pas non plus que ce sentiment d '«odeur de code» disparaisse un jour. Au fur et à mesure que vous vous améliorez, vous corrigerez certains problèmes, mais commencez à remarquer de nouveaux, plus obscurs / avancés.

Il s'agit d'un problème courant avec les programmeurs débutants. Ne vous paralysez pas en pensant que tout doit être parfait. C'est le moyen le plus sûr de ne jamais terminer un projet. L'une des compétences les plus importantes à apprendre en tant que développeur est la différence entre parfait et assez bon . Acceptez que chaque système que vous créez peut être amélioré. Concentrez-vous sur la finition de vos projets. Après avoir terminé, vous pouvez revenir en arrière et les améliorer. C'est pourquoi nous avons des versions 2.0, après tout.

Suis-je censé essayer d'apprendre un peu tout en même temps?

J'espère que non. D'un autre côté, vous devriez apprendre et vous améliorer tout le temps.

Lire des livres, suivre des cours, se qualifier, y travailler et vous devriez vous améliorer.

Mon meilleur conseil est de me concentrer sur les fondamentaux tels que la liste suggérée par Robert Harvey. Le développement de logiciels est un monstre complexe qui met des années à se perfectionner à distance, en particulier dans le domaine de la conception d'une bonne interface. Il est vraiment difficile d'apprécier de nombreux aspects du développement logiciel sans en avoir d'abord fait l'expérience. Même quelque chose d'aussi basique que le code de commentaire peut être sous-estimé. Dès le premier jour, on vous apprend à écrire du code bien documenté. J'avoue que ce n'est que lorsque j'ai été vraiment mordu dans un code essayant de comprendre $$ que j'ai écrit il y a des mois avant que j'apprécie vraiment la valeur des bons commentaires. La même chose peut être dite pour de nombreux concepts de programmation. Par exemple, l'encapsulation des données, les modules à faible couplage et les interfaces propres nettes.

La ressource la plus précieuse que j'ai rencontrée est mes collègues. Vous allez mal écrire du code. Acceptez cela. C'est ce que vous faites pour vous assurer que vous écrivez un meilleur code au fil du temps qui vous définit en tant que programmeur. Par exemple, lorsque j'ai commencé à travailler, mon entreprise ne disposait d'aucune sorte de code formel ou de procédures d'examen de la conception. J'ai pris sur moi de soumettre mon travail à la critique de mes collègues plus âgés et pour être honnête, je me sentais comme un idiot pour une meilleure partie de ma première année de travail.

Le développement de logiciels est une expérience d'apprentissage continue. Posez des tonnes de questions, faites réviser votre code, comprenez le pourquoi des suggestions de plus de personnes âgées, n'ayez pas peur de remettre en question la validité des suggestions de plus de développeurs seniors et surtout, n'ayez pas peur de vous tromper. Finalement, le facteur d'intimation ou l'impression d'être submergé par les modes. Pour mémoire ... les courbes d'apprentissage sont nulles.

• Premièrement: Refactoring (ça sentira toujours mais sera un peu plus organisé)
• Deuxièmement: voyez si vous pouvez utiliser un Design Patter pour que les pièces refactorisées correspondent à votre logique.
• Troisièmement: lorsque les choses commencent à s'améliorer, rappelez-vous le temps que vous avez passé à faire la première et la deuxième étape. De cette façon, lorsque vous écrivez une nouvelle fonctionnalité, vous y penserez pendant que vous le faites et non comme un autre processus.

Jetez un œil au livre Refactoring: Improving The Design Of Existing Code , par Martin Fowler. La première chose à faire est de refactoriser votre code , afin d'améliorer la lisibilité du code et de réduire la complexité pour en améliorer la maintenabilité.

Lorsque vous refactorisez votre code, vous utilisez déjà des modèles de conception , l' encapsulation de code , etc.

C'est l'un des meilleurs livres que j'ai jamais lu sur ce sujet. Il fournit de nombreuses recettes utiles.

Une bonne ressource est le programmeur pragmatique . Le chapitre sur "Windows cassé" décrit où vous vous voyez. La réponse courte et concise est de résoudre les problèmes.

Lorsque vous commencez à réparer votre conception, cela aide à comprendre ce que vous n'aimez pas. Il est facile de trouver des réponses vagues comme "ça va partout" ou "pourquoi ai-je fait ça là-bas?". Mais prenez le temps de voir s'il existe des modèles communs que vous avez utilisés.

• Un bon design réutilisera un petit nombre de concepts dans la base de code (l'idéal est un concept, mais en pratique, vous aurez peut-être besoin de quelques autres)
• Une bonne conception permet de déterminer facilement où résoudre les problèmes (principe DRY, principe SRP)
• Un bon design aura un bon rapport d'erreurs (lié au point ci-dessus, mais appelé comme un élément séparé car c'est un aspect souvent négligé)

Une fois que vous avez déterminé où vous voulez aller, faites de petites étapes facilement réversibles pour y arriver (c'est-à-dire, c'est le sujet de la refactorisation ). Chaque fois que vous améliorez votre code, tenez compte de son impact sur le reste du code. Avez-vous amélioré ou aggravé les choses? C'est du moins mon approche pour mettre de l'ordre dans le chaos.

Si vous avez déjà une certaine expérience en programmation, pourquoi n'étudiez-vous pas certains projets open source qui ont du code propre ? Vous pouvez vous pencher sur CETTE question de SO qui a des liens pertinents.

En outre, les modèles de conception sont un must - pensez-y, l'idée d'avoir des modèles est de résoudre des problèmes connus sans réinventer la roue ou écrire du code buggy.

Enfin, il semble que vous ayez besoin d'une dose de programmation fonctionnelle pour vous vider la tête. Regardez dans Haskell ou Ocaml pour commencer.

Si vous n'êtes pas un monstre dangereux, vous devriez trouver un soi-disant ami , qui peut réviser votre code, et vice versa. De plus, si vous faites des choses, qui seront revisitées ou simplement supervisées par d'autres, c'est une bonne pression pour le faire mieux.

Et n'oubliez pas, la programmation commence avant le codage, revoyez toujours vos idées, vos plans. Si votre plan est mauvais, c'est un acte joyeux de le jeter: vous venez de sauver la frustration de jeter un tas de code (et le temps de sa création) basé sur un mauvais plan.

Mon conseil est de prendre chacune des odeurs au sérieux et d'essayer de la réparer. Il existe de nombreux bons livres sur le sujet (le code propre et le GOOS sont les meilleurs IMHO). Mais plus que des livres vont aux conférences pour entendre et discuter avec d'autres personnes et sur les communautés en ligne (liste de diffusion, groupes). Encore mieux, essayez de rejoindre votre xxug local (dotnetug, jug, xpug, etc.) ou en avez trouvé un.

Discuter avec d'autres programmeurs est le seul moyen que je connaisse pour vraiment m'améliorer (sauf si vous avez la chance de travailler avec d'autres programmeurs dédiés).