Arg. Conception par contrat a été autour depuis longtemps, mais il n'a jamais gagné de la popularité des paradigmes de programmation. Bien que je ne comprends pas complètement pourquoi car la qualité elle complète les tests unitaires si bien et si les augmentations globales des logiciels, je suppose que je peux deviner certaines suppositions.

<Rant>

La première, c'est parce que des procès (ce que nous appelons ces types de gestion sur ce blog [ce qui exclut certains types de gestion que j'aime]). S'adapte n'aime pas les DBC. Suites n'ont pas DBC parce que c'est quelque chose qui exige une participation très peu sur leur fin, et donc ils ont peu d'indications sur le processus global. Depuis s'adapte ont tendance à être ceux qui sont directement responsables de l'invocation du projet, ont tendance à être le parrain du projet global, ils ne sont pas les ventilateurs quand ils ne peuvent avoir un rôle direct dans le processus de développement logiciel. Dans le même esprit, les costumes ont tendance à venir, non issu d'un milieu de programmation eux-mêmes, ou il ya des entourages de programmation est fricking si désuet qu'il est totalement inapplicable, par conséquent, DBC a tendance à tirer sur leurs têtes. Avec s'adapte à, le coût est roi, et DBC, si être adapté, coûtera plus de temps et d'argent. Lorsque vous dites s'adapte vous allez prendre un dix minutes supplémentaires pour développer quelque chose, voici comment la conversation est généralement go:

[Développeur] Je vais revoir mon approche de développement. Je vais utiliser quelques principes de DBC, afin que mes méthodes ont pré-conditions et post-conditions. Il sera ainsi plus facile d'écrire des tests unitaires car il sera essentiellement mettre en place un atelier de test pour moi d'utiliser.

[répondre] Whatever. Combien de temps faut-il.

[Développeur] Je serais d'estimation, mais pas plus de quelques heures

(silence, le développeur peut dire à ce qui se passe plus comme un pet dans l'église)

[répondre] Est-ce l'application courante de travail?

[Développeur] Bien sûr, mais il augmentera la fiabilité du logiciel, cela pourrait être important à considérer.

[répondre] Mais il fonctionne en ce moment n'est-ce pas?

[développeur] de travail ne s'apparente pas à la fiabilité ou de robustesse.

[répondre] Si cela fonctionne, vous devriez commencer à travailler sur l'exigence suivante.

[Développeur] (bras levés) d'amende!

Voilà donc la première raison que je pense DBC n'a jamais eu de succès, même s'il est tout naturel.

Deuxièmement, je ne pense pas que les gens trouvent dans intéressante, et la plupart des gens qui font du développement SharePoint Just Don't Care. Et les clients ne se soucient pas. C'est la même raison, je crois que l'externalisation a décollé fricking si étonnant (c'est une affirmation quelque peu). Les gens sont prêts à sacrifier la qualité d'un logiciel pour le temps et l'argent. Ce n'est pas comme les autres produits car il est rare que la personne que le logiciel est livré à l'air effectivement sous le capot, et dit: "Hé, qu'est-ce !?!?!?". Si elle s'exécute, il s'exécute. Si ça casse, tant pis, même si cela peut coûter plus cher à corriger l'application que ce qu'elle aurait été de passer plus de temps sur lui dans la première place.

Troisièmement, les gens ne se rendent pas compte que vous pouvez faire du contrat Driven Design (CDD) avec TDD. Vous savez, cela est possible.

Quatrièmement, les gens confondent les tests unitaires avec DBC. Ils mai paraître similaires, mais ils ne sont pas les mêmes. CDD est d'abord automatique, puisque les données aléatoires peuvent être directement passé à l'intérieur et la loi sur les contrats précisé que le harnais de test. Cela vous aide à trouver les bogues logiciels que vous pouvez ne pas trouver autrement dans votre code. Pour une plus grande extension, les couples CDD avec ATS (comme décrit dans la gripe ci-dessus) dans le sens où lorsque vous exécutez vos tests unitaires sur le code de votre contrat de contraintes seront prises en considération.

Enfin, depuis que je suis las d'écrire au sujet de cette clients les plus pourrait donner à foutre de documentation de l'API. Pourquoi? Je ne sais pas, mais ils ne pouvais vraiment pas. DBC sens qu'il se fonde vos contrats dans votre documentation de l'API (qui est généralement automatisée) améliore considérablement la lisibilité de votre code tel qu'il est remis du développeur à développeur.

Ugh, I'm done écrit à ce sujet.

</ Rant>

Article ou de recherche Classé dans Général (Personal) | SharePoint développement.

2 Commentaires »

1. 

   Wow. Je crois que j'ai été témoin de cette conversation. Oui, s'adapte = mauvais.

   Commentaire de Chooklay - Juin 27, 2007 @ 4:25

2. 

   Oui, vous avez à peu près n'a

   Commentaire par Adam Buenz - Juillet 2, 2007 @ 11:57

Flux RSS pour les commentaires sur ce post. TrackBack URL

Laissez un commentaire