Mi jefe siempre me ha dicho que un buen programador debería poder asegurarse de que el código que él o ella cambia sea confiable, correcto y completamente auto-verificado; que debes comprender completamente todos los resultados e impactos que tus cambios causarán. He intentado 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 sin errores.
Los errores son inevitables porque los programadores son humanos, todo lo que podemos hacer es intentar 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 ciertos programas de alto riesgo. El software Space Shuttle 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, solo tuvieron un error cada una. Las últimas 11 versiones de este software tuvieron un total de 17 errores.
Tome la actualización del software para permitir que la lanzadera 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 ejecutan 2.500 páginas, un volumen más grueso que un directorio telefónico. Las especificaciones para el programa actual llenan 30 volúmenes y ejecutan 40,000 páginas.
"Zero-bug programmer" es un oxímoron, como un cantante silencioso, pero más o menos 60 años de programación han producido algunos destilados de sabiduría, que te harán un mejor programador, como:
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 función escribiendo una prueba de aceptación. Aquí he encontrado que escribir las pruebas de estilo cucumber es ideal.
El enfoque TDD ofrece al menos dos beneficios.
No prueba cero errores, ya que eso sería imposible (ya se han señalado en muchas 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 comprendo por completo sin preocuparme por romper la funcionalidad.
Pero TDD no te ayuda en todo el camino. No puede escribir código libre de errores si no comprende a fondo la arquitectura del sistema y las dificultades de dicha arquitectura. P.ej. 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 de novato para almacenar datos mutables en caché para mejorar el rendimiento).
Creo que los equipos de desarrollo que son buenos en TDD entregan el código con el menor número de defectos.
La cuestión es que los errores son las cosas que no reconocen. A menos que tenga algún tipo de conocimiento enciclopédico del lenguaje de programación / compilador, así como de todos los entornos en los que se ejecutará su aplicación, realmente no puede esperar producir un código 100% libre de errores.
Puedes reducir tu cuenta 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 en 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 vas a tener errores" es solo una solución 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 que los siguientes puntos son útiles.
Personalmente creo que luchar por una programación libre de errores parece ser más caro (tanto en tiempo como en dinero). Para llegar a cero errores, o incluso a casi cero, es necesario que los desarrolladores realicen pruebas exhaustivas. Esto significa que la regresión prueba todo antes de enviar cualquier código para revisión de parches. Este modelo no me parece que sea rentable. Es mejor que los desarrolladores realicen las pruebas diligentes debidas y dejen las pruebas en profundidad al equipo de control de calidad. Aquí es por qué:
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. Aún debe garantizar la calidad en su trabajo, pero puede exagerar.
¿Cuántas profesiones puedes nombrar que siempre cumplan correctamente su tarea la primera vez sin una revisión y / o evaluación por pares?
¿Cero errores? Suena como necesitas Lisp (sigue el camino escéptico y evita el video musical).
Es extraordinariamente difícil lograr un código libre de errores en los entornos de codificación principales (Java, C #, PHP, etc.). Me concentraría en producir código bien probado y revisado por pares en iteraciones breves controladas.
Mantener el código tan simple como puedas te ayudará a evitar errores.
Asegúrese de estar usando herramientas de análisis de código (como FindBugs , PMD y así sucesivamente) que, combinado con advertencias estrictas del compilador, revelará todo tipo de problemas con su código. Tome nota de lo que le están diciendo, realmente intente comprender cuál es la naturaleza del error, y luego tome medidas para cambiar su lenguaje de programación de modo que no se sienta natural codificar de una manera que vuelva a introducir ese error.
Todos los "No codificar en absoluto". Las respuestas están completamente perdiendo el punto. Además, ¡su jefe definitivamente no parece ser un imbécil!
No puedo recordar con qué frecuencia he visto a programadores que simplemente no sabían lo que hace su código. Su único desarrollo de philosohpy parecía ser prueba y error (y muy a menudo también copiar / pegar / modificar). Si bien la prueba y el error son 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 no tendrá solo resolvió el problema, pero también la mayoría de los casos de esquina (posibles errores) antes de implementarlo por primera vez. ¿Se puede 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 que le gustaría pensar la próxima vez que escriba / cambie algo. Si haces esto, por lo tanto, ganarás mucha experiencia en 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 debería eliminarse. Por supuesto, a veces hará suposiciones del funcionamiento interno de los métodos a los que llama, de lo contrario tendría que 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 los errores? Sí, por supuesto. Pero estos errores se deben a su comprensión incompleta del sistema / herramientas con los que trabaja y con cada corrección de errores tendrá una mejor cobertura.
Como ya se ha indicado correctamente en otros comentarios, no hay software no trivial sin errores.
Si desea probar el software siempre tenga en cuenta que las pruebas solo pueden probar la presencia de errores, no su ausencia.
Dependiendo de su dominio de trabajo, puede probar la verificación formal de su software. Al utilizar métodos formales, puede estar bastante seguro de que su software cumple exactamente con la especificación.
Eso, por supuesto, no significa que el software haga exactamente lo que usted quiere. Escribir una especificación completa en casi todos los casos tampoco es posible. Básicamente, cambia el lugar donde pueden ocurrir errores de implementación a especificación.
Por lo tanto, dependiendo de su definición de "errores", puede probar 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 dices 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
Puedes esforzarte por ser un programador de cero errores. Me esfuerzo por ser un programador de cero errores cuando estoy escribiendo código. Sin embargo, yo no
No hago estas cosas porque tienen un costo prohibitivo para el software que escribo. Si hiciera estas cosas, probablemente estaría más avanzado 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 cero errores porque no puedo hacer que la gente dedique ese tipo de tiempo a 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 la línea si mi software se rompe, por lo que no nos involucramos en ese nivel de seguridad.
Ajustaré el nivel de seguridad al uso previsto del software. Si está escribiendo un código que el transbordador de la NASA utilizará, tal vez la tolerancia a errores cero sea razonable. 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 tu actitud hacia los errores. En lugar de decir "suceden", "mejoran el control de calidad y los evaluadores" o "los desarrolladores apestan en las pruebas", por ejemplo:
Los errores no son aceptables y haré todo lo que esté a mi alcance para eliminarlos.
Una vez que esto se convierta en tu actitud, los errores caerán rápidamente. En su búsqueda para encontrar formas de eliminar errores, se encontrará con un desarrollo guiado por pruebas. Encontrarás muchos libros, publicaciones en blogs 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ás a tener un mejor desempeño en el trabajo porque comenzarás a trabajar en tu oficio en casa. Y, con suerte, una vez que veas que es posible escribir un buen software , tu pasión por tu 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 de cero errores es prohibitivamente alto . Necesitas hacer cosas como:
Utilice especificaciones formales de sus requisitos. Formal, como en el uso de Z o VDM o alguna otra notación matemáticamente sólida.
Use las técnicas de prueba de teoremas para probar formalmente que su programa implementa la especificación.
Crea conjuntos extensos de pruebas de unidades, regresión y sistemas, y arneses para probar errores en todos los sentidos. (Y esto no es suficiente en sí mismo).
Haga que muchas personas revisen los requisitos (formales e informales), el software (y las pruebas). Pruebas y despliegues.
Es extremadamente improbable que su jefe esté preparado para pagar todo esto ... o aguantar el tiempo necesario para hacerlo todo.
He alcanzado el estado de "error cero". Les digo a mis usuarios que es una característica no documentada, o están solicitando una nueva característica y, por lo tanto, es una mejora. Si ninguna de estas respuestas es aceptada, simplemente les digo que no han entendido sus propios requisitos. Por lo tanto, no hay errores. Los programadores son perfectos.
Aquí están los pasos para hacer un programa libre de errores:
Las pruebas solo pueden probar que tienes errores, pero generalmente es inútil probar lo contrario. Con respecto a los comentarios, si tiene una máquina para hacer monedas que hace monedas y cada moneda de 10s en promedio tiene un defecto. Puede tomar esa moneda, aplanarla e insertarla nuevamente en la máquina. La moneda que hizo que el blanco reciclado no sea tan buena, pero tal vez sea 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 programador bueno y libre de defectos, tienes que invertir mucho tiempo, entrenando e iterando sobre cada defecto creado. Los desarrolladores deben recibir capacitación en métodos de verificación formal que a menudo son difíciles de aprender y aplicar en la práctica. La economía del desarrollo de software también está en contra, ¿invertirías 2 años en capacitar a un programador que puede hacer menos defectos solo para verlo saltar a otro empleador? Puedes comprar una máquina que haga monedas perfectas, o contratar 10 monos de código más para crear un montón de pruebas al mismo costo. Puede percibir este proceso exhaustivo como su "máquina", su activo: invertir en la capacitación extensa de desarrolladores excelentes no da frutos.
Muy pronto aprenderá cómo desarrollar software de calidad aceptable, pero probablemente nunca será uno que esté libre de defectos por la sencilla razón de que no existe un mercado para desarrolladores que haga el código perfecto porque es lento.
Programa defensivo: enlace
Si alguien sigue las convenciones de la programación a la defensiva, entonces los cambios serán fáciles de rastrear. Combine esto con informes de errores rigurosos durante el desarrollo y una documentación sólida, como con doxygen, y debería 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 malinterpretar una metodología buena , y no solo de cabeza de cabeza genérica?
Lo que quiero decir es que es posible que su jefe haya oído hablar de "metodología de cero defectos" (consulte la sección no.5), y no se molestó en entender lo que eso significaba?
Por supuesto, es inconveniente para la administración posponer el desarrollo de nuevas características, en favor de los errores que usted no debería haber introducido ...
Y, por supuesto, eso amenaza su bonificación, por lo que, por supuesto, no obtendrá uno porque "los buenos programadores no tienen errores" ...
Está bien hacer errores, siempre que puedas encontrar y corregir (dentro de lo razonable, por supuesto).
Uno de los conceptos fundamentales de las pruebas de software es que NUNCA puede estar absolutamente seguro de que el programa sea perfecto. Puedes validarlo para siempre, pero eso nunca prueba que el programa esté completo porque rápidamente no es factible ni siquiera probar contra todas las combinaciones de entrada / variable.
Tu jefe parece ser uno de los que "no entiende qué es tan difícil acerca de la programación, ya que solo está escribiendo"
Si asumimos que las grandes empresas de software saben cómo obtener los mejores desarrolladores (como en cero programadores de errores ) podemos deducir que el software de Microsoft debe ser sin 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 lo resuelven más tarde.
A menos que esté desarrollando algo más complejo que una simple calculadora, no es posible evitar errores por completo. Demonios, incluso la NASA tiene redundancia en sus vehículos e insectos también. Aunque tienen pruebas muy rigurosas para evitar fallos catastróficos. Pero aún así, incluso tienen errores en su software.
Los errores son inevitables como lo es la naturaleza humana para errar.
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 es inalámbrico. Por lo tanto, no hay un sistema perfectamente seguro , no hay un sistema complejo sin errores.
Solo veo respuestas acerca de que somos humanos y propensos a errar, lo cual es muy cierto ... pero veo tu pregunta desde otro punto de vista.
Creo que puedes escribir programas sin errores, pero esos son típicamente programas que ya escribiste 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 tu mente. Todos los patrones están ahí, en todos los niveles.
Esto me pasa 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. Tengo un par o tres errores de compilación (en su mayoría errores tipográficos y otras cosas así) y eso es todo. Puedo hacer esto para programas pequeños, y también creo que algunas personas pueden hacerlo 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 puedes estar de un programador libre de errores. Si comprende las cosas profundamente, creo que puede 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 (llevo años haciendo eso), te confundirás y cometerás errores. Grandes errores como aquellos en los que repentinamente se da cuenta de que su solución no funciona, cuando finalmente comprende el problema, y tiene que hacer cambios tan complicados que podrían impedirle resolver su problema o hacer que el código sea horrible. TDD es para estos casos, creo. Usted sabe que no trata el problema que está abordando y, por lo tanto, realiza pruebas en todas partes para asegurarse de que tenga una base sólida. Sin embargo, TDD no resuelve la visión de 10,000 pies. Puede caminar en círculos con código perfectamente limpio todo el tiempo.
Sin embargo, si intentas hacer algo que es nuevo pero que está solo por encima de tu nivel, puedes obtener tu programa perfecto o casi perfecto. Creo que es realmente difícil saber qué programas se encuentran en su "frontera del conocimiento", pero en teoría esa es la mejor manera de aprender. Reescribo programas desde cero mucho, en realidad. Algunas personas lo hacen, pero necesitas mucho tiempo y paciencia porque la tercera vez que repites un programa no trivial no te emociona como la primera vez.
Así que mi consejo es: no creas que entiendes algo hasta que puedas escribir un programa sin errores solo para eso. Y luego intente combinar dos de esos conceptos que conoce profundamente en el mismo programa. Estoy casi seguro de que lo harás bien la primera vez. Una de las mejores maneras es reescribir el software no trivial, algo que requirió mucho esfuerzo la primera vez (lo estoy haciendo con las aplicaciones de Android en este momento). Cada vez que vuelvo a empezar, cambio algo o agrego cosas, solo para agregar un poco de diversión, y puedo decirte que mejoro y mejor y mejor ... tal vez no esté libre de errores pero realmente orgulloso.
Los errores imho y los artefactos de algoritmos repentinos y misteriosos deben aparecer durante el proceso de codificación: inspiran y forzan la evolución del código. Sin embargo, es posible (generalmente después de algunas pruebas) verificar todas las variables que se pueden usar antes de la declaración, para manejar cada error donde sea que aparezca, para que el programa no tenga errores ... hasta que reciba una solicitud de una característica eso se consideraba 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, en general, pequeños descuidos, un enfoque en mejores pruebas y un poco de corrección de código sería de ayuda.
Sin embargo, si los errores tienden a ser debidos a decisiones de programación subóptimas, tal vez se requiera un mayor esfuerzo en un mejor diseño. En este caso, creo que es posible depender demasiado de las pruebas para mejorar la calidad del software, ya que la aplicación de un parche a un código deficiente puede hacer que el mantenimiento futuro sea más complicado. Por un lado, obtienes menos errores cuando los encuentras y los arreglas, pero por otro lado preparas el terreno para futuros errores.
Una forma de juzgar si tiene un problema con descuidos o un problema con el diseño podría ser considerar cuánto esfuerzo se requiere para corregir los errores. Si los arreglos tienden a ser grandes, o si sientes que no los entiendes bien, eso apunta a la figura en el diseño del código que se puede mejorar.
Creo que se trata de una especie de buen gusto sobre el código, que puede desarrollar con la práctica y la revisión, y leer sobre personas con problemas similares.
En última instancia, es inútil esperar que no haya ningún error en absoluto, pero no hay ningún daño en tratar de reducir el número de errores a menos que ya lo tenga en algún nivel bajo, y luego se convierta en un intercambio entre su tiempo y su tiempo. de quien encuentre errores que no atrapes.
Si me refiero a: "cero errores al escribir el código" - > Esa es una buena meta 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: alta calidad de código y casi 100% de cobertura de prueba (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. Necesitas ir a algún grupo de usuarios y discutir sobre esto. Cursos, conferencias, etc. La calidad de los errores cero no es fácil.
Primero que todo, necesitas un jefe que esté realmente interesado en la alta calidad y que esté dispuesto a pagar por ello.
Solución del programador:
Solución del usuario:
Estoy de acuerdo en que para ser un programador sin errores, simplemente no puedes 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.
Empareja con otro ingeniero. Escribe una prueba de falla. Haga que todos los caracteres que escriba sean necesarios para hacer que se apruebe la prueba que falla. Refactoriza tu código para hacerlo más simple. Escribe otra prueba fallida, y así sucesivamente.
Lea otras preguntas en las etiquetas code-quality