Faut-il embaucher un développeur inexpérimenté ?

Lorsqu’on est at­ten­tif à ce qui se dit dans les com­mu­nautés comme les sites de Stack Ex­change, ou en­core par les lead­ers, tels que Joel Spolky, en matière de l’or­gan­i­sa­tion du tra­vail au sein des en­tre­pris­es de développe­ment, on en­tend se répéter l’un des points clés en matière d’em­bauche : il est im­pératif d’avoir les salariés les plus com­pé­tents, dans la lim­ite des ca­pac­ités fi­nan­cières de l’en­tre­prise.

Ceci est vrai dans le sens où une en­tre­prise de développe­ment qui con­stam­ment cherche à avoir les développeurs les moins coû­teux en se dis­ant que c’est un moyen de ré­duire les coûts se met le doigt dans l’œil : non seule­ment ses pro­duits seront d’une qual­ité désas­treuse, et il fau­dra être très au­da­cieux pour con­va­in­cre, sou­vent par tromperie, les clients de pay­er pour ça, mais aus­si ces développeurs vont coûter actuelle­ment plus cher à long terme.

Ce dernier point est rel­a­tive­ment sim­ple à ex­pli­quer. Au cours de sa car­rière, un développeur in­téressée va croître très forte­ment à la fois ses com­pé­tences et, pas sans lien, sa pro­duc­tiv­ité. Il ap­prend à utilis­er de nou­veaux out­ils (ou des out­ils qu’il con­nais­sait depuis le début mais dont il ne pou­vait s’en servir ef­fi­cace­ment, faute de maîtrise), il ap­prend les pat­terns qu’il ap­plique, il re­specte les rè­gles de style, per­me­t­tant à son code d’être relu plus facile­ment, il ap­plique les méthodolo­gies per­me­t­tant de ren­dre son code plus sûr, il fait le refac­tor­ing réguli­er, etc. Par­al­lèle­ment, son salaire aug­mente, mais à une vitesse moin­dre.

Don­nez à un développeur débu­tant une tâche com­pliquée qu’un pro­fes­sion­nel pour­ra ac­com­plir en cinq heures. Ce développeur débu­tant restera dessus pen­dant des jours, voire des se­maines, pour au fi­nal aboutir à une so­lu­tion d’une qual­ité forte­ment in­férieure, qui né­ces­sit­era des se­maines sup­plé­men­taires pour le QA ou les développeurs qui seront amenés à tra­vailler sur ce code par la suite. Cepen­dant, ce développeur débu­tant est payé peut-être seule­ment deux fois moins que le pro­fes­sion­nel.

Ain­si, un développeur in­ex­péri­men­té est plus coû­teux qu’un pro­fes­sion­nel lorsqu’il s’agit de tra­vailler sur des pro­jets de moyenne ou de grande taille.

Plus le pro­jet est grand, plus le fait d’avoir un développeur in­ex­péri­men­té dans l’équipe sera pé­nal­isant fi­nan­cière­ment. Mais cela sig­ni­fie-t-il qu’on ne peut pas em­bauch­er de développeurs in­ex­péri­men­tés du tout ? Car si oui, com­ment vont-ils ac­quérir de l’ex­péri­ence ?

En ef­fet, le tra­vail quo­ti­di­en au sein du dé­parte­ment IT d’une en­tre­prise de développe­ment ne se lim­ite pas aux tâch­es com­pliquées. Il s’agit plutôt d’une mul­ti­tude de tâch­es, al­lant des plus sim­ples à celles qu’on a in­térêt de con­fi­er, de par leur statut busi­ness crit­i­cal, à des salariés les plus ex­péri­men­tés en la matière.

Le fait qu’il y a une mul­ti­tude de tâch­es sim­ples per­met, juste­ment, d’em­bauch­er les développeurs débu­tants. Il ne s’agit pas là des pro­jets de pe­tite taille, bien que ceux-ci ex­is­tent mar­ginale­ment : générale­ment, le dé­parte­ment IT se voit con­fi­er soit des pro­jets al­lant d’un site e-com­merce à des sys­tèmes de grande échelle. Il s’agit en re­vanche des so­lu­tions qui peu­vent servir dans la vie quo­ti­di­enne des autres développeurs, soit des so­lu­tions aux prob­lèmes ponctuels. Les con­fi­er aux développeurs moins ex­péri­men­tés est béné­fique sur les trois points de vue :

• Fi­nan­cière­ment, il n’y a pas de grande dif­férence en­tre un développeur qual­i­fié et non qual­i­fié lorsqu’il s’agit de ré­soudre un prob­lème sim­ple. Les deux peu­vent le faire, sans que le pre­mier pos­sède une qual­ité de na­ture à le ren­dre man­i­feste­ment plus pro­duc­tif.

• De point de vue de l’ap­pren­tis­sage des nou­veaux développeurs, tra­vailler dans une équipe de pro­fes­sion­nels est certes très for­ma­teur, mais à par­tir d’une cer­taine dif­férence de niveau, le développeur in­ex­péri­men­té va juste avoir ten­dance à s’éclipser, laiss­er faire ses col­lègues, et ne plus s’in­téress­er vrai­ment au pro­jet. Les pe­tits pro­jets en re­vanche ont plus de chance d’in­téress­er la per­son­ne, tout en lui don­nant une sat­is­fac­tion per­son­nelle d’avoir ac­com­pli, à elle seule, le pro­jet.

• De point de vue de la pro­duc­tiv­ité, la présence d’un développeur in­ex­péri­men­té dans une équipe est par­ti­c­ulière­ment pé­nal­isante.

Je souhaite décrire ci-dessous deux de ces prob­lèmes qui au­raient pu être con­fiés à une per­son­ne ayant pas ou peu d’ex­péri­ence pro­fes­sion­nelle. Mais avant cela, je pense qu’il est utile de pré­cis­er plusieurs rè­gles qui s’im­posent à une en­tre­prise de développe­ment souhai­tant em­bauch­er un développeur pas ou peu qual­i­fié :

• Il n’est pas souhaitable de mélanger dans une même équipe les per­son­nes dont la qual­i­fi­ca­tion est très dif­férente. Si un nou­veau développeur ne pos­sède qua­si­ment au­cune con­nais­sance en la matière, met­tez-le avec les « débu­tants avancés ». S’il a un niveau moyen, met­tez-le avec les pro­fes­sion­nels. S’il est un pro­fes­sion­nel, il peut tra­vailler dans une équipe d’ex­perts.

• Un développeur pas ou peu qual­i­fié ne peut être em­bauché que dans une en­tre­prise qui compte déjà as­sez de salariés pro­fes­sion­nels. Si le core com­pe­ten­cy de l’en­tre­prise est le développe­ment, au­tant faire en sorte qu’il soit fait par des gens qui s’y con­nais­sent un min­i­mum.

Ces réserves étant faites, pas­sons aux ex­em­ples.

Ex­em­ple de Guid util­i­ty

Cet util­i­taire a été crée pour faire deux choses :

• Fournir les GUIDs, chose qui peut servir des fois lorsqu’il s’agit d’in­clure un nou­veau GUID dans le code source,

• Per­me­t­tre de génér­er les en-têtes pour les fichiers C#, ces en-têtes com­por­tant le GUID de l’au­teur du fichi­er et son nom.

S’est ajoutée par la suite une troisième fonc­tion­nal­ité, à dé­faut de pou­voir être mise dans une autre ap­pli­ca­tion et à dé­faut d’être si im­por­tante pour mérit­er une créa­tion d’une ap­pli­ca­tion à part :

• Généra­tion des mots passe aléa­toires, ceci pou­vant être util­isé dans les con­textes où le mot de passe ne doit pas être en­reg­istré du tout par ex­em­ple, ou en­core lorsque le mot de passe n’a pas à fig­ur­er dans Pass­words Man­ag­er.

Avec unique­ment une cen­taine de lignes IL, ce n’est claire­ment pas une ap­pli­ca­tion com­pliquée. Cepen­dant, elle présente des points in­téres­sants pour un développeur C# débu­tant :

• Il était néces­saire de baser le code sur les bib­lio­thèques ex­is­tantes dévelop­pées en en­tre­prise. Par ex­em­ple, la ges­tion des mots de passe était as­surée déjà par les bib­lio­thèques de Pass­words Man­ag­er, ou en­core la récupéra­tion de la liste des util­isa­teurs se fai­sait via un com­posant de ges­tion des util­isa­teurs.

• La liste des util­isa­teurs pou­vant pren­dre une à deux sec­on­des pour se charg­er, il était in­dis­pens­able de faire ce charge­ment en asyn­chrone.

• Les in­di­ca­teurs des touch­es du clavier de­vaient ap­pa­raître lors de l’ap­pui sur Ctrl, puis dis­paraître après quelques sec­on­des.

For­ma­teur, sans être sim­pliste, ce pro­jet se présente donc comme un can­di­dat par­fait dans le cadre de stage de courte durée ou de l’ar­rivée d’un salarié in­ex­péri­men­té dans l’en­tre­prise. Un autre avan­tage, c’est que ce pro­jet peut être repris par la suite par la même per­son­ne qui souhaite ap­pren­dre com­ment ef­fectuer le refac­tor­ing, le data bind­ing, ou en­core com­ment l’ar­chi­tec­tur­er d’une façon à per­me­t­tre une ex­ten­si­bil­ité d’une source qui four­nit la liste des util­isa­teurs.

Ex­em­ple d’analyse des logs

Ce prob­lème vient de se pos­er avant la mi­gra­tion vers le nou­veau site de Pel­i­can De­sign & De­vel­op­ment. Il était souhaitable de con­naître quelles pages du site ont été con­sultées le plus d’une part à l’ex­térieur, d’autre part à par­tir des ma­chines de l’en­tre­prise-même. Le nou­veau site n’ayant rien en com­mun avec l’an­cien, tous les liens au­raient été rom­pus, et il s’agis­sait de déter­min­er la liste des redi­rec­tions à établir pour les pages qui pou­vaient être util­isées. Le site com­por­tait l’en­sem­ble des logs IIS pour les dernières an­nées.

Une telle mis­sion peut très bien être con­fiée à une per­son­ne in­ex­péri­men­tée. Com­ment au­rait-elle procédé ? Il n’y a pas là de bonnes ou mau­vais­es ap­proches, sem­ble-t-il. Je con­nais­sais vague­ment qu’il ex­is­tait un out­il de pars­ing des logs IIS. Si je n’avais été pas au courant, j’au­rais prob­a­ble­ment es­sayé de faire bête­ment mon pro­pre util­i­taire très basique en C# per­me­t­tant de charg­er les don­nées vers la base de don­nées, pour en­suite l’analyser selon les moyens or­di­naires.

Une per­son­ne dif­férente au­rait peut-être cher­ché « parse iis logs » sur Google. Sans sur­prise, on tombe sur le site de Scott Hansel­man qui par­le de Log­Pars­er, et sans grande dif­fi­culté on trou­ve la page de télécharge­ment. Mais après avoir re­gardé la doc­u­men­ta­tion, je préfère plutôt im­porter les don­nées dans la base de don­nées et utilis­er Mi­crosoft SQL Man­age­ment Stu­dio qui m’y est plus fam­i­li­er pour analyser les don­nées.

La recherche « iis logs to mi­crosoft sql serv­er » donne en pre­mier ré­sul­tat l’ar­ti­cle de Knowl­edge Base de Mi­crosoft Sup­port qui in­dique qu’il faut :

• Créer une table SQL via une com­mande fournie dans l’ar­ti­cle-même,

• Faire un bulk in­sert des don­nées.

L’ar­ti­cle pré­cise, en out­re, qu’il faut sup­primer les lignes com­mençant par le car­ac­tère « # ». L’ar­ti­cle ren­voie vers un util­i­taire de Mi­crosoft chargé de le faire. Pas be­soin, Pow­er­Shell est là pour ça, et en plus per­met de com­bin­er tous les fichiers en un fichi­er unique :

foreach($i in ls -name *.log)
{
    get-content $i
        | where {$_ -notlike "#*"}
        | out-file -encoding oem -append All.log
}

Lors de l’im­por­ta­tion du fichi­er, le pre­mier souci ren­con­tré : il n’est pas pos­si­ble d’im­porter les don­nées dans la base de don­nées avec le sché­ma don­né dans l’ar­ti­cle de Knowl­edge Base, car le for­mat du log est dif­férent (W3C Ex­tend­ed en l’es­pèce). La re­quête peut être alors réécrite ain­si :

create table [dbo].[MainLogs]
(
    [date] date null,
    [time] time(0) null,
    [s-ip] varchar(40) null,
    [cs-method] varchar(10) null,
    [cs-uri-stem] varchar(1024) null,
    [cs-uri-query] varchar(1024) null,
    [s-port] int null,
    [c-username] varchar(50) null,
    [c-ip] varchar(50) null,
    [cs(User-Agent)] varchar(1024) null,
    [sc-status] int null,
    [sc-substatus] int null,
    [sc-win32-status] bigint null,
    [time-taken] int null
)

Dé­sor­mais, l’im­port avec :

bulk insert [dbo].[MainLogs] from 'c:\All.log'
with (fieldterminator = ' ', rowterminator = '\n')

se fait sans souci. On ob­tient alors les don­nées brutes qu’il faut dé­sor­mais analyser.

Reste le plus sim­ple : for­muler les re­quêtes pré­cis­es pour dis­soci­er les IP dis­tants des IP de l’en­tre­prise, puis af­fich­er les pages dans l’or­dre al­lant des URI les plus vis­ités à ceux qui n’étaient tapés qu’une fois, analyser les ré­sul­tats et les présen­ter.

Cette mis­sion s’avère donc tout à fait adap­tée à des développeurs débu­tants qui souhait­ent élargir leurs hori­zons, en peau­fi­nant ses con­nais­sances en SQL, mais aus­si en ap­prenant l’util­i­sa­tion de Pow­er­Shell ou d’out­ils sim­i­laires.