Que tu le nettoies ou que tu le refasses entièrement, profites-en pour le documenter.
Même sans refactoring, je suis en train de documenter cette chose... pas le choix si je veux y voir ne serait-ce qu'un peu et éviter de tout péter au moindre commit... parce que la, c'est du boulot sans procédure d'install, sans description de quels ports sont ouverts et dans quels protocoles (tcp? udp?), sans API décente, avec du zombie de tous les côtés, et j'en oublie. J'ai même trouvé cet aprem une classe qui encapsule les sockets BSD et... euh... y'a un peu un membre qui n'est jamais écrit (sauf init, c'est déjà ça) mais donc la valeur est utilisée par listen, bind, accept et close. Youpi. Y'a un bug, c'est sûr, mais comment ça se fait que ça semble marcher en prod?
Et tu l'auras deviné: debug en prod: essayer de reproduire l'environnement de prod à base de VM risque de me prendre encore quelques heures, au bas mot.
Bref: je pleure.
C'est une bonne occasion de le faire parce que tu ne seras pas poussé aux fesses pour sortir en temps et en heure un produit qui n'existe pas encore. Et tant qu'à faire, essaie de faire quelque chose qui soit auto-généré, donc soit du Doxygen, soit une page de référence interactive à la manière de celle d'Apache.
C'est bien mon intention.
Généralement, j'utilise doxygen, mais contrairement à pas mal de choses que je vois, je me contente d'expliciter les pré-requis et post-conditions, avec quand nécessaire (je sais que tout le monde n'est pas d'accord, mais régulièrement les noms d'une fonction et de ses arguments se suffisent à eux-même) une description du rôle du code. Les "doc doxygen" dans lesquelles on peut lire "GetSize(): retourne le nombre d'éléments" me filent des boutons et sont malheureusement les plus répandues de mon expérience.
Après, l'auto-génération ne fait pas tout, surtout quand on a affaire à des usines à gaz dont l'architecture, n'en déplaise potentiellement aux auteurs, n'a jamais été pensée.
Faire du multi-thread parce que c'est la mode, c'est pas ce que j'appelle réfléchir à une archi pérenne et maintenable (dans un truc ou la performance n'est pas critique et ou donc utiliser des processus ou même simplement des IO bloquantes avec du polling aurait suffit tout en étant 1000 fois plus lisible)
Désolé pour la râlerie, mais là, j'avais besoin :/
Je ne commente généralement presque pas mon code, mais j'essaie au maximum d'en expliciter les contrats: le jour ou j'ai lu pour la 1ère fois ce dont il s'agit à changé à tout jamais ma façon de programmer, et honnêtement, je pense que ces quelques heures de lecture m'ont fait gagner bien des jours de debug :)
[^] # Re: Pour quelles applications ?
Posté par freem . En réponse au message quand et pourquoi implementer un pilote?. Évalué à 2.
Même sans refactoring, je suis en train de documenter cette chose... pas le choix si je veux y voir ne serait-ce qu'un peu et éviter de tout péter au moindre commit... parce que la, c'est du boulot sans procédure d'install, sans description de quels ports sont ouverts et dans quels protocoles (tcp? udp?), sans API décente, avec du zombie de tous les côtés, et j'en oublie. J'ai même trouvé cet aprem une classe qui encapsule les sockets BSD et... euh... y'a un peu un membre qui n'est jamais écrit (sauf init, c'est déjà ça) mais donc la valeur est utilisée par listen, bind, accept et close. Youpi. Y'a un bug, c'est sûr, mais comment ça se fait que ça semble marcher en prod?
Et tu l'auras deviné: debug en prod: essayer de reproduire l'environnement de prod à base de VM risque de me prendre encore quelques heures, au bas mot.
Bref: je pleure.
C'est bien mon intention.
Généralement, j'utilise doxygen, mais contrairement à pas mal de choses que je vois, je me contente d'expliciter les pré-requis et post-conditions, avec quand nécessaire (je sais que tout le monde n'est pas d'accord, mais régulièrement les noms d'une fonction et de ses arguments se suffisent à eux-même) une description du rôle du code. Les "doc doxygen" dans lesquelles on peut lire "GetSize(): retourne le nombre d'éléments" me filent des boutons et sont malheureusement les plus répandues de mon expérience.
Après, l'auto-génération ne fait pas tout, surtout quand on a affaire à des usines à gaz dont l'architecture, n'en déplaise potentiellement aux auteurs, n'a jamais été pensée.
Faire du multi-thread parce que c'est la mode, c'est pas ce que j'appelle réfléchir à une archi pérenne et maintenable (dans un truc ou la performance n'est pas critique et ou donc utiliser des processus ou même simplement des IO bloquantes avec du polling aurait suffit tout en étant 1000 fois plus lisible)
Désolé pour la râlerie, mais là, j'avais besoin :/
Je ne commente généralement presque pas mon code, mais j'essaie au maximum d'en expliciter les contrats: le jour ou j'ai lu pour la 1ère fois ce dont il s'agit à changé à tout jamais ma façon de programmer, et honnêtement, je pense que ces quelques heures de lecture m'ont fait gagner bien des jours de debug :)