08-01-2011, 12:01 AM
ma position professionnelle (pas en tant que développeur , je ne suis pas bon, mais en tant que responsable d'une entité qui fait développer des prestataires)
- utilisation de frameworks connus, documentés
- utilisation de peu de frameworks (la multiplication nuit)
- une architecture simple (inutile de faire le dernier truc à la mode ou l'architecture la plus ouverte à un tas de possibilités si le besoin ne le nécessite pas)
- utilisation d'un langage connu, reconnu et partagé, par l'entreprise tout comme par les SSII* du marché (aujourd'hui, pour moi, ça veut dire .net, java, et dans une moindre mesure php pour le côté serveur, pour le côté client, on est bien embêté, finalement pas grand monde* connait autre chose que html et javascript)
- utilisation de design pattern (et/ou autre modélisation) en quantité limité (la multiplication nuit), les moins subtiles possibles. Y a pas que des cadors qui développent. Y a surtout des gens moyens qui développent
- normes (nommage, utilisation du gestionnaire de sources, etc...)
- éviter le procédural pour privilégier la poo (voire utiliser l'événementiel ou le fonctionnel, mais beaucoup moins de monde* connait autre chose que poo ou procédural)
- commenter correctement le code
- documenter correctement le programme (architecture, processus, use case, ...)
- intégrer des tests (unitaires voire d'intégration, voire fonctionnels) de manière automatisé (si je recompile, je dois avoir déjà une idée du ça marche, ça marche pas)
ma position personnelle/artisanale/de plaisir
- faire au mieux en fonction de ses connaissances pour être satisfait de soi (et chacun n'est pas satisfait de la même manière)
- commenter le code, voire documenter (mais uniquement si on est prêt à revenir sur la documentation quand on revient sur le code)
- privilégier la modélisation que l'on sait utiliser (ex : si on sait faire poo et procédural, privilégier poo, si on ne sait pas faire de poo, faire du procédural)
- privilégier un langage avec des communautés bien établies
- privilégier un langage avec une syntaxe qui plait à l'équipe (si plusieurs personnes sur le projet) si une équipe adore l'assembleur, qu'elle fasse son truc en assembl...eurk :p
- privilégier des frameworks si ceux si plaisent (cf fonction point 1) ou font des choses qu'on ne saura pas faire sans une lourde réflexion (typiquement pour moi, framework php ne me fait pas plaisir donc je n'en prends pas, mais comme je ne sais pas faire aisément du javascript "riche", je choisirai un framework javascript)
- privilégier un découpage de l'activité fonction du plaisir (exemple, privilégier un découpage qui permet de montrer l'avancée des résultats)
*"SSII", "grand monde" dont je parle = grosses boîtes (cap gemini, logica, accenture, etc...) voire moindre, mais pas boîte de niche ou start up, là je ne connais pas, pour la simple. Evidemment on trouvera d'autres compétences dans ces boîtes là, mais pour obtenir rapidement une équipe de 10 personnes pour un projet, c'est les technos qu'il faut privilégier aujourd'hui si on veut être serein sur la capacité de l'équipe à réaliser dans des temps... raisonnables, de même pour la pérennité de l'équipe de maintenance
- utilisation de frameworks connus, documentés
- utilisation de peu de frameworks (la multiplication nuit)
- une architecture simple (inutile de faire le dernier truc à la mode ou l'architecture la plus ouverte à un tas de possibilités si le besoin ne le nécessite pas)
- utilisation d'un langage connu, reconnu et partagé, par l'entreprise tout comme par les SSII* du marché (aujourd'hui, pour moi, ça veut dire .net, java, et dans une moindre mesure php pour le côté serveur, pour le côté client, on est bien embêté, finalement pas grand monde* connait autre chose que html et javascript)
- utilisation de design pattern (et/ou autre modélisation) en quantité limité (la multiplication nuit), les moins subtiles possibles. Y a pas que des cadors qui développent. Y a surtout des gens moyens qui développent
- normes (nommage, utilisation du gestionnaire de sources, etc...)
- éviter le procédural pour privilégier la poo (voire utiliser l'événementiel ou le fonctionnel, mais beaucoup moins de monde* connait autre chose que poo ou procédural)
- commenter correctement le code
- documenter correctement le programme (architecture, processus, use case, ...)
- intégrer des tests (unitaires voire d'intégration, voire fonctionnels) de manière automatisé (si je recompile, je dois avoir déjà une idée du ça marche, ça marche pas)
ma position personnelle/artisanale/de plaisir
- faire au mieux en fonction de ses connaissances pour être satisfait de soi (et chacun n'est pas satisfait de la même manière)
- commenter le code, voire documenter (mais uniquement si on est prêt à revenir sur la documentation quand on revient sur le code)
- privilégier la modélisation que l'on sait utiliser (ex : si on sait faire poo et procédural, privilégier poo, si on ne sait pas faire de poo, faire du procédural)
- privilégier un langage avec des communautés bien établies
- privilégier un langage avec une syntaxe qui plait à l'équipe (si plusieurs personnes sur le projet) si une équipe adore l'assembleur, qu'elle fasse son truc en assembl...eurk :p
- privilégier des frameworks si ceux si plaisent (cf fonction point 1) ou font des choses qu'on ne saura pas faire sans une lourde réflexion (typiquement pour moi, framework php ne me fait pas plaisir donc je n'en prends pas, mais comme je ne sais pas faire aisément du javascript "riche", je choisirai un framework javascript)
- privilégier un découpage de l'activité fonction du plaisir (exemple, privilégier un découpage qui permet de montrer l'avancée des résultats)
*"SSII", "grand monde" dont je parle = grosses boîtes (cap gemini, logica, accenture, etc...) voire moindre, mais pas boîte de niche ou start up, là je ne connais pas, pour la simple. Evidemment on trouvera d'autres compétences dans ces boîtes là, mais pour obtenir rapidement une équipe de 10 personnes pour un projet, c'est les technos qu'il faut privilégier aujourd'hui si on veut être serein sur la capacité de l'équipe à réaliser dans des temps... raisonnables, de même pour la pérennité de l'équipe de maintenance