Bonjour tout le monde,

Je me suis trompé de rubrique en postant ce sujet dans une autre rubrique, du coup je le reposte ici

voila j'ai commencé à coder mes première appllications, je suis content, sauf que je trouve que ma manière de coder est ... comment dire affreuse.

Je suis tombé par hasard sur cet article

L'auteur explique qu'il ne faut pas passer beaucoup de temps sur le code et qu'il faut passer plus de temps à réfléchir sur comment on va coder, il va même à dire qu'il faut donner 20% de son temps au code et 80% à la refléxion.

Je suis un peu perturbé vis a vis de ça. Pensez vous que je dois appliquer ce qu'il dit ou qu'il y'a un problème dans sa méthode ?

Oui et non .

Moi aussi au départ je codais comme un cochon, aujourd'hui ça dépend du contexte, si je dois faire un travail perso (ex : petit script linux pour mon pc perso) alors je code très très mal.

Mais si jamais mon travail, sera partagé ou repris alors je fais l'effort de bien coder.

Il n'y a pas de loi qui t'obliges à rendre ton code visible, aéré et commenté cependant si tu le partage, travail en équipe, ou encore veut re-travaillé dessus, alors autant te faciliter la tâche.

faut pas oublier les commentaires aussi meme si tu partages pas, c'est tres pratique (je me suis arraché les cheveux nombre de fois pour ne pas avoir mis de commentaire dans un tres gros code, j'y pigeais plus rien)

et un peu d'uml, pour organiser ton boulot, est pas de refus

donc oui, bien coder, pour moi c'est commenter et préparer ne serait ce qu'un peu son boulot

-
Edité par Anonyme 6 décembre 2014 à 15:20:49

En effet, bien souvent mes professeurs du passé me disaient qu'il fallait avant tout préparer l'algorithme de son code, réfléchir à l'ordre de création du script, etc... Que de foncer tête baissée. Évidemment, cela dépend du codage et du projet demandé.

Il en va de même niveau base de donnée (et surtout là d’ailleurs). Bien souvent les tables sont mal créées, un bon petit MCD/MLD et tout est plus simple et claire, dans tous les sens du terme.

Pour rendre un code propre, à mon avis, il faut tout d'abord que l'idée de l'application en elle même, soit propre.

A savoir une application au périmètre établie (dans un premier temps), des principes clairs, compris et découpables en sous-besoins. Une fois que l'application et les modules sont encré dans les moeurs de la team qui code, il faut répartir les tâches de manière intelligente selon un planning et selon les compétences des mecs en questions.

Une fois que toute la partie organisationnelle (et c est bien la que ça coince souvent) est opérationnelle, normalement, ta team et toi êtres largement prêt à vous mettre en route pour la réalisation de l'appli, et pour commencer à sprinter du module.

Si tu es en phase d'appréhensions des notions d'architectures de bases, tu devrais peut être te documenter sur ces patterns et méthodes de travailles.

Méthodes de travail :

- méthodes AGILES (notamment SCRUM et XP qui sont les plus utilisées, ou en tout cas les plus connus)

- Test Driven Developpment et Domain Driven Design (pour commencer)

Patterns et organisation du code

- MVC et MVVM (des designs patterns d'application, comment organiser son code)

- IoC (inversion de contrôle et donc l'injection de dépendance)

- Active Record et Data Mapper pattern (pour l'enregistrement en base de données)

- SOLID (programmation orienté objet et 5 principes à respecter quoi qu'il arrive

Bien coder, ça ne veut pas toujours dire avoir le moins de code possible pour effectuer une tâche. Mais ça veut dire mettre en place un code qui puisse être exploité par d'autre personnes de la manière la plus simple possible, sans perdre de performance.