Me encuentro reflexionando sobre esta pregunta de vez en cuando, una y otra vez. Quiero hacer las cosas de la manera correcta: escribir código limpio, comprensible y correcto que sea fácil de mantener. Sin embargo, lo que termino haciendo es escribir parche sobre un parche; solo porque no hay tiempo, los clientes están esperando, un error debe repararse de la noche a la mañana, la compañía está perdiendo dinero por este problema, un gerente está presionando mucho, etc., etc.
Sé perfectamente que a largo plazo estoy perdiendo más tiempo en estos parches, pero como este tiempo abarca meses de trabajo, a nadie le importa. Además, como solía decir uno de mis gerentes: "no sabemos si habrá un largo plazo si no lo arreglamos ahora".
Estoy seguro de que no soy el único atrapado en estos infinitos ciclos de elección real / ideal. Entonces, ¿cómo ustedes, mis compañeros programadores, lidian con esto?
ACTUALIZACIÓN: Gracias a todos por esta interesante discusión. Es triste que tantas personas tengan que elegir diariamente entre una cantidad y una calidad de su código. Aún así, sorprendentemente, muchas personas piensan que es posible ganar esta batalla, así que gracias a todos por este aliento.
Respuestas:
En realidad, esta es una pregunta muy difícil porque no hay una respuesta absolutamente correcta. En nuestra organización, hemos estado implementando mejores procesos para producir un mejor código. Actualizamos nuestros estándares de codificación para reflejar cómo nosotros, como grupo, escribimos código, y hemos instituido un ciclo muy fuerte de prueba / refactorización / diseño / código. Entregamos continuamente o al menos lo intentamos. Como mínimo, tenemos algo que mostrar a los interesados cada dos semanas. Sentimos que somos artesanos del software y la moral es alta. Pero, a pesar de todos estos controles y equilibrios, sufrimos el mismo problema que usted.
Al final del día, estamos entregando un producto a un cliente que paga. Este cliente tiene necesidades y expectativas, realistas o no. A menudo, el equipo de ventas nos mete en problemas solo para obtener una comisión. A veces, el cliente tiene expectativas de puesta en marcha que no son realistas o exigen un cambio a pesar de que tenemos un contrato vigente. Las líneas de tiempo suceden. La PTO y los días perdidos durante un sprint pueden suceder. Todo tipo de pequeñas cosas pueden culminar en una situación en la que nos vemos obligados a entrar en el enigma de "hacerlo bien" o "hacerlo lo antes posible". Casi siempre, nos vemos obligados a "hacerlo lo antes posible".
Como artesanos del software, desarrolladores, programadores, personas que codifican un trabajo, nuestra inclinación natural es "hacerlo bien". "Hazlo CUANTO ANTES" es lo que sucede cuando trabajamos para sobrevivir, como lo hacemos la mayoría de nosotros. El balance es duro.
Siempre empiezo acercándome a la gerencia ejecutiva (soy Director de Desarrollo de Software y un desarrollador activo en ese grupo) para defender el cronograma, el equipo y el trabajo que se realiza. Por lo general, en ese momento me dicen que el cliente tiene que tenerlo ahora y que tiene que funcionar. Cuando sé que no hay espacio para negociar o dar, vuelvo y trabajo con el equipo para ver qué esquinas se pueden cortar. No sacrificaré la calidad en la función que impulsa la necesidad del cliente de obtenerla lo antes posible, pero algo saldrá y será empujado a otro sprint. Esto casi siempre está bien.
Cuando no puede entregar porque hay tantos errores, la calidad del código es mala y empeora, y los plazos se acortan, entonces se encuentra en una situación diferente a la que describo. En ese caso, la mala gestión actual o pasada, las malas prácticas de desarrollo que condujeron a una mala calidad del código u otros factores pueden llevarlo a una marcha de la muerte.
Mi opinión aquí es hacer todo lo posible para defender el buen código y las mejores prácticas para comenzar a sacar a su empresa de las trincheras. Si no hay un solo colega dispuesto a escuchar o pelear por el grupo en contra de la gerencia, entonces podría ser el momento de comenzar a buscar un nuevo trabajo.
Al final, la vida real triunfa sobre todo. Si está trabajando para una empresa que necesita vender lo que está desarrollando, entonces encontrará esta compensación diariamente. Solo al esforzarme por lograr buenos principios de desarrollo desde el principio, he tenido éxito en adelantarme a la curva de calidad del código.
El empuje y atracción entre desarrolladores y vendedores me recuerda una broma. "¿Cuál es la diferencia entre un vendedor de autos usados y un vendedor de software? Al menos el vendedor de autos usados sabe que está mintiendo". Mantenga la cabeza en alto e intente "hacer lo correcto" a medida que avanza.
fuente
Una cosa que me di cuenta en mi carrera es que siempre hay tiempo para hacerlo bien. Sí, tu gerente podría estar presionando. El cliente puede estar enojado. Pero no saben cuánto tardan las cosas en hacer. Si usted (su equipo de desarrollo) no lo hace, no se está haciendo; tienes todo el apalancamiento.
¿Porque sabes lo que realmente hará que tu gerente te empuje a ti oa tu cliente a enojarse? Mala calidad .
fuente
Esto se reduce a lo que comencé a pensar como "El conflicto eterno" (entre negocios e ingeniería). No tengo la solución, ya que es un problema que nunca desaparece, pero puedes hacer cosas para ayudar a mitigar.
Lo que la gente a menudo no se da cuenta es que, como ingenieros, estamos asumiendo que el problema del "negocio exitoso" siempre es un hecho. Queremos que nuestro código sea agradable, ordenado y fácil de mantener para que podamos agregar nuevas funciones y ajustar las existentes rápidamente y con un mínimo de clientes haciendo QA por nosotros descubriendo casos extraños que hubieran sido frustrados por un mejor código. Mantener a los clientes y mantener una ventaja competitiva con características y delicadeza que nadie más puede producir con la suficiente rapidez son dos ventajas comerciales a las que contribuye un buen código e informan en gran medida la razón por la que queremos un mejor código en primer lugar.
Así que explícalo. "Queremos hacer X en nuestra base de código porque si no lo hacemos, impactará negativamente en el negocio debido a Y" o "... porque mejorará nuestra capacidad de seguir siendo competitivos al mejorar nuestra capacidad de cambiar nuevas mejoras y características más rápido ".
Y haga todo lo posible para tratar de obtener evidencia tangible de que las mejoras están funcionando. Si mejorar algún subconjunto de una aplicación resultó en una función / mejora más rápida, verifique cualquier herramienta de trabajo atrasado que pueda estar usando para evidencia de ello y apúntela en las reuniones apropiadas.
Los egos son a menudo un problema. Una cosa que los equipos de ingeniería necesitan con urgencia es establecer el valor de tener algún tipo de enfoque consensuado para resolver ciertos tipos de problemas en lugar de que todos hagan su propia taza de Kool Aid d'jour porque saben más. Está bien creer que la preferencia del otro tipo es peor que la tuya, pero valora la coherencia en lugar de tener más razón si su enfoque es viable y es un argumento que no puede ganar. El compromiso por el bien de la consistencia es clave. Cuando las cosas son consistentes, es más difícil hacerlas mal, ya que la forma establecida y consistente también será la más rápida.
Hay dos escuelas de marcos / conjuntos de herramientas / bibliotecas / lo que sea. "Configura el 99% para mí, así que tengo que saber / hacer muy poco" vs. "mantente fuera de mi camino cuando no te quiero allí, pero ayúdame a hacer bricolaje muy rápida y consistentemente con las cosas que realmente quiero para usar en el principio de zanahoria en lugar de palo ". Favorecer el segundo. La flexibilidad y el control granular nunca deben sacrificarse en el altar de un cambio rápido porque, por ejemplo, "no podemos hacer esto porque nuestras propias herramientas no nos lo permiten" nunca es una respuesta aceptable y la pregunta siempre surgirá Ingeniería de producto trivial / desechable. En mi experiencia, las herramientas inflexibles casi siempre se rompen de par en par o se solucionan de manera poco elegante y hacen un gran desastre gigante inmanejable. Más a menudo que no, las soluciones flexibles / más fáciles de modificar son igual o casi tan rápidas a corto plazo, independientemente. Rápido, flexible y fácil de mantener son posibles con las herramientas adecuadas.
Tengo la sensación de que esta es una pregunta de perspectiva del desarrollador, pero he estado en demasiadas situaciones en las que las decisiones tecnológicas se tomaron con cero aportes del ingeniero. ¿Qué demonios es eso? Sí, en última instancia, alguien debe hacer la última llamada, pero obtener opiniones calificadas si es un gerente no técnico, no lo que dice un vendedor o un sitio de demostración sobre sus propios productos. Cualquier cosa prometedora para ahorrarle dinero porque las personas no necesitan ser tan inteligentes o porque protege a los desarrolladores de sí mismos es una mentira sucia y sucia. Contrata talentos en los que puedas confiar. Explíqueles lo que desea de una pila u otra solución tecnológica y tómese en serio sus aportes antes de decidir a qué carro tecnológico se subirá.
Las herramientas son para la implementación y, como tales, pueden ayudarlo, pero la primera prioridad debe ser la arquitectura, independientemente del conjunto de juguetes que tenga para construir esa arquitectura. Al final del día, KISS y DRY y todas las excelentes filosofías que se extienden de esos asuntos más que si se trata de .NET o Java o tal vez algo que es gratis Y no apesta.
Cuando el lado del negocio insista en que lo haga de la manera incorrecta, guarde ese correo electrónico, especialmente la parte donde dijo por qué le costaría. Cuando todas sus predicciones se hacen realidad y resultan serios problemas que dañan el negocio, es cuando tiene una gran cantidad de argumentos para tomar las preocupaciones de los ingenieros más en serio. Pero cronometra las cosas con cuidado. En medio del infierno ardiente es un mal momento para un "te lo dije" en el siguiente código de incendio. Apague el fuego y lleve su lista de preocupaciones previamente ignoradas a una reunión / conversación retrospectiva, e intente mantener el enfoque en las preocupaciones de ingeniería expresadas e ignoradas y el razonamiento que entendió por qué se ignoraron, no los nombres de las personas reales tomando la decisión de ignorar. Eres ingeniero Mantente en los problemas, no en las personas. " Expresamos preocupación por X porque temíamos que esto condujera a problemas con Y. Nos dijeron Z y posponer el trato con eso ".
fuente
Sólo hay una solución. Reserve alrededor del 10-20% del tiempo de proyecto / trabajo para refactorizar. Si es difícil convencer a la administración de que es una tarea justificable, déles el único argumento real: sin refactorizar, el costo del mantenimiento del código crecerá exponencialmente con el tiempo. Es bueno tener algunas métricas / artículos / resultados de investigación para respaldar esta tesis durante la reunión con el gerente :)
Editar: hay algunos buenos recursos sobre "refactorización frente al aumento de los costos de mantenimiento" mencionados en este documento técnico: http://www.omnext.net/downloads/Whitepaper_Omnext.pdf
fuente
Siempre que tenga tiempo para hacer algo bien, úselo: escriba el mejor código que pueda y mejórelo constantemente. No dificulte su trabajo siendo descuidado e introduciendo deudas técnicas cuando no sea necesario.
Las llamadas de emergencia para corregir un error grave no son cosas que pueda controlar usted mismo, cuando ocurren, debe reaccionar lo antes posible, así es la vida. Por supuesto, si tiene la impresión de que todo su trabajo consiste en llamadas de emergencia, y nunca tiene tiempo suficiente para hacer las cosas bien, entonces está en camino de agotarse y debe hablar con su jefe.
Si eso no ayuda, todavía existe la "estrategia de Scotty" para tener tiempo suficiente para hacer las cosas bien: multiplique todas sus estimaciones por un factor de 4:
http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/
fuente
Considero que mi trabajo es proporcionar el mejor software de calidad posible dentro de las limitaciones de tiempo permitidas para el proyecto. Si me preocupa que el nivel de calidad sea bajo, involucraré al propietario del proyecto. Describo mis preocupaciones y analizo los riesgos potenciales de implementar el software en ese estado. Una de las 3 cosas sucederá en este punto:
El propietario del proyecto no querrá aceptar los riesgos y retrasará el cronograma para permitirnos dedicar más tiempo a la calidad del software.
El propietario del proyecto no querrá aceptar los riesgos, pero no puede retrasar el cronograma. Si esto sucede, debemos negociar qué características / funcionalidades eliminar del alcance del proyecto para dedicar más tiempo a la calidad del software para las partes principales de la aplicación.
El propietario del proyecto aceptará los riesgos y el software de baja calidad saldrá a tiempo. A veces, el riesgo empresarial de no implementar nada (o hacerlo tarde) es mucho mayor que el riesgo empresarial de implementar software de baja calidad, y solo el propietario del proyecto puede tomar esa decisión.
Escribir software es muy parecido a pintar un retrato. Es imposible decir que un retrato se hace "bien" o "perfecto". Lo perfecto es enemigo de lo hecho. Literalmente, podría pasar 1 mes trabajando en un solo método y algunos aún no lo consideran "perfecto". Mi trabajo es pintar un retrato con el que el cliente esté satisfecho.
fuente
Esto no funcionará en todos los casos, pero he tenido suerte usando esta estrategia si el problema es un problema de producción roto que debe solucionarse con urgencia. Calcule el tiempo para hacer una solución rápida para poner en marcha la producción y el tiempo para hacer la solución de calidad para el futuro. Presente las estimaciones a su jefe / cliente y obtenga el tiempo aprobado para ambos. Luego, realiza la solución rápida para que la producción se ejecute y una solución a largo plazo inmediatamente después, cuando la presión de tiempo urgente está apagada. Creo que si lo presento, ya que necesito este tiempo para hacer bien el trabajo, pero puedo poner una solución temporal hasta que pueda hacer eso, parece que a mis clientes les gusta ese enfoque. Se pone en marcha nuevamente y se atiende la necesidad a largo plazo.
fuente
El equilibrio óptimo puede ser pasar tanto tiempo extra haciéndolo bien como desperdiciaría arreglando los errores que elimine haciéndolo bien. Evite el dorado de la solución. En la mayoría de los casos, la solución de Volkswagen bien hecha es tan buena como la solución de Cadillac. Por lo general, puede actualizar más tarde cuando se demuestre que necesita el Cadillac.
La reparación del código que no ha seguido las mejores prácticas suele llevar mucho más tiempo. Intentar encontrar de dónde viene el valor nulo cuando la llamada se ve como abcde (), puede llevar mucho tiempo.
Aplicar DRY y reutilizar el código existente suele ser mucho más rápido que codificar y probar otra solución más. También facilita la aplicación de cambios cuando se producen. Solo necesita cambiar y probar un conjunto de códigos, no dos, tres o veinte.
Apunte a un código básico sólido. Se puede perder mucho tiempo tratando de hacerlo perfecto. Hay mejores prácticas que conducen a un código que es rápido, pero no necesariamente el más rápido que podría ser. Más allá de eso, tratar de anticipar cuellos de botella y optimizar el código a medida que se construye puede ser una pérdida de tiempo. Peor aún, la optimización puede ralentizar el código.
Siempre que sea posible, proporcione la solución de trabajo mínima. He visto semanas desperdiciando soluciones de chapado en oro. Tenga mucho cuidado con el alcance.
Pasé un tiempo trabajando en un proyecto que debería haber tomado seis meses. Cuando me uní, había estado en progreso durante un año y medio. El líder del proyecto le había hecho una pregunta al gerente del proyecto al principio: "¿Quieres que lo haga bien o que responda?" En una semana, se implementó una función los lunes, miércoles y viernes; Martes y jueves la función fue eliminada.
EDITAR: cuando el código esté hecho a un nivel satisfactorio, déjelo. No vuelvas a arreglarlo si encuentras una mejor manera de hacerlo. Si debes hacerte una nota. Si se requieren cambios, revise su idea e impleméntela, si aún tiene sentido.
Si hay lugares donde implementaría extensiones para las próximas funciones, no implemente las extensiones. Puede dejar un comentario de marcador para recordarle dónde hacer los cambios.
fuente
Haz que funcione y luego hazlo perfecto
Puedo sacar un poco de tiempo para esto, pero si el tiempo es esencial, entonces su prioridad principal debería ser hacerlo funcionar, así de simple. Comente extensamente sobre las deficiencias en su código y tome nota de lo que ha hecho en cualquier software de gestión de proyecto / tiempo que esté utilizando.
Con suerte, esto le dará más tiempo para volver a estos problemas y hacerlos perfectos.
Obviamente no hay una respuesta correcta absoluta a esto, pero es una respuesta que trato de seguir. Sin embargo, es posible que no lo encuentre adecuado para su estilo de trabajo actual. Lo que me lleva a la alternativa ...
Simplemente encuentre un método que funcione para usted ; y luego seguir con eso. Todos tienen su propia forma de tratar los proyectos y no existe un enfoque de "talla única". Encuentra un enfoque y hazlo tuyo.
fuente
"Hacerlo bien" significa hacer las compensaciones correctas para una situación particular. Algunos de ellos son:
Obviamente, si se usa una pieza de código una vez y se tira, el # 2 puede ser sacrificado por cualquiera de los otros. (Pero tenga cuidado: puede pensar que va a tirarlo a la basura, luego encontrará que debe seguir usándolo y manteniéndolo, en ese momento será más difícil convencer a las personas de que le den tiempo para mejorar algo que "funciona").
Si usted y / o su equipo van a seguir usando y actualizando algún código, tomar atajos ahora solo significa reducir la velocidad más adelante.
Si actualmente está entregando código defectuoso (débil en el n. ° 4) y está tardando mucho en hacerlo (débil en el n. ° 1), y es porque está tratando de actualizar el código que estaba débil en el n. ° 2, bueno, ha Obtuve un argumento sólido y pragmático para cambiar tus prácticas.
fuente
Si es un error, hágalo lo antes posible, si es una función nueva, tómese su tiempo.
Y si trabaja para una empresa que no respeta el trabajo del desarrollador, es posible que no tenga más remedio que hacerlo rápido y sacrificar la calidad.
He trabajado para varias compañías que simplemente iban de proyecto en proyecto y hacían todo rápido. Finalmente, tuvieron poco éxito en cada proyecto porque la implementación (no solo la programación) se apresuró.
Las mejores compañías por ahí entienden que un buen software requiere tiempo y artesanía.
fuente
En caso de emergencia, cree la solución de parcheo. Cree un nuevo error en el seguimiento de errores mencionando esto. Hazlo bien, siempre que tengas tiempo adecuado.
fuente
Creo que hago lo que hacen todos los que están atrapados trabajando en esta industria. Lo hago lo más rápido que puedo y si tengo que dejar de lado algunas de las cosas buenas que ayudarían a prevenir problemas en el futuro, o facilitar la resolución de problemas en el futuro, lo hago. No es una situación óptima, pero cuando tiene que cumplir con plazos basados en estimaciones basadas en estimaciones, basadas en muchas variables desconocidas, es prácticamente lo mejor que puede hacer.
fuente
Aquí hay un buen plan:
fuente
Hago la mayoría de las cosas de manera rutinaria, la primera forma que me viene a la mente. Eso es rápido, y me gusta pensar que soy un programador decente y que hago la mayoría de las cosas razonablemente bien en el primer intento.
De vez en cuando (me gustaría decir dos veces al día, pero dos veces por semana es más realista), especialmente cuando encuentro algo extremadamente aburrido que hacer de forma rutinaria, pienso "¿cuál sería una forma IMPRESIONANTE de hacer esto? ? " y paso el tiempo extra para encontrar o inventar una mejor manera de hacerlo.
Creo que si sigo haciendo eso con la frecuencia suficiente, mi codificación de rutina continuará mejorando.
fuente
El software es algo extraño y el proceso de desarrollo de software es más extraño.
A diferencia de la mayoría de las cosas en la vida real, pero como la mayoría de las cosas que tienen que ver con las computadoras
Más rápido es más confiable
Esto va en contra de cada intuición que su vida le ha enseñado hasta ahora, los autos altamente afinados se descomponen con más frecuencia que los estándar, las casas construidas rápidamente se desmoronan más rápidamente, la tarea hecha en la parte trasera del autobús escolar no obtiene altas calificaciones.
Pero los procedimientos metódicos lentos no producen un mejor software. Los chicos que pasan semanas produciendo documentos de requisitos y días en diagramas de clase antes de escribir código no producen un mejor software. El tipo que obtiene el requisito básico, aclara algunos problemas, garabatea un diagrama de clase en la pizarra y obtiene la codificación de su equipo casi siempre producirá un software más confiable y mejor, y lo hará en días en lugar de meses.
fuente
El trabajo no es adecuado para ti.
El código de baja calidad escrito "porque no hay tiempo, los clientes están esperando, un error debe repararse de la noche a la mañana, la empresa está perdiendo dinero por este problema, un gerente está presionando mucho" es un síntoma de una empresa mal administrada.
Si está dispuesto a enorgullecerse de su trabajo y escribir un código de alta calidad, entonces lo mejor que puede hacer es encontrar un empleador que lo entienda y que le pague por hacerlo.
fuente