Meilleures pratiques - Concevoir avant de coder

Question

Je suis curieux de savoir ce que vous pensez ? (je veux dire une façon de penser) à la conception de l'architecture de vos bibliothèques, systèmes, frameworks, etc. avant de commencer à les coder.

Je me retrouve récemment à ressentir de la douleur dans ce que j'ai fait, et pratiquement à chaque fois, je veux tout recommencer à zéro

Je fais du design avant, en peignant des schémas sur le papier et en imaginant comment cela va fonctionner, mais peut-être que je ne le fais pas de la bonne manière ?

Par exemple, comment décidez-vous des interfaces dont vous aurez besoin, ou comment tout sera connecté de la meilleure façon possible ?

(J'ai eu un problème il y a quelques jours, mon ami m'a demandé une bibliothèque que j'avais faite il y a quelque temps, et au lieu de lui donner un seul fichier, j'ai dû lui donner environ 3-4 fichiers, et c'est parce qu'ils sont connectés d'une certaine manière mais pas dans le bon je pense :) donc c'était mon erreur de conception )

Answer 1

En général, je fais une analyse suffisante du domaine du problème sur le papier/le tableau blanc pour avoir une compréhension suffisante du domaine du problème pour commencer à écrire du code. Je dessine rarement des diagrammes d'implémentation ou de classe sur papier. Une technique clé que j'ai trouvée pour obtenir une meilleure conception est de ne pas trop s'attacher au code que vous écrivez. Si je ne l'aime pas, je le supprime, le renomme, le déplace et le remanie jusqu'à ce qu'il exprime une solution suffisamment bonne à ce que j'essaie de résoudre. Cela vous semble facile ? Pas du tout ! Mais avec de bons outils de "codage", l'écriture du code n'est pas l'effort principal. Écrire un peu, remanier, supprimer, écrire à nouveau...

Un bon design ne commence presque jamais par être bon. Il évolue vers le bien. En acceptant cela, il est plus facile de travailler par petites étapes sans être frustré parce que le design n'est pas "parfait". Pour que ce processus fonctionne, vous devez cependant posséder de bonnes compétences en matière de conception. Le fait est que même d'excellents designers ne réussissent pas du premier coup.

Souvent, je pensais avoir compris le domaine du problème quand j'ai commencé, mais ce n'était pas le cas. Je retourne alors au tableau blanc, je parle à quelqu'un ou je me documente sur le domaine du problème si je me rends compte que je ne le comprends pas assez bien. Je retourne ensuite au code.

C'est un processus très itératif.

Une question intéressante à se poser lorsqu'on aborde la façon dont les programmeurs pensent, est de savoir comment ils ont développé leur mode de pensée. Personnellement, ma façon de penser a évolué au fil des ans, mais quelques événements ont eu une profonde influence sur ma façon de développer des logiciels. Le plus important d'entre eux a été de concevoir des logiciels avec des personnes qui sont des concepteurs experts. Rien ne m'a plus influencé que de passer des itérations avec de grands concepteurs. Un autre événement qui a influencé, et influence toujours, ma façon de penser est le retour en arrière et l'examen d'un logiciel que j'ai écrit il y a quelque temps.

Answer 2

Pour une approche orientée objet, je trouve que c'est généralement une bonne idée de s'éloigner un peu de l'interface utilisateur, et de se concentrer sur les entités (objets) qui existeront dans le système, et sur les propriétés et actions appropriées.

Dessiner sur un tableau blanc ou une grande feuille de papier, en utilisant différentes couleurs pour identifier les différentes caractéristiques est également une bonne idée. Les post-it sont également un bon moyen de visualiser votre modèle.

Même si je passe beaucoup de temps à réfléchir soigneusement à un projet, je finis TOUJOURS par le modifier au fur et à mesure. Il est donc bon de garder à l'esprit que votre conception VA changer au fur et à mesure que vous prenez une décision sur la façon de documenter votre conception.

Answer 3

Je commence le plus souvent par une boîte de cartes, et j'écris les concepts du domaine que je veux modéliser. Parfois, j'utilise une carte mentale pour cela.

Examinez les parties prenantes et ce qu'elles veulent accomplir. Il est important de commencer par là, car cela vous permet d'établir correctement vos priorités (c'est-à-dire de ne pas vous focaliser sur la partie technique la plus intéressante, mais sur celle qui a le plus de valeur commerciale).

La réflexion sur la conception est principalement écrite dans les tests. Ils sont écrits avant le code qui les met en œuvre. Commencez par les objectifs finaux des parties prenantes, puis revenez au début (inversion temporelle). Cela permet de se concentrer sur le quoi, et moins sur le comment. L'interaction entre les objets est plus importante que les attributs des objets.

L'autre partie est principalement sur le tableau blanc. Un appareil photo numérique compact est un équipement standard de nos jours.

Réaliser un framework avant d'avoir trois implémentations qui en ont besoin est une mauvaise pratique. Si vous devez le faire, préparez-vous à d'importants changements d'interface (et d'implémentation).

Voir :

• http://www.robvens.nl/en/articles/computers/29-time-inversion-pattern
• http://www.robvens.nl/en/articles/computers/28-active-passive-pattern

Answer 4

Je consacre généralement 2 à 4 heures à la conception de mon application, puis je la note dans un carnet.

Ensuite, je commence à coder, et chaque fois que les choses se compliquent (parce que quelque chose n'est pas à la bonne place), je refactore. Je déplace une classe vers un autre paquet, ou j'extrais une méthode, etc. etc. Quand le "design" me semble correct, je peux passer à autre chose.

De cette façon, j'évite la "paralysie de l'analyse" qui m'arrivait souvent. Souvent, lorsque je concevais trop en amont, je finissais par ne pas utiliser certains artefacts.

J'ai donc adopté cette approche plus "agile".

Esquissez la conception très rapidement et affinez-la (en la remaniant) au fur et à mesure.

Bien sûr, cela est possible pour les petites applications (2 à 4 semaines).

Je vous suggère de lire cet article : Le design est-il mort ? de Martin Fowler. Il est un peu long mais vaut la peine d'être lu.

EDIT

Lien supplémentaire _{(légèrement hors sujet)} Comment concevoir une bonne API et pourquoi c'est important par Joshua Bloch. Il a parlé de la pertinence de la conception lorsque vous avez un public pour votre API. En résumé, commencez de la manière la plus privée possible et développez-la à partir de là.

Answer 5

Bien que ce ne soit pas une réponse complète à votre question, je trouve parfois que le moyen le plus facile de se mettre en route pour un projet est de trouver un petit élément de fonctionnalité isolé sur lequel commencer et de travailler dessus tout en pensant à l'ensemble du projet.

De cette façon, vous ne vous attardez pas sur les moindres détails, vous êtes productif et vous vous donnez le temps de voir clairement ce que vous devez faire.

Comme je l'ai dit, ce n'est pas une réponse.