Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Salut !
Moi je pense qu'un bon code doit être réutilisable et je pense que programmer en objet va dans ce sens.
Après, je ne suis pas une pro mais je suis sur quelques petits projets persos qui demandent une assez grande rigueur tant au niveau du code que de la présentation du code (indentation, commentaires etc)...
justement, le debat ici porte sur le fait que la rigeur risque de nuire a l'inspiration du programmeur.Envoyé par Nahla_India
Merci de la précision Gokud
De ce point de vue là, je pense que programmation et inspiration peuvent aller de pair. Les programmeurs ne sont pas des machines et doivent pouvoir faire de "belles" choses (efficaces également). La programmation est un art
S'il s'agit d'un travail d'artiste, qu'est-ce qui empêche un développeur d'adopter un cycle de développement itératif ?...
Un cycle itératif n'est nullement artistique. C'est une méthode qui se veut aussi pleine de rigueur.
Sauf qu'il n'y a pas d'inspiration à avoir chez un programmeur. C'est le concepteur qui a besoin d'avoir un peu l'esprit créatif. Le programmeur suit la conception et ne devrait jamais s'autoriser une digression. Il n'a peu ou pas de choix à faire. Si une personne fait les deux (conceptions/programmation) il doit s'évertuer de séparer les deux aspects du travail en évitant de jouer le concepteur lorsqu'il est en train de programmer. Mais même là, le concepteur n'a pas les mains complètement libre car il doit respecter le document de spécification. S'il est certainement celui qui dispose le plus de sa liberté, ce n'est que pour choisir le meilleur outil (architecture, algorithme, interface etc.)
Si on fait un jouet on peut faire ce qu'on veut, si on fait un travail sérieux la rigueur est nécessaire. Le débat est un faux débat. La créativité du concepteur n'est intéressante que s'il est déjà rigoureux. Sinon c'est l'échec du projet.
T'as pas compris.
Gokud parlait d'inspiration. Que ce soit du concepteur ou du programmeur, ça n'a pas trop d'importance.
Le principe est que si le travail n'est pas soumis à des délais (j'avais pas trouvé de meilleur terme qu'"artistique" pour qualifier un travail "pour le fun, pour soi-même"), dans ce cas, rien n'empêche de produire une maquette toute pourrie histoire de laisser libre son "inspiration", puis de reprendre et de reprendre, etc....
bref, un cycle itératif en quelque sorte.
Ceci dit, vu le dernier paragraphe de ton dernier message sur ce thread, même si j'ai du mal à m'exprimer à 1h30 du matin, on est du même avis.
Il ya toujours des choix, même dans une architecture précise et pour un résultat fixe.
quand on demande à un programmeur de faire un module de garnissage , qui a une structure d'entrée déterminée, une structure de sortie determinée, et un garnissage fixé par les spécifications, le résultat exigé est totalement figé par la conception. Pourtant, le programmeur a plien de manières de faire. Il peut suivre les données une par une. Il peut les regrouper par flux. Il peut les regrouper par thématique technique ou fonctionelle.
Dans ce cas précis, j'avais choisi de suivre le regroupement technique, puis ensuite de suivre l'ordre des données dans la spec. Parceque, dans ce cas précis, ça nous faisait gagner beaucoup de temps(et on avait le feu aux fesses). J'ai eu quelques secondes pour faire ce choix.
Quand on a tout le temps du monde, on peut tout prévoir, et le programmeur d'est qu'un pousse-bouton. Quand on est préssés(et c'est souvent le cas), alors un minimum de liberté peut, au contraire, faire gagner du temps, à condition que le programmeur soit lui même expérimenté et rigoureux(voire talentueux, mais ça c'est un autre débat). Sur le cas que je cite, en ne suivant pas le regroupement fonctionnel qui m'était préconisé, j'ai divisé le temps prévu de développement par 5. Evidemment, c'est un cas extrême.
Ce que je veux dire, c'est que tant qu'on respecte :
1)les entrées sorties telles qu'elles sont définies(dans une équipe de plus de 1, c'est obligatoire)
2)les specs(quoique signaler des erreurs puisse arriver, mais ça dépend fortement des spécificateurs)
3)les normes et choix locaux de développement(sur le cas que je cite, on m'avait demandé de tout coller dans un programme existant)
alors après, sur la mécanique interne, le savoir-faire et l'inspiration du programeur sont utiles.
Evidemment, si il change la zone d'entrée sortie, ignore les specs et s'assied sur les normes de développement, ça n'est plus un artiste, c'est un saboteur.
Peux-tu me définir ce qu'est l'inspiration ?
Parce que sinon on parle pour ne rien dire.
Je pense que c'est un débat creux.
Ah... alors j'aurais compris ?
mais meme la, la rigueur peut faire une grande difference. la programmation spontannee, que je considere de non-rigoureuse, recquiert un certain talent pour qu'il ne genere pas du code bon a jeter des qu'on veut le retoucher.
Une des rigueurs que le programmeur spontanne type ne suit pas, pour ce que j'en ai vu au debut de cette discussion, est une documentation approfondie du code. Ils pretendent pouvoir comprendre le code source aussi vite que s'ils lisaient les commentaires explicatifs, et donc ils ne s'embarrassent pas a documenter leur code au dela du strict minimum(entete de champs et methodes publiques). Et c'est deja la que je sais que je ne fais pas(plus) partie des programmeurs spontannes car devoir reprendre un bout de code de ce genre m'enerve tellement(enorme perte de temps a decoder) que je n'ai pas envie d'infliger ca aux autres.
un autre point que j'ai releve qui determine un programmeur spontanne est qu'il ne modelise pas ce qu'il va faire. C'est un peu du genre a taper du code des qu'il a lu l'enonce du probleme car il a une idee de comment faire dans sa tete. et apres egalement, il ne fait aucune documentation sur la logique de son code(ref. premier point).
Vous comprendrez donc que je ne suis pas un adepte de la programmation spontannee, surtout apres l'avoir pratique pendant plusieurs annees lorsque j'apprenais la programmation. Personnellement, j'aurais plutot tendance a appeller ca de la programmation immature.
Sur le premier point, d'accord. Le code doit être lisible, même par un non informaticien. Si je ne suis pas fan de la doc externe(qui a tendance à se perdre), je mets un point d'honneur à faire du code qui se lit aussi facilement que possible. Idéalement, exactement comme la spec(mais c'est pas toujours posible).
Sur le deuxième point, si on a le talent, on peut. Je connais mes limites à ce niveau-là, mais jusqu'à un certain niveau de complexité(disons 7-8 jours de travail), je sais que je n'ai pas besoin de modélisation. Au delà, il m'en faut. Quelqu'un de meileur que moi pourra très bien intuiter un mois complet de travail..... Par contre, il faut en effet documenter la méthode une fois qu'elle est en place(encore une fois, je fais ça dans le code, les docs papier ont tendance à disparaitre). En celà, je ne suis pas un pur "spontané"
Bonjour les amis,
J'aimais bien me faire des challenges de temps en temps, des chalenges du genre Developper sans aucun schema : Ouvrir IntelliJ et coder comme un malade.
Mais avec le temps, je me suis rendu compte que ce n'est pas bon, avec programmation spontanné, bugs spontanés, surtout les bugs d'architecture !
Maintenant, je suis passé à l'autre extreme suite à des problèmes graves avec ma main (RSI) ou le clavier me faisait trop mal : Programmer sur papier, essayer ça c'est vachement bien. Ca consiste en gros à eviter de reflechir face à l'écran, passer le max de temps face à un cahier, jusqu'à mettre les méthodes, l'algo, ... Se mettre face à l'écran pour écrire.
Et depuis, j'ai remarqué que je maitrise beaucoup mieux mon code, et j'ai moins de problèmes, surtout qu'actuellement je travaille sur la couche de Securité d'un projet refonte, face du code spontané dans la Securité est tout simplement suicidaire !
je pratique surtout la programmation spontanée.
je la fait facilement car je connait bien les mecanismes de l'asm.
il m'est arrivé de faire des codes de plusieurs milliers de lignes en une seule passe sans le moindre bout de papier.
mais quand on veu faire un gros programme utils, il faut evidement faire des specifications avant de coder.
c'est ce que je fait pour les fonctiosn archi compliquées et les gros programmes de plusieurs dixaines de milliers de lignes.
en plus, les milliers de lignes ne sont pas dans un seul fichier, elles sont coupées en blocs et enregistrées dans des includes.
mais je ne suis pas un pro, je n'ai pas encore gagné le moindre centime avec mes codes.
donc, je doit etre dans l'erreur.
D'un côté j'allais te dire que t'es complètement à côté de la plaque et que s'il y a bien un langage où il faut faire beaucoup de papiers avant c'est ASM.
Grosso modo, on pourrait dire que plus le langage permet de manipuler des abstractions, plus il s'approche lui-même de la conception; on peut donc réduire les étapes.
Maintenant t'as l'air d'être clairvoyant et lucide... alors je dirais que c'est bien. Au moins tu sais que tu sais peu (plutôt que rien) et c'est déjà excellent
Et être son propre client est parfois plus simple, donc on a plus tendance à se satisfaire d'un truc qui marche juste pour nos besoins.
C'est malheureusement une expérience très difficile à faire valoir dans un entretien. L'ère des "vrais Programmeurs" est révolue. Il ne faut plus seulement être efficace mais aussi efficient. Et la programmation spontanée n'est qu'efficace.
J'espère que tu es conscient qu'efficient dans le sens où tu l'utilises, est un anglicisme qui signifie « efficace »?
Sinon il existe effectivement un terme français « efficient » mais il est de nature philosophique.
Autre chose: que veux dire « vrais programmeurs » ?? hacker (dans le sens originel anglais) ?
Pire, on modifie les besoins en cours de route pour les soumettre aux problèmes rencontrés. Très mauvaise habitude.
une theorie, si le papier est dans la tete, c'est à dire que la memoire du programmeur c'est deja chargée de toute la definition du probleme, est ce de la programmation spontanée?
perso, je visualise d'abord l'algorythme avant de coder.
et, au fur et à mesure, je corrige les erreurs en fonction des bugs.
mais j'essaye de me passer de papier pour ne pas polluer.
car le papier, ça genere de la polution.
les entreprises ne s'en soucient pas et obligent les developeurs a generer des documents papier. c'est domage.
Comme bien maintenir une application qui se développe sur 20 ans avec plusieurs langages par toute une génération de développeur sans document ?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager