Aujourd’hui pas de recette de cuisine (remplacé par un barbecue + rosé bien frais demain), mais une question qui m’est venue à la lecture des commentaires de cette news :
http://linuxfr.org/news/de-tout-de-rien-des-bookmarks-du-bla-bla-29
Qu’est ce qui est demandé à un développeur aujourd’hui : maitriser un langage et son API sur le bout des doigts ; ou bien maitriser ce qu’il y a autour du code ?
Lorsque j’étais jeune développeur, j’ai eu des entretiens où on me posait des questions (y compris au tableau !) sur comment coder telle ou telle chose, écrivez une méthode qui fait ci ou ça, etc…
Sur le moment, j’y répondais en me disant que ça n’avait aucun intérêt. J’en suis encore plus persuadé aujourd’hui. Ainsi j’ai établi une liste de choses plus importantes à savoir qu’optimiser une fonction de tri :
Les choses plus importantes
- Savoir utiliser quotidiennement un outil de gestion de version, et tout le vocabulaire qui va avec, savoir pourquoi c’est important d’avoir une branche stable et une branche évol (à minima)
- Savoir lire une spec/un besoin, poser les bonnes questions fonctionnelles
- Savoir écrire et exécuter un Test unitaire (cas passant ET non passant), avec le jeu de données requis
- Savoir écrire et exécuter un test d’intégration
- Connaitre les critères d’acceptation d’une fiche d’anomalie, ainsi que le processus de traitement (quand est ce que je livre ? à qui sur quel environnement ?)
- Savoir évaluer la charge Dev+TU d’une fonctionnalité, au besoin en posant des hypothèses, et donc savoir quand est ce qu’on aura (raisonnablement) fini
- et bien sur savoir travailler en équipe
Pour moi tout cela est primordial sur la maitrise d’un langage en particulier ou même d’algorithmes génériques (mais cela ne l’empêche en rien).
Comment recruter un bon développeur ?
Il m’est arrivé d’avoir à faire passer des entretiens (de recrutement ou à l’entrée d’un nouveau dev sur un projet). Il ne m’est jamais venu à l’idée de lui faire coder au tableau un algo de tri pour savoir s’il maitrisait dans le détail le langage/l'algo. Ça ce sont des questions qui il me semble doivent être réservées aux experts techniques / développeurs seniors (appelez les comme vous voulez).
Au développeur sortant d’études, je lui demanderai s’il sait ce qu’est que la gestion de version, quels outils il a utilisés (IDE, VCS, base de données), ce qu’il a codé, s’il sait me parler de l’importance des TU.
A un développeur plus expérimenté, connaitre la gestion des anomalies, savoir évaluer une charge de dev+TU, et savoir ce qu’est une campagne de TI ou une PIC.
Pour les développeurs seniors et experts techniques, là ok, on peut rentrer dans de l’optimisation, de l’archi : « quels sont les pb de perfs que vous avez rencontrés et qu’avez-vous fait pour y remédier ? », « dans une appli web, à quelles couches rencontrez vous habituellement des pbs de perf ? ». Je tacherai de lui demander comment il fait pour gérer ou diminuer la dépendance aux libs externes.
D’ailleurs en passant j’ai rencontré incomparablement plus de problèmes de perfs dus à un mauvais schéma de base de données qu’à un algo de tri en Java. Au final, il vaut mieux connaitre SQL que savoir la notation O :)
Et vous qu'en pensez vous ?
Si vous faites passez des entretiens, que demandez vous aux personnes en face de vous ?
Et pour ceux ayant passé des entretiens récemment, quelles questions avez vous eues ?
PS : au passage, dans les commentaires de la news deux articles qui m'ont paru intéressants :
http://techcrunch.com/2013/06/22/the-technical-interview-is-dead/
http://techcrunch.com/2011/05/07/why-the-new-guy-cant-code/
# Algorithmique
Posté par Jérôme Flesch (site web personnel) . Évalué à 10. Dernière modification le 19 juillet 2013 à 17:25.
Les entretiens d'embauche les plus passionnants (et probablement les plus pertinents) que j'ai eut étaient pour des postes en Californie. Ils étaient concentrés sur l'algorithmique.
En gros, ils partent du principes que le langage et l'API, tout le monde peut l'apprendre sur le tas dans un temps raisonnable. Les bonnes pratiques (utilisation correcte d'un outil de gestion de version, l'écriture de tests unitaires, etc) peuvent être forcées par un passage systématique par la code review et donc elles peuvent être apprises sur le tas.
Par contre, la capacité d'analyse et de réflexion, c'est une autre histoire. En l'occurrence, ils cherchaient des gens capables de se sortir de situations complexes avec des algorithmes aussi peu coûteux que possible. Je ne parle pas juste d'écrire une fonction de tri. Je parle d'algorithmes sur des arbres/graphes, d'algorithmes distribués, etc.
Ces exercices d'algorithmique avaient aussi le mérite de tester l'aptitude à comprendre un énoncé (--> specs). Ils mettaient aussi fortement l'accent sur la capacité à communiquer : tout au long de sa réflexion, ils attendent du candidat qu'il explique sa démarche et discute avec l'interviewer.
Ils conseillent de se préparer fortement avant. Avant l'interview, ils suggèrent divers livres et exercices sur le sujet.
Je n'ai jamais eut d'entretien aussi complet et stimulant en France.
[^] # Re: Algorithmique
Posté par ckyl . Évalué à 4.
Même expérience pour moi. J'ai aussi eu ca sur des boîtes à Londres. Où il y a une communauté de très très bons et de boîtes qui poussent forts.
J'ai l'impression que depuis quelques années on est revenu du tout algorithmique/puzzle type CS bot. Maintenant ca commence plus avec des problèmes assez larges/ouverts/vagues pour finir par pousser très loin selon ce que tu maîtrises, où tu vas et ce qu'ils veulent tester. Ou avec des sessions de pair-programming. Du coup c'est super intéressant.
En France jamais eu un entretient intéressant ou utile pour le moment :(
[^] # Re: Algorithmique
Posté par kpet . Évalué à 3.
Pareil pour moi. Tous les entretiens que j'ai passés en Angleterre étaient vraiment techniques et intéressants. Les interlocuteurs sont réellement capables de comprendre les réponses et ne se contentent pas d'évaluer si "il a l'air de savoir de quoi il parle".
Quelqu'un a déjà vu ça en France ?
[^] # Re: Algorithmique
Posté par NeOwA . Évalué à 2. Dernière modification le 20 juillet 2013 à 13:38.
Oui, chez Dassault Systèmes, je me rappelle d'un entretient où on m'avait sortit différentes classes C++ et demandé quel aurait été le sizeof() retourné par le compilateur dans chacun des cas.
Héritage multiple, fonction virtuelle, variables statiques, padding, meta, public/privé…Je me rappelle qu'il y avait de quoi se prendre la tête :)
Plusieurs questions aussi sur le code généré par le compilateur avec des exemples de template, de generics, de meta-programmation.
Avec le stress de l'entretient, je me rappelle avoir bien flippé !
PS: Si il y'en a un qui pense qu'il aurait eu 20/20, qu'il nous fasse donc un journal ;)
Hors sujet (trolldi+1): Je sais que notre beau pays est en crise mais pourquoi vous avez tous cherché à relier la situation à "la France" ?
[^] # Re: Algorithmique
Posté par Renault (site web personnel) . Évalué à 6.
Tu trouves cette question pertinente et utile ?
Personnellement pour un entretien je trouve cela un peu exagéré.
Tu travailles dans les systèmes embarqués ou des systèmes très bas niveaux ? Car dans le cas contraire, là aussi je pense que c'est un peu exagéré dans le cadre d'un entretien.
Je n'ai rien contre des questions techniques en entretiens mais il ne faut pas non plus que ces dernières s'attachent à des compétences un peu inutiles voire inutilement complexes… Ce n'est que mon point de vue sur la question. ;)
[^] # Re: Algorithmique
Posté par octane . Évalué à 7.
Ca dépend. Ca dépend surtout de la réponse que va faire le candidat. J'ai eu à superviser une partie d'entretien pour un gars d'admin système (linux) avec un gros bagage en sécurité. J'ai posé des questions du genre: voici un laptop sous linux, peux tu te loguer root dessus? Certains ont rigolé et booté en init=/bin/bash, d'autres ont dit que ça ne se faisait pas, et d'autres ont dit que c'était impossible car linux était "sécurisé" par défaut.
Pareil avec des questions simples, et d'autres pointues. Du genre: qu'est ce que le phishing, ou bien: quelle est la meilleure manière de pousser un patch kernel sur un serveur en prod?
Je ne sais pas qui a été choisi au final, mais on voit vite "ceux qui savent", "ceux qui comprennent très bien la question, qui ne savent pas, mais qui vont trouver vite", et "ceux qui sont perdus car c'était pas dans le cours".
[^] # Re: Algorithmique
Posté par Renault (site web personnel) . Évalué à 7.
Tes questions ont du sens, surtout pour un admin système expert en sécurité.
Franchement la valeur de retour d'un sizeof dépend de tellement de facteurs et le résultat est tellement peu intéressant que je n'en vois pas l'intérêt sauf si la réponse attendue n'est pas une valeur brute mais une explication des parties variables.
C'est cela que je sous-entendais.
[^] # Re: Algorithmique
Posté par cedric . Évalué à 9.
Ca fait plus de dix ans que je suis developpeur et j'ai fait un certain nombre d'entretiens aussi bien en tant que candidats qu'employeurs.
Au final, je pense que la methode "californienne" cree un biais sur les candidats potentiels et ce biais n'a rien a voir avec leur competence, mais uniquement sur leur profil psychologique. Elle favorise les gens qui sont capable de sortir un jugement rapide (moins d'une heure pour trouver une solution a un probleme complex) sur un probleme donne. Or pour avoir rencontre un certain nombre de personne tres tres doue en informatique, aucun, mais alors absolument aucun, ne passera un tel test haut la main, car il leur faut un temps de reflexion.
Ce n'est pas pour rien qu'on dit qu'il faut reecrire 3 fois un programme pour arriver a la bonne solution ! Mais l'avantage d'une telle selection, c'est que si tous les membres de l'equipe ont la meme maniere de penser, cela facilite grandement la gestion des ressources humaines et permet d'avoir une equipe qui va facilement et rapidement dans la meme direction… De maniere symetrique, cela rend plus complique toute remise en question !
Je ne pense pas que ce soit un vrai probleme dans une culture de startup ou l'objectif est d'aller vite dans une direction et ou la remise en question est assure par le marche et une faillite de la societe. Mais cela peut etre plus problematique dans la societe francaise, ce qui explique probablement les differences des entretiens.
Apres a la sortie d'ecole, c'est tout de meme difficile de faire parler un candidat de ses experiences passees pour l'evaluer sans tomber dans l'approche scolaire avec une "soutenance" d'algo/developpement… Au final, recruter pour un stage a l'avantage de vraiment donner l'occasion de connaitre la personne et d'avoir une meilleur vision de ses capacites sans trop compliquer la vie de la societe si ca se passe mal (theoriquement le travail d'un stagiaire ne doit pas etre crucial pour l'entreprise).
[^] # Re: Algorithmique
Posté par Renault (site web personnel) . Évalué à 7.
C'est un peu dommage si tu n'as jamais étudié ces cas de figures en profondeur, ça pénalise fortement.
L'algo c'est bien mais c'est tellement vaste qu'à poser des questions trop pointues on peut se fausser dans l'évaluation du candidat. Sauf si justement les questions pointues portent sur ce que fait l'entreprise dans la plupart de ses applications (mais est-ce réellement le cas ? J'en ai vu pour qui ce n'était pas le cas…)
Mouais, quand tu tentent de passer une dizaine d'entretiens tu ne peux pas t'amuser en plus à faire des exercices et lire des bouquins pour chacun car cela prend énormément de temps. Ok ça teste la motivation mais là encore, ça me paraît un poil abusé.
Normalement tu utilises ton expérience, éventuellement ton diplôme, tes projets pour justifier ton savoir et ton savoir faire. Un bachotage avant un entretiens bof.
Pourtant pas mal de boîtes te font passer devant un directeur technique qui te font passer des tests ou te posent des questions techniques pour évaluer rapidement ton niveau. C'est souvent un change agréable où tu peux apprendre des choses sur le domaine de métier de la boîte et les technologies associées.
[^] # Re: Algorithmique
Posté par Jérôme Flesch (site web personnel) . Évalué à 1.
Oui mais non. Les questions que j'ai eut en Californie étaient à chaque fois des problèmes originaux (ils ont une énorme collection d'exercices en stock). Ils cherchent justement à éviter les cas déjà préalablement étudiés pour voir comment le candidat va s'adapter.
À mon avis, c'est plus une question d'apprendre à créer des algos performants que d'apprendre par cœur les cas courants (bien que les cas courants sont généralement de bonnes bases de réflexion). Si tu le fais pour un entretien, tu l'as fait pour tous. Au final, je pense que c'est loin d'être du temps perdu.
J'ai eut des tests techniques en France, mais leurs niveaux étaient bien peu poussés par rapport à ceux que j'ai eut en Californie. Ça manquait franchement de "challenge".
[^] # Re: Algorithmique
Posté par Renault (site web personnel) . Évalué à 3.
Sauf que chaque entreprise peut demander des choses différentes car ils ne font pas la même activité ou avec les mêmes méthodes et peuvent se pencher sur des problèmes différents.
Je prends beaucoup de plaisir à apprendre de l'algo, j'ai des bouquins théoriques et les exercices sont intéressants. Cependant l'apprentissage et la réalisation des exercices est long non seulement car ce n'est pas toujours évident mais aussi parce qu'il y en a beaucoup.
D'autant que en entretiens tu peux largement expliquer les choses sans aller dans du détail technique quand tu as un peu d'expérience, réalisé des projets où tu peux valoriser ce côté en expliquant les choix techniques, les problèmes et solution, les méthodes de travail, etc.
Des questions d'algo si pointues qu'il faut se préparer à l'avance, à part dans certains cas très précis où c'est le critère principale de sélection, je n'en vois pas l'intérêt immédiat. Je réserverais ce genre de tests sur la période d'essais.
# Les deux mon général
Posté par ckyl . Évalué à 7.
Le deuxième si tu fais de la "plomberie".
Les deux si tu fais de la plomberie un peu plus smart.
Les deux, plus des connaissances honnêtes en réseau/algo/hardware/OS si tu fais des "vraies" applis non plomberies qui font des trucs un peu chaud/marrant/gros.
Faut pas voir les choses de facon aussi binaire ;)
Maintenant tu as cité les compétences de base. En dessous c'est compagnie créole pas dev. Tu cherches des mecs qui se distinguent de différentes facon au dessus de ca. Tu places les exigences plus ou moins haut selon ce que tu cherches.
Si tu penses que tes critères de selection sont les bons, bonne nouvelle tu es très riche…
[^] # Re: Les deux mon général
Posté par Pierre Tramonson . Évalué à 2.
En effet je fais bien une distinction entre le développeur débutant (qui n'a souvent jamais rien vu de ces notions), le développeur tout court (qui utilise un VCS, un IDE, lit des specs, fait des tests, etc..) et le développeur senior et/ou expert technique (qui lui a la responsabilité de faire les algos compliqués, poser l'archi technique, mettre en place la gestion de conf…)
Je n'attends pas les mêmes choses de chacun c'est bien évident !
Et du coup les critères de sélection sont en conséquence.
Ce que je dis c'est que je n'ai pas besoin d'une équipe projet constituée à 100% d'experts techniques. C'est overkill, ça coute un bras et en plus ils vont se taper dessus parce leur framework/algo est meilleur/plus performant que celui du voisin (ce que j'appelle le syndrome de l'expert technique).
En contrepartie en effet ça dépote :)
Je préfère un mix de niveaux d'expertise, qui permet à l'expert de coacher le développeur qui lui même explique au débutant comment faire un commit.
Mais la recette miracle n'existe pas, et en plus elle est spécifique à chaque projet !
[^] # Re: Les deux mon général
Posté par ckyl . Évalué à 4.
Premièrement, ca dépend effectivement de ce que tu fais.
Deuxièmement, en pratique le coup des experts qui se battent sur des conneries ca arrive dans les boîtes ou tu utilises les experts comme tu le dis, que ca fait 10 ans qu'ils se tripottent la nouille dans des "cellules" plutôt que de livrer, et ou la gestion de projet est "rigolotte".
Autrement mon expérience quand les bons sont habitué à faire plutôt qu'à coacher; on discute pendant les X heures attribuées au design, estimations, ce qui est une très bonne chose et après on bosse basta.
Mouarf c'est ce que tu vois dans les boîtes Francaises. Du coup le bon il passe 0% de son temps à faire son job, régresse, et attrape le "syndrome de l'expert technique".
Quand tu embauches un débutant c'est pour que dans 1/2/3/4 ans il soit "expert" comme les autres de ton équipe. Par par ce que tu prévois que tu as actuellement du taff de merde à lui donner et qu'il ne faut surtout pas voir plus loin.
On entend souvent les gens se plaindre qu'ils sont super bon mais que leur taff c'est de la merde à cause des méchants client/SSII/autre. Mais le nivellement par le bas affiché un peu partout me fait assez peur. Martin Fowler disait dans Who needs an architect ?:
Je trouve cela très juste. Quand tu fais la comparaison entre la différence de salaire à embaucher des gens compétents et ce qu'ils sont capable de produire par rapport aux autres. Le calcul est assez vite fait. Nous sommes sur un marché où la compétition est mondiale et l'informatique est un moyen de faire la différence, de pousser de l'innovation, de gagner des marcher, de se doter d'outils performants qu'on aurait pas forcément imaginé etc.
Exemple: d'un côté tu as l'approche des journaux Français à chouiner pour des subvention incapables d'avoir la moindre idée nouvelle, de l'autre le New York Times qui se bouge…
# qu'est-ce qu'il dit ?
Posté par palm123 (site web personnel) . Évalué à 5.
quand je vois ta liste
"les choses les plus importantes"
je me marre.
C'est pertinent, mais je suis passé dans plein de boites où, à part les deux derniers points, ils ne comprennent pas du tout de quoi tu parles.
J'ai l'impression que par certains côtés, on revient avant la préhistoire de l'informatique…
ウィズコロナ
[^] # Re: qu'est-ce qu'il dit ?
Posté par Anonyme . Évalué à 2.
comme les premiers outils de versionning date de 1982, c'est pas faux. Parfois je le fait remarquer, tiens tu bosse comme en 1981 avant la création des outils de version de code (versionning ils connaissent pas)
[^] # Re: qu'est-ce qu'il dit ?
Posté par neil . Évalué à 2.
SCCS montre qu’il y avait quand même de la vie avant le GNU.
[^] # Re: qu'est-ce qu'il dit ?
Posté par Anonyme . Évalué à 1.
for an IBM System/370 ce n'etait pas dans tout les entreprises :) comparer au bon vieux IBM PC avec l'ecran vert
[^] # Re: qu'est-ce qu'il dit ?
Posté par netsurfeur . Évalué à 4.
SCCS était aussi disponible sur tous les UNIX des années 80 (SunOS, HP-UX, AIX,…).
[^] # Re: qu'est-ce qu'il dit ?
Posté par Mali (site web personnel) . Évalué à 4.
Rigoles pas, je bosse sans outil de versionning depuis 10 ans. J'ai beau avoir lancé l'idée plusieurs fois, ma hiérarchie n'y a jamais vu d'intérêt :(
Certainement que je n'ai pas trouvé les bons arguments … Je n'ai pas dù insister assez, sur l'aspect gain de temps et donc d'argent :-)
[^] # Re: qu'est-ce qu'il dit ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Intégration continue ?
Test automatique au moins partiel ?
Traçabilité avec les exigences ?
Test qui couvre toutes les exigences
bugtracker ?
Revue de code ?
Revue du code des testes ?
"La première sécurité est la liberté"
[^] # Re: qu'est-ce qu'il dit ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 9.
Travailler à plusieurs ? Revenir en arrière de 14j 3h 12m 8s ? Gérer 3 branches correspondant aux versions en prod et une branche de développement ? Avoir des sauvegardes ? Générer un changelog a posteriori ? Associer des bugs et des corrections ? Associer des exigences et des patchs/dév associés ? Savoir qui a codé quoi pour lui lancer des pierres ? Gérer le cas de l'écrasement du seul développeur par un tractopelle ? Tester une fonctionnalité expérimentale et la jeter ensuite ? etc.
[^] # Re: qu'est-ce qu'il dit ?
Posté par octane . Évalué à 10.
Je fais la réponse de très très très premier degré du responsable.
Aucun rapport avec un outil de versionning.
Va expliquer l'interêt de ce genre de truc a un chef. Si ça marche, c'est en prod. Si ça marche pas, faut corriger. Pourquoi revenir en arrière?
Cf ci-dessus.
Y'a Bob qui zip le dossier tous les soirs et qui se l'envoie par mail. Il paraît.
Un quoi???
Un bug, ça se corrige, point.
Le commercial a vendu la techno? Alors tu la codes, et tu te la fermes, t'as pas besoin de savoir pour qui c'est.
Les gars, c'est VOTRE code, c'est à VOUS de vous démerder pour savoir qui a fauté.
Des devs, y'en a pleins dans les cabinets de recrutements.
Quoi? Faire du travail non payé? Je sais que les devs aimeraient passer 80h par semaine devant leur écran à écrire du code, faudrait pas qu'ils s'imaginent pouvoir coder des trucs inutiles.
Voila
[^] # Re: qu'est-ce qu'il dit ?
Posté par Kerro . Évalué à 6.
Mauvaise entreprise, changer d'entreprise :-)
[^] # Re: qu'est-ce qu'il dit ?
Posté par Mali (site web personnel) . Évalué à 3.
Voilà, vous avez tous un peu raison, mais comme souvent le vie fait que les possibilités de choix de changer d'entreprise ne sont pas si simples ;-)
Et pour l'instant la balance penche penche toujours du côté "pas bouger", donc je reste tranquille. Si j'étais seul je pourrais, mais avec femme, enfants, maison, etc, il faut bien peser le pour et le contre. Et puis il y a aussi de bons côtés, même si on travaille avec les outils du moyen-âge :-)
[^] # Re: qu'est-ce qu'il dit ?
Posté par liberforce (site web personnel) . Évalué à 3. Dernière modification le 02 août 2013 à 02:38.
Au pif, trouver avec
git bisectquand un bug a été introduit, histoire de moins se galérer à deviner ce qui cloche ?Et sinon, à la RATP, j'avais des collègues qui faisaient des zip pour les sauvegardes, et aucune plateforme pour la gestion de version. Ça s'est fini que je me suis pris une vieille bécane et j'y ai installé un SVN + Trac. Suite à cette expérience, sur mon boulot suivant, je suis devenu intégrateur SVN.
[^] # Re: qu'est-ce qu'il dit ?
Posté par Christophe B. (site web personnel) . Évalué à 5.
+1
quand je vois certains devs de ma boîte c'est tout a fait ca …
ceci dit IRL je ne connais pas de client qui paierait
- pour que l'on fasse des tests
- pour que l'on gère des versions
et je ne parle même pas de la doc
de plus même si le dev précise qu'il faut 15 jours pour le coder/tester/mettre en oeuvre
le client répond qu'il veut que cela soit fait pour avant hier
bref parfois on n'a que ce que l'on mérite …
[^] # Re: qu'est-ce qu'il dit ?
Posté par Alex . Évalué à 6.
la gestion de version, ton client n'a même pas a le savoir, c'est dans ton process interne, et une fois le process mis en place et compris, ça a un cout très faible
pour les tests, j'aurai été daccord avec toi il y a 10 ans, mais actuellement, je vois de plus en plus passer des demandes grosses campagnes de tests, et on voit sur le marché de plus en plus de sociétés spécialisés (sogeti, altran, pour les grosses ssii, precilog, kereval, dalisys pour les petites)
[^] # Re: qu'est-ce qu'il dit ?
Posté par Hodj . Évalué à 1.
Pour la gestion de version, OK, c'est dans les process interne mais je ne connais pas un client qui est prêt à payer
Par contre pour les test, je bosse dans le service depuis 22 ans et j'ai vu très peu de client prêt à payer pour ça, ce qui l'intéresse c'est que ça marche et il y à la recette pour ça. Après comment tu te débrouille pour éviter les régression c'est ton problème. Je me souvient d'un client (l'année dernière), quand je lui ai présenté l'indus, il a été emballé, quand je lui ai dit que le charges allait être augmentée, il a dit qu'il s'en passerait.
[^] # Re: qu'est-ce qu'il dit ?
Posté par ckyl . Évalué à 6.
Au bout d'un moment on constate que la recette est contre productive et qu'il est beaucoup plus efficace de bosser en amont et de manière continue.
La recette, c'est beaucoup trop tard pour trouver les problèmes. C'est ta dernière phase avant la livraison. Tu fais quoi quand il y a un vrai problème ? Tu fais quoi quand il y a un truc à modifier ? Tu fais quoi quand tu te rends compte 6 mois après le début du dev que ca passe pas ?
Pour avoir vécu la migration de phase de recette qui durent 6/8 semaines vers des techniques de notre époque le client est au contraire très content pour ce que ca lui coûte moins cher pour avoir un meilleur produit… Avant les devs se tournaient les pouces pendant ce temps. Le produit était inévitablement plus mauvais par ce que l'assemblage, les tests, la détection des regressions et la validation par le client arrivaient beaucoup trop tard qu'on puisse y faire quoi que ce soit d'utile. Maintenant ca bosse de manière fluide, on livre à la demande des choses de qualité constante avec une vélocité constante et bien supérieure.
Le client il est pas con. Si c'est mieux pour moins cher il achète… Si en plus il peut comparer les résultats de différentes équipes ca devient vite flagrant pour lui. Si le coût à long terme augmente en faisant les choses correctement il y a un soucis quelque part…
[^] # Re: qu'est-ce qu'il dit ?
Posté par Pierre Tramonson . Évalué à 2.
Pour la gestion de versions, au contraire, je connais des clients qui sont prêts à payer pour que ce soit bien fait. Par contre le coût n'est pas explicite, il est souvent implicite et compris dans celui du développement (par ex).
Ils ont bien compris (j'imagine à la dure) que la gestion de branches, versions… est extrêmement sensible dans le cas de la maintenance logicielle.
Certains même demandent à déposer les sources dans leur VCS, et bien sur à utiliser leur VCS en cas de TMA. Ca me parait tout à fait sain, dès que le client est assez gros pour avoir son propre département informatique (capable donc de mettre en place les outils et process et les équipes pour les gérer).
Pour les tests, c'est à la fois plus simple et plus compliqué.
Les tests unitaires sont pour moi indissociables du développement et font partie du coût de dev. Je ne montre jamais au client un coût séparé pour les devs et les TU.
Par contre pour les tests d'intégration, là oui j'estime que ces couts sont montrables. Tout d'abord parce qu'ils ne sont pas forcément proportionnels aux cout de devs et qu'ils peuvent être calculés à part (ex: un test d'interface); ensuite parce que c'est un moyen de montrer au client qu'on s'assure que l'appli marche bien dans son ensemble avant de la lui livrer.
Un client ne peut pas à la fois exiger la qualité et ne pas payer pour cela (enfin si ils essaient, mais il ne faut pas céder).
Il faut convaincre en montrant tous les aspects négatifs de ne pas faire de TI (tests d'intégration) : manque de qualité, rejet utilisateur, recette plus longue (et délais de mise en prod explosés), maintenabilité en baisse, etc…
Pour l'industrialisation (donc j'imagine que tu parles par ex d'une PIC ?), je rejoins ton sentiment, c'est quelque chose qui sera difficile à facturer. Perso je vois ça plus comme un investissement à faire une année A, qui va améliorer les choses à l'année A+1 (gains de productivité, détection des régressions…)
J'ai pas encore rencontré de client qui était prêt à payer pour ça, je pense que c'est un coût à intégrer aux développements si tu souhaites en mettre une en place.
(vous aurez bien compris que je me place dans le cas du dév d'une application dite de gestion, pas d'un programme de type kernel, driver, programmation de commande numérique, etc…)
[^] # Re: qu'est-ce qu'il dit ?
Posté par Christophe B. (site web personnel) . Évalué à 3.
Pour être tout à fait honnête je ne code quasiment plus au boulot,
sauf pour des trucs d'admin ou qq petits projets qui trainent et qui durent.
admin sys c'est plus cool quand même (a condition de faire semblant d'être très méchant :) )
Certains client sont de plus en plus fous et sont prêts à tout pour économiser 3 euros six sous,
si tu as l'expérience tu peu expliquer au client qu'il se trompes.
Mais malheureusement beaucoup se croient plus malin que les technos et presque informaticien
tout cela parce qu'ils lisent je ne sais quel revue à la c.. spécial neuneus.
sans parler des malhonnêtes qui te font faire l'étude et utilisent ta proposition pour obtenir moins cher
chez l'épicier du coin.
Je sais que l'on a les clients que l'on méritent mais quand même …
D'un autre coté j'ai vu trop d'escroquerie pour qu'une relation de confiance s'installent entre client et techno.
A quand une forme de compagnonnage pour l'informatique ?
après tout nous autre technos nous sommes plus proche d'un artisan, dans le sens originel ou l'on met son art au service d'autrui.
[^] # Re: qu'est-ce qu'il dit ?
Posté par Alex . Évalué à 2.
Mais je ne dis pas le contraire, je dis juste qu'actuellement, le test est devenu une demande du client.
Même si on le croit bête, le client a subit le retour d'un projet foireux en terme de finance et d'image.
[^] # Re: qu'est-ce qu'il dit ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Le munci est un syndicat d'informaticien il me semble. Cela peut aussi servir dans ton cas.
"La première sécurité est la liberté"
[^] # Re: qu'est-ce qu'il dit ?
Posté par Alex . Évalué à 3.
Ce n'est pas un syndicat, juste une asso, mais ils sont assez lié à l'unsa
[^] # Re: qu'est-ce qu'il dit ?
Posté par Christophe B. (site web personnel) . Évalué à 1.
Merci je ne connaissais pas, en parcourant en diagonale je n'ai pas tout compris, sauf le Vrai/faux débat du manque d'informaticiens
mais je vais essayer de suivre.
En tout cas merci.
# ça dépend de ce que tu code!
Posté par brendel . Évalué à 5.
Je pense que ça dépend des projets sur lesquels tu bosses. Si tu bosses sur un énorme logiciel qui fait intervenir des dizaines de développeur mais qui ne met pas en œuvre des algorithmes compliqués, ou des traitements qui demandes des performances particulière (par exemple, le cas classique d'un système d'information où bien comprendre ce que veut le client est plus difficile que d’implémenter la solution à son problème) alors oui, maitriser les outils et les méthodes qui permettent de travailler efficacement dans une grande équipe c'est le plus important. Mais c'est pas toujours le cas. Par exemple, dans un gros logiciel il peut y avoir un petit noyau qui effectue des des traitements très compliqués, qui doivent être optimisé à mort etc… Les quelques devs qui bossent sur cette partie ont besoin de connaître leur langage à un niveau de détail plus élevé et/ou avoir un niveau correcte en algorithmique.
C'est que tu bosses probablement sur des logiciels avec beaucoup de code et de modules mais dans lequel la majorité du traitement est de faire des requête vers la base de données. La difficulté est surtout de gérer une grande quantité de code et de développeur efficacement. C'est loin d'être le seul boulot de développement possible. En plus, il y a d'autres boulot que développeur dans l'informatique :)
ça, c'est pas de l'informatique mais de la gestion de projet. Ce genre de compétence est commun à la gestion de projet dans d'autres domaines. C'est important et enseigné, mais c'est normal d'apprendre aussi des compétences plus spécifiques à l'info, par exemple de l'algorithmique ou de la théorie, pour les gens qui se dirigent vers d'autres métiers de l'informatique.
[^] # Re: ça dépend de ce que tu code!
Posté par barmic . Évalué à -3.
Un sacré paragraphe pour paraphraser le journal.
Faux, les tests par exemple, c'est de l'informatique. C'est des compétences spécifiques à l'informatique et ça demande des développements spécifiques. D'ailleurs il faudrait le prendre en compte lorsque l'on code. Dernier point c'est très peu enseigné.
Ensuite ce que tu appel la gestion de projet qui est en fait plutôt de la méthode de travail, ce n'est pas parce que c'est pas de l'informatique que ça n'est pas primordial. Pour moi c'est comme si tu disait à un médecin que gérer le patient c'est pas spécifique à la médecine que c'est de la gestion de clientèle ou du social.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ça dépend de ce que tu code!
Posté par brendel . Évalué à 4.
Ben, non, le journal dit que l'algo ça sert à rien, et mon paragraphe dit le contraire…
Certes, enfin savoir faire des tests c'est savoir programmer dans le langage dans lequel tu vas travailler quoi. Certes c'est pas de la gestion de projet comme le reste.
Ça pourrait être bien de lire mon commentaire avant d'y répondre. Je me cite :
[^] # Re: ça dépend de ce que tu code!
Posté par barmic . Évalué à 0.
Il dit le contraire parce qu'il parle d'un petit groupe de développeurs qui auraient besoin de maîtriser les performances sur les bouts des doigts ? On va dire qu'on les appels des experts techniques (c'est un peu ce qu'ils sont, non ?). Ça colle tout à fait à ce dont il parle :
Peut être devrais-tu lire le journal jusqu'au bout avant de le commenter ?
Bien sûr on peut tout mettre dans le socle initial sans quoi ça veut dire qu'on sait pas programmer (qu'on est à la compagnie créole diront certains). D'ailleurs personnellement je pense que l'algorithmique en fait partie justement parce que c'est le boulot. C'est ce que l'on passe 2, 3 ou 5 ans à étudier, donc quoi qu'il arrive on s'y est froté. Ce qui va démarquer les développeurs c'est ce qui est un peu moins technique, légèrement moins au cœur de leur métier.
Mais bon si on regarde d'un peu plus près, est-ce qu'il y a vraiment tant de tests que ça qui sont fait ? Par exemple le noyau Linux possède-t'il une base de tests unitaires (on comprend que les tests d'intégration peuvent être assez complexes à faire) ? Quelle est la couverture des tests de LibO ? LinuxFR possède-t'il une base de tests ?
En fait les tests c'est un peu comme l'algorithmique et les bench, c'est l'étape d'après la maîtrise d'un langage c'est l'étape « maintenant je sais parler qu'est ce que j'ai à dire ? ».
Dans la vrai vie, les tests sans quoi « tu ne maîtrise pas le langage¹ » sont relativement rares.
Pour la suite de ton commentaire. Tu peux être certain que les compétences spécifiques à l'informatiques sont enseignées relativement bien. Les « à coté » quand ils sont enseignés (on parle pas d'un cours de 2H sur les VCS), on une grande probabilité d'avoir étaient considéré comme barbant par les étudiants qui ont fait le strict minimum pour passer à l'année suivante et sachant qu'ils n'auront plus ce cours au semestre d'après.
¹ : Je ne comprends pas pourquoi tu parle de langages, la majeure partie des choses à savoir pour écrire des tests n'est pas liée au langage.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ça dépend de ce que tu code!
Posté par brendel . Évalué à 1.
Je ne pense pas que les développeurs qui font des trucs compliqués/optimisé en info soit "un petit groupe". J'ai pris l'exemple d'un petit noyau au sein d'un gros logiciel dont la majorité du code serait de l'enrobage du traitement effectué par ce noyau (IHM, etc) parce que ça me semblait correspondre à l'environnement du posteur. Mais je pense qu'il y a pleins de métier de l'informatique qui demande d'avoir des vrai compétence en algo/programmation avancé/système, etc.
Ouais enfin savoir faire des tests unitaire je trouve pas que ce soit une compétence a part entière, mais bon on peut le considérer comme ça si tu veux. C'est plus de l'enculage de mouche qu'autre chose la. J'ai déjà dit que je considérait que c'était pas de la gestion de projet et que c'était de la programmation. Je sais pas ce que tu veux me faire dire de plus. On dirait que t'es tombé dans le service test d'une SSII et tu veux me faire remarquer toute l'importance des journées passé à écrire des tests. Oui c'est super important, dans un gros logiciels avec pleins de modules c'est indispensable. Je pense que c'est overkill dans des projets simple (linuxFR par exemple) mais bon, jamais inutile. Après je pense pas qu'on ai besoin de faire des heure d'enseignement dessus, je me rappelle avoir eu un ou deux cours dessus, ça suffit selon moi.
c'est gentil de me donner une vidéo de 50minutes mais si tu pouvais résumer le passage important?
Encore heureux, le but c'est quand même de former des gens à l'informatique. Encore une fois le métier de développeur "Java dans les gros SI avec quasi que des requêtes SQL" (oui je généralise à mort c'est mal), c'est pas le seul métier possible, loin de la.
Le fait que les étudiants le trouve barbant ne veut pas dire que c'est mal enseigné. C'est pareil pour l'algo. En plus, d’expérience, beaucoup trouvent ça intéressant (dans mon expérience perso c'était les moins intéressés par l'info en général). De toute façon les gens que ça intéresse pas trop vont se diriger vers des domaines ou y'en a pas trop besoin. (J'ai par exemple fait très attention à éviter de me retrouver dans ce genre de boulot, parce que c'est pas mon truc).
A l'IUT ou j'ai été, l'accent était vraiment mis sur ce genre de cours. Je ne sais pas si c'est le cas de tous les IUT. En tout cas c'est ce qui m'a donnée envie de fuir le plus loin possible de ce genre de boulot. Je sais que dans les facs c'est très peu enseigné, sauf dans les master spécialisés (tard, donc), mais l'enseignement à la fac se veut plus théorique normalement. Dans certaines école d'ingé tout ce qui est gestion de projet est très prioritaire sur les autres cours.
[^] # Re: ça dépend de ce que tu code!
Posté par barmic . Évalué à 2.
Ton objectif quelque soit le logiciel que tu développe que tu sois une SSII, un projet communautaire, quelque soit ton langage et quelque soit les utilisateurs. C'est que la version N+1 puisse faire ce que fait la version N avec des choses en plus.
Tu tourne le problème dans le sens que tu veux mais l'idée c'est de trouver une solution pour garantir au mieux cette hypothèse de base. Pour ça tu as pleins de solutions (faire faire des tests par ta communauté, avoir tes recettes, embaucher des gars hyper-bon qui ne font jamais d'erreur, prouver ton logiciel, faire des tests, prier un dieux) et tu évalue la solution que tu met en place en fonction des contraintes de ton logiciel et de ta confiance en ceux-ci.
Ne pas s'intéresser sérieusement à cette problématique c'est faire du logiciel à la noix où l'on continue à habituer les utilisateurs à avoir des bugs et des régressions. La preuve que beaucoup de logiciels sont dans ce cas ? Certains sont bien heureux de pouvoir downgrader leur logiciel. Toute la plus value des distributions « stable » (Debian et Red Hat) par exemple viens du fait qu'ils ne prennent pas les logiciels upstream mais les logiciels upstream testé (par eux même et pas les autres distributions).
J'essaie juste de partager mon point de vu, rien de plus. On voit pleins de monde jouer des biscoto en expliquant qu'ils économisent x octets d'un coté et n de l'autre et qu'avec ça dans leur cas d'utilisation, le logiciel consommer 70 fois moins de mémoire et généraliser pour dire que c'est la base que nous devrions tous connaître. Alors que depuis des lustres le plus gros problème de l'informatique particulièrement quand c'est grand publique c'est les bugs, les régressions etc.
Fais-toi, un kiff et clique sur le lien pour voir.
Si tu avais cliqué sur le lien tu aurais vu que tu tombe pile au moment où Greg explique comment ils testent (grosso modo ils s'appuient sur la communauté et ne font aucun autre test, chaque commiter est responsable des tests de sont code). Ça dure 1m15s.
Pour ce qui est de la « gestion de projet » dans les points indiqués :
Bref tout ça pour dire que ton étiqutage basique « gestion de projet » / « technique » ça ne tiens pas la route. Soit tu es dans le monde de l'entreprise et il tu dois savoir faire ça pour ton chef, tes collègue et/ou tes clients, soit tu fais du logiciel libre à titre personnel et tu doit faire tout ça parce que c'est à toi de tout faire.
L'IUT forme avec l'optique que tu arrête tes études à bac+2 et que potentiellement tu crée ton entreprise. C'est pour ça, entre autre, que tu as eu des cours de droit et de compta. Les programmes ont bien sûr un peu évolués lorsqu'ils se sont rendu compte que 70% de ceux qui sortent n'arrêtent pas leurs études.
Les facs se trimbales 2 ans de sciences assez générales pour permettre aux étudiants de switcher plus facilement. Ensuite l'enseignement y est relativement modulaire et tu choisi ce que tu fait (bien sûr il y a un tronc commun).
Les écoles, ben ça dépend des écoles, ENSIMAG et Epitech ne sont pas comme d'autres écoles (on verra ce que donnera 42).
En tout cas il faut comprendre que faire du logiciel c'est bien. Le rendre utilisable c'est mieux et ça ça englobe un tas de choses qui ne sont pas de l'algorithmique à proprement parlé mais qui sont très importante et qui doivent souvent être pris en considération par les développeurs eux-même.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ça dépend de ce que tu code!
Posté par Batchyx . Évalué à 2.
Et toi, si tu avais fait un test fonctionnel sur le lien, tu te rendrai compte que en fait, ça tombe pile poil au tout début.
[^] # Re: ça dépend de ce que tu code!
Posté par barmic . Évalué à 3.
Je ne reproduit pas avec Firefox 21 sous Debian Wheezy Linux en 64 bits.
Peux-tu détailler ton problème ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ça dépend de ce que tu code!
Posté par Batchyx . Évalué à 2.
Si tu veut un rapport de bug formel avec un peu plus d'investigation…
OS: Debian sid amd64
Iceweasel 17.0.7
Plugin flash: Le dernier que flashplugin-nonfree propose de télécharger (11.2.202.297)
Extensions firefox: oh un paquet. C'est tellement plus simple quand on peut les installer avec apt ;) Mais parmi elles, il y a xul-ext-flashblock.
Description du bug:
Lorsque flashblock est installé et activé et que je suis ton lien, puis sur la vidéo (pour dire à flashblock de charger l'applet flash) la vidéo se lit depuis le début.
Le bug n'appairait pas si je me dépêche de cliquer sur la video dès que la page est chargée, ou si Flashblock est désactivé.
# Petite check list
Posté par Croconux . Évalué à 10.
Personnellement quand je recrute quelqu'un, je m'intéresse dans l'ordre à:
- La façon dont il/elle pense
- Le relationnel
- Un (tout petit) peu de technique pure
En premier le raisonnement parce que les outils, les langages, ça s'apprend. Quand on a l'esprit tordu, on ne peut souvent pas faire grand chose. Depuis que j'ai été embauché, j'ai connu pas mal de changements techniques (nouveaux frameworks, nouveaux languages, cvs -> svn -> git,…) et quand on est démerdard, ça ne pose pas de problème. Je préfère quelqu'un qui sache apprendre qu'une personne qui ait tous les buzzwords du moment sur son CV.
En général, il suffit de discuter un peu de problèmes sur lesquels la personne a pu travailler, ou bien lui demander quelle serait sa démarche face à tel soucis. On voit assez vite si le gars est logique dans sa tête ou pas et son niveau de culture "technique" (au sens large). Ce sur quoi il a pu bosser, ce qu'il connaît de la vraie vie. Exemple typique, l'un des meilleurs recrutement que j'ai fait c'est un gars qui venait de l'embarqué pour bosser sur du web. Il n'avait jamais fait de web (professionnellement). La plupart des cabinets l'auraient envoyé bouler. Mais en 10 min, on se rends compte qu'il touche un peu à tout. Face à un problème, il développe des petits outils pour gagner du temps. Il sait trouver de l'info, se former, il sait se qui se fait dans divers domaines. Bref, il apporte beaucoup.
Ensuite le relationnel parce que tu n'a vraiment pas envie de bosser avec un connard. Il y a des gens qui brillants mais incontrôlables voire carrément psychopathes. Je pense en particulier à un petit "terroriste" qui code la nuit, qui change du code qui marchait bien parce que "sa façon est meilleure" alors que 1) ça n'était pas prévu et ça met le projet en retard 2) avant ça marchait maintenant ça ne marche plus 3) il n'a pas jugé utile de prévenir qui que soit (surtout pas l'équipe de validation, faut pas déconner). Dans l'informatique, on ne travaille pas tout seul dans sa grotte donc il faut déjà être un minimum sociable, savoir communiquer/expliquer/donner de l'info et savoir écouter/comprendre. Beaucoup de soucis viennent de specs mal comprises, de questions non posées, d'informations perdues en cours de chaînes.
Je pose quand même une ou deux question un peu technique juste au cas où. Il y a des gens qui sont capables de pipoter de façon presque crédible si on ne gratte pas trop le vernis. Pas besoin d'aller chercher très loin, il suffit de prendre une techno sur laquelle il a bossé et de lui poser une question à laquelle quelqu'un qui a vraiment utilisé le truc (pas lu en diagonale un article sur la question) peut répondre. On voit tout de suite la différence entre celui qui a vaguement entendu parler d'un truc et qui se fait mousser et celui qui a mis les mains dans le cambouis. Le bullshit passe mal. Je préfère quelqu'un d'honnête qui admet ne pas savoir qu'un joueur de flûte soit disant capable de tout faire mais infoutu d'écrire un hello world.
Pour ce qui est des estimations, je dirais peu importe. Les estimations sont souvent fausses par contre chacun à tendance à se tromper toujours dans le même sens. Il y a les optimistes qui voient toujours un peu trop court et de l'autre côté les prudents qui se gardent une marge de sécurité qu'il n'utilisent souvent pas. A l'usage, on s'adapte. On voit rapidement du quel côté la personne penche et on fait en fonction. Et puis il ne faut pas oublier qu'une estimation reste une estimation. Il y a des aléas. Ca fait partie de la gestion de projet d'estimer les risques et de prévoir plus ou moins de marge en fonction de la complexité.
# Mes questions
Posté par small_duck (site web personnel) . Évalué à 0.
Ma première question en entretien (C++): "Quel est ton conteneur préféré?". Ensuite, je les grille dessus. Complexité de toutes les opérations, détails d'implémentation, efficacité vis à vis des caches du CPU, algorithmes standards (fusion de deux conteneurs triés…). Quant on est allé au fond des choses, je fais écrire un peu de code avec des templates (par exemple, retourner le max d'un conteneur), ce qui permet de reparler un peu des performances (incrémenter un itérateur de vecteur et un itérateur de liste, par exemple).
Après, quelques questions de culture générale sur les ordres de grandeur en temps pour accéder à un registre, la mémoire cache, la mémoire, le disque, et le réseau.
On parle ensuite un petit peu multithread, de réseau, de SQL.
Enfin, je les fait parler un peu de leur expérience, en leur demandant ce qu'ils considèrent comme étant la chose la plus difficile qu'ils aient faite cette année.
Et puis, c'est à eux de poser des questions :)
[^] # Re: Mes questions
Posté par Meku (site web personnel) . Évalué à 8.
Mais… ? Tu ne leur fais pas résoudre quelques expressions C++ et constructions du langage ambiguës durant ton entretien ? Comment savoir si ce sont des vrais bons sans ça !?
[^] # Re: Mes questions
Posté par Graveen . Évalué à 10.
C'est bien, tu les évalues niveau technique. De mon expérience, c'est généralement loin d'être un problème majeur.
Mais c'est sans doute spécifique à ton boulot.
De mon côté, en embarqué, j'ai besoin d'une équipe flexible, avec une culture informatique. Même en essayant de capitaliser sur certaines technos, il est rare que les devs aient travaillés sur tel bus, tel os, telles extensions temps réels, telle plateforme, tel CPU, tel compilateur/IDE/toolchain. Pourtant ils font tous du C….
Et l'aspect humain. Trés important l'aspect humain.
En général, l'aspect technique pur est de toutes façons évalué significativement pendant la période d'essai. Même si le but est évidemment de faire un bon recrutement.
[^] # Re: Mes questions
Posté par Littleboy . Évalué à 6.
Bon, je sais pas si ta boite est en France, mais je dirais que c'est pas tres representatif de la majorite des profils sur le marche (en France) :)
Par curiosite, tu en as beaucoup de profils qui tiennent la route en entretien? J'ose esperer que vous recherchez des gens avec deja beaucoup d'experience et qu'ils sont tres bien payes (parce qu'un inge junior C++ avec les competences listees et des connaissances reseau & DB, qui accepte d'etre paye des clopinettes, ca doit pas courir les rues).
[^] # Re: Mes questions
Posté par small_duck (site web personnel) . Évalué à 3.
En effet, c'est à Londres, et d'autant que je puisse comparer nous payons bien nos développeurs.
Je ne compte pas recevoir des réponses parfaites à toutes mes questions. Le but est de faire réfléchir le candidat, et s'il ne connaît pas par coeur la complexité d'insertion dans un std::set, c'est une bonne occasion de le faire réfléchir sur les opérations de base sur les arbres binaires.
Mais au final, c'est l'attitude qui compte le plus. On fait tous des erreurs et on ne peut pas tout savoir, mais l'envie d'apprendre et de s'améliorer, la petite étincelle dans les yeux quand ils découvrent quelque chose de nouveau, c'est ce qui fait généralement le bon candidat, je trouve. La manière dont un candidat va réagir lorsqu'on lui donne finalement la réponse à un problème sur lequel il vient de plancher est incroyablement utile pour le juger, d'ailleurs. Et j'ai horreur des entretiens dans lesquels on ne donne pas la réponse au candidat à la fin. C'est généralement le signe que les questions cherchent à coller ou à coincer le candidat, plutôt qu'à démarrer la conversation lui laissant sa chance de montrer là où il est bon.
[^] # Re: Mes questions
Posté par 2PetitsVerres . Évalué à 3.
Celui de 40 pieds, bien sûr, plus c'est gros, mieux c'est, non ?
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# Formation
Posté par Meku (site web personnel) . Évalué à 3.
Je partage ta liste de points importants.
Aujourd'hui je sais de quoi il s'agit, mais à la sortie de l'école (il y a 5 ans), je n'avais jamais vu aucun de tous les points que tu as cités (sauf le travail en équipe à la limite, en projet école, ou TP si on veut). Je n'ai eu aucune formation là dessus durant mes études et je le déplore. J'ai dû tout apprendre sur le tas :-/
Aujourd'hui ça me parait même incroyable que ces points ne soient pas abordés dans un cursus informatique (au moins pour une partie, je pense notamment à la gestion de version et l'écriture de tests). C'est pourtant si important !
[^] # Re: Formation
Posté par dave_null (site web personnel) . Évalué à 2.
Ça a peut-être beaucoup évolué en 5 ans, je suis en train de finir mes études d'ingénieur (plus que deux mois!), mais j'ai vu tout les points abordés.
L'écriture de tests et le Test Driven Development sont au programme dès la première année (et c'est normal). On a des cours sur l'utilisation des gestionnaires de versions et le bon sens fait que l'on est obligés de les utiliser tout au long de la scolarité.
[^] # Re: Formation
Posté par navaati . Évalué à 1.
Du coup, la question évidente : quelle école ?
[^] # Re: Formation
Posté par Alex . Évalué à 2.
Je vais faire mon casse couilles, mais il me semble que le test technique est enseigné partout, ce qui n'est pas enseigné (et je ne pense pas que cela soit un manque) c'est les compétences plus "procédurale", ce qu'on trouve, en gros dans le cftl
[^] # Re: Formation
Posté par barmic . Évalué à 2.
Tu entends quoi par est enseigné ? Un projet dans le quel tu par d'un projet existant et du quel tu doit écrire les tests ou quelques cours + quelques questions dans un examen ? Si c'est le premier, ce n'est pas partout.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par Alex . Évalué à 2. Dernière modification le 20 juillet 2013 à 14:27.
Le premier
bon je n'ai pas la prétention de connaître toutes les fac et école d'ingé de france, mais géneralement il y a toujours des moments du cursus où tu déroules un cycle en V, et donc tu réalises l'ensemble des tests (unitaire, système, etc…).
[^] # Re: Formation
Posté par dave_null (site web personnel) . Évalué à 2.
C'est Polytech Nice-Sophia, mais je ne sais pas si c'est très important :D
# Ce qu'on demande à un développeur aujourd'hui...
Posté par Claude SIMON (site web personnel) . Évalué à 10.
…c'est surtout ne pas faire preuve d'originalité !
Je suis développeur professionnel depuis plus de 12 ans, durant lesquels j'ai développé moult programmes, du petit utilitaire en ligne de commande, à la grosse application client/serveur, dont j'ai réalisé, et la partie serveur, et les clients pour les différentes interfaces (native, Web…). Les programmes que j'écris, en plus d'être portables, sont conçus de manière à être fiables, performants, économes en ressources et évolutifs, et les retours que j'en ai de leurs utilisateurs m'incite à penser qu'ils répondent à ces critères de manière plus que satisfaisante.
A priori, j'ai un profil susceptible d'intéresser un certain nombre d'entreprises. Pourtant, je pense que j'échouerai dans la plupart des entretiens 'standards' de recrutement, d'autant plus si ces derniers sont réalisés par des SSII.
Douze années de développement, durant lesquelles j'ai essentiellement codé en C++. Cela ne devrait-il pas faire de moi un spécialiste de ce langage ? Sauf que, dans les faits, je n'ai pas les connaissances communément admises comme nécessaires pour pouvoir me qualifier comme tel. Par exemple, je n'ai jamais, mais alors vraiment jamais, utilisé la STL, bien qu'il n'y ai pas un seul de mes programmes qui ne fasse un usage intensif des 'template's.
A mon avis, déjà là, je suis grillé.
Plusieurs applications client/serveur, autant la partie serveur que client, multiplate-formes qui plus est ? Je devrais connaître les bibliothèques de gestion des sockets, du multitâche, des mutex et consorts sur le bout des doigts ! Que nenni ! Parce que j'utilise des bibliothèques maisons qui prennent en charge ces éléments. Par exemple, pour la partie serveur, j'ai une bibliothèque qui gère un objet prenant un numéro de port et un 'callback', et qui, à chaque requête sur le port qui va bien, appelle la fonction adéquate du 'callback'. Bien sûr, lorsque j'ai écrit cette bibliothèque, j'ai étudié les sockets, le multitâche, les mutexes et consorts de manière approfondie. Mais, depuis qu'elle est fonctionnelle, et à part quand j'y apporte des modifications, ce qui est très rare, je ne me suis plus jamais penché sur ces éléments.
Grillé une seconde fois.
Les bonnes pratiques. Je n'écris pas de tests unitaires. En soi, je n'ai rien contre ; c'est rassurant d'utiliser du code dont on sait qu'il a passé avec succès tout une batterie de tests. Seulement, je n'ai pas le temps. Le fait est que je factorise mon code le plus possible, ce qui fait que les bugs sont très vite détectés, et donc corrigés, lors de l'utilisation courante du code incriminé. Bien sûr, il m'arrive de tomber sur des bugs particulièrement
ch…,emm…, ardu, genre qui se déclenche lorsque l'application est compilé en configuration 'release', mais pas 'debug', ou celui qui surgit de manière aléatoire, ou encore celui qui, bien que le même compilateur soit utilisé pour les deux, survient sur une architecture ARM, mais pas x86… Probablement que la plupart de ces bugs auraient été détectés lors de tests unitaires. Cependant, ce genre de bug est rarissime, et le temps que je prends pour les corriger est négligeable en comparaison du temps nécessaire à l'écriture systématique de tests unitaires.Et de trois !
Bref, un développeur, s'il ne se conforme pas à un certains nombre d'usages, même s'il apporte la preuve que ces usages ne sont nullement nécessaires pour faire du développement logiciel de manière efficace, n'a quasiment aucune chance de passer un entretien avec succès.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par Meku (site web personnel) . Évalué à 6.
Pourtant ça en fait gagner, du temps ;-)
Bien sûr, au début quand on n'est pas habitué à écrire des tests, ça prend un certain temps, c'est comme pour tout. Mais un bug découvert en développement coûte moins cher que s'il est découvert plus tard (en validation ou chez le client).
Quand on développe, on ne pense pas forcément à tous les cas qui peuvent survenir (cas nominaux comme cas d'erreurs). Par contre, quand on écrit des tests, on y pense plus facilement vu qu'on va essayer de retourner le soft dans tous les sens (on essaie d'imaginer toutes les combinaisons possibles en entrée). Et donc on peut revenir sur son code et colmater les cas oubliés. Sans compter les trucs dont on se dit « c'est trivial, ça ne peut que marcher » puis l'on se rend compte en testant que non, c'est quand même buggué… Maintenant, je considère carrément que du code non testé c'est du code qui ne marche pas (et j'ai déjà la ceinture et les bretelles grâce à Ada).
À une époque, sur un projet, on a tenté la production rapide sans tests (on code un truc puis on le valide immédiatement en plateforme intégrée), mais on a fini par abandonner, ça coûtait plus cher au final : régressions dans tous les sens (« ah merde, ça touche ça aussi ? »), tests à la con non passés car plus difficiles une fois tout intégré, qualité du soft moins bonne. Je faisais notamment beaucoup de factorisation de code aussi ;-)
Quand tu as un soft avec énormément de fonctionnalités, une bonne batterie de tests unitaires c'est redoutable contre les régressions. Ça me permet de coder plus vite, puisque je passe moins de temps à tout vérifier 3 fois avant de passer le bulldozer dans le code. Je vérifie une fois, puis si je casse des choses, les tests me le révéleront très vite.
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par barmic . Évalué à 5.
Je pense que le mieux pour s'en rendre compte c'est de le faire avec de l'IHM. Passer une recette est super lourd et long. C'est une plaie équivalente à celles d'Egypte. Une fois qu'on a automatisé ça on trouve les choses tout de suite plus agréables.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par Claude SIMON (site web personnel) . Évalué à 1. Dernière modification le 20 juillet 2013 à 11:26.
Pour en revenir au C/C++, si l'on code un logiciel en utilisant directement des fonctions des bibliothèques systèmes ou standards, il est indispensable d'écrire des tests unitaires. Si on appelle, par exemple, la fonction 'memcpy()', il est nécessaire de s'assurer, par ces tests, que les paramètres passés à cette fonction, quelles que soient les circonstances, soient toujours cohérents, sous peine de se retrouver avec un 'segfault' en production ou, pire, un comportement erratique de l'application, dont il sera très difficile de diagnostiquer l'origine, et donc d'y apporter les corrections nécessaires.
Dans mon cas, je ne fais jamais appel directement à des fonctions des bibliothèques standards ou systèmes. J'utilise un framework maison qui, lui, utilise bien entendu ces fonctions. Mais les objets gérés par ce framework sont écrits de telle manière que toute mauvaise utilisation, dont celles qui pourraient mener à un appel à des fonctions comme 'memcpy()' avec des paramètres incohérents, soit détectées et signalées. Ainsi, même des cas de figure qui mènerait à un appel à une fonction comme 'memcpy()' avec des paramètres corrects, mais algorithmiquement faux, sont détectés et signalés.
Ce framework est utilisé dans toutes mes programmes. Personnellement, j'utilise quotidiennement plusieurs outils, basés sur ce framework, que j'ai développés, ce qui fait que je détecte les éventuels problèmes du framework bien avant qu'ils n’apparaissent chez les utilisateurs de mes logiciels. De ce fait, à l'usage, ce framework se révèle extrêmement fiable.
Je ne sais pas si c'est cela qui fait la différence, mais, à ton expérience sur un projet mené sans écrire de tests, avec, pour conséquence, d’après tes dires, une augmentation des coûts, je ne peux que t'opposer mon expérience concernant l'ensemble des mes programmes, que j'ai développé sans écrire de tests unitaires, et qui ne présentent qu’extrêmement rarement des bugs une fois en production. Et si bugs il y a, leur correction est presque toujours triviale.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par Jérôme Flesch (site web personnel) . Évalué à 5.
Je ne vois pas ce que ça change. Que ça segfault ou que ça remonte une exception non-catchée, d'un point de vue fonctionnel, le problème est le même : le programme est buggué. Lever une exception au lieu de segfaulter n'excuse en rien l'absence de tests.
Vu que tu as ton framework maison, tu le connais par coeur. Tu connais ses points forts et ses points faibles. Tu sais de quel façon il est sensé être utilisé et du coup tu l'utilises toujours correctement. Au final, quand je lis ton post, j'ai l'impression que la fiabilité de tes programmes ne tient qu'à ça.
Est-ce que quelqu'un d'autre a déjà utilisé avec autant de succès ton framework ? Est-ce que quelqu'un a déjà fait des modifications importantes dans ton code sans causer de régression ?
Aussi est-ce que tu as déjà développé un programme en équipe ? Je veux dire à plusieurs sur un même programme ou librairie (et je ne parle pas de pair-programming). D'après mon expérience, dans cette situation, comme chacun ne sait jamais précisément ce que l'autre a codé, les tests fonctionnels et unitaires sont le seul moyen efficace d'éviter des régressions.
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par Meku (site web personnel) . Évalué à 3.
J'ajouterais que ça ne couvre pas tous les problèmes, notamment tout ce qui est résultat erroné. Exemple : lors d'un traitement, le logiciel affiche « Foo » alors qu'on attendait plutôt « Bar ». Ça n'a rien d'un bug technique, mais plus de logique. Pour détecter ces bugs, il faut bien tester !
[^] # Les tests unitaires, c'est bon, mangez-en :-)
Posté par Claude SIMON (site web personnel) . Évalué à 1.
Mes commentaires n'ont absolument pas pour but de jeter le moindre discrédit sur les tests unitaires ou de mettre en doute leur utilité. Au contraire, j'encourage fortement tout un chacun d'écrire des tests unitaires pour les programmes qu'ils développent. Mes propres programmes ne s'en porteraient certainement pas plus mal si je les soumettais à une batterie de tests unitaires. Seulement, il se trouve que, dans ma situation actuelle, avec les outils que j'utilise, de la manière dont je les utilise, le gain que m'apporteraient les tests unitaires est tellement faible par rapport au temps que je devrais consacrer à leur mise en œuvre que cette mise en œuvre n'est économiquement pas justifiable. Si cette situation devait évoluer, que le nombre de bogues entachant mes programmes augmentait de telle manière que cela le justifierait, je n'aurais absolument aucun état d'âme à mettre en place des tests unitaires.
Parce que j'ai l'audace de ne pas écrire de tests unitaires pour mes programmes, et surtout l'outrecuidance de m'en justifier au lieu de faire repentance, et voilà qu'on me jette l'anathème (bon, j'avoue, j'exagère un peu :-> ). Les réaction à mes commentaires vont exactement dans le sens de ce que j'affirmais dans la dernière phrase de mon premier commentaire.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Jérôme Flesch (site web personnel) . Évalué à 4.
Je reprend donc la dernière phrase de ton premier commentaire :
De mon point de vue, pour l'heure, le seul moment où tu as prouvé que les tests unitaires sont optionnels, c'est quand on développe un logiciel dans son coin, avec aucune intention de laisser quelqu'un d'autre toucher aux sources. Or en entreprise ce cas n'arrive grosso-modo jamais.
Même en mettant ça de coté, un autre problème, c'est que ce n'est même pas ce que tu me sembles dire dans tes commentaires. Ce que tu me sembles dire, c'est qu'ils sont optionnels, point.
Présenté comme ça, avec moi comme interviewer, effectivement, je te confirme que tu n'aurais pas le job.
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Claude SIMON (site web personnel) . Évalué à 1.
Cette phrase signifie, associée au paragraphe sur les tests unitaires, qu'il existe au moins une situation (la mienne) dans laquelle ne pas écrire de tests unitaires n'influe pas de manière significative sur la qualité globale du code produit, et que cela constitue au moins une exception à une règle qui, parce qu'elle s'est trouvée vérifiée dans leur propre situation, ou dans les situations dont ils ont eu connaissance, a été érigée en dogme par beaucoup.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par j_m . Évalué à 4.
Tu as l'air de vouloir éviter la question du travail en équipe. A mon avis, dans un entretient il faudrait que tu y répondes.
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Claude SIMON (site web personnel) . Évalué à 1.
Je suppose que tu fais référence à ça :
Dans le mesure où il ne me semble pas avoir signifié ou laisser entendre que j'excluais formellement tout usage de tests fonctionnels et unitaires dans la situation décrite ci-dessus, je ne vois pas ce que j'aurais pu écrire à ce sujet qui aurait fait avancer le débat…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Ce qu'on te dit, c'est que tu ne cesses de dire que dans ton cas les tests unitaires n'apporterait que peu de valeur ajoutée car tu connais bien le code , mais en entretien (puisque c'est de ça dont vous parliez à la base), on embauche rarement quelqu'un en ayant en tête le fait qu'il sera le seul (non seulement sur une période définie mais également du début à la fin de vie du produit hein, du genre si tu te barres et que quelqu'un reprend ton code, pas de tests unitaires => modification délicate des libs de la part du newbie) à bosser sur un code et le connaîtra tellement qu'il pourra se passer de tests unitaires.
Donc en gros, tu lui diras quoi à l'interviewer ? Que tu pourrais te passer de tests unitaires sur un projet où tu bosserais en solo ? mouaiiis. En effet, bonne chance !
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Claude SIMON (site web personnel) . Évalué à 1. Dernière modification le 22 juillet 2013 à 17:21.
Ce que je dis, c'est qu'en entretien, si le sujet est abordé par le recruteur, il suffise que je dise que je ne soumets pas mon code à des tests unitaires pour que la plupart d'entre eux ai un à-priori négatif à mon sujet, comme si cet état de fait était limite constitutif d'une faute professionnelle et impliquait une opposition inconditionnelle de ma part à leur mise en œuvre quelle que soit la situation.
A l'image de ce qui se passe ici. L'objet du premier commentaire à mon intervention, et d'un certains nombre des suivants, a été de tenter de prouver que j'avais tord de ne pas faire usage de tests unitaires, et ce sans même s'enquérir d'éventuelles particularités dans ma manière de développer, dans ma façon d'utiliser certains outils, ou dans que sais-je quoi d'autre encore, qui eussent pu justifier leur non-utilisation.
Je me contente simplement de faire preuve d'esprit critique à l'égard des test unitaires, et cela est perçu comme une hostilité de ma part à leur usage, quand bien même j'ai explicitement affirmé le contraire dans ce commentaire-ci.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par ckyl . Évalué à 4. Dernière modification le 22 juillet 2013 à 17:49.
Sauf cas extrême (Linux en est un), si tu as trouvé une manière de développer, une facon d'utiliser certains outils, ou que sais-je quoi d'autre qui permet d'avoir la même qualité à long terme en ce passant de une partie importante du cout de développement d'un logiciel, écrit un bouquin tu es riche, très riche… Autrement c'est pipo.
A chaque fois qu'une équipe m'a sorti le refrain "Non mais tu comprends pour ce type de produit ca sert à rien c'est trop difficile" ils livraient de la merde et avancaient comme des tortues… Ou c'était un mec qui faisait des trucs tout seul dans son coin comme un gros goret.
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Claude SIMON (site web personnel) . Évalué à 1.
Je me borne à rapporter un fait. J'écris du code, je ne le soumets pas à des tests unitaires, et il fonctionne de manière satisfaisante, autant du point de vue de ses usagers dans son utilisation quotidienne, que du mien en terme de maintenabilité et d'évolutivité. Maintenant, bien que j'ai quelques idées à ce sujet, je n'ai jamais lancé d'étude approfondie visant à en déterminer les raisons. Peut-être que je devrais. En tout cas, tu comprendras je ne vais pas me lancer dans la rédaction d'un ouvrage sur le sujet, ce qui représente une tâche conséquente, sur la seule foi de tes affirmations…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Tu comprends bien qu'on est plus trop ici dans l'optique "que faisiez vous avant ?" mais plutôt "qu'êtes vous prêt à faire avec nous ?" et que si tu insistes en disant que tu as pris l'habitude de bosser sans tests unitaires, si l'autre en face n'est pas né de la dernière pluie, va interpréter ça comme "ouais alors lui, je pense qu'il aime pas les tests unitaires, il a des années de stratégie d'évitement (pas forcément au sens négatif du terme) pour les utiliser, ça va pas l'faire avec nous car on bosse en équipe avec parfois des stagiaires qui mettent les mains dans le code, ou bien seulement des gens qui veulent optimiser une routine bas niveau la veille de la mise en prod' et paf le chien"
Pour ma part, je considère que pour un code donnée, il faut toujours assumer que
- on est pas le seul à bosser dessus (même si on est vraiment seul à un moment donné)
- l'autre n'aura pas forcément notre connaissance du code
- l'autre, c'est peut-être nous-même dans quelques mois/années
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Claude SIMON (site web personnel) . Évalué à 2.
Je partage tout à fait cette analyse, c'est pour cela que j'ai précisé "si le sujet est abordé par le recruteur". Il est clair que si j'en parlais de ma propre initiative, cela pourrait être perçu comme une revendication, et je comprendrais que cela soit mal perçu. Mais si le recruteur me demande, voyant que j'ai quelques programmes à mon actif, si je les soumets à des tests unitaires, je ne vais pas mentir juste pour lui faire plaisir, d'autant qu'il risque de me demander de lui montrer le code correspondant, auquel cas je serais bien ennuyé. Le problème c'est que, même dans ce contexte, ben ça passe mal…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
En même temps, les tests unitaires c'est pas super utile, si tu as des vrai tests couvrant de très haut niveau. Il est rare d'avoir un bug de bas niveau non trouvé par un test haut niveau, et il est impossible de trouver un bug de haut niveau avec un test unitaire (problème d'intégration, trou de spec, etc…).
J'ai jamais vu de test LLR qui trouve des bug non trouvé par les tests HLR, en général, il s'agit de mode non utilisé.
"La première sécurité est la liberté"
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Meku (site web personnel) . Évalué à 2.
Il faut trouver un juste milieu, ça dépend des types de logiciels je pense.
Les tests couvrant de haut niveau peuvent parfois être vite limités par la combinatoire des cas possibles (qui explose). Dans ce cas, on peut couvrir en haut niveau les cas nominaux et les cas d'erreur courants, et laisser les tests de plus bas niveau couvrir les autres cas d'erreur.
Le choix du niveau du test (bas ou haut niveau) peut aussi se faire en fonction de la complexité de mise en oeuvre du test. C'est parfois bien plus facile de stimuler (ou simuler) une erreur bas niveau en unitaire, plutôt qu'en test de haut niveau ou test sur environnement intégré (par exemple, des cas de race condition).
Sur le projet sur lequel je travaille (un système distribué), on a trois niveaux de tests :
- test unitaire bas niveau : on test les rouages, les algos, les traitements des données, …
- test de pré-intégration : on test le comportement du composant logiciel, s'il répond bien aux entrées, sans forcément regarder dans le détail les données qui sortent. C'est un test de plus haut niveau déjà.
- test de validation : tous les composants sont intégrés, on test alors qu'ils communiquent bien ensemble (interfaces), ainsi que les cas nominaux en partant du bas de la chaîne jusqu'au résultat final. Les cas d'erreurs peuvent par contre être extrêmement chers à mettre en place.
On a bien sûr pas la même couverture sur chacun de ces niveaux de tests.
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"Les tests couvrant de haut niveau peuvent parfois être vite limités par la combinatoire des cas possibles (qui explose). Dans ce cas, on peut couvrir en haut niveau les cas nominaux et les cas d'erreur courants, et laisser les tests de plus bas niveau couvrir les autres cas d'erreur."
C'est vrai, d’où l’intérêt de concevoir en fonction des testes pour ne jamais avoir ce genre cas. Ce cas veut juste dire que tu as une surface énorme de bug potentiel, et je ne parle pas de surface d'attaque de sécurité. J'aime bien aussi les tests avec fuzzers, cela doit permettre de couvrir un paquet de cas.
Concernant vos tests, vous faites de la revue de code de test ? Les tests (non unitaire) sont écrit par des personnes différentes ? La couverture est bien vérifié ?
"La première sécurité est la liberté"
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Meku (site web personnel) . Évalué à 2.
Hélas, non, on n'a pas de revue de code (code de test ou non). C'était prévu à l'origine, mais bon… C'est un des premiers trucs qui saute dès qu'on a des retards ou problèmes de budgets. Il faut aussi des gens capables d'auditer du code ou des tests.
Certains tests de pré-intégration ont été fait par des personnes qui ne codaient pas les logiciels testés. Je suis un peu mitigé sur le résultat (mais c'est peut-être déjà mieux que si ce n'était pas le cas).
La vérification de la couverture… C'est dans la TODO list.
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Si le temps manque, cela peut se faire par "sampling". Cela mets la pression sur le développeur, et cela évite au testeur de se laisser tenter par un "return true;" dans un tests… (vécu).
La vérification de couverture, cela peut être rapide. Cela permet au minimum de découvrir une zone oubliée. C'est toujours instructif.
"La première sécurité est la liberté"
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par barmic . Évalué à 2.
Tu as des outils pour faire ça automatique (couverture des instructions, des branches, des chemins…).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Au niveau libre, gcc ne permet que la couverture d'instruction. C'est un peu léger, par contre. Une couverture de branche serait plus complète.
"La première sécurité est la liberté"
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
T'es sûr de ton coup ? Ou alors, on n'utilise pas le même vocabulaire ?
Moi, je pensais couverture de branche comme le monsieur ici.
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Oui, c'est ça. Cela a du être ajouté depuis la dernière fois que j'ai regardé.
"La première sécurité est la liberté"
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Meku (site web personnel) . Évalué à 2.
C'est vrai. Depuis que je code en faisant beaucoup de tests, ma façon de concevoir des logiciels a évolué dans ce sens. Il faut aussi parfois convaincre les architectes systèmes, qui ne s'en rendent pas forcément compte vu qu'ils n'écrivent pas les tests.
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
C'est en général en suivant ce genre de règle que l'on évite de mettre des eval() dans un fichier de configuration, cela parait pratique pour le dev, mais pour la validation, c'est impossible à tester.
"La première sécurité est la liberté"
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par ckyl . Évalué à 4.
C'est possible d'échouer à un entretien de SSII ? Pour de vrai ?
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par Dr BG . Évalué à 5.
Facile. Quand ils me demandent quel serait le type de boulot rêvé, si je suis mobile, et combien je compte gagner, ils ont toutes les infos pour savoir que je n'ai pas le profil.
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par ckyl . Évalué à 4.
Ca ne compte pas comme échouer ;)
Mais même en appliquant à la lettre ce que tu dis, vraiment, j'en connais qui ont "réussi" tout de même. Ils ont juste recu une proposition 20K en dessous de leur salaire actuel (en étant au courant)…
Non sérieusement tu peux pas échouer dans le sens ou le seul truc qui intéresse c'est le différentiel prix de placement/salaire et que techniquement ils pigent rien, c'est juste des, plus ou moins mauvais, RH. Au pire t'as une proposition irréaliste.
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par cedric . Évalué à 4.
C'est sur, le test unitaire avec couverture de code, c'est utile. Mais ce n'est pas une balle d'argent qui change la face du monde. Ca aide, des fois… Tu peux rarement avoir une couverture superieur a 80%, car juste la gestion des erreurs qui n'arrivent jamais et sont difficile a injecter durant tes tests (quel appel systeme peut echouer, quels sont les valeurs de retour acceptable, …). Quand tu commences a devoir tester des interfaces graphiques, ca tombe encore plus bas. Tu peux comparer les pixels de sortie. Mais si le probleme est frame drop dans une animation pilotee par un developpeur, tu vas avoir beaucoup de mal a le detecter. Sans compter les problemes entre les differentes version de drivers qui fait que au final, ton test unitaire devient en pratique un test d'integration sur plusieurs millions de ligne de code…
Au final, avoir une communaute de testeur qui a l'oeil est rapporte les problemes clairement et rapidement a plus de valeur qu'une suite de tests (Ce qui ne veut pas dire qu'on peut s'en passer). Pour faire simple, le meilleur test, c'est eat your own dog food !
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"Tu peux rarement avoir une couverture superieur a 80%, car juste la gestion des erreurs qui n'arrivent jamais et sont difficile a injecter durant tes tests"
L'avantage de s'obliger à 100% de couverture, c'est que te repenses ton architecture, pour éviter justement tout ces cas, qui n'existent pas. Coder en imaginant le test, peut faire gagner beaucoup de temps.
Concernant les piles logiciels, si chaque bout est correctement testé, l'assemblage est (censé) avoir peu de bugs.
"La première sécurité est la liberté"
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par cedric . Évalué à 4.
C'est plus l'exception que la regle. Avoir des appels systemes qui ne font jamais d'erreur, avoir de la memoire infini pour ne jamais faire un echec lors d'une allocation, ne pas avoir de corruption de ses systemes de stockage, … Il y a toujours des erreurs, faut juste faire en sorte que le systeme se degrade pas trop.
Tester le cas qui marche, oui. Tester quand une partie du materiel a chaud, froid, recoit un rayon cosmique, … ca devient moins probable. Sans compter que le materiel moderne est tres tres fortement asynchrone et multi cpu, ce qui introduit des races conditions que tu vas avoir un mal de fou a voir sur une suite de test unitaire.
Une suite de tests limite les regressions, mais pas les bugs.
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"Avoir des appels systemes qui ne font jamais d'erreur, avoir de la memoire infini pour ne jamais faire un echec lors d'une allocation, ne pas avoir de corruption de ses systemes de stockage, … Il y a toujours des erreurs, faut juste faire en sorte que le systeme se degrade pas trop."
Disons que si le logiciel ne considère pas avoir une infinité de mémoire, et par exemple essaye de ne plus allouer de mémoire au bout d'un moment, cela réduit fortement la probabilité de problème de mémoire. Il faudrait aussi que les erreurs des appels systèmes ne soient pas forcément toujours rejeté à la couche au dessus, qui ne sait souvent pas quoi faire.
"Une suite de tests limite les regressions, mais pas les bugs."
Cela dépend si tu as une vrai spécification. Je peux te dire que pour un soft DO178, il peut rester des bugs mais dans des coins super tordu (souvent lié à une trop grosse spécification).
"La première sécurité est la liberté"
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par cedric . Évalué à 3.
Oula, non surtout pas ! Je les veux les erreurs pour pouvoir tenter d'agir intelligement. Une allocation memoire qui echoue, c'est le moment de vider les caches ! Un acces au disque qui est corrompu, il faut peut etre le signaler a l'utilisateur, … Je te laisse faire la liste de tous les cas possible et imaginable !
Si tu ne fais pas de multi tache, que tu n'as pas de multi coeur, que ton OS n'a pas d'acceleration hardware, alors probablement que oui. Mais pour tout le reste, ce qui correspond globalement a la grande majorite de l'informatique moderne, ta suite de test ne t'aidera pas pour chasser les bugs juste eviter que certains ne reviennent pas !
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 24 juillet 2013 à 11:11.
Ben non, perdu ! Il suffit de regarder que 98% de la production de processeurs finit dans l'embarqué (source). Sachant que l'embarqué ne se cantonne pas à des plateformes lourdes type Linux, une partie non négligeable de l'informatique moderne se trouve donc dans les lave-linges, les lave-vaisselles, les téléviseurs et les fours micro-ondes (les autres m'excuseront de les avoir oublier) et n'a pas de multi-coeur, de multi-tâche et pour certains même pas d'OS (le petit lien pour ça).
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par cedric . Évalué à 3.
Peut etre qu'ils sont plus present en quantite, mais ce n'est clairement pas eux qui recoivent la majeur partie du logiciel qui est developpe. D'ailleur, ceux ne sont plus des microprocesseur que tu trouves dans les l'air conditionnee, four, lave-linges, lave-vaisselles, tv et autre micro-onde. Aujourd'hui on met dedans des Linux complets dedans, ils commencent a se connecter en Wifi avec un ecran LCD et sont multicoeur… Meme les imprimantes deviennent multi-coeurs.
Clair que les quantites de microprocesseur 8bits sont deverse sur le monde, mais la majorite du developpement logiciel a bien lieu sur les 2% restant. Le nombre de personne qui travaille sur un micro controleur sont vraiment pas la norme, mais l'exception.
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Dans l'embarqué "lourd" (train, avion, bateau, voiture, grue, ascenseur, machine-outils, satellite, …), c'est souvent du PowerPC, voir de l'ARM. Et cela tourne avec vxworks ou rtems. Et les équipes de logiciels se comptent en milliers de personne.
Et c'est vrai que le multicoeur fait peur.
"La première sécurité est la liberté"
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par 2PetitsVerres . Évalué à 2.
Quand tu dis que les équipes de logiciels se comptent en milliers de personnes, tu veux dire quoi exactement ? En cumulant plusieurs trains, bateaux, voitures, … ? Parce que je me rappelle avoir travaillé sur du logiciel de satellite, et l'équipe logiciel, développement et validation compris, on était moins de 20. (Ah et ce n'était ni du vxworks ni du rtems, c'était un OS temps réel maison)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
20 personnes pour un seul satellite ? Je cumule la validation et le dev du bus, de la charge utile et de tous les composants.
"La première sécurité est la liberté"
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par 2PetitsVerres . Évalué à 2.
Bon, je pensais principalement au bus, tout en sachant aussi qu'on réutilisait des COTS, mais effectivement, il devait y avoir un peu de software dans la charge utile (mais pas tant que ça) et dans certains composants. Mais à part le GPS qui nous fournissait des résultats «intelligents» (et d'une certaine façon c'était aussi un COTS, vu le temps qui leur fallait pour répondre à des questions simples, ils ne devaient plus être des masse à bosser dessus…), la plupart des développements en dehors de notre équipe (j'ai dit 20, c'est peut-être 30 en tout sur la durée, mais jamais plus de 20 simultanément) étaient très bas niveau. Les autres équipements, c'est principalement matériel (des capteurs qui renvoient des voltages/pulse/…, des actionneurs qui prennent des pulses/voltages en entrée, le tout qui doit être converti par le logiciel du bus)
La charge utile, par exemple, c'était principalement géré par notre logiciel (avec assez peu d'intelligence), on recevait la TC, et on transformait ça commandes sur le bus 1553. Les commandes à interpréter par le logiciel de la payload se résumaient en gros à «mute, unmute, on, off, changement de gain, changement de position de switch.» Pas vraiment de quoi occuper des centaines de développeurs a priori. (je ne compte que le logiciel, pas ceux qui développent le matériel)
Après ça dépend comment et qui on compte, je suppose. Est-ce qu'il faut intégrer les gens qui mettent au point les lois de contrôle (mais qui n'écrivent pas de code, mais une spec), est-ce qu'il faut intégrer les gens qui font le logiciel des bancs de tests, des simulateurs, … ? Faut-il compter ceux qui ont développé il y a des années des parties réutilisées ?
Mais on n'arrive pas à des milliers, ça c'est sûr.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Quand je bossais chez TI, ils avaient estimé qu'il y avait 1000 personnes qui avait touché à l'OMAP3. Lors du dev d'une partie d'une boite d'un avion, il y a eu jusqu'à 40 dev en parallèle (des boites comme ça il y en a une dizaine dans un appareil). Et je ne parle pas de validation.
Je compte vraiment tout. Le mec qui a fait son hard, il a sans doute fait un modèle logiciel de son truc, idem pour le valider.
C'est vrai que le satellite, c'est spécial, car on cherche à en faire le moins possible et tout mettre dans le segment sol.
"La première sécurité est la liberté"
# My tailor is rich
Posté par _kaos_ . Évalué à 4.
Je vois que le sujet n'est pas abordé.
Au delà de la technique, une langue étrangère (l'anglais, pour citer) est bien plus important à mes yeux que la maitrise d'une API.
Matricule 23415
# Les choses importantes
Posté par Meku (site web personnel) . Évalué à 6.
Dans la listes des choses importantes, j'ajouterais quelques compétences qui me paraissaient évident mais qui en fait, ne sont pas partagées par tout le monde (certains cumulent l'absence de tous ces points) :
Savoir se remettre en question, évaluer un peu son travail, prendre du recul, se demander ce qu'on aurait pu faire mieux (pour une prochaine fois). Certains n'ont pas du tout conscience qu'ils perdent du temps bêtement, ou qu'ils font n'importe quoi.
Savoir évoluer (la suite logique de se remettre en question). Certains développeurs stagnent pendant des années avec des méthodes très inefficaces, et ne s'améliorent pas, comme s'ils n'acquéraient pas d'expérience.
Être un peu autonome, débrouillard. Savoir chercher par soi-même sur le net quand on a un problème technique (notamment les problèmes de langage ou d'API). Il y a des gens qui sont incapable de se démerder d'un problème de ce genre, d'aller sur Internet (même quand on leur dit !), et qui vont bloquer pendant des jours (c'est peut-être plus le cas de certains « vieux » ?).
Savoir faire de la conception logicielle. Sans même entrer au niveau de la méthodologie ou des langages de conception, il y a des développeurs qui ne savent ni concevoir, ni comprendre une conception (les relations entre les modules, les classes, etc.). Personnellement, je me demande comment on peu espérer être efficace ainsi (c'est un peu comme être analphabète). Autant sous-traiter offshore…
Ne pas avoir peur du code. J'en ai vu qui vous font un ulcère dès qu'il s'agit de modifier une ligne de code, dans leur propre code en plus (remarque moi aussi je suis au bord de l'ulcère quand je lis leur code :D). Et je ne vous parle même pas d'aller lire et explorer du code nouveau… Si on a peur du code, ou si on ne l'aime pas, ben on ne fait pas du développement.
[^] # Re: Les choses importantes
Posté par Anonyme . Évalué à 2.
merde je reconnais quelqu'un qui possède tous ces points ! c'est mauvais signe ?
# Intéressant mais très « acronymique »...
Posté par MarbolanGos (site web personnel) . Évalué à 3.
J'ai lu avec intérêt ce sujet mais sans être dans ce monde là. c'est toujours passionnant de lire des idées plutôt différentes qui ne passent pas par un mode scolaire de recrutement.
Par contre, quand on lit (attention je vais écrire des bêtises) :
campagne TI : Texas Instruments ?
une PIC : Pointer Independant Code ?
importance des TU : ???
Un peu d'explication d'acronymes n'aurait pas fait de mal.
[^] # Re: Intéressant mais très « acronymique »...
Posté par Benoît Sibaud (site web personnel) . Évalué à 7.
J'ai inféré ainsi :
[^] # Re: Intéressant mais très « acronymique »...
Posté par barmic . Évalué à 1.
TI tests d'intégration
TU tests unitaires
PIC plateforme d'intégration continue
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# question pour un champion
Posté par bghflt (site web personnel) . Évalué à 3.
Vu dans un QCM de pré-selection (Collectivité Locale)
Qu’imprime ce programme en C sur la sortie standard ?
main() { printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}réf. 4th International Obfuscated C Code Contest 1987, David Korn Best One Liner
[^] # Re: question pour un champion
Posté par brendel . Évalué à 2.
C'est une entrée des IOCC parmi les plus simple et assez fun à comprendre, c'est plutôt cool comme question (mais ça dépend de combien de temps le candidat dispose).
[^] # Re: question pour un champion
Posté par Juke (site web personnel) . Évalué à 2.
que signifie &unix ?
[^] # Re: question pour un champion
Posté par calandoa . Évalué à 3.
unixest une macro prédéfinie sur certains systèmes : http://stackoverflow.com/questions/3770322/is-unix-restricted-keyword-in-cPour la résolution, ça semble être "unix\n" :
-
&unix["\021%six\012\0"]se résout en adresse du caractère 1 de la chaine donnée, çàd la chaîne "%six\n"-
(unix)["have"]+"fun"-0x60se résout en la chaîne "fun" à partir du caractère numéro (caractère 1 de "have" - 0x60, soit 1) ce qui nous donne la chaine "un".Il faut savoir qu'en C, a[b] est équivalent à b[a], et qu'une chaine est équivalent à un tableau : "abcdef"[3] correspond à 'c'. Il faut aussi connaitre sa table ASCII en octal. Bref, que des trucs hypers importants que j'utilise tous les jours.
Sinon, je suis aussi tombé sur un petit problème sympatoche un jour, rapporté sur stackoverflow : écrire une fonction en C, prenant et renvoyant un entier signé, telle que appliqué deux fois sur n'importe quel entier (à une ou deux exceptions prés) elle renvoie son négatif. Soit vous êtes un petit malin, soit il faut aimer jongler avec les compléments à deux…
Si vous avez des problèmes de ce genre, je suis preneur (c'est pour mes prochains candidats, niark niark niark).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.