Reprise du message précédent :
reprends tes études

Parce que dans une boite pleine de geeks, si tu réussis à décrocher une position un peu managériale tu auras potentiellement des gens intelligents et motivés avec qui bosser, et qui ne renacleront pas à évoluer, apprendre ou tenter des approches différentes?

L'autre solution, c'est de partir faire un tour du monde en marchant sur les mains, si tu préfères.

c'est un peu ce que j'ai ici (le barbu a un peu évolué quand même), sauf que c'est le plafond de verre et la vérité c'est que j'ai pas envie d'appliquer la stratégie établie par le directoire.

Oh putain j'ai envie.

en fait c'est vrai qu'il faut que je bosse avec des dev un peu évolués, parce que sinon je vais péter les plombs, mais je veux qu'ils soient capable de comprendre les aspects non-techniques du truc aussi (j'veux bien faire les formation, il faut juste qu'ils soient perméables quoi)

Si t'as du fric de côté, l'idée la moins conne c'est effectivement le tour du monde (pas sur les mains), ça te donnera largement tous les indices pour savoir ce que tu veux faire de ta vie après

sauf si tu bosses avec Chaos, enfin je veux pas relancer un debat là

réponds toi au lieu de dire des conneries

 
dans le même temps, ils peuvent aussi passer leur temps a jouer à touche pipi, et à préférer mettre en ouevre la techno XYZ au lieu de faire avancer. Le problème du geek, c'est que souvent le moyen importe plus que le résultat. Or en industrie, c'est le résultat qui compte en premier. Le moyen n'est pas une fin en soi.

bha tu viens de résumer la source principal de désacord avec mon chef technique...

Coucou,
pas eu le courage de lire les 40 et quelques pages.
 
Je suis assez d'accord avec Kadreg, d'autant qu'à vouloir tout faire de la façon la plus élégante on peut largement sous estimer le temps de réalisation.  
Il faut trouver un bon compromis.

et c'est pour cette raison que plus de 70% des projets informatiques dont le résultat prime sur le moyen ne voient jamais le jour.
 
un résultat basé sur des moyens foireux fait qu'avec le temps, le résultat ne peut pas tenir dans une évolution.

Donc, tu es du style à ne pas faire de spécifications, ni de test unitaires avant ton développement. Est-ce que je me trompe ?
 
Un bon design permet une très bonne évolution, désolé, mais depuis des années, j'ai un code qui n'a jamais été pensé évolution, mais simplement "résultat" qui demande de la patience pour le faire bouger en évitant de faire crasher tout le système. Alors qu'une bonne analyse, de bonnes specs et tu gagnes du temps.

c'est sur que de bonnes specs bien figées c'est la meilleure voie vers l'évolution

 
il ne s'agit pas de chercher le moyen foireux, ou le premier qui traine. Simplement de pas chercher forcément le moyen le plus hype pour le réaliser, quand une techno simple et limite conne permet d'y arriver.  
 
Exemple con : je prefère coder des boites de dialogues à la main, quitte à ce que ce soit répétitif et chiant, plutot que de devoir utiliser un framework a coucher dehors, qui necessiteras du tuning pas possible pour obtenir quelque chose de logique pour l'utilisateur (qui n'a pas forcément besoin d'une représentation du modèle de données, mais d'une approche par rapport à son monde et ses idées), et dont une evolution impacte potentiellement TOUTES les boites de l'outil.
 

ca c'est surtout une excuse bidon, si ya pas le temps on descope, et si c'est une fonctionalité nécessaire on se démerde en amont pour avoir les délais nécessaires pour la réaliser.

 
Je connais aussi les clients qui se disent "oh c intéressant, on y avait pas pensé" et qui ensuite disent "bon, on veut que ça évolue, il nous faut ceci". Et là si ton code est figé, ou sur une techno fort simple, tu arrives à des limites auquelles tu n'avais pas pensé.
 
Pour ce qui est des boites de dialogues, je préfère faire mon ptit générateur de code scripté surtout si c'est répétitif et ennuyant ( maintenant je ne sais pas ce que contenait ton exemple, mais c une manière que j'aime faire pour les machins répétitifs ).

pas toujours faisable
pas toujours voulu par les tete "pensantes" ...

Temps insuffisant ?  
 
Je préfère me casser la tête pendant un jour ou deux de plus, et pondre quelque chose de correct, que de faire un code merdique pour répondre à la demande et qui dans deux mois ne sera plus maintenables parce qu'incompréhensible, mal pensé et non documenté.
 
deux mois c'est peu, mais d'habitude les devels oublient très vite ce qu'ils ont fait, surtout le pourquoi et le comment.
 
je suis chaque jour avec des livraisons à la va-vite, foireuse etc... parce que justement on ne nous laisse pas le temps de faire les choses correctement. ET ensuite j'entends, ah mais ça fonctionne pas comme ça, où zut, il faut rajouter ceci mais cela n'est pas possible.
 
Zut l'avarice sur la gestion du temps dans un projet. Développer c'est pas simplement écrire du code, c'est aussi un art où l'on s'exprime.
"Si tu codes comme un pied, alors tu es un pied, etc......"

surtout qu'en suivant les specs, on peut paufiner des tests unitaires qui figeront définitivement le code, et permettront de designer son interface ( je parle de l'interface des classes qui permettront de résoudre le probleme ).

faut commenter le code quand il est pas trivial aussi hein ...

 
Pour les tests unitaires j'ai appris récemment ce que c'était, oups
 
C'est difficile de garder le cap si on ne regarde que le navire, c'est ce que je voulais dire.
Les solutions peu élégantes ? C'est un peu comme la dénormalisation pour l'efficacité de certains traitements. C'est moche mais ça marche 200 fois plus vite. Quelquefois c'est utile. Quelquefois on est tout seul pour faire un truc pour dans 48H, ou pire, qu'on vendra 50€  

Je ne parlais pas de la dénormalisation qui effectivement dans certains cas est vraiment très utile.
 
Mais de la manière dont certains développeurs ou chef de projets travaillent. La méthode la plus facile n'est vraiment pas toujours la plus intéressante.
 
Pourquoi est-ce je dis cela, car chaque jour et depuis des années maintenant, je vois le même soft qui doit être étendu à partir de bases qui n'ont pas été pensée pour évoluer. Imagine toi que tu modifies un bout de code, tu tests et boom, tout plante. Débile, mais les personnes qui ont développés cet outil avant moi, non jamais dû penser à ce petit "soucis".
 
Imagine, je te parle de test unitaires ( qui permettent de gagner un temps non négligeable ), ne sont même pas intégré dans notre méthode de développement pour la simple et unique raison que l'on me sort "ça prendrait trop de temps".
 
Mais cela prendrait quoi comme temps ? par rapport au temps gagné, je veux bien les coder à la mano ces tests.
 

Oui Matrixise je comprends ce que tu veux dire, j'ai parfois écrit des codes à chier, et pour lesquels des jours supplémentaires m'auraient beaucoup plu. Mais à l'inverse l'évolution ne prend pas toujours le chemin qu'on attendait et au final parfois c'est aussi revenu au même, refonte conseillée.
Je ne dis pas qu'il faut ignorer les moyens techniques non plus, et d'ailleurs pour moi l'analyse est bien plus importante que le langage.

Souvent avec 20% de temps en plus on peut généraliser à partir d'un problème donné.

 
 
D'accord avec toi, mais même si en fin de compte, une version évolutive n'était pas forcément nécessaire, il ne faut pas oublier que tu garderas l'idée en tête, et lors d'un prochain développement pouvant se baser sur cette idée, tu pourras la soumettre en la faisant elle-même évoluer. Ce qui veut dire qu'en gros, tu auras eu du recul, ce qui t'aura permit de réfléchir aux problèmes que tu aurais pû avoir et les résoudre plus efficacement.
 
Par exemple, quelque chose d'assez intéressant est d'appliquer la méthode "DRY" ruby vers des mondes tels que C++, c'est bête, mais c'est simplement du refactoring.

Et plus, tu généralises et à moment, tu auras un cas qui viendra casser ta généralisation => spécialisation.
 
suffit de voir les templates c++ avec la généralisation et puis la spécialisation.
 
mais tu n'as pas tord. c'est d'ailleurs pour cela qu'un code bien designé est plus intéressant qu'une bouze.  
 

Oui c'est vrai. D'ailleurs c'est pour ça que je reviens ici, je suis autodidacte, assez ignorant, et je veux apprendre, évoluer.
 
Edit: Réponse à l'avant dernier.
Pour le dernier post oui ça revient régulièrement le petit truc qui casse tout

j'crois t'as jamais bossé dans ma boîte.
ici c'est "tu développes ça, tant pis si c'est merdique, tant pis si ça marche pas bien, mais il faut présenter ça au client".
Et dans ce cas-là, je n'ai pas un jour ou deux de plus.

c'est triste, mais c'est la réalité (après j'ai pas l'expérience nécessaire pour savoir si c'est juste ici ou partout pareil)

si c'était le cas, nous aurions été collègue

C'est une réalité merdique, ou tu devrais peut-être te casser.  
 
Un développeur heureux est un développeur qui fait du bon code, et un bon code aide à progresser.

 
En informatique, la curiosité est un bon défaut
 
Sincèrement, il faut apprendre tous les jours, sinon on est vite dépassé.

Cosmoschtroumpf ça arrive souvent, mais les contraintes ne sont pas toujours les mêmes. On peut aussi te demander que ça marche bien mais pour rendre un résultat de traitement le lendemain, peu importe la qualité du code, etc. dans tous les sens possibles. Quelquefois c'est ce "mensonge" qui permet de remporter le marché, quitte à devoir se battre un peu derrière.  
 
Et plutôt que de hurler sur le dév original c'est plus positif de se dire qu'il avait probablement des contraintes et qu'on est devant un monument historique

prem's

Truc con à faire pour ceux qui se font chier: programmer un bot qui preum's le matin

prems

cron + wget ...

prems au bureau

 
oui, et un cheval, aussi.
 

 
....Une idée qui va sans doute te rebuter au premier abord, mais bon, on sait jamais....Vois si tu peux pas te trouver un poste avec de l'avant vente dans une SSII pas trop grosse : ça te permettrait sans prendre de risque de te faire une idée de ce genre de boulot : un peu de specs, un peu de managérat pour coinstituer les équipes, un peu de relation client, tout ça...
 
 

Ben tu penses à t'acheter des couilles un jour

95% du temps les commentaires sont la marque de code merdique.

Si le code a besoin de commentaires, il faut surtout le refactoriser jusqu'à ce que ça ne soit plus le cas

DRY ne vient absolument pas du Ruby, la première mention de cette expression que j'ai pu voir était dans The Pragmatic Programmer: From Journeyman to Master

Accessoirement, DRY s'applique à tout (pas seulement au code écrit), mais tout généraliser le plus possible de base n'est pas nécessairement une bonne idée et fait perdre du temps (YAGNI toussa).

Une bonne règle, c'est Don Robert's Rule of the Three telle que citée dans Refactoring de Martin Fowler:

Et elle s'applique à tout