¿La reutilización del software impide la repetibilidad del proceso?

25

Reutilización de código como problema

Estaba pensando en esta pregunta sobre la entrega de software, y seguí volviendo al tema de la repetibilidad y / o reproducibilidad . Importan, porque si no repites un proyecto, entonces se vuelve más difícil mejorar el proceso que usaste para construir el proyecto. La ingeniería implica mejorar constantemente los procesos relacionados con el diseño y la construcción para producir proyectos de mayor calidad.

El software puede depender en gran medida de la reutilización debido a su forma digital. En lugar de reescribir un módulo, simplemente lo llamamos nuevamente o lo copiamos al otro sistema. Algunos ejemplos son autenticación / inicio de sesión o quizás una función de registro. Hay muchos ejemplos bien conocidos para esas categorías, y la sabiduría convencional es reutilizar lo que existe en lugar de crear uno propio.


Algunas comparaciones con otras disciplinas

Construcción

En contraste, la construcción de sistemas físicos (edificios, puentes) no es tan reutilizable. Es cierto que el plano de una casa se puede reutilizar muchas veces para construir la misma copia de la casa, pero la construcción debe realizarse cada vez. Cortar y pegar no funciona así en el mundo analógico. Los planos del puente son menos reutilizables que las casas porque las condiciones del sitio variarán.

Los maestros constructores son expertos reconocidos por haber diseñado y / o construido decenas, cientos o miles de cosas en su área. Por ejemplo, Frank Lloyd Wright , un arquitecto y diseñador de renombre mundial designed more than 1,000 structures and completed 532 works. Compare eso con Anders Hejlsberg, quien ha diseñado "solo" cinco idiomas (Turbo Pascal; Delphi; J ++; C #; Typecript). En muchos sentidos, es una comparación injusta porque los dominios son diferentes. Pero en un nivel amplio, la producción cuantificable de dos personas muy inteligentes es muy diferente.

Artes marciales

Los artistas marciales dirán que el dominio de un movimiento proviene solo de miles de repeticiones. Después de que una buena parte de esas repeticiones se han realizado, muchos artistas marciales se sorprenden de cómo un kata o forma compleja previamente percibida se ha vuelto simple. Los instructores de esos estudiantes también notarán cómo el movimiento se vuelve más fluido y decidido, además de tener una economía de movimiento. Del mismo modo, los artistas marciales experimentados pueden recoger katas más complejas más rápidamente que los estudiantes menos experimentados. La experiencia de la repetición les ha dado un marco o proceso que les permite aprender más rápidamente.

Carpintería

Los trabajadores de la madera experimentan una transformación similar. Los carpinteros aficionados siempre se refieren a su primer proyecto que requería muchos cajones. Si completan el proyecto, obtienen una nueva apreciación de las eficiencias que producen las líneas de ensamblaje. Hay otros beneficios, como una mejor comprensión de cómo colocar las piezas de los cajones en el material de la lámina para maximizar el uso de la madera. En comparación con los aficionados, los carpinteros profesionales pueden diseñar, comenzar y construir más rápidamente artículos que han hecho muchas veces antes. También obtienen la capacidad de ver problemas inherentes dentro del diseño de otra persona después de haber cometido ese error en su trabajo.


Entonces, ¿la reutilización del software impide que los desarrolladores de software se vuelvan más competentes?

En muchos sentidos, el diseño y la construcción del software siempre son nuevos. No repetimos trabajos pasados, porque si podemos reutilizar un módulo, biblioteca o sistema, entonces lo hacemos. Preferiblemente extenderemos un sistema existente antes de reescribir todo desde cero. Pero la repetición es lo que nos permite encontrar eficiencia en el diseño y la construcción. Cualquiera que haya practicado un deporte o actividad física le dirá que la repetición es la clave para convertirse en un buen practicante.

Mi pregunta: ¿la capacidad del software para ser reutilizado impide la mejora y eficiencia del proceso necesarias que se obtienen al repetir un proyecto?

Comunidad
fuente
Si ha escrito un código, esencialmente ha resuelto un problema. Si eres bueno en esto, esta pieza resuelve una CLASE de problemas. Si eres realmente bueno, es extensible a una metaclase de problemas. Y luego pierde interés: no hay necesidad de perfeccionar una bicicleta si hay problemas de diseño sin resolver. La emoción de la resolución de problemas proviene de brillar cosas nuevas, no de pulir viejos problemas a la perfección.
Deer Hunter
2
Los buenos proyectos de software "cambian" mucha repetibilidad al control de calidad. Cuando era un probador en un proyecto de 1,5 años, realizamos ciclos de prueba en lanzamientos semanales de "puntos de control", aproximadamente 70 veces en total durante el proyecto. Eso fue ... bastante repetible, en voz baja (no cambian muchas cosas en una semana). Las pruebas de compilaciones nocturnas han sido, naturalmente, aún más repetibles, aproximadamente 500 veces a través del proyecto (pocos errores entretenidos eran demasiado raros para hacer la diferencia). Ahora, cuénteme una empresa de construcción que ha construido 500 puentes, todos con el mismo equipo
mosquito
@gnat: esa es una excelente visión y una perspectiva que aún no había reflexionado. Otros aspectos del SDLC se vuelven mucho más eficientes debido a esa repetición.
1
@ GlenH7 lo amplió en la respuesta , principalmente para incluir imágenes de puentes :)
mosquito
¿Cuántos problemas tuvo que resolver Frank Lloyd Wright en sus 1000 estructuras contra Anders Hejsberg al definir sus meros 5 idiomas? Wright tomó decisiones por decreto, Anders tuvo que justificar las decisiones ante muchas personas tan inteligentes y conocedoras como él. Apuesto a que Anders tuvo que resolver muchos, muchos más problemas. Por lo tanto, sus números de lanzamiento en la mezcla se basan simplemente en lo que está eligiendo contar y no en números comparables cuantificables REALES. Entonces me gusta la pregunta, simplemente no me gusta el razonamiento / ejemplos que inspiran la pregunta. La eficiencia de SW ha mejorado enormemente a lo largo de los años.
Dunk

Respuestas:

10

La capacidad de reutilizar el software no impide la mejora del proceso.

Si piensa en los procesos que intervienen en la creación de software: desarrollo de requisitos, diseño del sistema, implementación del sistema, implementación del sistema, gestión de requisitos, gestión de configuraciones, verificación y validación del producto de trabajo, seguimiento de cambios y una serie de otros (consulte el Áreas de proceso de CMMI para un posible desglose de actividades clave en el desarrollo de software): se repiten en cada proyecto, independientemente de la cantidad de reutilización que tenga. Además, cada uno tiene algún tipo de medidas cuantitativas y cualitativas que se pueden utilizar para determinar qué tan bueno es ese proceso o actividad particular y, como resultado, qué tan bueno es el proceso de desarrollo en su conjunto.

En un extremo del extremo, podemos asumir una línea de productos de software robusta .. En el otro, puede asumir el desarrollo greenfield. Todavía es necesario realizar todos estos procesos, en diversos grados, aunque pueden ocurrir a diferentes velocidades o incluso en diferentes secuencias. Por ejemplo, en una gran cantidad de reutilización, se puede dedicar un mayor porcentaje del tiempo asignado a actividades de integración y verificación / validación a nivel de sistema (requisitos V&V, pruebas de integración, pruebas de sistema, pruebas de aceptación). Con nuevos esfuerzos de desarrollo, se puede requerir un mayor porcentaje del tiempo en el diseño y la implementación. Siempre que realice un proceso al menos una vez durante el curso de un proyecto, puede medirlo (cuantitativa y cualitativamente). Una vez que realice los ajustes y vea cómo esos ajustes afectan alguna medida del área del proceso o de la capacidad general para entregar software,

La clave para la mejora del proceso es tener algún tipo de desglose lógico de sus actividades y procesos, determinar cómo medirlos (preferiblemente de manera consistente) y cómo comprender esas mediciones para realizar cambios en el proceso hacia algún final. No se trata de repetir el proyecto, sino de la coherencia en la forma en que repites el proceso.

Thomas Owens
fuente
depende de lo que se está reutilizando, incluso podría caer en la adquisición de CMMI, es decir, no en el trabajo de desarrollo.
imel96
1
Pero CMMI no ha tenido éxito de ninguna manera significativa. Ninguna de las "aplicaciones asesinas" del siglo XXI fueron construidas por personas relacionadas con la matriz de madurez CMMI. Algunas personas brillantes tuvieron una idea y la implementaron, y luego contrataron a personas más brillantes para aumentar la escala de la solución. Por el contrario, los proyectos que probablemente al menos pagaron las reglas como CMMI han fracasado miserablemente, por ejemplo, el intento del Departamento de Defensa de los Estados Unidos de construir una nueva aplicación de nómina.
Kevin Cline
1
@kevincline No importa que CMMI haya tenido éxito o no. Sentado en la industria aeroespacial / de defensa, veo a CMMI en mi organización y en las compañías con las que trabajamos, de las que somos subcontratistas y que subcontratamos. Sin embargo, mi punto es que para mejorar el proceso, debe identificar sus procesos. CMMI es una herramienta única para hacer precisamente eso. Hay otros por ahí, y puedes definir el tuyo. Una vez que tenga procesos, puede definirlos, medirlos y mejorarlos.
Thomas Owens
1
@Kevin: "Las aplicaciones asesinas" están por su naturaleza "fuera de la corriente principal". Por lo tanto, no sería sorprendente que la mayor parte del trabajo nuevo e innovador fuera creado por la experimentación y la piratería más que por algún proceso disciplinado. Aunque, "aplicación asesina" depende de la definición de uno. Es una aplicación que se convierte en una moda realmente una "aplicación asesina" o es el programa DoD que permite a los Jet Fighters volar con seguridad y evitar que disparen a sus aliados más que una "aplicación asesina". Las modas de moda con frecuencia no requieren habilidad / innovación (por ejemplo, pet rock, hula-hoop) ......
Dunk
... incluidos muchos programas de aplicación "de moda" realmente populares. Mientras que los grandes proyectos tipo DoD casi siempre requieren una gran cantidad de habilidad y proceso. Además, su punto de vista sobre el fracaso de CMMI probablemente diga más sobre su experiencia (o falta de ella) en industrias que usan CMMI que el propio CMMI. CMMI no es perfecto, y probablemente ni siquiera es bueno, pero como mínimo hace que las empresas al menos intenten escribir y seguir un proceso e incluso intentar mejorarlo. Si eso es todo lo que CMMI logra, entonces es un éxito.
Dunk
5

Creo que la idea de que otras disciplinas de ingeniería no hacen uso de la reutilización es incorrecta. Incluso al diseñar edificios / máquinas, todavía tiene componentes que son utilizados por muchos otros proyectos. Por ejemplo, ¿diseñas tus propios tornillos? Motores? Puertas o ventanas? Por supuesto no. Esos a menudo están diseñados por diferentes personas que luego los usan en diferentes productos. Y a menudo están estandarizados, lo que promueve aún más la reutilización.

Creo que el problema le gusta en complejidad. Simplemente no puede comparar la complejidad de incluso los edificios más complejos con el software complejo. Es una idea generalmente aceptada que la complejidad del software es lo que dificulta el acercamiento desde el lado de la ingeniería. En el momento en que tiene un proceso establecido que le permite crear software de calidad aceptable, descubre que la complejidad del software que necesita para crear saltos en orden de magnitud. Entonces el proceso no puede ser utilizado. Entonces, si tuviéramos que repetir alguna parte del software varias veces hasta que estemos satisfechos con el resultado, nunca terminaríamos ese software.

Por eso se promueve el código limpio. Se puede decir que la capacidad de cambiar el código pasado en base a nuevas experiencias es una forma de reutilización del diseño. Entonces, en lugar de crear diferentes softwares varias veces, refactorizamos y refinamos una sola pieza de software reutilizando nuevas experiencias y diseños sobre viejos problemas. Todo mientras intenta que el software haga lo mismo.

Eufórico
fuente
No es que otras disciplinas no reutilicen el diseño, la diferencia es la cantidad de reutilización. Todos los objetos que mencionaste tienen que ser construidos físicamente para cada instanciación. No puedo simplemente copiar y pegar una puerta, por ejemplo. La repetición que proviene de la construcción conduce a identificar eficiencias y mejoras que no son obvias al inicio. Construya un conjunto de gabinetes de cocina y habrá descubierto cosas nuevas entre el primero y el último. Usted tiene un punto con la complejidad general, ya que la naturaleza virtual del software nos permite acumular complejidad sin saberlo.
1
@ GlenH7 La cuestión es que el desarrollo de software no se está construyendo. Su diseño Con la construcción de cosas, estás haciendo lo mismo una y otra vez. Pero con el diseño, siempre tienes diferentes objetivos y problemas. No debe compararlo con la construcción de un edificio, sino con la creación de su plan.
Eufórico el
2
No estoy seguro de estar totalmente de acuerdo con su punto sobre el desarrollo de software. El desarrollo de SW es ​​tanto de diseño como de construcción. La construcción debe proporcionar un circuito de retroalimentación al diseño. Tanto en el ámbito analógico como en el digital, los buenos arquitectos "se ensucian las manos" y construyen para completar el ciclo de retroalimentación. Incluso si nos centramos solo en el diseño, creo que la repetición del diseño identifica eficiencias que conducen a un mejor diseño. SW no se repite como lo hacen otros campos. Cada puente requiere modificación de un enfoque general que se adapta al sitio al que se dirige.
SW dev no es tan complejo en comparación con el diseño que el arquitecto elaboraría. Es solo que pensamos que es difícil porque no tratamos el software como una disciplina de ingeniería adecuada y porque seguimos reinventando cosas. Si solo supieras lo que entró en el diseño de otras cosas, verías que la mayoría del software debería ser trivial, pero nos lo ponemos difícil :(
gbjbaanb
Para comparar con el puente, tiene razón, los puentes son un problema resuelto. Desea un nuevo puente, desempolva los diseños antiguos y realiza algunos ajustes y tiene un nuevo puente (exagero la simplicidad aquí, por supuesto). Entonces, ¿por qué un servicio web no está construido de manera similar en el software? Es por eso que el software no es ingeniería en mi humilde opinión, lo tratamos más como un oficio (o arte) donde cada proyecto es un trabajo personalizado.
gbjbaanb
2

El software es diferente a la mayoría de las otras disciplinas, por lo que la economía de dónde mejor pasamos nuestro tiempo a menudo es diferente.

En construcción, gastas una cierta cantidad de tiempo y dinero en un plano (y el software es mucho más parecido a producir un plano que como construir un edificio), luego, en términos generales, mucho más en construirlo una o más veces. Por lo tanto, vale la pena dedicar mucho trabajo a obtener el plan correcto. Más específicamente a su pregunta: vale la pena repetir el esfuerzo de hacerlo desde cero para mejorar un poco el producto final.

En el software, cuando tiene el modelo, es mucho más barato construir el producto que crearlo. Al menos la mayor parte del tiempo: si el software se incrustará en un marcapasos, estará mucho más cerca de la situación de un constructor de puentes de alguna manera. Pero, en general, la reutilización del software puede ahorrar el 90% del costo de su partida presupuestaria más grande, frente a ahorrar el 90% de una partida presupuestaria mucho más pequeña para construir un puente. Por lo tanto, la reutilización gana mucho más a menudo.

En cuanto a la productividad: cuando construyes, por ejemplo, un puente, te enfrentas a restricciones realmente importantes del mundo real. Imagínese si a los arquitectos se les pagara grandes sumas de dinero para diseñar puentes para juegos multijugador masivos en línea, donde los costos de construcción estuvieran cerca de 0 y la limitación fuera significativamente menor que en el mundo real. Diseñarían puentes que son extrañamente complejos para los estándares de puentes del mundo real. La fase del plan podría llevar un poco más de tiempo.

Además, hay un número limitado de puentes para construir y, dado que el diseño es una parte pequeña del costo, puede pagar por lo mejor, y algunos de los mejores pueden hacer la mayor parte del diseño. Hay cientos de miles de desarrolladores de software y, básicamente, todos ellos tienen una enorme acumulación de cosas que harían si tuvieran tiempo. No vas a encontrar a un chico que haga una gran parte de todo eso; es sorprendente que haya personas que realmente se acerquen.

Su punto real parece ser que podemos estar perdiendo algo al reutilizarlo en lugar de intentar repetirlo y mejorarlo. Creo que tienes un punto. El problema es que, aunque probablemente sería más eficiente a nivel mundial reescribir algunas de las cosas fundamentales y tratar de mejorarlas, quien sea que se haga cargo de ellas asumirá todo el riesgo y probablemente no tanta recompensa. (También existe un gran problema práctico del infierno de la dependencia, que probablemente le quite parte de la victoria al reescribir las cosas, pero no hasta el punto de que no valga la pena, al menos mirando la imagen global. Los derechos de autor y las patentes también pueden forzar un esfuerzo de reingeniería propuesto, hacer un poco de trabajo de reescritura para rehacer piezas más pequeñas de código existente).

En términos de aprendizaje a partir de la repetición - en todas las disciplinas esto ocurre menos en el diseño de la construcción, debido a que es menos repetición, por lo menos la oportunidad de aprender, y tal vez menos beneficios. Además, el proceso de diseño probablemente no sea tan repetible. Es un poco como tener un proceso para escribir una novela. Es casi seguro que un buen proceso puede ayudar, y el software generalmente es mucho más colaborativo que una novela, pero repetir un proceso cuando el objetivo es inventar algo nuevo es problemático. Incluso los novelistas aprenden mucho del pasado, pero un proceso repetible es un factor secundario para los esfuerzos creativos. Y si alguna parte del desarrollo de software es realmente repetible, ¿por qué no lo hace una computadora?

psr
fuente
2

¿La capacidad del software para ser reutilizado impide la mejora y eficiencia del proceso necesarias que se obtienen al repetir un proyecto?

He trabajado como ingeniero de sistemas y software en el mismo gran proyecto durante los últimos 17 años, por cierto (pensando en la referencia del Airbus A380 en su primer enlace) en la industria aeronáutica, aunque mis responsabilidades recaen en el sector de la aviación militar. Historias como esa son básicamente pura ficción, y en realidad son muy divertidas de ver cuando tienes información privilegiada.

Pero para su breve y concisa pregunta: desde mi experiencia, diría que sí y no.

Permítanme decir primero que estoy a favor del reciclaje de software en todas sus formas (bueno, tal vez no todas ...). Las ventajas de reutilizar casi cualquier cosa, desde cortar y pegar fragmentos de código y algoritmos, hasta módulos de código completos y bibliotecas de funciones, en general son mucho mejores que comenzar siempre desde el principio nuevamente (para empujarlo un poco).

La desventaja es, como señala (o al menos infiere), que cuando agrega funcionalidad simplemente reuniendo un conjunto dado de componentes (y, sí, estoy simplificando esto al extremo), realmente no evoluciona como un programador, ingeniero o lo que sea.

Solo mirando a los ingenieros de software que me rodean en el trabajo, sé por una larga experiencia que la mayoría de ellos no lo saben, y lo que es peor: no tienen interés en aprender, nada sobre el producto que estamos construyendo, aparte del mínimo que necesitan para producir el documento o el fragmento de código que se les asignó hacer.

Me estoy desviando un poco del tema aquí, pero mi punto es que cuando los programadores no necesiten aprender para qué se utilizará realmente el código que están construyendo, y no necesitan aprender el funcionamiento interno del sistema, ya que pueden reutilice los componentes ya escritos y probados, entonces la mayoría de ellos simplemente no se molestarán en hacerlo.

De acuerdo, esto también se debe a otras circunstancias, como que el producto que estamos construyendo es increíblemente complejo, y sería imposible que una persona se enterase de todo (y solo estoy hablando de una de las computadoras en el avión, el más complejo de ellos, pero aún así).

Si nuestros ingenieros de software no tuvieran la opción de reutilizar la mayor cantidad de código, estoy convencido de que mejorarían en su profesión en general, y de activos mucho mayores para el proyecto específicamente.

Ah, y es posible que hayas notado que hablo mucho de ellos aquí. Por supuesto, también estoy incluido entre estos ingenieros de software. La excepción es que parezco mucho más curioso y ansioso por aprender cosas nuevas que los demás :-) Cuando me enfrento a una nueva tarea, siempre me encargo de aprender todo lo que pueda, tanto en el forma de hechos y estudiando el código fuente (sí, realmente disfruto eso también).

Ah, maldición, volví a desviarme ... Mi excusa es que no he dormido durante 32 horas, así que mi capacidad de enfoque es un poco ... ¿qué estaba diciendo?

Si alguien sigue leyendo, mi conclusión es que:

, la reutilización excesiva de software hace que los ingenieros de software tengan menos conocimientos, lo que los hace notablemente menos eficientes cuando realmente necesitan saber cómo funcionan las cosas. El análisis de problemas es un buen ejemplo, o incluso solo es capaz de saber si una solución de diseño sugerida es viable. Y, por supuesto, la mejora del proceso también es más difícil de lograr cuando realmente no sabes lo que estás haciendo :-)

y No , reutilizar el software con cuidado puede darle mucho tiempo libre para considerar y planificar mejoras en el proceso.

Boise
fuente
¿No es el hecho de que la mayoría de los desarrolladores de sw pueden pasar sin conocer el funcionamiento interno del sistema como un fuerte indicador de una reutilización extensa? También me parece curioso cómo las historias de proyectos del gobierno dan ese sonido simplemente terrible, pero si tuvieras algún conocimiento sobre el trabajo del gobierno, entenderías lo despistado que es el autor. Los martillos de $ 1500, etc. Todos se vuelven comprensibles cuando se reconoce que los procesos del gobierno requirieron que 10 personas revisaran y obtuvieran presupuestos competitivos antes de la compra O simplemente no movía fondos entre los cubos de contabilidad.
Dunk
No me consuela saber que un ingeniero de software que trabaja en el sistema informático "más complejo" de un avión no ha dormido en 32 horas. =)
RubberDuck
2

Como se señala en la respuesta aceptada en otra pregunta de los Programadores, las analogías con la construcción deben tomarse con cuidado:

Una lectura recomendada para esto es La Analogía de la Construcción del Software está rota

El software a menudo se compara con la construcción. Desafortunadamente, esta analogía es defectuosa y las lecciones aprendidas de la industria de la construcción son sospechosas ...

Lo que observé es que los buenos proyectos de software "cambian" mucha repetibilidad en garantía de calidad.

Cuando era un probador en un proyecto de 1,5 años, realizamos ciclos de prueba en lanzamientos semanales de "puntos de control", aproximadamente 70 veces en total durante el proyecto. Eso fue ... bastante repetible, en voz baja (no cambian muchas cosas en una semana). Probar las compilaciones nocturnas ha sido, naturalmente, aún más repetible: aproximadamente 500 veces a través del proyecto (pocos errores entretenidos eran demasiado raros para hacer la diferencia).

Ahora, siguiendo esa analogía "sospechosa", dígame una empresa constructora que ha construido 500 puentes, todos con el mismo equipo.

  • Siguiéndolo más, dígame una compañía que ha estado utilizando principalmente los mismos ladrillos y hierro en cada uno de sus nuevos puentes (aquí, me refiero al hecho de que las versiones que probamos tenían en su mayoría los mismos fragmentos de código día a día, semana tras semana - "no cambian muchas cosas").
    http://upload.wikimedia.org/wikipedia/commons/thumb/0/0c/GoldenGateBridge-001.jpg/220px-GoldenGateBridge-001.jpg http://upload.wikimedia.org/wikipedia/commons/thumb/5/52/Ponte25Abril1.jpg/220px-Ponte25Abril1.jpg

Los maestros constructores son expertos reconocidos por haber diseñado y / o construido decenas, cientos o miles de cosas en su área.

Bien, siguiendo su explicación de repetibilidad citada anteriormente, puedo decir ¿y qué? En aquel entonces, nuestro pequeño grupo de evaluadores no muy especial ha verificado, ver arriba ("aproximadamente 500") cientos de cosas en nuestra área.

En cuanto a los desarrolladores de proyectos, literalmente han construido ("compilaciones nocturnas"). Vea, la palabra es la misma y el significado es correcto en este contexto: cientos de cosas en su área.

Si se quiere continuar con esa analogía "sospechosa" más allá de "miles de cosas", estas cantidades son, nuevamente, nada espectacular en el desarrollo de software cuando se miran las cosas correctas.

  • Como ejemplo, otro de mis proyectos pasados ​​(una vez más, nada espectacular, más bien regular), esta vez en el rol de desarrollador, ha estado en marcha durante más de 5 años (8 lanzamientos principales, varias docenas menores). Hubo puntos 5x52~=250de control semanales similares ( de ellos), lanzamientos nocturnos similares ( 5x365~=1800de ellos) y del mismo modo, los mismos equipos de desarrollo / control de calidad que trabajan en estos. Día a día, semana a semana, mes a mes, principalmente cosas repetitivas (no hay muchos cambios entre dos versiones nocturnas), como se prometió, en el rango de miles de veces (1800).

Los proyectos más longevos como Windows o Java, o AutoCAD pueden abarcar 10, 20, 30 años, lo que explica fácilmente la repetición de tantas "miles" de compilaciones y pruebas nocturnas como sea posible.


El concepto de cambio de repetibilidad a QA se vuelve aún más prominente con la integración continua ...

la práctica ... de fusionar todas las copias de trabajo del desarrollador con una línea principal compartida varias veces al día ... CI puede verse como una intensificación de las prácticas de integración periódica ...

Además de las pruebas unitarias automatizadas, las organizaciones que usan CI generalmente usan un servidor de compilación para implementar procesos continuos de aplicación de control de calidad en general: pequeños esfuerzos, aplicados con frecuencia. Además de ejecutar la unidad y las pruebas de integración, dichos procesos ejecutan pruebas estáticas y dinámicas adicionales, miden y perfilan el rendimiento, extraen y formatean la documentación del código fuente y facilitan los procesos manuales de control de calidad. Esta aplicación continua de control de calidad tiene como objetivo mejorar la calidad del software y reducir el tiempo necesario para entregarlo, al reemplazar la práctica tradicional de aplicar el control de calidad después decompletando todo el desarrollo. Esto es muy similar a la idea original de integrar con mayor frecuencia para facilitar la integración, solo se aplica a los procesos de control de calidad ...

Repetibilidad está ahí, tanto como se pueda imaginar.

Con un control de calidad frecuente / continuo, las cosas que salen mal vuelven rápidamente a los desarrolladores que se ven obligados a repetir los intentos de hacerlo bien hasta que las pruebas que no pasan satisfactoriamente pasen. En cierto sentido, ese ciclo de repetición hasta que pasa se asemeja al código cata ,

un ejercicio de programación que ayuda a un programador a perfeccionar sus habilidades a través de la práctica y la repetición ...

mosquito
fuente
1
Excelentes puntos, y creo que los escapes que luego se volvieron al paquete de pruebas automatizadas capturan parte de la experiencia a la que me refiero. Con respecto a las afirmaciones del "mismo equipo", aplazo la experiencia de Wright. Con más de 500 edificios construidos, fue un elemento común para todos ellos. Pero el punto está hecho, y estoy de acuerdo con algunas de las premisas.
@ GlenH7 sí, el impacto de la repetición ha sido realmente profundo y fue mucho más allá de las suites de prueba. El conocimiento se acumuló en todas partes donde sucedió la repetición; ya sabes, todo tiende a establecerse de manera óptima después de 20 ... 30 ... 50 veces hacerlo. Punto de control / preparaciones nocturnas, presentación de errores (y toda la "vida del error" en absoluto), comunicación de dev / QA / mgmt / sysadmins, documentación de cosas, etc. tener un efecto firehose al presentar mi punto
mosquito
-1

Algo de lo que usted dice es cierto: por ejemplo, las bibliotecas resuelven funciones no resueltas por lenguajes de alto nivel que resuelven problemas no resueltos por ensamblaje que resuelven problemas no resueltos por código máquina. Cuando llama a System.out.println () en java, está perdiendo de vista cómo sale una CPU a un dispositivo.

Entonces sí, estás perdiendo algo. Lo que gana es la capacidad de concentrarse en problemas no resueltos. Ahora puede ser que necesite sumergirse en otros aspectos de la tecnología (por ejemplo, cómo funcionan las redes) para resolver un problema. Pero no necesita convertirse en un experto en lectura de lenguaje de máquina cuando todo lo que quiere hacer es crear una página web.

Del mismo modo, los constructores de puentes están resolviendo un problema ligeramente diferente cada vez (es un río diferente). No se preocupan por cómo crear vigas de acero de cierta resistencia a la tracción, o cómo mecanizar tornillos con una cierta tolerancia. Se lo dejan a los especialistas que han resuelto ese problema.

Mire de cerca y verá que toda nuestra sociedad e infraestructura están construidas en un 99% de reutilización y solo en un 1% de progreso real. La mayoría de las cosas nuevas son solo cosas viejas con un poco de algo extra agregado o eliminado. Es la acumulación de conocimiento humano. Puede escribir código en un lenguaje de alto nivel con bibliotecas decentes porque alguien descubrió todas las cosas increíblemente complicadas necesarias para llegar a este punto. Te permite resolver problemas nuevos e interesantes.

Para unir todo esto y responder a los comentarios: no es necesario resolver los problemas que ya se han resuelto para desarrollar la competencia. Además, gran parte de lo que hagas será reinventar la rueda. En resumen, la respuesta es no: no es necesario volver a implementar las funciones de las bibliotecas para dominarlas. Hay muchas oportunidades, algunas de memoria, otras creativas para perfeccionar tu oficio.

Amot
fuente
1
Creo que toca algunos puntos potencialmente válidos, pero no veo que se unan para responder la pregunta. Y no estoy de acuerdo con su relación 99: 1 para la reutilización. Creo que sobreestima enormemente la cantidad de reutilización que se produce. Incluso dentro del desarrollador de software, las tasas de reutilización no están tan cerca.
-2

Se trata de recursos. Hace años, si desarrollaba proyectos de software para computadoras mainframe grandes, podrían existir durante aproximadamente 15 años con un entorno de desarrollo estático. El programa FORTRAN escrito para calcular la nómina o el programa COBOL se perfeccionó durante décadas porque se usaba constantemente. Había recursos para ver cómo esto podría mejorarse. Ya no tenemos ese tipo de ambiente lento para afinar y pulir las habilidades para un proyecto específico. Pero tomamos las habilidades y las adaptamos a los recursos del próximo proyecto que lo permitan. Pero al final se convierte en una opción de dinero gastado en el nuevo proyecto para hacer el trabajo, o para hacer el nuevo trabajo con una gran cantidad de chapado en oro. Un proyecto chapado en oro significa mejorarlo en el enésimo grado y agregar un montón de campanas y silbatos, incluso si el usuario no

Lo mejor que podemos hacer es mirar el diseño general de un nuevo proyecto y ver cómo se puede mejorar en función de la experiencia pasada del equipo. Pero se necesita una experiencia real del arquitecto de software para tener una visión sobre lo que realmente se considera mejorar el diseño para mejorar las habilidades en lugar de simplemente presentar la última palabra de moda en desarrollo, como Agile, OOP, etc.

Eduardo
fuente
3
Entiendo algunos de los puntos que está tratando de hacer, pero se basan en la presunción y la falta de familiaridad. Solía ​​desarrollar para mainframes, y puedo asegurarle que la tasa de desarrollo fue tan rápida como en los sistemas abiertos. El proceso fue diferente, pero el ritmo fue el mismo. Su respuesta sería más fuerte al enfocarse en el componente de habilidades transferibles y exponer las posibles eficiencias obtenidas de esa manera.
Debe mirar la historia, no había nuevas tecnologías que salieran cada año más o menos en los sistemas mainframes para CDC 6600 Kronos OS, por ejemplo. Básicamente fue estático durante 15 años. Ahora las cosas se mueven mucho más rápido y no hay tiempo para adquirir el conocimiento profundo durante 15 años. No hay programadores de Flash con 15 años de experiencia simplemente haciendo Flash, por ejemplo. Después de volver a leer mi publicación, mantengo mi publicación original.
Edward