La qualité du logiciel est-elle vraiment importante Pour un développeur d'applications dans la pratique?
Je sais que cette question ressemble à la question la plus muette. Mais s'il vous plaît voir ci-dessous pourquoi je pose cette question. J'aime bien de tels principes d'ingénierie, des modèles et que vous aviez mis en œuvre et profitant jusqu'à présent. Mais maintenant, je me rend compte que de tels principes ne signifient pas vraiment que des développeurs d'applications, mais que la matière est la matière "temps de développement", "l'application est le travail comme prévu" et " fini fini Mais ça va ".
Je suis vraiment confus maintenant quelques jours sur l'importance pratique de la qualité et des principes du logiciel pour un développeur d'applications. Donc, cherche une réponse pratique après que mon guide de tous les temps ne puisse pas donner une réponse à Organisation d'impact sur la qualité du logiciel et [Importance de la qualité du code de conception] [2]
Des tonnes d'informations sont disponibles pour parler de qualité logicielle et d'ingénierie logicielle, mais sont pratiquement appliquées dans le développement des applications?
Je pose cette question en tant que développeur d'applications et ne parle pas de développement OS, de langue ou de compilateur / innovations.
Merci à tous pour votre réponse. Permettez-moi d'ajouter plus sur pourquoi j'ai posé cette question sur la première place.
Je pense aussi et pense qu'il ne devrait y avoir aucune hésitation tout en pensant à de tels principes. Je crois que c'est une sorte d'art et
stratégie ne peut pas être commuté en fonction de quelque chose . Mais si vous voyez quelque chose sur ce sujet ou que vous dites ce post, une phrase de notification telle que "dépend de quoi". Maintenant, la question pratique est de savoir qui est directement bénéfique avec un tel code de qualité, à l'exception de votre sanctification, de la morale, de l'éthique.
permet de prendre un exemple très courant; Un site Web ayant des millions de hits. Les utilisateurs finaux sont heureux car le site semble attrayant et ils sont passés à l'ordre. La direction est heureuse car le développement / l'amélioration a été effectué dans le budget et toutes les fonctionnalités sont mises en œuvre. Le PM est heureux parce que l'équipe l'a livré à temps. Le plomb technique est heureux car tous les sous-systèmes hétérogènes communiquent comme prévu et les contraintes d'infrastructure sont remplies. Une équipe de 25 développeurs est satisfaite car tous les bugs sont fixes et que maintenant leur code est en cours d'exécution; Bien sûr, ils sont confiants car ils utilisaient le type de langage de sécurité, un excellent IDE et ils trouveront le numéro de ligne de toutes les erreurs de temps d'exécution depuis que le bloc de capture est partout pour la persister.
Ici, disons, ils n'ont suivi aucun modèle ni pratiques optimales. Donc, le code n'est pas réutilisable ou des couches logiques dépendent du format de données ou du ... Mais pour le développement suivant, il y aurait de nouveaux budgets, un nouveau barème de développement et des développeurs obtiennent une nouvelle tâche qui pourrait ne pas être alignée sur la tâche passée.
Donc, qui a bénéficié directement ou doit faire respecter les éliminations en suivant certains principes, peut être en payant un coût supplémentaire en termes de temps et de budget?
Puis qui se soucie de les suivre pratiquement? Tout le monde connaît son importance théorique, mais dans la pratique, est-ce "touch d'or" ou "bien d'avoir" une fonctionnalité "DOIT avoir"? Si cela compte vraiment, alors autant de choses disent, pourquoi le budget ou le temps a été donné la plus grande importance à la qualité de la qualité d'importance.
18 Réponses :
l'application fonctionne comme prévu n'est pas toujours la solution souhaitée. Comment le travail interne se produit est également un point à noter plutôt que d'obtenir seul la sortie souhaitée.
Si ce n'était pas là, il n'y aurait pas d'aile pour Assurance de qualité logicielle dans les entreprises.
La qualité logicielle est souvent négligée car nous avons souvent tendance à faire Optimisations à court terme .
Pourquoi pensez-vous que le développement des applications n'a rien à voir avec la qualité?
Et la raison du vote en aval.
Cela dépend vraiment de votre public. Si vous êtes un développeur indépendant et vendez vos produits directement aux utilisateurs finaux, vous devriez vraiment vous soucier de la qualité.
Si vous travaillez sur des applications exclusivement utilisées en interne par certaines sociétés, vous n'avez probablement pas à vous soucier de la qualité, La plus grande concurrence Il y a moins d'importance que la qualité est
Cela dépend vraiment de la critique de l'application. Il existe des différences entre la rédaction de logiciels médicaux et une application d'utilité simple.
Je ne suis pas vraiment sûr de ce que vous entendez par qualité?
la netteté du code source?
L'UI?
la fiabilité?
la vitesse?
la taille?
C'est tout par rapport à qui vous payez de le faire, ce qu'ils veulent, ce qu'ils attendent (ceux-ci peuvent être différents et très frustrants), quand ils en ont besoin, etc.
La qualité signifie avoir un commentaire pour chaque méthode / classe, de petites méthodes, tests d'unité, aucune duplication de code. Jetez un coup d'œil à Checkstyle.
01, la qualité également, et bien plus important encore, signifie que le logiciel fait ce qu'il est censé faire correctement. La qualité signifie également que les performances de l'application sont acceptables. Je garantissons que les utilisateurs trouveront votre logiciel de mauvaise qualité si cela leur prend dix minutes pour passer de l'écran à l'écran (qui s'est produit une fois avec un logiciel commercial que nous avions dans un travail que j'avais) ou si elles ont des temps de temps. Vous pouvez avoir toutes les choses que vous avez mentionnées et que vous avez toujours un logiciel de mauvaise qualité s'il ne répond pas aux exigences. Même avec des tests unitaires, je peux facilement écrire des tests qui testent les mauvaises choses!
Vous faites un logiciel de qualité pour trois raisons:
Je suis d'accord avec vous, mais un logiciel moche peut être bien écrit.
Je dois supposer que vous voulez dire laids dans le sens de l'esthétique visuelle. Le code laid est, par définition, pas bien écrit, puisqu'il négligerait la nécessité d'être comprise par l'homme et la machine. Je n'ai trouvé aucune référence à une esthétique visuelle dans la question de l'OP.
Je serais d'accord avec en général, surtout si vous ne prévoyez pas de commercialiser de masse votre produit. Pour moi, la plupart des applications que je travaille sont vendues sur une base individuelle et que le look de l'application n'est pas aussi important que la fonctionnalité. J'ai constaté que rarement une application gagne-t-elle parce qu'elle semble mieux quand elle a moins de fonctionnalités. De plus, j'ai des clients qui deviennent assez ennuyés lorsqu'un changement est fabriqué pour que quelque chose a une apparence mieux, mais elle enfreint la fonctionnalité ou modifie le flux de travail de manière drastique, éventuellement ralentissement ou plus fastidieux.
D'autre part, si un produit a l'air agréable ou même beau, je pense que les utilisateurs de l'expérience sont beaucoup meilleures et elles seront plus heureuses pendant l'utilisation. Je pense qu'ils vont même demander plus de modifications / ajouts, car ils aiment utiliser l'application et vouloir l'utiliser plus. Je pense aussi que parfois la beauté va avec la fonctionnalité: Beaucoup d'applications agréables ont l'air bien parce qu'ils ont de belles fonctionnalités, telles que Ajax dans des applications Web.
Enfin, si l'application est une demande du public, je pense que le look de l'application est très important. (C'est moins important lorsque vous travaillez sur des applications internes.) Si une application a l'air laid de première fois lorsque des gens cliquent sur un résultat de Google, ils sont moins liés à rester pour voir plus et aller au concurrent qui a le bon site Web / application.
Une dernière chose: j'essaie généralement de faire paraître les choses bien. Je prendrai le temps supplémentaire, même si ce n'est pas la citation de le rendre plus agréable. Je suis un perfectionniste et je veux des choses que je peux montrer à d'autres clients, pas de choses que j'ai honte de.
La plupart des développeurs sont capables de livrer des logiciels qui fonctionnent comme prévu et à temps. Le vrai problème est la maintenance. Pour des projets courts, la maintenance commence après la livrable. Pour les grands projets, ses débuts même avant d'atteindre V1.0. Les bonnes pratiques et les développeurs de qualité créent Code de maintenabilité .
Bien sûr, votre projet fonctionne comme prévu . Mais chaque projet que j'ai vu jusqu'à présent comme prévu n'est pas au besoin . Toujours, le client se rend compte que quelque chose que certaines fonctionnalités demandées ne sont même pas proches de ce qui était nécessaire et que les demandes de changement de conception inévitables entrent dans. Ou le projet réussit et est adopté par plus d'équipes dans les clients Org, et chaque fois qu'il a un petit changement. demande de mieux adapter leurs besoins. Ou l'échelle d'exigence d'origine est un dixième de l'utilisation actuelle de déploiement et le logiciel doit accueillir la plus grande base d'utilisateurs.
Ce ne sont que correctement mis en œuvre, en fonction des exigences, des projets. Et nous sommes tous des êtres humains et font des erreurs, nous avons mal compris les exigences et nous livrons parfois quelque chose de loin ce qui a été demandé.
Tout se résume au fait que le logiciel ne gèle jamais, tant qu'il existe un sponsor pour payer les modifications nécessaires. Un logiciel piraté mal écrit est impossible à changer. Les bonnes pratiques imposent un fardeau au cours du développement pour que le produit final soit possible de changer, de refacteur, de déboguer et de maintenir.
La plupart des non-développeurs définiraient une demande de qualité comme celle qui répond à leurs attentes. Dans l'ensemble, différentes parties prenantes auraient une définition différente:
De nombreux développeurs travaillant sur de petits projets sont bloqués en pensant à un motif XYZ, ou pontifiant sur le bon cadre / langue à utiliser. Ces choses importantes sur les grandes applications d'entreprise ou les grandes applications Web critiques de performance (c'est-à-dire Facebook, Google, etc.), mais sont souvent moins importantes lorsque la solution serait préférable.
En fin de compte, les propriétaires / directeurs d'entreprise sont ceux qui déterminent votre emploi, leur définition de la qualité est ce qui compte le plus.
Je viens de gagner des projets qui ont été lancés par des développeurs qui n'avaient aucun respect de la qualité de leurs logiciels.
vrai, le fait que j'ai un flux constant de clients signifie que, au lieu d'embaucher quelqu'un comme moi pour commencer avec ils ont embauché quelqu'un qui a fait un travail bâclé. Donc oui, dans le sens où vous pouvez vous échapper et gagner de même gagner sa vie, peu importe.
Mais pour moi, il s'agit de plus que du court terme. J'aimerais donner des projets plus importants car mes compétences et mes expériences grandissent et je ne pouvais pas faire cela si je n'ai pas fait attention à la qualité de mon logiciel.
En plus, il semble juste plus joli quand vous le faites.
Bien sûr qu'il importe.
Comme vous l'avez dit, il y a beaucoup d'informations pour concevoir des applications comme elles sont censées être conçues et codées comme elles doivent être codées.
Même si vous êtes un développeur d'applications comme vous l'appelez, vos coéquipiers et vos collègues ne voudront pas travailler avec vous si vous êtes négligé. La qualité de votre travail reflète sur toute votre équipe.
Vous pourriez passer votre carrière à développer sans apprendre les principes et l'architecture, mais ne vous attendez pas à ce que vous n'ayez jamais été reconnu ou pour que des positions supérieures. Vous ne serez jamais en mesure de concevoir l'architecture d'une application par vous-même car vous ne saurez que développer les fonctionnalités / écrans les plus élémentaires.
Alors oui ... ça compte. Allez apprendre!
Je n'ai pas vraiment eu votre question. Mais au cas où vous interrogez la nécessité de suivre toujours des principes de conception et de la manière dont ils jouent dans la qualité de votre projet, voici ma réponse.
Cela dépend de la phase du projet, de la taille de l'équipe et du temps à l'achèvement prévu.
Parfois, il est important d'être rapide et sale. Obtenez-le le plus rapidement possible. L'utilisation du meilleur modèle de conception dans ces cas est surchargée et non nécessaire. Le développeur qui est capable de livrer rapidement avec une solution de solution. Celui avec la tête dans le ciel perd.
Cependant, parfois (souvent) l'approche rapide et sale échoue de manière misérablement. Par exemple, si le projet a ou aura un grand groupe de développeurs (plus de 4) ou plusieurs équipes, à la suite de schémas de développement et de techniques de développement solides / éprouvés, c'est le seul moyen de réussir à long terme. En outre, la mise en œuvre de nouveaux modèles échoue souvent s'il existe une grande quantité de code hérité complexe. Enfin, les lignes de temps prévues sont cruciales pour rester en ligne. Si le client s'attend à une sorte de prototype dans une journée, alors ne dépensez pas une semaine à installer un cadre complet MVC.
J'ajoute une seconde réponse parce que c'est mon opinion personnelle et que j'essaie de fonctionner, non seulement avec la qualité logicielle, mais tout ce que je suis payé à faire.
Avec tout, quand quelqu'un me paye pour faire quelque chose, je vais le faire au mieux de mes capacités. Je ne vais pas prendre de raccourcis, je ne vais pas arperquer, je ne vais pas couper les coins. Je vais mettre tout ce que je peux, car les gens remarquent cela, ils l'apprécient, et ils reviendront. C'est mon nom de mon (ou de mon entreprise) sur le produit que je leur donne, et je ne veux pas mon nom sur un morceau de merde. Cela pourrait prendre un peu plus de temps et coûter un peu plus que les autres personnes, mais ça va.
Je veux me sentir bien à propos de ce que je fais et je ne peux pas faire ça si je sais que je bas moins cher. Malheureusement, tout le monde ne fonctionne pas comme ça. Ferrari n'a pas fait de nommer des coins coupant des coins et affamer. Les gens remarqueront que vous avez passé le temps à le faire, et plus souvent, si vous coupez les coins, vous devrez probablement y retourner de toute façon. Voulez-vous vraiment une réputation de faire des choses qui se brisent?
Il y a un dicton qui dit quelque chose comme si un client a une bonne expérience, il dira 3 personnes, s'il en a un mauvais, il en dira 10. Il y aura la vérité dans cela, et c'est beaucoup plus difficile à réparer une mauvaise réputation que de garder un bon. Parfois, ces ombres de doute ne disparaissent jamais, et ça fait mal.
Faire des choses bien la première fois est toujours meilleure que de le faire ok la première fois, puis la fixant la deuxième fois, à venir avec des excuses de conneries en cours de route.
morale, éthique, bla bla bla bla
Comment l'utilisateur d'application saura-t-il que vous mettez des commentaires sur chaque méthode / classe et ligne? La plupart des gens ne vendent pas de logiciels. Je pense que plus de mauvais représentant vient d'avoir une mauvaise conception graphique.
Je me fiche de ce que tu penses. Je n'ai également jamais rien dit sur les commentaires. S'ils m'ont payé pour écrire un code et commenter chaque étape expliquant ce qui se passe, alors c'est ce que je vais faire. Il est assez évident de ce que vous avez dit déjà que vous n'aviez jamais été payé au code.
La première étape consiste à définir la qualité.
En fin de compte, tout ce qui compte est quelle valeur le logiciel apporte au consommateur. Ainsi, en ce qui me concerne, il n'y a que deux choses qui constituent un code «de qualité».
Une base de code de haute qualité vous permet de modifier rapidement et facilement, avec une grande confiance que vous n'introduisez pas le monde et que vous n'avez pas de coût pour construire / vérifier vos modifications. Une base de code de bonne qualité est fragile, difficile à modifier et prend beaucoup de temps pour construire / vérifier.
Tout le reste est juste une ligne directrice qui s'appuie sur l'un de ces deux points. La qualité constante et la bonne nommée augmente la qualité car cela indique clairement ce que le code fait et comprendre ce que le code fait facilite la modification. Les suites de test de l'unité augmentent la qualité car elles facilitent la modification du code avec une grande confiance. Les principes de "bon design" telles que la séparation des préoccupations facilitent la modification du code, car les changements ont tendance à être plus isolés.
Donc, oui, ces choses peuvent même au développement des applications. Les facteurs de qualité internes facilitent l'ajout de plus de fonctionnalités à l'application sur une période donnée - toutefois, cela doit être équilibré contre les caractéristiques pouvant être implémentées compte tenu de la même quantité d'effort de développeur.
Quant à la première étape: Stackoverflow.com/ Questions / 405243 / ...
On dirait que vous disiez que ce qui compte vraiment, c'est que vous le mettez, "le temps de développement", "l'application fonctionne comme prévu" et "fini peu tard, mais ça va". Qui est fondamentalement du temps de développement, de la fonctionnalité et ... du temps de développement.
Et vous êtes mort à droite. Tout ce qui compte, c'est que votre produit fonctionne comme prévu et sort à temps. Et parfois même de travail comme prévu est moins important que de simplement le sortir.
Mais voici la prise: comment obtenez-vous un produit qui fonctionne comme prévu rapidement? Pour une très petite base de code, la réponse pourrait être juste pour lancer quelque chose de rapide et sale ensemble. Il y a des cas où Le raptor
Mais la «forte> vaste vaste la majorité des cas vous travaillez sur quelque chose que vous allez passer au moins quelques semaines d'homme. Et le code rapide et sale a un moyen de spirale de contrôle et de laisser votre produit un tas de SEGFAULTS SEGFAULTS, des exceptions non capturées et des conditions de course. Cela pourrait arriver au deuxième jour, ou la deuxième semaine, ou deux mois, mais ce sera toujours avant que vous vous attendiez et quand il n'y a pas de bonnes options. Vous pouvez faire vos premières émines avec toutes vos fonctionnalités sans bug, mais que votre code rapide et sale cessera d'être rapide et continuera d'être sale, et cela affectera votre temps de développement, votre fonctionnalité et votre ... / p>
Alternativement, vous pouvez prendre le temps d'écrire un code lisible, idiomatique et extensible qui permet d'utiliser correctement les modèles de conception. Au début, il semblera que c'était un moyen beaucoup plus lent de faire des choses. c'est parce que c'est , mais seulement pour le moment. Trois mois sur la ligne, votre patron vous dira de changer de changement. Peut-être qu'il portait tout votre système de Solaris à Linux: car vous avez écrit un bon code indépendant de la plate-forme, vous modifiez quelques appels de fonction et compile sans erreurs. Ou peut-être qu'il ajout de support pour les plugins tiers: puisque tout votre rendu a été traité dans la même zone selon le principe sec, il suffit d'ajouter un support de plugin à une classe. Pendant ce temps, vos concurrents rapides et sales envisagent de réécrire complètes pour leur produit, car leurs normes et leur conception originales (ou leur manque) n'ont pas pris en compte la portabilité ou l'extensibilité.
En bref, la qualité logicielle est la manière dont vous rencontrez des délais et de créer une fonctionnalité bien fonctionnelle.
Il n'y a vraiment jamais de bonne raison d'écrire un mauvais code.
Près de tous les logiciels passeront la majeure partie de sa vie en maintenance. Par conséquent, presque tout le code doit être maintenu.
Construction du code maintenu ne prend pas plus de temps que de construire un code non immobile, une fois que vous entrez dans l'habitude. Mais vous n'obtiendrez pas l'habitude d'écrire du code maintenu en écrivant un code non immobile. Par conséquent, même le code que vous voulez jeter devrait être maintenu.
Les mêmes pratiques qui conduisent à un code maintenu conduisent également à un code vérificateur. Si vous n'avez pas testé le code, vous ne pouvez pas dire honnêtement que cela fonctionne comme prévu. Par conséquent, même le code que vous voulez jeter doit être testé.
code écrit pour être maintenu et testtable a moins de bugs. Même le code testable bien écrit que n'a pas été testé (EM> n'a pas été testé est beaucoup moins susceptible d'avoir des bugs que le code mal écrit et difficile à tester qui n'a pas été testé. Par conséquent, même le code que vous ne testez pas doit être bien écrit.
Qu'est-ce que vous devez vous protéger, ce n'est pas le temps gaspillé de faire du code. Il est temps de perdre du mal au travail.
La qualité de l'application signifie une grande affaire à un développeur et surtout uniquement pour le développeur, rarement à la gestion.
Lorsque vous faites attention à la bonne architecture d'applications, concevez-la avec l'extensibilité et la maintenabilité à l'esprit, vous économisez à l'esprit le temps et la douleur à l'avenir lorsque vous essayez de déboguer le code et de réparer les choses qui à un moment donné commencent à tomber en morceaux. < / p>
Il y a le terme pour ces petits hacks et les développeurs de fixes rapides tentent de faire de la dette de développeur. Si vous en tirez assez, à un moment donné à l'avenir, vous serez bloqué - la faillite technique. Ce qui signifie qu'il est maintenant presque impossible d'ajouter de nouvelles fonctionnalités ou de changer quelque chose sans le reste en train de s'effondrer. Il est maintenant moins cher et plus simple juste de réécrire tout à partir de zéro. La direction ne voudrait jamais faire cela. En tant que fier développeur, vous ne voudriez jamais aider à «atteindre» cette situation, probablement même pas à un projet avec cette philosophie de développement.
La qualité du code est défini par Vous affirmez essentiellement que seuls des facteurs visibles de l'extérieur, ou un sous-ensemble d'entre eux («fonctionne comme prévu»), matière. Ce sont certainement les plus visibles, mais il existe un consensus général en ce sens sans facteurs de qualité de code internes, vous n'obtenez pas une qualité externe élevée.
Analogie - Vraiment Great Cars Ne comptez pas seulement dans des tests très difficiles du prototype final. Le processus de conception et de développement lui-même doit appliquer des technologies de haute qualité afin de réaliser une voiture qui est un candidat être une bonne voiture.
+1 pour l'analogie MFG. "Vous ne pouvez pas inspecter la qualité dans le produit; c'est déjà là." - W. Edwards Deming
Merci à tous pour votre réponse. Permettez-moi d'ajouter plus sur pourquoi j'ai posé cette question sur la première place.
Je pense aussi et pense qu'il ne devrait y avoir aucune hésitation tout en pensant à de tels principes. Je crois que c'est une sorte d'art et de stratégie ne peut pas être commuté en fonction de quelque chose.
Mais si vous voyez quelque chose sur ce sujet ou que vous dites ce post, une phrase de notification telle que "dépend de quoi". Maintenant, la question pratique est de savoir qui est directement bénéfique avec un tel code de qualité, à l'exception de votre sanctification, de la morale, de l'éthique.
permet de prendre un exemple très courant; Un site Web ayant des millions de hits. Les utilisateurs finaux sont heureux car le site semble attrayant et ils sont passés à l'ordre. La direction est heureuse car le développement / l'amélioration a été effectué dans le budget et toutes les fonctionnalités sont mises en œuvre. Le PM est heureux parce que l'équipe l'a livré à temps. Le plomb technique est heureux car tous les sous-systèmes hétérogènes communiquent comme prévu et les contraintes d'infrastructure sont remplies. Une équipe de 25 développeurs est satisfaite car tous les bugs sont fixes et que maintenant leur code est en cours d'exécution; Bien sûr, ils sont confiants car ils utilisaient le type de langage de sécurité, un excellent IDE et ils trouveront le numéro de ligne de toutes les erreurs de temps d'exécution depuis que le bloc de capture est partout pour la persister.
Ici, disons, ils n'ont suivi aucun modèle ni pratiques optimales. Donc, le code n'est pas réutilisable ou des couches logiques dépendent du format de données ou du ... Mais pour le développement suivant, il y aurait de nouveaux budgets, un nouveau barème de développement et des développeurs obtiennent une nouvelle tâche qui pourrait ne pas être en ligne avec la tâche passée.
Donc, qui a bénéficié directement ou doit faire respecter les éliminations en suivant certains principes, peut être en payant un coût supplémentaire en termes de temps et de budget?
Puis qui se soucie de les suivre pratiquement? Tout le monde connaît son importance théorique, mais dans la pratique, est-ce "touch d'or" ou "bien d'avoir" une fonctionnalité "DOIT avoir"? Si cela compte vraiment, alors autant de choses disent, pourquoi le budget ou le temps a été donné la plus grande importance à la qualité de la qualité d'importance.
Dry / Kiss / Yagni + Sont + meilleures pratiques.
Le pragmatisme à éviter / sous ingénierie est très important. Cela fait partie d'un bon design. L'utilisation de modèles de design non pertinents est un obstacle: baiser. Rendre le code réutilisable lors de son application spécifique est une erreur: Yagni. Concentrez-vous sur une bonne conception et une bonne gestion de projet, et toutes les meilleures pratiques se trouveront en place.
S'ils ne suivaient aucun modèle ni des pratiques optimales, il est peu probable que toutes les fonctionnalités fonctionnent réellement et que tous les sous-systèmes communiquent comme prévu. Surtout avec une équipe de 25 développeurs. "Tous les bugs" ne sont jamais fixés - mais je parie que cette équipe a définitivement trouvé et corrigé un nombre anormalement élevé de bugs. Je parierai également que cela a pris plus de temps qu'il ne devrait pas avoir à réparer ces bugs, que le nombre de bogues non encore trouvés est également anormalement élevé et que lorsque ces bugs se trouvent, ils prendront une période anormale pour réparer.
J'aimerais également souligner que les modèles de conception ne sont ni nouveaux ni magiques; Ils sont un résumé formel de bonnes stratégies observées sur le terrain. Lorsque vous concevez quelque chose de bien, les modèles se forment eux-mêmes. Vous ne verrez aucune amélioration de faire l'étiquetage des schémas si tout le monde comprend déjà la spécification.
J'essaie de toujours écrire un bon code pour la satisfaction personnelle. =)
Pourrait vouloir marquer cela comme wiki communautaire.
Oui. Cela appartient au wiki communautaire.
Mérite d'être mentionné: votre Google-Fu est faible, en tapant simplement des phrases comme ça dans Google ne va pas vous avoir ce que vous recherchez. L'organisation d'impact sur la qualité du logiciel est si vague, je pensais que c'était un Songtitle Indy au début.
> L'organisation d'impact sur la qualité du logiciel est si vague que je crois aussi. Mais quoi que ce soit et après avoir eu un mauvais sens, j'ai essayé de trouver une réponse définitive et mesurable réponse à propos de "qualité logicielle" en recherchant sur le réseau. Maintenant, pourquoi pensez-vous que, on ne peut pas obtenir "en tapant simplement des phrases comme ça"? La seule possibilité est que je n'ai pas beaucoup essayé. Sinon, en utilisant simplement (de nombreuses) phrases, je crois, on obtiendra les informations si disponibles. Je suis désolé, je ne connais aucune autre méthode pour rechercher le NET autre que d'utiliser des moteurs de recherche.
Ce que vous semblez conduire ici, un peu, est une qualité culte de cargaison, l'idée qui suivait de manière rigoureuse certaines règles entraînera une base de code de haute qualité, même si vous ne comprenez pas les règles. C'est intrinsèquement une mauvaise hypothèse. Si les pratiques rendent le codeBase plus difficile à travailler avec ou moins efficace, alors ils ne sont pas, par définition , ajoutant de la qualité à votre codeBase. La plupart des choses étiquetées les meilleures pratiques sont faites donc car, plus souvent, elles vous feront gagner du temps et de l'énergie à long terme.