Le retour de ckyl est très intéressant et constructif. Il te donne une multitude d'exemples concrets.
Tu as une réaction assez normale (je me défend aussi quand je présente un projet et qu'il se fait démonter) lorsque l'on expose son travail publiquement mais je crois que tu es beaucoup sur la défensive, la justification et la minimisation des remarques qui ont été faites.
Pour le moment, mon code est publique, ainsi que et mon activité lié (Issues, site, historique Git). Je n'ai pas encore de politique de projets à plusieurs, pour différences raisons, mais surtout par ce qu'il me manque encore des socles techniques indispensables pour que le tout soit cohérent (comme les actions utilisateurs).
Je ne pense pas que cela soit un problème de socle technique. Un nouveau venu ne connaîtra jamais le code aussi bien que toi et sans politique de test il sera incapable de s'assurer qu'une modification ne cassera pas la compatibilité.
Pire, imagine qu'il t'arrive un accident et qu'une personne doive reprendre ton code en urgence. Combien de temps pour que le nouveau dev soit à l'aise?
Comme t'es parti dans l'aventure de l'ouverture pourquoi ne pas pousser la logique jusqu'au bout?
Beaucoup des réactions remontent que tu devrais t'entourer d'une équipe. Le nez dans le guidon ça va un moment. Alors pourquoi ne pas redémarrer le projet from scratch avec une bonne base et une équipe dès le début?
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: Show me the code
Posté par passant·e . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 3.
Le retour de ckyl est très intéressant et constructif. Il te donne une multitude d'exemples concrets.
Tu as une réaction assez normale (je me défend aussi quand je présente un projet et qu'il se fait démonter) lorsque l'on expose son travail publiquement mais je crois que tu es beaucoup sur la défensive, la justification et la minimisation des remarques qui ont été faites.
Je ne pense pas que cela soit un problème de socle technique. Un nouveau venu ne connaîtra jamais le code aussi bien que toi et sans politique de test il sera incapable de s'assurer qu'une modification ne cassera pas la compatibilité.
Pire, imagine qu'il t'arrive un accident et qu'une personne doive reprendre ton code en urgence. Combien de temps pour que le nouveau dev soit à l'aise?
Comme t'es parti dans l'aventure de l'ouverture pourquoi ne pas pousser la logique jusqu'au bout?
Beaucoup des réactions remontent que tu devrais t'entourer d'une équipe. Le nez dans le guidon ça va un moment. Alors pourquoi ne pas redémarrer le projet from scratch avec une bonne base et une équipe dès le début?
Je trolle dès quand ça parle business, sécurité et sciences sociales