Un des aspects que j'apprécie le plus dans le développement, est la liberté totale de ce qu'il est possible de faire. Nous construisons des applications, des logiciels, des systèmes entiers, pouvant atteindre des complexités rendant leur appréhension par un seul cerveau quasiment impossible. Pourquoi ? Parce que oui, nous construisons, mais contraitement aux maçons, nous construisons de l'air. De l'intangible. De l'information. Pas de problème de forces, torsions, d'approvisionnement (exception faite de café, bien entendu !). Là où, lorsqu'on travaille n'importe comment, rien ne dépasse 2 mètres et s'écroule, dans le développement, on peut tout à fait construire des applications utilisées par des milliers de personnes, qui ne tiennent que grâce à des hacks et autres bouts de ficelles. Cette liberté, cette possibilité de tout faire, permet à certains d'entre nous de faire des merveilles, mais surtout à d'autres de faire n'importe quoi.
Disclaimer : Toute ressemblance avec des situations réelles ou avec des personnes existantes ou ayant existé ne saurait être fortuite, et découle d'une volonté de l'auteur de témoigner, afin d'éviter aux générations futures de recommencer cette horreur. Pour préserver l'anonymat, les noms et fonctions ont d'ailleus été changés.
Prenons un exemple concret. Vous développez une application web, qui affiche des graphiques sur l'évolution de quelques données métier. Tout se passe au mieux, puis le directeur financier s'approche, vous félicite pour votre bon travail, et vous demande si ce serait possible d'avoir, en dessous des graphiques, les mêmes données mais dans un tableau. Prenez quelques secondes pour imaginer comment vous feriez, sachant que les données sont extraites d'une base de données, que les diagrammes sont en flash, et que ces données sont fournies au flash à travers le HTML :
Trouvez une formation
<object type="application/x-shockwave-flash" data="/flash/exemple.swf">
<param name="flashvars" value="data=SomeSerializedDataToBeDisplayed" />
</object>
Vous avez trouvé ? Bien. Je pense ne pas me tromper si je dis que vous vous êtes probablement dit quelque chose d'approchant :
Facile. J'ai visiblement déjà les données extraites, puisque je les fournis au Flash. Je rajoute quelques lignes pour créer un
<table>, quelques minutes de réflexion sur le design, et hop, à moi le ronronnement du directeur financier !
Oui, mais seulement voilà, pourquoi faire simple quand on peut faire autrement ? Le développeur avec lequel je travaillais, du reste parfaitement compétent et doué, eu ce jour là un autre idée d'approche. Avec quelques lignes de javascript placées après la balise flash, il parse le HTML, en extrait les données sérialisées, les parse, construit à la volée le tableau HTML et affiche le tout. Oui. Rien que ça.
Je passe outre les problèmes de maintenance, de compréhension, ainsi que les jurons que prononceraient les pauvres développeurs qui se retrouveraient avec ce code à maintenir. Et je ne pas pas de la testabilité, des bonnes pratiques (et des petits chatons morts). Cet exemple montre le large spectre que couvrent les solutions à un même problème. Et pourtant, le problème est relativement simple. Imaginez que vous deviez écrire un compilateur pour LISP, ou un système d'exploitation, ou encore indexer l'Internet dans sa totalité.
Malheureusement, dans le développement comme dans la religion, il n'y a jamais de réponse universelle (sauf éventuellement 42). Pas de solution miracle. Pas de balle d'argent. Mais s'il n'y a pas de méthode ultime, il y a quand même des bonne pratiques, dont une qui peut sembler évidente, mais qui est paradoxalement dure à appliquer : la simplicité, aussi connue sous le nom de KISS : Keep It Simple, Stupid. L'idée est que, plus la solution retenue est simple, moins elle est mauvaise, et même parfois bonne.
Personne ne veut de code astucieux, ni de code exploitant une fonctionnalité du langage connu des 4 core-developpers initiaux. Un bon code est un code simple à lire, et encore plus simple à comprendre, le rendant logique et maintenable (et souvent élégant).
« Write programs for people first, computers second », Steve McConnell - Code Complete
Vous avez un projet avec un simple formulaire de contact pour un site vitrine ? Pas la peine de créer un framework de validation des saisies des utilisateurs. Quelques lignes suffiront à valider cet unique formulaire. Besoin d'un export vers du XML ? Pas besoin de créer un meta-language, modélisé par un ensemble de classes, et faisant la liaison entre vos objets et n'importe quel format d'export imaginable.
Faites simple, clair, et efficace.
Le premier billet d'un blog. Généralement un essai un peu timide, expliquant les raisons de vivre du blog, son but, traditionnellement suivi par quelques billets et un silence de plusieurs années, entrecoupé de "Désolé pour le vide, je suis de retour dans peu de temps, j'ai été beaucoup occupé".
L'idée d'un blog me trotte dans la tête depuis un moment. Un endroit où apporter une (maigre) contribution à la communauté, de laquelle j'ai bien profité durant ma vie étudiante et professionnelle : que ce soit des magnifiques frameworks open-sources, des réponses à mes questions, ou encore un système d'exploitation me permettant de travailler tranquillement.
Un endroit où, éventuellement, je pourrais recevoir des commentaires constructifs, et interessants (ceci est un message subliminal), parce que finalement, là où j'ai appris le plus, c'est en discutant et en travaillant auprès de gens talentueux et passionnés.
Je ne compte pas poster (uniquement) à propos de sujet techniques, mais sur le developpement informatique sous toutes ses facettes. J'avoue que les relations humaines et la communication - qu'elles soient inter-developpeurs, avec le client un peu retort, ou avec le chef de projet mettant la pression - m'interessent au moins autant que les nouveaux frameworks web, voire même de choses dont je lis le nom partout et dont j'ai du mal à cerner l'utilisation.
Comme tous les développeurs j'ai dans l'esprit des méthodes agiles, des tests, de bonnes pratiques,
et pourtant bien peu de clients et d'employeurs où ces méthodes peuvent passer de ma tête à la
réalité du terrain. Ce blog est une occasion de m'améliorer, et de ne pas évoluer vers
le developpeur désabusé, conscient de mal coder, et pourtant ne prenant pas la peine
de refactoriser ce petit doublon de code, ou de repenser ce petit morceau d'architecture,
se contentant d'ajouter juste un petit hack, ou un commentaire //TODO: refacto/fixer ça, pas le temps pour le moment
(ça fait froid dans le dos non ?).
J'espere garder un rythme d'un billet par semaine, l'idée étant qu'écrire dans un blog force à travers sa façon de communiquer et de faire véhiculer ses idées. Pourquoi pas poster en anglais, histoire de permettre aux éventuels developpeurs anglo-saxons, entrés sur ce blog voyant qu'il y avait de la lumière dans le salon, de bénéficier de ma prose (ou pas?).
A venir un beau billet sur ...¹
¹ Ceci est un minable teaser visant à vous faire vous abonner au flux RSS de ce blog. Pardon aux familles, tout ça tout ça.
Suggestions
Flux RSS News
Twitter
Facebook
Google+