¿Cómo ser un programador de cero errores? [cerrado]

Mi jefe siempre me ha dicho que un buen programador debería poder asegurarse de que el código que cambia sea confiable, correcto y completamente autoverificado; que debe comprender completamente todos los resultados e impactos que causarán sus cambios. He hecho todo lo posible para ser este tipo de programador, probando una y otra vez, pero los errores siguen ahí.

¿Cómo puedo ser un programador de cero errores y saber qué causará y afectará cada carácter de mi código?

No codifique en absoluto.

Esa es la única forma en que puedes ser un programador de cero errores.

Los errores son inevitables porque los programadores son humanos, todo lo que podemos hacer es hacer todo lo posible para evitarlos, reaccionar rápidamente cuando se produce un error, aprender de nuestros errores y estar al día.

Cero errores es imposible para un programa no trivial.

Es posible acercarse mucho, pero la productividad sufre. Y solo vale la pena para cierto software de alto riesgo. El software del transbordador espacial me viene a la mente. Pero su productividad es del orden de unas pocas líneas al día. Dudo que tu jefe quiera eso.

Este software está libre de errores. Es perfecto, tan perfecto como lo han logrado los seres humanos. Considere estas estadísticas: las últimas tres versiones del programa, cada una de 420,000 líneas de largo, tuvieron solo un error cada una. Las últimas 11 versiones de este software tuvieron un total de 17 errores.

Aproveche la actualización del software para permitir que el transbordador navegue con satélites de posicionamiento global, un cambio que involucra solo el 1.5% del programa, o 6,366 líneas de código. Las especificaciones para ese cambio abarcan 2.500 páginas, un volumen más grueso que una guía telefónica. Las especificaciones para el programa actual llenan 30 volúmenes y corren 40,000 páginas.

"Zero-bug programmer" es un oxímoron, como un cantante silencioso, pero en los últimos 60 años de programación ha producido algunos fragmentos de sabiduría destilada, que lo harán un mejor programador, como:

• Sé humilde: estás y estarás cometiendo errores. Repetidamente.
• Tenga en cuenta el tamaño limitado de su cráneo. Enfoque la tarea con total humildad y evite trucos inteligentes como la peste. [Edsger Dijkstra]
• Lucha contra la explosión combinatoria
• Deshágase del estado mutable (siempre que sea posible). Sí, aprende programación funcional.
• Reduce el número de posibles rutas de código
• Comprenda (la magnitud de) el tamaño de los espacios de entrada y salida (de sus funciones) e intente reducirlos para acercarse aún más al 100% de cobertura de prueba
• Siempre asuma que su código no funciona, ¡demuestre lo contrario!

TDD

El punto de TDD es que no escribe una sola línea de código si no hay una prueba que requiera esa línea de código. Y para llevarlo al extremo, siempre comienza a desarrollar una nueva característica escribiendo una prueba de aceptación. Aquí he descubierto que escribir pruebas de estilo de pepino es ideal.

El enfoque TDD ofrece al menos dos beneficios.

• Todo el código está escrito para resolver una característica específica, por lo tanto, no hay sobreproducción innecesaria.
• Cada vez que cambie una línea de código existente, si rompe una característica, se le notificará

No prueba cero errores, ya que eso sería imposible (ya han sido señalados por innumerables otras respuestas). Pero después de haber aprendido TDD y ser bueno en eso (sí, también es una habilidad que necesita práctica), tengo una confianza mucho mayor en mi propio código porque está completamente probado. Y lo que es más importante, puedo cambiar el código existente que no entiendo completamente sin preocuparme por romper la funcionalidad.

Pero TDD no te ayuda en todo momento. No puede escribir código libre de errores si no comprende completamente la arquitectura del sistema y las trampas de esa arquitectura. Por ejemplo, si está escribiendo una aplicación web que maneja múltiples solicitudes simultáneamente, debe saber que no puede compartir datos mutables entre múltiples solicitudes (no caiga en la trampa del novato para almacenar en caché los datos mutables para mejorar el rendimiento).

Creo que los equipos de desarrollo que son buenos en TDD entregan el código con la menor cantidad de defectos.

La cuestión es que los errores son las cosas que no reconoces. A menos que tenga algún tipo de conocimiento enciclopédico del lenguaje / compilador de programación, así como de todos los entornos en los que se ejecutará su aplicación, realmente no puede esperar producir código 100% libre de errores.

Puede reducir su recuento de errores a través de muchas pruebas, pero al final probablemente habrá algún caso marginal que no se tendrá en cuenta. Joel Spolsky escribió un artículo particularmente bueno sobre la corrección de errores .

Sí, es imposible nunca tener un error en su código, pero no es imposible tener menos errores. La actitud de que "Eso es tonto, siempre tendrás errores" es solo una trampa para evitar reducir la cantidad de errores en tu código. Nadie es perfecto, pero podemos y debemos esforzarnos por ser mejores. En mis propios esfuerzos por mejorar, he encontrado útiles los siguientes puntos.

• Esto no es facil. No mejorarás durante la noche. Así que no te desanimes y no te rindas.
• Escribe menos y escribe de manera más inteligente. Menos código suele ser mejor código. Es natural querer planificar con anticipación e intentar crear patrones de diseño impresionantes, pero a la larga, escribir lo que necesita ahorra tiempo y evita errores.
• La complejidad es el enemigo. Menos no cuenta si es un desastre complicado y oscuro. El golf de código es divertido, pero es un infierno de entender y un infierno peor de depurar. Cada vez que escribes un código complicado, te abres a un mundo de problemas. Mantenga las cosas simples y cortas.
• La complejidad es subjetiva. El código que alguna vez fue complicado se vuelve simple una vez que te conviertes en un mejor programador.
• La experiencia importa. Una de las dos formas de convertirse en un mejor programador es practicar. La práctica NO es escribir programas que sabes cómo escribir con facilidad, es escribir programas que duelen un poco y te hacen pensar.
• La otra forma de mejorar es leer. Hay muchos temas difíciles en la programación para aprender, pero nunca podrás aprenderlos solo con la programación, debes estudiarlos. Necesitas leer las cosas difíciles. Cosas como la seguridad y la concurrencia son imposibles: aprende correctamente simplemente escribiendo código a menos que desee aprender limpiando desastres. Si no me cree, mire los sitios épicos de seguridad que tuvo Gawker. Si se tomaran el tiempo para aprender cómo hacer la seguridad correctamente y no solo hacer algo que funcionó, ese desastre nunca hubiera sucedido.
• Leer blogs Hay un montón de blogs interesantes que te darán formas nuevas e interesantes de mirar y pensar sobre la programación, esto te ayudará a ...
• Aprende los detalles sucios. Los detalles menores de cuán oscuras partes de su idioma y aplicación funcionan son muy importantes. Podrían contener secretos que lo ayudan a evitar escribir código complicado o podrían ser partes que tienen sus propios errores que debe evitar.
• Aprende cómo piensan los usuarios. A veces, sus usuarios están completamente locos y trabajarán con su aplicación de formas que usted no comprende y no puede predecir. Debes meterte en la cabeza lo suficiente como para saber las cosas más extrañas que podrían intentar y asegurarte de que tu aplicación pueda manejarlo.

Personalmente, creo que luchar por una programación libre de errores parece ser más costoso (tanto en tiempo como en dinero). Para alcanzar un error cero, o incluso un error cercano a cero, debe hacer que los desarrolladores prueben a fondo. Esto significa una prueba de regresión antes de enviar cualquier código para revisión de parche. Este modelo no me parece rentable. Es mejor que los desarrolladores realicen las pruebas de diligencia debida y dejen las pruebas en profundidad al equipo de control de calidad. Aquí es por qué:

• Los desarrolladores apestan en las pruebas. Es verdad y lo sabes. (¡Soy un desarrollador!) Un buen equipo de control de calidad siempre encontrará los casos límite en los que los desarrolladores nunca piensan.
• Los desarrolladores son buenos en la codificación. Permítales volver a lo que destacan (y generalmente lo que prefieren hacer de todos modos).
• El equipo de control de calidad puede encontrar errores relacionados con múltiples tareas de desarrollador en una sola pasada.

Acepte que cuando escriba código, habrá errores registrados en él. Es por eso que tiene un proceso de control de calidad, y todo es parte de ser un desarrollador. Por supuesto, esto no significa que envíe algo tan pronto como escriba su último punto y coma. Todavía necesita garantizar la calidad en su trabajo, pero puede exagerar.

¿Cuántas profesiones puede nombrar que siempre hagan bien su tarea la primera vez sin una revisión o prueba por pares?

Cero errores? Parece que necesita Lisp (siga el camino escéptico y evite el video musical).

Es extraordinariamente difícil lograr un código libre de errores en los entornos de codificación convencionales (Java, C #, PHP, etc.). Me enfocaría en producir código bien probado y revisado por pares en iteraciones controladas cortas.

Mantener el código lo más simple posible le ayudará a evitar errores.

Asegúrese de estar utilizando herramientas de análisis de código (como FindBugs , PMD , etc.) que, combinadas con estrictas advertencias del compilador, revelarán todo tipo de problemas con su código. Tome nota de lo que le están diciendo, realmente trate de comprender cuál es la naturaleza del error y luego tome medidas para cambiar su idioma de programación de modo que no sea natural codificar de una manera que vuelva a introducir ese error.

Todo el "No codifique en absoluto". las respuestas están perdiendo completamente el punto. Además, ¡tu jefe definitivamente no parece ser un imbécil!

No recuerdo con qué frecuencia he visto programadores que simplemente no sabían lo que hace su código. Su única filosofía de desarrollo parecía ser prueba y error (y muy a menudo también copiar / pegar / modificar). Si bien el método de prueba y error es una forma válida de solucionar algunos problemas, a menudo puede analizar el dominio del problema y luego aplicar una solución muy específica basada en su comprensión de las herramientas que utiliza y con un poco de disciplina y diligencia que no tendrá solo resolvió el problema, pero también la mayoría de los casos de esquina (errores potenciales) antes de implementarlo por primera vez. ¿Pueden garantizar que el código esté libre de errores? Por supuesto no. Pero con cada error que encuentre o lea, puede agregarlo a las cosas en las que quiera pensar la próxima vez que escriba / cambie algo. Si hace esto, en consecuencia obtendrá mucha experiencia sobre cómo escribir código que esté casi libre de errores. - Hay toneladas de recursos disponibles sobre cómo convertirse en un mejor programador que puede ayudarlo en el viaje ...

Personalmente, nunca cometería código donde no puedo explicar cada línea. Cada línea tiene una razón para estar allí, de lo contrario, debe eliminarse. Por supuesto, a veces hará suposiciones sobre el funcionamiento interno de los métodos que llama, de lo contrario necesitaría conocer la lógica interna de todo el marco.

Su jefe tiene toda la razón al decir que debe comprender los resultados y el impacto del código que escribe en el sistema existente. ¿Ocurrirán errores? Sí, por supuesto. Pero estos errores se deben a su comprensión incompleta del sistema / herramientas con las que trabaja y con cada corrección de errores tendrá una mejor cobertura.

Como los otros comentarios ya señalaron correctamente, no hay software no trivial sin errores.

Si desea probar el software, tenga siempre en cuenta que las pruebas solo pueden probar la presencia de errores, no su ausencia.

Dependiendo de su dominio de trabajo, puede intentar la verificación formal de su software. Usando métodos formales puede estar bastante seguro de que su software cumple exactamente con las especificaciones.

Eso por supuesto no significa que el software hace exactamente lo que quieres. Escribir una especificación completa en casi todos los casos tampoco es posible. Básicamente cambia el lugar donde pueden ocurrir errores desde la implementación hasta la especificación.

Entonces, dependiendo de su definición de "errores", puede intentar la verificación formal o simplemente tratar de encontrar tantos errores como pueda en su software.

O no escribas nada más complicado que "¡Hola Mundo!" o si le dice a todos que nunca lo usen.

Pídale a su jefe algunos ejemplos de este llamado código libre de errores.

Estoy de acuerdo con los otros. Así es como abordaría el problema

• Consigue un probador. Vea la prueba de Joel para saber por qué.
• Use bibliotecas ampliamente; Probablemente se hayan depurado mejor. Soy un gran admirador de CPAN para Perl.

Puedes esforzarte por ser un programador de cero errores. Me esfuerzo por ser un programador de cero errores cada vez que escribo código. Sin embargo no

• participar en múltiples técnicas de prueba (que no sean ATDD)
• crear verificaciones formales de nuestro software
• tener un equipo de control de calidad separado
• hacer un análisis exhaustivo de cada cambio realizado en la base del código
• usa un lenguaje que se inclina más hacia la seguridad y la precaución

No hago estas cosas porque tienen un costo prohibitivo para el software que escribo. Si hiciera estas cosas, probablemente estaría más lejos hacia cero errores, pero no tendría sentido comercial.

Creo herramientas internas que utilizan gran parte de nuestra infraestructura. Mis estándares para pruebas y codificación son altos. Sin embargo, hay un equilibrio. No espero errores cero porque no puedo permitir que la gente ponga ese tipo de tiempo en una sola pieza de trabajo. Las cosas podrían ser diferentes si estuviera creando el software para controlar una máquina de rayos X, motores a reacción, etc. No hay vidas en juego si mi software falla, por lo que no nos comprometemos con ese nivel de seguridad.

Yo igualaría el nivel de seguridad con el uso previsto del software. Si está escribiendo un código que el transbordador de la NASA utilizará, tal vez sea cero la tolerancia a errores. Solo necesita agregar un montón de prácticas adicionales y muy costosas.

Creo que un buen primer paso para convertirse en un programador de "cero errores" es cambiar su actitud hacia los errores. En lugar de decir cosas "suceden", "obtener un mejor control de calidad y evaluadores", o "los desarrolladores apestan en las pruebas", dicen:

Los errores no son aceptables, y haré todo lo que esté a mi alcance para eliminarlos.

Una vez que esto se convierta en su actitud, los errores caerán rápidamente. En su búsqueda para encontrar formas de eliminar errores, se encontrará con un desarrollo basado en pruebas. Encontrarás muchos libros, publicaciones de blog y personas que ofrecen consejos gratuitos sobre mejores técnicas. Verás la importancia de mejorar tus habilidades a través de la práctica (como codificar katas o probar cosas nuevas en casa). Comenzará a desempeñarse mejor en el trabajo porque comenzará a trabajar en su oficio en casa. Y, con suerte, una vez que vea que es posible escribir un buen software, su pasión por su oficio crecerá.

En cierto sentido, tu jefe tiene razón. Es posible escribir software que se acerque a cero errores.

Pero el problema es que el costo de escribir (casi) programas sin errores es prohibitivamente alto . Necesitas hacer cosas como:

• Use especificaciones formales de sus requisitos. Formal, como en el uso de Z o VDM o alguna otra notación matemáticamente sólida.

• Use técnicas de prueba de teoremas para demostrar formalmente que su programa implementa la especificación.

• Cree amplios conjuntos de pruebas de unidad, regresión y sistema y arneses para probar cualquier forma de errores. (Y esto no es suficiente en sí mismo).

• Haga que muchas personas revisen los requisitos (formales e informales), el software (y las pruebas). pruebas e implementaciones.

Es extremadamente improbable que su jefe esté preparado para pagar todo esto ... o que aguante el tiempo que lleva hacerlo todo.

He alcanzado el estado de "error cero". Les digo a mis usuarios que es una característica no documentada, o están pidiendo una nueva característica y, por lo tanto, es una mejora. Si ninguna de estas respuestas son aceptadas, simplemente les digo que no han entendido sus propios requisitos. Por lo tanto, no hay errores. Los programadores son perfectos.

Estos son los pasos para hacer un programa libre de errores:

1. Nunca comience a codificar a menos que tenga ESPECIFICACIONES UNAMBIGUAS para su funcionalidad.
2. NO PRUEBE o, si lo hace, NO CONFÍE EN LAS PRUEBAS para detectar defectos en el software.
3. Aplique todos los comentarios de los defectos descubiertos durante las pruebas, revisiones y producción a un proceso y desarrolladores que insertaron defectos en primer lugar. Deseche todos los componentes defectuosos por completo tan pronto como se encuentren defectos. Actualice sus listas de verificación y vuelva a capacitar a sus desarrolladores para que no vuelvan a cometer errores como ese.

Las pruebas solo pueden probar que tienes errores, pero generalmente es inútil demostrar lo contrario. Con respecto a la retroalimentación: si tiene una máquina de fabricación de monedas que fabrica monedas y cada 10s en promedio tiene un defecto. Puede tomar esa moneda, aplanarla e insertarla nuevamente en la máquina. la moneda que hizo ese blanco reciclado no será tan buena, pero puede ser aceptable. cada moneda de 100s tendrá que volver a estamparse 2 veces y así sucesivamente. ¿Sería más fácil arreglar la máquina?

Lamentablemente, las personas no son máquinas. Para hacer un buen programador libre de defectos, debe invertir mucho tiempo, entrenar e iterar sobre cada defecto realizado. Los desarrolladores deben recibir capacitación en métodos de verificación formales que a menudo son difíciles de aprender y aplicar en la práctica. La economía del desarrollo de software también está trabajando en su contra: ¿invertiría 2 años en capacitar a un programador que puede hacer menos defectos solo para verlo saltar a otro empleador? Puedes comprar máquinas que hagan monedas perfectas o contratar 10 monos de código más para crear muchas pruebas al mismo costo. Puede percibir este exhaustivo proceso como su "máquina", su activo: invertir en una amplia capacitación de excelentes desarrolladores no vale la pena.

Muy pronto aprenderá a desarrollar software de calidad aceptable, pero probablemente nunca será libre de defectos por la simple razón de que no hay mercado para desarrolladores que creen códigos perfectos porque son lentos.

Programa defensivo: http://en.wikipedia.org/wiki/Defensive_programming

Si alguien sigue las convenciones de programación a la defensiva, los cambios serán fácilmente rastreables. Combine esto con informes rigurosos de errores durante el desarrollo y una documentación sólida, como con doxygen, y podrá saber exactamente qué está haciendo todo su código y corregir cualquier error que surja, de manera muy eficiente.

¿Podría ser esto el resultado de una mala interpretación de una buena metodología, y no solo de un genio descabellado?

Lo que quiero decir es que es posible que su jefe haya oído hablar de la "metodología de cero defectos" (consulte la sección n. ° 5) y no se haya molestado en comprender lo que eso significaba.
Por supuesto, es inconveniente para la administración posponer el desarrollo de nuevas características, a favor de errores que no debería haber puesto ...
Y, por supuesto, eso amenaza su bonificación, por lo que no obtendrá uno porque "los buenos programadores no tener errores "...

Está bien crear errores, siempre que pueda encontrarlos y corregirlos (dentro de lo razonable, por supuesto).

Uno de los conceptos fundamentales de las pruebas de software es que NUNCA puedes estar absolutamente seguro de que el programa es perfecto. Puede validarlo para siempre, pero eso nunca prueba que el programa esté completo porque rápidamente no es factible incluso probarlo con todas las combinaciones de entrada / variable.

Tu jefe parece uno de los que "no entiende lo que es tan difícil de programar, ya que solo está escribiendo"

Si asumimos que las grandes casas de software saben cómo obtener desarrolladores de primer nivel (como en el programador de cero errores ) podemos deducir que el software de Microsoft debe estar libre de errores. Sin embargo, sabemos que eso está lejos de la verdad.

Desarrollan su software y cuando alcanzan cierto nivel de errores de baja prioridad, simplemente lanzan el producto y los resuelven más tarde.

A menos que esté desarrollando algo más complejo que una simple calculadora, no es posible evitar los errores por completo. Demonios, incluso la NASA también tiene redundancia en sus vehículos y errores. Aunque tienen pruebas muy rigurosas para evitar fallas catastróficas. Sin embargo, incluso ellos tienen errores en su software.

Los errores son inevitables al igual que errar la naturaleza humana.

No tener errores es como tener un sistema 100% seguro. Si un sistema es 100% seguro, definitivamente ya no es útil (probablemente se encuentre dentro de toneladas y toneladas de concreto y no esté conectado al exterior en absoluto. No está cableado ni inalámbrico. Por lo tanto, al igual que no hay un sistema perfectamente seguro , no hay un sistema complejo sin errores.

Solo veo respuestas sobre nosotros siendo humanos y propensos a errar, lo cual es muy cierto ... pero veo tu pregunta desde otro punto de vista.

Creo que puedes escribir programas libres de errores, pero por lo general son programas que ya has escrito 10 o 12 veces. La 13ª vez que escribe el mismo programa desde cero, ya sabe cómo hacerlo: conoce el problema, conoce las técnicas, conoce las bibliotecas, el idioma ... lo ve en su mente. Todos los patrones están ahí, en todos los niveles.

Esto me sucede con programas muy simples porque enseño programación. Son simples para mí, pero difíciles para los estudiantes. Y no estoy hablando de soluciones a problemas que he hecho muchas, muchas veces en la pizarra. Por supuesto que los conozco. Me refiero a ~ programas de 300 líneas que resuelven algo usando conceptos que conozco muy bien (los conceptos que enseño). Escribo estos programas sin planificación y simplemente funcionan, y siento que conozco todos los detalles, no necesito TDD en absoluto. Recibo un par o tres errores de compilación (principalmente errores tipográficos y otras cosas por el estilo) y eso es todo. Puedo hacer esto para programas pequeños, y también creo que algunas personas pueden hacer eso para programas más complicados. Creo que personas como Linus Torvalds o Daniel J. Bernstein tienen tanta claridad mental que son lo más cerca que se puede estar de un codificador libre de errores. Si tuentiendo las cosas profundamente, creo que puedes hacerlo. Solo puedo hacer esto para programas simples, como dije.

Creo que si siempre intentas hacer programas que están muy por encima de tu nivel (he pasado años haciendo eso), te confundirás y cometerás errores. Grandes errores como aquellos en los que de repente te das cuenta de que tu solución no puede funcionar, cuando finalmente entiendes el problema, y ​​tienes que hacer cambios tan complicados que podrían impedirte resolverlo o hacer que el código sea horrible. TDD es para estos casos, creo. Usted sabe que no entiende el problema que está abordando y, por lo tanto, realiza pruebas en todas partes para asegurarse de tener una base sólida. Sin embargo, TDD no resuelve la visión de 10,000 pies. Puede caminar en círculos con un código perfectamente limpio todo el tiempo.

Sin embargo, si intenta hacer algo que es nuevo, sino que es simplemente por encima de su nivel, es posible obtener su programa perfecto o casi perfecto. Creo que es realmente difícil saber qué programas están en su "frontera del conocimiento", pero en teoría esa es la mejor manera de aprender. Reescribo mucho los programas desde cero. Algunas personas lo hacen, pero necesita mucho tiempo y paciencia porque la tercera vez que repite un programa no trivial no se emociona como la primera vez.

Así que mi consejo es: no creas que entiendes algo hasta que puedas escribir un programa libre de errores solo para esa cosa. Y luego intente combinar dos de esos conceptos que conoce profundamente en el mismo programa. Estoy casi seguro de que lo hará bien la primera vez. Una de las mejores formas es reescribir el software no trivial, algo que requirió mucho esfuerzo la primera vez (estoy haciendo esto con las aplicaciones de Android en este momento). Cada vez que empiezo de nuevo, cambio algo o agrego cosas, solo para agregar un poco de diversión, y puedo decirte que cada vez estoy mejor y mejor ... tal vez no esté libre de errores, pero estoy realmente orgulloso.

Durante el proceso de codificación deben aparecer errores de error y artefactos repentinos y misteriosos del algoritmo : inspiran y fuerzan la evolución del código.
sin embargo, es posible (generalmente después de algunas pruebas) verificar cada variable que se pueda usar antes de la declaración, manejar cada error donde sea que aparezca, hacer que el programa tenga cero errores ... hasta que reciba una solicitud de una característica que se consideró imposible cuando discutías la arquitectura del programa;)

Tal vez piense más sobre la naturaleza de los errores que obtiene. Si los errores son generalmente descuidos menores, entonces sería útil enfocarse en mejores pruebas y un poco de lectura de pruebas de código.

Sin embargo, si los errores tienden a deberse a decisiones de programación subóptimas, tal vez se requiera un mayor esfuerzo para un mejor diseño. En este caso, creo que es posible depender demasiado de las pruebas para aumentar la calidad del software, porque aplicar un parche a un código deficiente puede hacer que el mantenimiento futuro sea más complicado. Por un lado, obtienes menos errores a medida que los encuentras y los reparas, pero por otro lado, preparas el terreno para futuros errores.

Una forma de juzgar si tiene un problema con la supervisión o un problema con el diseño podría ser considerar cuánto esfuerzo se requiere para corregir los errores. Si las correcciones tienden a ser grandes, o siente que no las comprende bien, eso señala la figura en el diseño del código que se puede mejorar.

Creo que se reduce a una especie de buen gusto sobre el código, que puedes desarrollar con práctica y revisión, y leer sobre personas con problemas similares.

En última instancia, es inútil no esperar ningún error en absoluto, pero no hay ningún daño en tratar de reducir su conteo de errores a menos que ya lo tenga en un nivel bajo, y luego se convierte en una compensación entre su tiempo y el tiempo de quien encuentre errores que no atrapas.

Si me refiero a: "cero errores al escribir el código" -> ese es un buen objetivo pero bastante imposible.

Pero si quiere decir: "cero errores en el código entregado" -> eso es posible, y trabajé en tales entornos.

Todo lo que necesita es: una calidad de código increíblemente alta y una cobertura de prueba cercana al 100% (pruebas unitarias + pruebas de aceptación + pruebas de integración).

En mi opinión, el mejor libro para aprender es: GOOS . Pero, por supuesto, un libro no es suficiente. Necesita ir a algún grupo de usuarios y discutir sobre esto. Cursos, conferencias, etc. La calidad de cero errores no es fácil.

En primer lugar, necesita un jefe que esté realmente interesado en la alta calidad y dispuesto a pagar por ello.

Solución del programador:

• Deja de programar.
• Construye una computadora mecánica.
• Reemplácelo cada 5 años para que el desgaste mecánico no entre en juego.

Solución del usuario:

• Deja de usar computadoras.
• Haz todo de forma manual.
• Siempre haga que una segunda persona verifique los resultados.

Estoy de acuerdo en que para ser un programador de cero errores, simplemente no puede programar / codificar. Es parte de la vida de cada programador encontrar y desarrollar errores. Ningún desarrollador experimentado puede decir, mano a mano, que nunca han encontrado un error en su código.

Emparejar con otro ingeniero. Escribe una prueba reprobatoria. Haga que todos los caracteres que escriba sean necesarios para aprobar la prueba reprobatoria. Refactorice su código para hacerlo más simple. Escriba otra prueba reprobatoria, y así sucesivamente.