ARB Security Solutions »¿Por qué Diseño por Contrato no es popular

¿Por qué Diseño por Contrato no es popular

Arg. Diseño por Contrato ha existido por mucho tiempo, sin embargo, nunca se ha ganado la popularidad de los paradigmas de programación. Aunque no entendemos por qué, ya que los suplementos de pruebas de unidades tan bien y aumenta la calidad del software en general, supongo que puedo entender algunas suposiciones.

<Rant>

La primera es que los trajes (que es lo que llamamos los tipos de gestión en este blog [lo que excluye algunos tipos de gestión que me gusta]). Trajes no me gusta DBC. Trajes no DBC, porque es algo que requiere muy poca participación en su fin, y por lo tanto tienen poca idea del proceso en general. Desde trajes tienden a ser los que son directamente responsables de la invocación del proyecto, tienden a ser el patrocinador del proyecto global, que no son aficionados, cuando ellos no pueden tener un papel directo en el proceso de desarrollo de software. En la misma línea, los trajes tienden a no provienen de un contexto de programación de sí mismos, o si hay antecedentes de programación es tan Fricking anticuada que es totalmente inaplicable, por lo tanto, DBC tiende a disparar por encima de sus cabezas. Con trajes a, el costo es el rey, y DBC, si se está adaptando, costará más tiempo y dinero. Cuando usted dice se adapte a usted se va a tomar un extra de diez minutos para desarrollar algo, así es como la conversación en general, va:

[desarrollador] voy a reconsiderar mi enfoque de desarrollo. Yo voy a usar algunos de los principios DBC para que mis métodos tienen condiciones pre-y post-condiciones. Esto hará que sea más fácil escribir pruebas de unidad, ya que básicamente construir un instrumento de prueba para que yo use.

[demanda] Cualquiera que sea. ¿Cuánto tiempo más va a tomar.

[desarrollador] sería la estimación, pero no más de un par de horas

(silencio, el desarrollador puede decir que esto va más como un pedo en la iglesia),

[demanda] ¿La aplicación actualmente?

[desarrollador] Claro, pero aumentará la fiabilidad del software, por lo que podría ser importante a considerar.

[demanda], pero funciona ahora no?

[desarrollador] de Trabajo no equivale a la fiabilidad y robustez.

[demanda] Si funciona, usted debe comenzar a trabajar en el siguiente requisito.

[desarrollador] (los brazos en alto) de multa!

Así que es la primera razón que creo DBC nunca se dieron cuenta, aunque es algo natural.

En segundo lugar, no creo que la gente encuentra en interesante, y la mayoría de la gente que hace el desarrollo de SharePoint simplemente no les importa. Y los clientes no les importa. Es la misma razón creo que la externalización se quitó de manera sorprendente Fricking (esta es una afirmación un tanto vaga). La gente está dispuesta a sacrificar la calidad de software para el tiempo y dinero. No es como otros productos ya que es raro que la persona que el software se entrega realmente se ve debajo del capó, y dice: "Oye, ¿qué !?!?!?". Si se ejecuta, se ejecuta. Si se rompe, bueno, a pesar de que podría costar más de fijar la aplicación de lo que hubiera sido la de pasar más tiempo en ella en primer lugar.

En tercer lugar, la gente no se da cuenta que usted puede hacer contrato Driven Design (CDD), con TDD. Ya sabes, esto es posible.

En cuarto lugar, la gente confunde la unidad de pruebas con DBC. Pueden parecer similares, pero NO son lo mismo. CDD es una parte automatizada, puesto que los datos aleatorios se puede repercutir directamente en el acto y los contratos se especifica que el instrumento de prueba. Esto le ayuda a encontrar errores de software que de otra manera no podría encontrar en el código. Para una mayor ampliación, las parejas CDD con TDD (como se describe en la queja anterior) en el sentido de que al ejecutar las pruebas unitarias en el código de sus limitaciones contrato será tomada en consideración.

Por último, ya que estoy cansado de escribir acerca de esta mayoría de los clientes podría dar una mierda sobre la documentación de la API. ¿Por qué? No sé, pero realmente no podía. DBC, ya que sus contratos se basa en la documentación de la API (que generalmente es automático), se mejora enormemente la legibilidad de su código, ya que se entrega de desarrolladores para desarrolladores.

¡Uf, he terminado de escribir acerca de esto.

</ Rant>

Puestos relacionados con:

Artículo o la investigación Filed Under General (Personal) | Desarrollo de SharePoint.

2 Comentarios »

Wow. Creo que fue testigo de esta conversación. Sí, trajes = malo.
Comentario de Chooklay - 27 de junio de 2007 @ 4:25 am
Sí, casi no
Comentario por Adam Buenz - Julio 2, 2007 @ 11:57 am