Développer en entreprise : Qu’est ce qui change ?
Entre développer des projets personnels et développer dans le cadre d’une mission en entreprise il y a tout un monde et vos petites habitudes pourraient bien finir par vous desservir.
Cet article n’a pas pour objectif de critiquer vos méthodologies de travail dans vos projets personnels où lorsque vous travaillez sur un projet open-source. Il a simplement pour but de mettre en évidence des comportements qui pourraient porter préjudice à vos missions professionnelles (notamment lorsque vous êtes dans des ESN).
Ce qui change dans le cadre du développement en entreprise
Il faut répondre aux besoins du client et non aux vôtres
Dans le cadre professionnel, ce qui compte en premier lieu c’est d’apporter une solution adaptée à la problématique du client (qu’il soit interne ou externe). Pour cela les besoins de ce dernier doivent passer en priorité avant vos envies personnelles.
Vous êtes probablement passionné, curieux et vous désirez montrer à la terre entière de quoi vous êtes capable, c’est tout à fait compréhensible. Ces traits de caractères peuvent être des atouts dans une carrière, mais il faut savoir les canaliser afin qu’ils n’interfèrent pas avec l’objectif de votre mission.
Ce n’est peut-être pas une bonne idée d’implémenter cette toute nouvelle technologie que vous avez apprise hier soir, car vous prenez le risque de ralentir le reste de l’équipe qui va devoir s’y adapter.
Bien entendu, il est parfois possible de faire des compromis ou de voir sur le long terme ce qui sera le plus bénéfique. Le développement est une discipline qui n’est étonnamment pas si binaire que ça et il n’y a jamais qu’une seule bonne solution qui peu s’appliquer à tous les cas. Dans le doute, discutez-en avec le reste de votre équipe.
Evitez les fonctionnalités non-prévues
Pour un développeur enthousiaste il peut-être tentant de vouloir implémenter des fonctionnalités non-prévues initialement.
Vous êtes sûr d’avoir compris et anticipé les besoins du client: “Il n’avait pas pensé à cet écran de monitoring mais il va en avoir besoin c’est certain !”.
Cela part probablement d’une bonne intention, mais attention, développer une fonctionnalité de plus signifie qu’il va falloir la maintenir tout au long du processus de développent. De plus, une fonctionnalité, même non prévue, doit-être documentée et le client doit être formé à son utilisation.
Que se passe-t-il si finalement ce dernier n’a absolument pas besoin de cet écran de monitoring qui vous a pris deux jours de développement ? Il part à la poubelle et tout le travail que vous y aurez passé n’aura servi à rien.
Avant de décider de surproduire, réfléchissez-y à deux fois et demandez-vous bien si cela ne va pas vous handicaper pour la suite. En effet, personne n’a envie de cruncher les deux dernières semaines d’un projet parce qu’un membre de l’équipe à fait du zèle en voulant développer une fonctionnalité non demandée.
Vous travaillez en équipe alors n’essayez pas de jouer au plus intelligent
Par esprit de challenge, avez-vous déjà tenté de rendre votre code le plus compact possible ?
Avant de réécrire votre code pour le rendre le plus court possible ou d’utiliser cette toute nouvelle fonction qui fait le café mais que seulement 0.1% des développeurs connaissent, rappelez-vous que vous travaillez en équipe. Cela signifie que d’autres personnes vont devoir passer derrière vous et déchiffrer ce que vous avez voulu faire. Sur la durée et dans une équipe, il est souvent plus efficace de coder de manière simple et efficace plutôt que comme si vous étiez un expert mondial.
Gardez toujours en tête qu’un projet en équipe n’est pas une compétition. A la fin, aucune médaille ne sera décernée au développeur qui à réussi à produire le code le plus illisible.
Votre temps est précieux, ne le gaspillez pas n’importe comment.
Dans une mission il y a toujours une deadline. Le temps vous est compté alors il faut éviter de le gaspiller autant que possible. Non, ce n’est peut-être pas le meilleur moment pour tester “Ce dernier Framework à la mode” sans savoir s’il va correspondre à vos besoins ou si il va falloir tout recommencer à mi-chemin.
Egalement, lorsque viendra le moment d’implémenter une nouvelle fonctionnalité, il vous faudra surement choisir entre la rendre simple mais efficace ou extrêmement complète mais également complexe. A ce moment-là, prenez un peu de recul et demandez-vous si le temps supplémentaire que vous allez utiliser en vaut la peine. Il se peut que ça soit le cas mais la plupart du temps, aux yeux de votre client du moins, ça ne l’est pas.
Gardez tout de même en tête le point précédent. N’essayez pas de gagner une paire d’heures si vous obtenez du code inmaintenable en retour. Avec l’expérience, vous finirez par savoir où placer le curseur entre rapidité et maintenabilité.
Ne pas faire de sur-abstraction
Lors du développement d’une application professionnelle, mettre en place une couche d’abstraction sur tous les composants peut se révéler être contreproductif.
Dans l’open-source, implémenter une couche d’abstraction est fortement encouragée. En effet, dans un module que des milliers de développeurs vont peut-être vouloir réutiliser pour répondre à différents besoins, l’abstraction apporte des avantages de maintenance et d’implémentation non-négligeables.
Mais dans le cadre d’un projet professionnel, le périmètre du besoin est (normalement) clairement défini et l’on sait généralement à quoi va servir chaque composant de notre application. Dans ces conditions, faire de la sur-abstraction peu rendre la maintenance et l’évolution de l’application plus complexe.
Mais que se passe-t-il si l’application doit évoluer ? Peut-être aurez-vous finalement besoin de cette abstraction ?
De mon expérience, il est plus simple de factoriser du code non-abstrait pour l’abstraire, plutôt que de devoir modifier une abstraction bancale parce qu’on ne savait pas dans quel contexte elle serait utilisée.
Ne réinventez pas la roue
Vous aimez maîtriser votre code et vous avez tendance à redévelopper des composants même si des équivalents existent déjà ?
C’est une très bonne idée dans un projet personnel car cela va vous permettre de monter en compétence beaucoup plus vite. C’est en revanche une moins bonne idée lors d’une mission professionnelle.
La raison la plus évidente, c’est que vous allez probablement utiliser du temps que vous auriez pu employer plus judicieusement. Mais réutiliser des modules existants présente également d’autres avantages à cotez desquels vous allez passer :
- Ils sont la plupart du temps fait par une communauté d’experts et seront maintenus sur la durée.
- Si ce sont des modules populaires, il est possible que les nouveaux développeurs les connaissent déjà. Le temps de formation s’en trouvera réduit.
- Il est probable que le module présente des fonctionnalités supplémentaires qui pourront s’avérer utile dans le futur
Bien sûr, il existe des cas de figures où redévelopper un module est préférable. Il est impossible d’en fournir une liste exhaustive, alors c’est à vous de prendre du recul et à peser le pour et le contre.
Ces règles ne sont bien entendu pas absolues. Toutes les entreprises n’ont pas les mêmes philosophies et certaines réussissent à garder des façons de travailler très “open-source”. Peut-être avez vous la chance de travaillez dans l’une d’elles et dans ce cas, vous pouvez oublier tout ce que j’ai écrit dans cet article !
Malheureusement ce n’est pas le cas dans la majorité des entreprises (surtout les ESN) et c’est dans ces dernières que ces petits rappels ont leur importance.
