Comment passer de l'écriture de code à un bon développeur?

Je suis frustré par le manque d'explications concrètes sur la façon de passer d'un script (bash, awk) et d'écrire des applications simples (c, php, python) à la conception et au développement de logiciels plus grands et plus compliqués. Il semble qu'il y ait d'un côté des livres de langage de programmation et de l'autre des livres de génie logiciel / gestion de projet conçus pour des équipes de programmeurs.

J'ai lu beaucoup des deux. J'ai lu les classiques XP / Agile et j'ai une bonne compréhension théorique du processus de développement logiciel. J'aime lire le code des autres et le suivre assez bien. Mais quand j'ai une idée de projet ou que je veux passer de "voici le problème / besoin" à "voici la solution", mon esprit dessine un blanc et je ne sais pas par où commencer.

Dois-je juste le pirater? Existe-t-il des workflows structurés pour les développeurs individuels qui ne travaillent pas en équipe ou pour une grande maison de logiciels? Je n'ai vraiment aucune envie d'obtenir un PMP ou de travailler pour une société de logiciels. Je recherche juste un workflow efficace, efficient et pratique.

À mon avis, vous devenez un bon développeur en ayant de l' expérience et en travaillant avec plusieurs façons de faire les choses. Vous avez indiqué que vous rencontrez un problème pour passer de "voici mon idée" à "voici ma solution". C'est quelque chose de plus vers les méthodologies de développement logiciel que d'être un développeur expérimenté.

L'utilisation d'une méthodologie de développement de logiciels ne se limite pas au «piratage de code» et ces méthodologies fournissent des flux de travail structurés. La famille Agile fournit une bonne structure pour les petites équipes de développement (ou les individus) que vous pouvez suivre pour vous aider à passer de la phase "idée" à la phase "produit fini".

Il y a quelques choses que j'ai apprises au fil des ans des autres et en travaillant sur divers projets, tels que:

• Rendez tout testable, cela vous facilitera beaucoup la vie;
• Vous ne pouvez pas vous attendre à avoir une conception parfaite et à pouvoir concevoir des applications d'entreprise / le prochain plus grand titre de jeu / insérer plus ici, sans avoir l'expérience de le faire;
• Il est difficile de concevoir un bon logiciel si vous n'en avez pas l'expérience et si vous avez appris des autres;
• Vous n'aurez jamais un design parfait la première fois, même en tant que développeur expérimenté - les choses changent et donc; votre conception pourrait aussi;
• Écrivez les choses: écrire / dessiner / tableau blanc / peindre / quoi que ce soit avec lequel vous vous sentez à l'aise, cela vous facilite la vie si vous avez des choses écrites. Tels que les conceptions d'interface graphique, les diagrammes de classes, etc. D'après mon expérience, le simple fait de "pirater quelque chose ensemble" a le potentiel d'échouer de manière catastrophique;
• Ne réinventez pas la roue, vous ne devriez pas avoir à le faire. Si vous essayez d'implémenter votre propre HashMap, vous faites probablement quelque chose de mal. Faites des recherches et réfléchissez avant d'écrire du code.

J'espère que cela vous aidera.

Eh bien, à mon avis, comme dans toute profession, pour être un bon professionnel, tout ce qu'il faut - en plus de la formation théorique - c'est de l' expérience .

Comme un médecin ne peut pas être bon avec seulement les cours suivis à l'école de médecine, ou un avocat ne peut pas connaître tout le côté politique d'être un avocat avec seulement son diplôme, être un bon développeur a besoin d'expérience et de temps.

L'expérience ne vient pas en lisant du code tiers. Si vous obtenez un étudiant en médecine, il / elle serait en mesure de signaler de nombreuses procédures, maladies, médicaments, etc., mais l'application réelle de ces choses (quand appliquer une procédure, quelle maladie diagnostiquer, etc.) ne vient que avec supervision et expérience.

Puisque vous ne voulez pas travailler pour une grande entreprise (ou toute autre entreprise d'ailleurs), je vous suggère de commencer par développer de petites applications, une étape à la fois. Le développement de logiciels par vous-même prend beaucoup de temps, croyez-moi.

Une autre chose que je vous suggère de devenir un bon développeur / ingénieur logiciel, est de contribuer aux logiciels open source. Beaucoup de gars ont fait beaucoup d'argent (et d'expérience, en passant) en aidant à développer des logiciels open source et en donnant des consultations par la suite. Ils se sont fait un nom grâce à leurs contributions à l'open source.

Quoi qu'il en soit, je pense qu'il n'y a pas de raccourci pour acquérir de l'expérience, et cela doit être poursuivi avec discipline et patience .

Vous pouvez commencer par améliorer le code des autres. Prenez un projet que vous avez et ajoutez-y une fonctionnalité. Vous devrez décider ce que la fonctionnalité va faire et comment elle doit le faire. En travaillant dans le cadre du code existant, concevez votre solution.

Et n'ayez pas peur de pirater des trucs. Beaucoup de nouveaux développements se font en affinant (ou de préférence en réécrivant) des prototypes rapides et sales. Allez-y et utilisez toutes les pires pratiques et contre-modèles du livre, lancez simplement quelque chose qui fait ce que vous voulez. Ensuite, revenez en arrière et concevez-le correctement. Habituellement, je me surprends à penser "Vous savez, une meilleure façon de faire serait ..." pendant que je coder en dur certains paramètres de configuration dans ma monstruosité en trois procédures de 800 lignes.

Je sais que c'est actuellement hors de mode, mais les techniques d'analyse structurée m'ont vraiment aidé à maîtriser la conception de logiciels. Jouez avec la création de quelques graphiques à bulles et DFD pour avoir une idée des problèmes de décomposition et concevoir différentes parties d'un système pour fonctionner ensemble.

Comme d'autres l'ont dit, l'expérience vient de l'écriture de code. Mais vous devriez aussi demander à quelqu'un d'autre de revoir votre code si possible. Un programmeur plus expérimenté peut signaler des problèmes dans votre code et vous montrer de meilleures façons de faire les choses. Contribuer à un projet open source vous donnera la chance de faire les deux.

Pour moi, cela aide à décomposer un plus gros logiciel en plus petits morceaux. Et puis divisez ces morceaux en parties encore plus petites et ainsi de suite. Chaque logiciel est une collection de petits morceaux de logique.

Prenons l'exemple d'un blog. Vous voulez pouvoir créer et éditer des articles que d'autres peuvent lire. Vous pouvez immédiatement diviser le projet en sections d'administration et publiques. L'administrateur aura au minimum besoin d'administrateurs, d'une page de connexion et d'une section pour gérer le blog. La section de gestion du blog peut être décomposée en une interface CRUD (Créer, Lire, Mettre à jour, Supprimer). La création d'un nouveau billet de blog nécessitera une vérification pour vous assurer que l'utilisateur administrateur dispose des privilèges appropriés, d'un formulaire, d'une validation de formulaire et de la possibilité d'enregistrer dans la base de données. Etc.

Plus vous décomposez un problème ou une fonctionnalité, plus elle devient gérable. C'est diviser pour mieux régner. Une fois que vous avez pu cartographier votre logiciel comme celui-ci, vous pouvez voir comment ses différents éléments interagissent les uns avec les autres. Où pourriez-vous répéter le code? Qu'est-ce qui peut être abstrait? Cela devrait être un processus itératif à la fois lorsque vous planifiez et que vous écrivez le code lui-même.

Je recommanderais de déterminer votre ensemble de fonctionnalités minimum pour commencer et de l'implémenter avant d'y ajouter d'autres éléments. Vous voudrez coder défensivement afin que les modifications futures ne soient pas trop difficiles, mais en même temps, vous ne voulez pas implémenter des demi-fonctionnalités qui ne seront peut-être jamais terminées. C'est une ligne difficile à parcourir entre rester flexible et être prêt à tuer impitoyablement vos chéris, à emprunter une référence littéraire. Être bon dans cet exercice d'équilibre particulier ne vient que de l'expérience.

Et c'est de cela qu'il s'agit, comme l'ont mentionné les autres réponses: l'expérience. La seule façon de l'obtenir est de commencer. Ne vous inquiétez pas tellement de le rendre parfait dès le départ. Faites d'abord fonctionner le code, puis rendez-le beau, puis faites-le rapidement.

De plus, contrairement à ce paragraphe, n'insistez pas sur la sécurité à la fin comme une réflexion après coup. Vous devriez avoir une idée des façons dont votre logiciel pourrait être compromis, mais pour commencer, ne faites confiance à aucune entrée d'utilisateur.

Je sais que vous dites que vous ne voulez pas travailler pour une société de logiciels, mais c'est un bon endroit pour acquérir l'expérience dont parlent de nombreuses autres réponses. Et que vous souhaitiez ou non travailler sur de grands projets, l'exposition au travail et aux styles de travail des autres est une bonne chose.

Vous ne pouvez pas essayer la programmation par paires par vous-même, par exemple. Et si vous êtes associé à quelqu'un de plus intelligent que vous, vous obtenez l'avantage supplémentaire de gagner de meilleures pratiques de sa part tout en acquérant de l'expérience dans cette méthodologie.

BTW, j'ai pris l'habitude d'essayer de travailler avec des groupes où je me sens en-dessous de la moyenne en termes d'expérience, de compétences, etc. Cela élève énormément mon jeu. C'est beaucoup plus difficile de le faire seul ou lorsque vous êtes le gars "expérimenté".

Ce que vous recherchez, ce sont des compétences en résolution de problèmes . J'ai remarqué qu'il est supposé que le développeur peut déjà le faire, ce qui est stupide. Heureusement, la résolution de problèmes est une compétence générale, utilisée en mathématiques, en recherche, dans la vie quotidienne, etc.

Surtout, vous devriez finir par suivre la méthode scientifique, avec quelques fioritures.

1. Vous avez un problème (utilisez des outils et des techniques pour aider à le définir)
2. Vous faites l'hypothèse d'une solution (modèles et aide à l'expérience)
3. Testez l'hypothèse (vous pourriez même ne pas avoir de code ici)
4. Répétez les étapes 2 et 3 jusqu'à ce que l'hypothèse se vérifie. Vous avez maintenant une théorie (programme de travail pour résoudre le problème)
5. Développer une expérience pour souligner la théorie, à la recherche de trous (cas de test!)
6. Si les cas de test tiennent, vous avez une solution! Sinon, rincez et répétez

Notez que ce niveau est plutôt élevé. Chaque étape implique généralement plusieurs sous-étapes, telles que la détermination du problème réel. Par exemple, regardez comment résoudre des problèmes de mots en mathématiques. Vous collectez des faits (un outil) et déterminez ce que vous voulez réellement. Ensuite, vous examinez vos faits, en essayant de les mettre en correspondance avec la solution.

Cela finit par devenir des sous-problèmes du problème principal. Suivez donc à nouveau les étapes. Nous avons besoin d'un élément intermédiaire pour obtenir le résultat final, alors cela devient notre nouveau problème. Cela décompose le problème en petites sections faciles à comprendre. Lorsque chaque pièce est résolue, la solution est reconstituée.