J'ai appris à l'école et j'ai lu partout ailleurs qu'une bonne méthodologie de développement a besoin de conception et de design avant de coder correctement.
Ce n'est pas une nouvelle information, même pour un programmeur débutant. Cependant, je me demande si c'est un bon conseil car depuis que j'ai commencé à développer dans plusieurs langages de programmation, je n'ai jamais réussi à tout concevoir et concevoir depuis le début.
Je veux dire, j'ai toujours fait fondre le design, la conception et la programmation. Suis-je le pire développeur du monde, ou l'idée que nous apprenons à l'école n'est-elle qu'un vieux dogme religieux dénué de sens ?
Comment pouvons-nous même concevoir et concevoir quelque chose que nous n'avons jamais vécu et programmé auparavant? N'est-ce pas ridicule? La programmation ne mène-t-elle pas plutôt la conception et le design?
Réponses:
Je pense que la réponse doit être: Planifiez autant que vous le pouvez, mais pas plus que cela.
Peu de gens s'opposeraient aux vertus de la planification, mais le débat néglige surtout un aspect important. La planification ne fonctionne que dans la mesure où vous avez la compétence pour faire un bon plan, cette compétence a tendance à venir avec l'expérience. Si vous n'avez pas beaucoup d'expérience, un plan que vous élaborez aura probablement des problèmes assez importants, cela signifie que pour fabriquer un produit qui n'est pas une catastrophe totale, le plan devra être fortement révisé pendant le développement, si le plan est détaillé, cela invalidera probablement beaucoup de détails, ou pire, vous essaierez de garder les ajustements au minimum afin de pouvoir suivre le plan.
Certaines choses nécessitent certainement une planification, et si vous n'avez pas les compétences nécessaires pour élaborer le niveau de plan requis, alors la seule façon d'avancer que j'imagine est le prototypage, en écrivant du code simplement pour acquérir l'expérience de la tâche requise pour faire un plan adéquat. .
Que vous soyez prêt ou non à écrire du code de production, une fois que vous avez atteint votre niveau maximum de planification, il ne reste plus qu'à coder. Ce sera peut-être un désastre, mais ce sont de bonnes expériences d'apprentissage, et vous serez bien mieux équipé pour faire un plan révisé.
la source
C'est absolument vrai. Plus l'exigence est grande et complexe, plus elle est vraie.
Pour qu'une petite application console calcule la séquence de Fibonacci, vous n'aurez peut-être pas besoin de plus de quelques minutes pour réfléchir à la façon de structurer l'algorithme et l'interface utilisateur (qui, oui, pourraient simplement être stdin et stdout).
Mais qu'en est-il d'une plate-forme de trading en temps réel censée effectuer des millions de transactions par seconde, réparties dans le monde entier et qui nécessite 99,9999 de temps de disponibilité et 100% d'exactitude? Souhaitez-vous simplement sauter dans le codage?
Il existe de nombreuses autres options entre ces deux extrêmes.
Jetez un œil au projet Euler . Résolvez quelques problèmes, dans la séquence présentée. Vous découvrirez que pour résoudre certains des problèmes dans un délai raisonnable, vous devez réellement réfléchir avant de vous lancer dans le code.
Si vous n'avez pas besoin de prendre le temps de réfléchir et de concevoir votre programme avant de commencer à coder, vous travaillez sur des choses triviales ou vous manquez quelque chose de plus grand.
Personne ne fait rien d'autre que le plus trivial des problèmes. Encore une fois, plus le projet est grand et complexe, plus cela est vrai - les conceptions auront des erreurs, des choses qui sont négligées, etc.
L'art consiste à concevoir en haut niveau d'abord, voir si les grandes pièces correspondent. Obtenez ensuite une liste de priorités - en commençant par travailler sur l'infrastructure / la plus cruciale. Ensuite, nous allons décomposer les plus gros morceaux en plus petits, en nous assurant que chaque plus gros morceau est composé de morceaux qui ont du sens.
Cela prend du temps et des efforts - et peut ne pas être complet ou entièrement correct au début.
Mais c'est pourquoi il est appelé doux -Ware et non dur -Ware. Il est malléable et peut être changé.
la source
C'est vrai.
Et il y a votre problème.
Pour la plupart des problèmes non triviaux, vous devrez réfléchir à la façon dont les choses vont fonctionner - comment les choses vont s'emboîter. Paradoxalement, pour la plupart des problèmes non triviaux, il est impossible de tout planifier . Il y a tout simplement trop de choses inconnues à prendre en compte, trop de changements qui se produiront au cours du développement. Agile a gagné la traction qu'il a parce qu'il accepte cette seconde moitié de l'accord: les gens ne sont pas omniscients et le changement est constant.
Il est donc certainement vrai que vous devez concevoir à l'avance, mais il est également vrai qu'il est impossible de concevoir uniquement à l' avance.
la source
Vous devez absolument avoir une conception avant de coder.
La raison est assez simple - si vous n'avez aucun design, vous ne savez pas ce que vous faites .
Vous devez absolument avoir du code avant que la conception ne soit définitive.
La raison est assez simple: la conception va changer et le développement de parties de la conception révèlera des questions, des opportunités et des défis difficiles à anticiper sans commencer à travailler sur la solution.
Le développement est itératif.
Que ce soit par plan ou non, que l'équipe le réalise ou non, chaque projet logiciel est effectué de manière itérative - une partie du travail est terminée, puis évaluée, et l'évaluation conduit à des changements dans la façon dont le reste du travail est effectué.
Essayez plusieurs approches.
Il faut de la pratique et de l'expérience pour connaître la meilleure façon d'équilibrer la conception initiale et la création de code. C'est une compétence que presque personne n'a maîtrisée et chaque projet aura des idéaux différents (envisagez de concevoir un petit outil pour votre propre usage par rapport à une équipe créant un grand produit à sortie unique comme un jeu vidéo majeur).
la source
J'ai conçu et observé que d'autres conçoivent plusieurs systèmes dans le passé et j'ai vu le processus se dérouler de nombreuses manières différentes, mais ce que je trouve commun, c'est que l'architecture initiale devrait au moins planifier l' existence de la plupart des fonctionnalités principales.
Par exemple, j'ai vu un système de contrôle de CVC qui n'avait aucun concept de bâtiments, d'étages, de chambres, etc. en étant modernisé et le résultat était aussi moche que possible. Ou un appareil de musique mobile construit à partir de composants mieux adaptés à votre montre de poche (non intelligente). Inutile de dire que les produits finaux dans les deux cas n'étaient pas les favoris des clients.
Lorsque vous dites «conception», ce n'est qu'une étape de plus que «idée» et un concept peut être très flou. Les entreprises se soucient généralement des concepts. Les clients se soucient généralement de l'expérience utilisateur - un concept concrétisé d'une manière qui est facile et agréable à utiliser et apporte de la valeur grâce à son utilisation.
Vous devez faire du "concept" avant toute programmation, je ne peux pas m'imaginer ouvrir Visual Studio (ou votre IDE de choix) et écrire du code au hasard, pour voir où ça va.
Vous ne pouvez pas faire une conception complète (et vous ne devriez pas) avant de coder, mais vous devriez avoir un aperçu approximatif de ce que serait le flux de travail de l'utilisateur.
La conception et le codage UX se nourrissent assez souvent les uns des autres, vous serez probablement obligé d'utiliser une approche Agile pour tout sauf le plus petit des projets comme moyen d'incorporer ce fait dans votre approche du travail. Alors ne pensez pas que vous êtes le pire des programmeurs si vous ne pouviez pas tout voir à la fois - personne ne peut et les personnes qui pensent pouvoir le faire sont celles qui ignorent suffisamment le problème pour pouvoir prétendre avoir une image.
Un exemple pour mettre une taille à quelque chose de grand. Concept: "Créer un outil visuel basé sur le cloud qui permet aux entreprises d'intégrer leurs plateformes logicielles". Cela semble génial et on peut commencer à rédiger du matériel marketing et le vendre avant même qu'il ne soit là. Vous devez avoir cela avant de coder.
Pré-conception: "Avoir des formes et des flèches comme dans Visio pour décrire la logique; avoir des capacités de plug-in pour permettre les connexions à diverses plates-formes (SAP, SF, bases de données ...); avoir une console de surveillance où l'on peut rechercher des données passant par le système; décrire visuellement les données et transformer un format en un autre ". Un autre grand blob marketing. Il vous donne également quelques idées sur ce qui est important, devrait avoir un croquis aussi grossier avant de coder aussi.
Conception / Code: "Avoir un concepteur HTML hébergé par navigateur avec telle ou telle fonctionnalité; coder le backend en Java afin qu'il puisse s'exécuter sur n'importe quel serveur existant; définir les structures de données et UX pour les interroger ou les modifier selon les besoins; planifier la reprise après sinistre, erreur rapports, journalisation d'audit; contrôle de version de plan; contrôle d'accès de plan; .... "- plus la liste est fine, plus il est irréaliste de tout prévoir.
... mais il faut au moins être conscient de ce à quoi les choses pourraient ressembler à peu près ou votre produit final peut se retrouver avec des implémentations vraiment inutiles qui finissent par tuer le concept par ailleurs génial - disons que votre concepteur visuel a besoin d'un 40 " écran pour afficher n'importe quel flux de travail du monde réel, ou il n'y a aucun moyen de rechercher les journaux autre qu'une correspondance de chaîne exacte limitée à l'un des 20 champs du journal, etc. Il n'y a pas de bon moyen d'empêcher que cela ne se produise autre que l'exécution de votre implémentation - certains réussiront, d'autres échoueront.
la source
J'attribue toujours du temps comme suit:
Design: non seulement visuel, mais aussi conceptuel. Divisez-le en parties, à la fois visuellement et par logique. Recherchez les points communs qui sont réutilisés et constituent un modèle de conception en soi.
Développement: Une fois que vous connaissez vos pièces, codez-les. Ensuite, vous les intégrez.
Tester: Non seulement tester que le code a été intégré et écrit correctement, il y aura toujours des aperçus et des leçons apprises et cela créera de nouvelles façons d'interagir, de nouvelles capacités seront conçues et souhaitées. Méfiez-vous du fluage de la portée.
En plus de ces aspects, sachez qu'un projet comporte également 3 phases en plus de ces phases.
J'ai trouvé que mieux vous faites la phase de conception, que cela minimise les tentatives supplémentaires. Au lieu de refaire tout cela, vous pourriez avoir juste un sous-système qui est retravaillé.
Je suis développeur de logiciels et responsable du développement de logiciels pour des projets de développement internes, externalisés et off-shore.
la source
Il y a ici une hypothèse incorrecte fondamentale. Vous ne pourrez jamais trouver un bon design sans avoir écrit le code au préalable (l'école ne vous l'apprendra jamais). Pourtant, l'école a raison: vous n'obtiendrez pas un bon code sans design.
La solution est:
Jeter tout le code n'est pas une étape facultative de ce processus, mais pour les petits projets, la conception formelle peut l'être. Pour les grands projets, vous êtes plus susceptible de répéter l' étape « jeter tout le code » - bien que si vous disposez d'une modularité suffisante, cela ne peut s'appliquer qu'à une partie de la base de code.
Beaucoup trop de projets conservent le code hérité parce qu'ils ne veulent pas le changer - ou parce qu'il est trop compliqué, car il n'a jamais été conçu pour être jeté. Reconnaître le fait que votre première tentative sera un échec vous rendra la vie bien meilleure.
la source
la conception est la conception clé peut toujours être modifiée la programmation devra répondre aux exigences de l'application entièrement conçue.
1 ° quel est le point, 2 ° comment doit-il être accédé, 3ème qui est l'utilisateur, 4ème exposer l'étendue complète du travail SOW définir en termes spécifiques tout ce que cette application doit faire. et comment chaque fonction que vous ajoutez fonctionnera.
avant de faire des choix quant à l'architecture de votre application Web, planifiez et réfléchissez-y complètement.
puis choisissez la meilleure pile
Je suis développeur LAMP
j'ai donc tendance à restreindre la question à quel framework php j'utiliserai. et les scripts frontaux dont j'aurai besoin pour faire faire tout ce dont j'ai besoin de manière idéale
pour ajouter ceci, apprenez à utiliser les frameworks MVC, ZEND et CAKEPHP sont les meilleurs frameworks de développement rapide (PHP)
la source