Je connais très bien cette situation. Lorsque je suis bloqué de cette façon, j'essaie d'adopter différents points de vue sur le projet.
1.) Point de vue de l'utilisateur / client - utiliser les commentaires
Malheureusement, nous sommes pris dans notre code de manière à ne pas voir nos propres défauts car nous utilisons nos applications de la manière dont nous les avons codées. Observez comment les gens l'utilisent et essayez de déterminer quel serait le guide d'utilisateur le plus intuitif. Jouez avec les prototypes d'interface utilisateur. Cela semble amusant, mais si vous découvrez que vous seriez obligé de recoder d’énormes parties de votre code simplement en modifiant la logique d’utilisation, il est temps de commencer un cycle de refonte.
2.) Faites une analyse fonctionnelle de votre code et visualisez-le
Certains IDE et frameworks vous poussent à mélanger par exemple du code d'interface utilisateur et du code de base. Si vous laissez cela se produire, vous serez un jour confronté à la situation selon laquelle votre base de code peut difficilement être maintenue à cause de dépendances nébuleuses et difficiles à rompre. Le mélange de code d'interface utilisateur avec un autre code peut conduire à un code spaghetti et à des fonctionnalités redondantes. Divisez votre code en blocs fonctionnels, tels que des classes de base de données, des classes de communication, des classes d'interface utilisateur, des classes de base, etc., et attribuez aux noms des noms fonctionnels. Puis visualisez la fonctionnalité avec un outil graphique (j’utilise un outil de cartographie conceptuelle) afin de déterminer si votre structure est suffisamment logique et modulaire pour pouvoir réutiliser d’énormes blocs de code pour différents projets et les remplacer par des versions plus récentes. grosse douleur.
D'après mon expérience, la meilleure façon de procéder consiste à créer un document qui visualise toutes les dépendances entre vos classes et leurs appels à partir de votre code. Le résultat est une visualisation de la conception de votre interface. Si cette carte de code ressemble à un cluster complet, il est temps d'agir. Si ce n'est pas encore le cas, vous devriez penser à une convention de nommage appropriée qui représente votre structure de code de manière à ce que vous n'ayez pas à réfléchir à la façon de l'appeler et à ce qu'elle fait.
3.) Utiliser des approches communes pour l'assurance de la qualité
Mon préféré est la FMEA. En termes de codage, cela signifie non seulement analyser ce qui a mal tourné dans le passé, mais aussi penser à ce qui pourrait mal tourner. Un exemple assez courant est une connexion réseau soudainement interrompue. Ceci fait, vous pouvez classer les conditions d'erreur en fonction de conséquences telles que la perte de données, un crash, un calcul erroné et en évaluer l'impact sur l'utilisateur. Si ce n’est pas encore fait, définir des classes et des routines d’erreurs et d’exceptions simplifiées peut vous aider à garder votre code propre et net. Le meilleur moyen est de les implémenter dans chaque nouvelle paix de code avant même de commencer à écrire autre chose. (Et bien, je ne suis pas coupable de suivre moi-même ce conseil.)
En outre, cela m'a aidé à générer et à mettre à jour fréquemment une "liste de propositions d'amélioration" pour mon propre code. (Pour être honnête, il y a encore beaucoup de code dans mes projets dont je ne suis absolument pas fier.) J'essaie également de prendre le temps de rassembler et de jeter un coup d'œil sur le code des meilleures pratiques dans les documentations API, les conférences de développeurs ou les magazines de développeurs.
Jusqu'à ce point, vous n'avez pas besoin de toucher votre code. Il s'agit simplement de savoir ce qui ne va pas et de trouver un moyen de définir comment améliorer votre code.
Enfin, quelques astuces pour le travail quotidien d'un vieux fou. Essayez d'éviter de mordre plus que vous ne pouvez manger. Cela conduit à trop de pression pour un codage propre. Vous avez rarement le temps de bien faire les choses, mais vous devrez prendre le temps de corriger les imperfections par la suite.
Rien n’est aussi durable que la solution provisoire, mais lorsqu’elle se casse, il est souvent trop tard pour la réparer à temps. Les exemples sont des hacks méchants ou des exceptions étranges que j'avais l'habitude de faire fonctionner, malgré par exemple une faille dans le framework ou le système d'exploitation sous-jacent. Et puis la faille se corrige ou la nouvelle version supprime simplement l'API…
Si vous êtes coincé et que vous êtes obligé de trouver une solution de contournement, faites des commentaires et prenez des notes qui devraient être révisées de temps à autre. Normalement, nous obtenons de mieux en mieux parce que nous apprenons quelque chose de nouveau. Si vous trouvez un meilleur moyen, mettez-le en œuvre le plus rapidement possible. Sinon, vous pourriez vous retrouver en train de coder la solution de contournement pour la solution de contournement et l'exception de l'exception un jour. (Celui qui est sans péché parmi vous, qu'il me jette le premier octet.)