Discussion :

[Cheetor]

Bien le bonsoir.

Autant j'arrive à coder ce que je souhaite sans trop problème dans différents langages (Matlab, C, notamment, y a aussi Labview (mais langage graphique)), autant avec le temps, je constate que mes codes tiennent plus du spaghetti bolognaise de haut vol que de code bien fait et surtout réutilisable par la suite (puis compréhensible par tous, moi la première...).

Le fait est, ça m'agace et je voudrais améliorer ça.

Aussi, je recherche des tutos/méthodologies ou autres, qui me permettrait de chopper une bonne fois pour toute un façon de rédiger mes codes correctement et surtout, de savoir comment délimiter le cadre de mes fonctions (en tout cas, les questions à se poser).

En vous remerciant d'avance pour vos retours.

[yildiz-online]

clean code de Robert C Martin est pas mal

[Cheetor]

Merci Yildiz, je vais tâcher de me le procurer. Je passe la conversation en résolu (néanmoins, soyez pas timides, d'autres sources/idées sont les bienvenues).

[Mat.M]

autant avec le temps, je constate que mes codes tiennent plus du spaghetti bolognaise de haut vol que de code bien fait et surtout réutilisable par la suite (puis compréhensible par tous, moi la première...).

ça c'est l'éternel problème de conceptualisation...
avant d'écrire une ligne de code il faudrait idéalement concevoir sous formes de classes ( donc avec UML ) ces lignes de code.
Si on n'est pas capable de conceptualiser, de faire du design simplement sur un morceau de papier eh bien on va passer son temps à faire du code spaghetti.
Le problème de la formation en informatique c'est qu'on enseigne majoritairement à faire du code mais pas du tout à conceptualiser et à concevoir dans l'abstrait.

[Cheetor]

Certes, le souci étant qu'au départ, je suis plutôt dans l'électronique, du coup, l'UML a pris peu de temps/place. J'irai également jeter un coup d'oeil aux tutos UML (un lien à favoriser ?).

[yildiz-online]

L'UML est avant tout un moyen de communication pour transmettre l'abstractions aux différentes parties (architecte, analystes, développeurs) dans un langage commun.

Pour affiner sa capacité d'abstraction, c'est l'expérience qui prédomine, et des lectures de référence.
A force de rencontrer des cas avec des similarités déjà abordés (ou étudiés), et en étendant ses connaissances sur les différents paradigmes et architectures, on peut en déduire une découpe de plus en plus efficace.

Il y a 3 points majeurs dans une application:

- Sa composition (ui, web service, persistence, logique, client vers système externe...) qui va définir les packages/module de code.
- Son déploiement physique (multi node, architecture du système hôte, librairie commune...) qui va définir la découpe en sous-projets.
- Son flux de données (entrées sorties système / utilisateur, communication avec d'autres services, ...) qui va définir le(s) paradigme(s) idéal à utiliser.

Ces 3 points sont 3 visions différentes qui doivent être prises en compte pour parfaire sa découpe.