Je vais travailler sur un projet, une application Web. Je lisais 37signals Obtenir une vraie brochure en ligne ( http://gettingheal.37signals.com/ ), et je Comprenez le processus recommandé pour construire l'ensemble du site Web. Brainstorming, esquisse, html, code.
Ils touchent à chaque processus à la légère, mais ils ne parlent jamais beaucoup sur le processus de codage (tout ce qu'ils disent sont de garder le code maigre). J'ai lu à propos de différentes façons d'y aller (de haut en bas, de bas en haut) mais je ne sais pas beaucoup de chaque façon. J'ai même lu quelque part que l'on devrait écrire des tests pour le code avant d'écrire le code ??? Quoi?
Quel processus de codage doit-on suivre lors de la création d'une application.
Si c'est nécessaire, j'utilise PHP et un cadre.
3 Réponses :
Selon le Méthode de développement de tests , vous devriez écrire des tests avant Vous vous écrivez du code. Cela aide à rendre le Code Nettoyant, plus modulaire, etc. et vous permet de tester le code à tout moment pour vous assurer qu'il fonctionne correctement.
En pratique, l'utilisation de TDD est un choix laissé à vous. Je vais admettre que je n'utilise généralement que TDD lors du développement de bibliothèques ou de code qui utilise de lourdes algorithmes. Mais il existe une juste quantité pouvant être testée automatiquement dans une application Web.
Dans tous les cas, ce qu'ils peuvent être obtenus, c'est que vous devriez commencer votre code de petite taille, codez simplement ce dont vous avez besoin. Ensuite, ITERE, et écrivez plus de code si nécessaire, testez autant que vous allez. Plus votre code est plus simple, plus il sera plus facile de tester et de s'étendre sur sa vie.
Vous avez donc tout regardé jusqu'au processus de codage et que vous avez une architecture et une conception, ainsi que des maquettes des pages Web.
Choisissez la fonctionnalité qui vous donnera le plus de bang pour le dollar. (Montrez quelque chose au client, qui peut être la direction ou les personnes qui l'achètent de votre part.)
Commencez à coder ce morceau de fonctionnalité et assurez-vous qu'il remplit les exigences et n'introduisez aucun crochets possibles futurs. Beaucoup de temps devient gaspillé d'essayer de deviner ce que les gens voudront peut-être à l'avenir avec la "boule de cristal des programmeurs".
Le code doit suivre les meilleures pratiques pour cette langue, espérons que quelqu'un connaît la langue que vous développez assez bien pour vous guider.
Comme vous l'avez fait avec chaque point de fonction effectue un examen de code, passez en revue tôt et souvent au début du projet.
Une fois que vous avez terminé avec codage de la pièce initiale et que le client est heureux, vous pouvez commencer sur de nouvelles pièces.
Si vous trouvez des morceaux de fonctionnalité communs, qu'ils soient horizontales (spécifiques du domaine) ou verticalement (architecture spécifique), vous devez les refracter. N'oubliez pas de couper et de pâte.
Couper-n-pâte est diabolique! Il est rapide à faire, mais extrêmement difficile à maintenir et à réparer.
Maintenant c'est une réponse "maigre". +1
Ma réponse serait A -1, mais j'écris réellement pour autre chose et cette question m'a fait décider de l'écrire maintenant au lieu de plus tard. (Espérons): o)
+1 "Beaucoup de temps est gaspillé d'essayer de deviner ce que les gens voudront peut-être à l'avenir."
+1 "Comme vous l'avez fait avec chaque point de fonction effectue un examen de code, passez en revue tôt et souvent au début du projet."
Le code maigre signifie que vous n'écrivez pas le code simplement parce que vous êtes programmeur. Vous n'écrivez que suffisamment de code pour obtenir le travail. Tout code supplémentaire est juste perdu du temps et de l'argent. Si vous trouvez que vous ajoutez du code à «utiliser plus tard». Arrêter. Il vient plus tard rarement et les applications vivent de longues vie. Ce code que vous avez ajouté pour plus tard ne confond que plus tard. Pense-y de cette façon. Chaque morceau de papier sur votre bureau doit être manipulé. Chaque ligne de code doit être traitée.
J'ai lu leur livre "devenir réel". Je ne suis pas d'accord avec tout. Pourtant, une grande partie de ce qu'ils disent s'appliquent au développement Web et ne s'appliqueraient pas aux applications de bureau ou de périphérique. Il semble beaucoup de contenu, surtout près de la fin, n'est que du bruit pour remplir un livre.
Document (pour vous-même) Ce que vous devez faire et votre compréhension de ce qui doit être fait. Soyez absolument clair sur votre compréhension. Mieux vaut obtenir un problème oui / non maintenant, alors un bug, ou un pire, une question de conception, plus tard qui vous coûtera des semaines, qui entraîne toujours un code "piraté".
génère un brouillon d'un brèves guide utilisateur. Même si vous êtes le seul à le lire. Faites cela avec un crayon et du papier. Ne perdez pas de temps avec un traitement de texte. Vous allez perdre plus de temps "Mise en forme" puis écrire du contenu. Si vous ne pouvez pas l'écrire en mots, comment pouvez-vous le coder? Il n'est pas nécessaire d'être jolie. Laids va bien.
génère tout type de documentation avec un crayon et du papier autant que possible. (Hé, je n'ai-je pas déjà dit ça.) C'est beaucoup plus rapide, il est clair, les utilisateurs peuvent écrire dessus, vous pouvez le copier, le suspendre sur le mur, etc. Plus important encore, vous pouvez l'effacer et recommencer avec l'utilisateur juste là. Ai-je mentionné que c'est beaucoup plus rapide?
Effectuez des critiques de code personnel. Une bonne méthode consiste à comparer chaque fichier avant de vérifier le contrôle de la source. Je vous garantis que vous trouverez des bugs, des articles que vous avez oublié de faire, et ainsi de suite. C'est un bon moment pour nettoyer le code et générer des tests d'utilisateur ou de documentation technique et de dernière minute.
Par exemple, j'ai passé une journée à créer un classeur Excel pour documenter un modèle dont je devais créer. Je l'ai fait pour moi-même. Le modèle a déjà été conçu par des spécialistes (sur papier). J'ai trouvé, je devrais dire Excel trouvé, une référence circulaire. J'ai rapporté cela, mais on m'a dit que le modèle a été élaboré avec soin au cours du mois dernier et que le problème était de ma compréhension. Deux mois plus tard, fixant cette "référence circulaire" nous coûte deux semaines. Nous avons à peine fait la date limite. Ce qui aurait pu être résolu dans huit heures d'homme, nous coûte plus de soixante hommes et beaucoup de stress. Pourtant, parce que mon code était "maigre", le correctif n'était que quelques lignes de code à une petite fonction de table.
La plupart des programmeurs coderont en premier. La plupart des développeurs avec document d'abord. En général, chaque minute documentant tôt vous évitera dix minutes plus tard. (Lire le "code complet".) Pourtant, n'oubliez pas de "devenir réelle". Votre travail n'est pas de coder, mais de construire des solutions. Pensez-y de cette façon, le travail d'un écrivain n'est pas d'écrire mais de créer un document que quelqu'un lira. Il n'ajoute pas un chapitre simplement parce qu'il ou que vous pourriez en avoir besoin plus tard. Il doit continuellement prendre une décision sur quoi d'inclure ou d'exclure pour atteindre son lecteur. Mieux vaut prendre quelques minutes pour prendre une décision concernant le code puis passer un codage de jour, seulement pour réaliser que le code n'est pas nécessaire.
Généralement, je n'écris pas code de développement de tests (TTD). Je trouve que vous finissez par écrire beaucoup de code sans raison, au lieu de fournir une solution. Avant que je reçois "flambé", j'écris toujours TTD sur papier en premier. Si je ne peux pas travailler quelque chose, je vais créer un projet "Jeter" et écrire du code. Si je trouve que je dois creuser plus profondément, je crée un projet "WIP" (WIP-IN-PROGRESS), et si cela échoue, je créerai enfin un projet de test réel. À cet égard, comme Justin Ethier mentionne, si je rédige des bibliothèques ou des fonctions principales pour une application, je crée toujours un projet de test.
Pour une application, j'ai créé et intégré un contrôle du volet RSS qui a téléchargé les informations financières de la société de Google. Mon superviseur a demandé à cette fonctionnalité de "wow" les dirigeants avant une démonstration. Ça faisait. Tout le monde a absolument aimé. Tout en travaillant avec une entreprise, les utilisateurs obtiendraient des alertes de nouvelles instantanées spécifiquement pour cette société. Cela m'a pris quatre heures pour créer et mettre en œuvre, ce que j'ai fait juste avant la démo. Pourtant, parce que c'était une fonctionnalité que les utilisateurs ne demandaient pas, ils se sont toujours plaints de perdre du temps à mettre en œuvre des caractéristiques inutiles, en particulier de fonctionnalités qu'ils ne demandaient pas quand je ne pouvais pas fournir les fonctionnalités qu'ils ont demandées. (Qui n'était pas ma décision.) Environ deux mois plus tard, ce contrôle a commencé à lancer des exceptions. Cela m'a pris deux jours pour résoudre et corriger. Cette fonctionnalité était un grand succès, mais imaginez les problèmes si ce n'était pas.
Une bonne réponse, même si je suis un peu confus sur les balles 2 et 3. Que voulez-vous dire un bref guide utilisateur, tout type de documentation? Voulez-vous dire un manuel d'utilisateurs sur la manière d'utiliser le logiciel et que les 2 et 3 ne seraient-ils pas quelque peu de la même chose?
# 2 - Vous écrivez un brouillon d'un guide d'utilisateur complet pour l'application. Pourtant, vous voulez le garder bref, car nous voulons "maigre". Si cela ne concerne pas directement l'utilisateur, conservez-le. Ce n'est pas dans le guide de l'utilisateur, vous ne le codez pas. De plus, bref comme faute de détails. Vous ne faites que cela pour identifier ce que l'utilisateur doit avoir. Vous passez mentalement dans le processus complet pour le point de vue d'un utilisateur.
# 3 - Ceci est important ... Maintenant, obtenez ceci ... N'utilisez pas d'ordinateur pour générer de la documentation. Par rapport au crayon et au papier, ils sont une perte de temps complète pour générer une documentation informelle. Certains documents et communications devront être créés. L'idée est de faire autant que possible rapidement et facilement. Pour le garder "maigre", vous devez penser avant de sauter dans Visio, passant quatre heures sur un joli diagramme, qui est jeté lors d'une réunion car ce n'est pas ce que veulent les utilisateurs. Vous pouvez faire le même diagramme avec un crayon et un papier, copier-le et distribuer, si nécessaire. Beaucoup beaucoup plus rapide.
# 4 - Est-ce que vous créeriez une documentation utilisateur ou technique nécessaire avec un ordinateur. Puisque vous faites l'examen, c'est un bon moment pour capturer les écrans, écrire des notes, vérifier et corriger le code. Il s'agit d'examiner complètement ce que vous avez fait pour vous assurer que vous êtes vraiment fait.
# 2 - Je recommande vivement cette étape. Dans toutes mes années, je peux dire que "les utilisateurs ne savent pas ce qu'ils veulent jusqu'à ce que vous ne leur donniez pas." Cette étape vous permet d'être un utilisateur et de voir ce que vous oubliez.
Encore une fois, bonne réponse. Merci.