...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.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
# Ce qu'on demande à un développeur aujourd'hui...
Posté par Claude SIMON (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. É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.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...