Lorsque j'étais un développeur principal dans l'équipe, un développeur junior de mon équipe est venu me dire qu'elle a du mal à refactorer un morceau de code particulier. J'avais dit que j'y jetterai un coup d'œil, pour découvrir qu'il avait été développé par l'un de nos autres Lead developer actuellement sur place. Nous avons fini par réécrire la logique. Cet incident a conduit à un peu de mauvaise réputation pour la personne à onsite.
La raison pour laquelle je cite cet incident est, le code que vous écrivez est un document vivant de ce que vous avez développé tout au long. C'est la raison pour laquelle les gens affichent leurs profils Github dans les CV pour montrer leurs compétences en matière de codage.
Répondant maintenant à la question posée,
- Développez un code lisible. Le code que vous écrivez doit être le document vivant de ce qu'il fait. Pensez que, vous serez la personne qui le maintiendra en environnement de production pendant les 10 prochaines années.
- Votre expérience doit être de N années et non de N fois des années. Laissez-moi vous expliquer davantage. Disons que vous avez 5 ans d'expérience, vous devez avoir 5 ans d'expérience dans le domaine. Et non pas 5 fois un an d'expérience. Lorsque vous êtes à l'aise avec ce que vous faites, vous avez tendance à faire la même chose et à y rester. Cela conduit à ce que votre même expérience soit multipliée au fil du temps et ne se développe pas réellement. C'est le plus gros problème de la plupart des développeurs.
- NE PAS réinventer la roue. Lorsque vous pensez à une solution pour un problème commun pendant votre développement, vérifiez si quelqu'un l'a déjà résolu. La plupart des problèmes courants sont déjà résolus et sont disponibles en tant que bibliothèque add on open source à utiliser. Vous pouvez simplement l'exploiter au lieu d'écrire votre propre.
- Structures de données et algorithmes. considérez dans la mise en œuvre de la recherche google (juste pour l'exemple. Je ne't savoir comment il est mis en œuvre) le développeur, par erreur, a décidé d'utiliser une structure de données plus lente conduisant à un retard dans les résultats de recherche, figurez l'impact qu'il aura sur les utilisateurs finaux. Alors que nous n'écrivons pas de code pour la fonctionnalité de recherche, nous devrions utiliser la meilleure structure de données possible et un bon algorithme.
- Doit apprendre au moins deux langages de programmation. Un bon développeur doit apprendre au moins deux langages de programmation. Cela permet de mieux comprendre à quel point les langages de haut niveau sont similaires. Il développe une meilleure compréhension sur la syntaxe et l'utilisation.
- Assumer la propriété, mais ne pas être le propriétaire. Vous devez être responsable du code que vous développez. Ne vous défendez pas lorsque quelqu'un trouve des problèmes sur votre code.
- Écrire des tests. Même si vous ne'suivez pas le développement piloté par les tests. Les logiciels se développent avec le temps. Ils finissent par avoir beaucoup de code non désiré et aussi des fonctions complexes. la seule façon d'empêcher sur les nouveaux changements impactent les anciennes fonctions de travail est en écrivant des tests. Ainsi, lorsqu'une nouvelle fonction ou routine a un impact sur l'existant, elle brisera le test et le fera échouer.
- Bienveillance. Soyez gentil avec quelqu'un qui se joint à votre équipe. Comme ils commencent dans votre projet, ils auront beaucoup de questions. Traitez-les avec respect comme quelqu'un vous a traité lorsque vous avez rejoint une nouvelle équipe de projet.
- Vous n'êtes pas important. Parfois les gens pensent qu'ils ont beaucoup de dépendance dans le projet car ils ont connu des entrées et des sorties dans le projet. Ils agissent de manière arrogante. Mais n'oubliez pas que vous êtes remplaçable. La nouvelle personne, le bon remplaçant, peut avoir du mal au début. Mais elle finira par comprendre. Donc, comprenez cela - on a besoin de vous maintenant, mais pas pour toujours.