Me uní a una startup que tiene un producto que tiene errores. Me presionan para que sea estable, pero la base del código está muy mal diseñada. ¿Qué tengo que hacer?

La respuesta será un poco desestructurada y abstracta, ya que no conozco su papel en la empresa, sus objetivos y el entorno general.

1. Concéntrese en solucionar problemas de alto nivel como un objetivo, no en refactorizar el código. Ejemplos comunes serían: asegurarse de que el código esté bien cubierto con pruebas, implementación continua, operaciones automatizadas y documentadas. A los empresarios nunca les importan los nombres deficientes o demasiadas devoluciones de llamadas desordenadas en el código JavaScript, pero les importarían los problemas de nivel superior: cantidad de tiempo y personas necesarias para mantener el código, cantidad de interrupciones, etc.
2. Empieza pequeño. Encuentra una sola cosa que puedas mejorar. ¿Hay algún subsistema que se caiga tres veces por semana por la noche? ¿Existe una base de datos que no se mantiene al día con la creciente carga? ¿Hay alguna parte del código que todos tengan miedo de modificar porque no tiene pruebas? Arregla eso y asegúrate de mostrárselo a la gente. Idealmente, el problema debería ser el dolor de todos en el trasero: ganarás más credibilidad y libertad de acción al resolverlo.
3. Las personas son tu mayor activo. Encuentra personas que estén interesadas en arreglar el estado de las cosas también, únete a ellos. Si se siente involucrado en la empresa, intente contratar a más personas con la mentalidad correcta. El poder de la manada es un verdadero negocio, cuanta más gente se dedique a hacer el software correctamente, más personas se convertirán en la misma forma de pensar, eventualmente. Un solo enemigo a veces puede desperdiciar todo tu trabajo, así que asegúrate de mantener buenos términos con todos, incluso con aquellos con quienes no estás de acuerdo.
4. Asegúrese de que el código recién agregado mejore. Anime al equipo a comenzar a hacer revisiones de código y escribir pruebas, si aún no lo están haciendo. Anime a las personas a realizar pequeñas refactorizaciones cuando cambien algo en el sistema. Trate de señalar cuándo las personas hacen un buen trabajo al respecto, trate de elogiar a las personas por hacerlo incluso un poco mejor que ayer. Asegúrese de que las revisiones de código no solo se relacionen con cosas para corregir, sino que también contengan comentarios positivos. Haga que la gente comience a automatizar cosas.
5. Descubre algunas métricas útiles para medir. La cobertura del código sería un buen comienzo en el lado del desarrollo. En el lado operativo, observe el tiempo entre el código finalizado y el momento en que entra en producción (minimícelo), preste atención a la frecuencia de las interrupciones y, lo que es más importante, al tiempo de recuperación durante todas estas interrupciones. La gerencia puede entender estos números y apreciar su mejora. Sin embargo, intente no optimizar en exceso para estas métricas.
6. Intente establecer un buen proceso de desarrollo si no está en su lugar. ¿El equipo está haciendo desarrollo iterativo? ¿Son claros y bien definidos los requisitos del gerente de producto? ¿Existe una buena alineación entre los plazos y la cantidad de trabajo por hacer? ¿La planificación se realiza de manera eficiente? Esta no es la línea de trabajo de un ingeniero, pero sin tener eso en su lugar, es realmente difícil ser efectivo.
7. Leer Sobre las formas de escribir la arquitectura y el código adecuados. Sobre buenas prácticas de ingeniería. Sobre cómo hacer cambios. Sobre hablar con la gente y hacer que quieran hacer lo mismo que tú. Sobre convertirse en un mejor pensador. Algunas selecciones personales a continuación, cosas que podría sacar directamente de mi cabeza.
8. Sepa cuándo dejar de fumar. Si el proceso de reparación de software dañado no lo hace feliz, tal vez sea una mejor idea encontrar una empresa con buenas prácticas de desarrollo establecidas y centrarse en lo que realmente es bueno.

Lecturas recomendadas para desarrolladores

Amazon.com: Decisivo: Cómo tomar mejores decisiones en la vida y el trabajo (9780307956392): Chip Heath, Dan Heath: Libros

Switch: Cómo cambiar las cosas cuando el cambio es difícil: Chip Heath, Dan Heath: 8601401261551: Amazon.com: Libros

Influencia: La psicología de la persuasión, edición revisada: Robert B. Cialdini: 9780061241895: Amazon.com: Libros

Ah, sí. Lo he hecho en muchas startups ahora.

Okay. Tomar una respiración profunda. Relajarse.

En primer lugar, esto es bastante estándar en las startups. Simplemente no hay tantos buenos ingenieros por ahí.

Segundo, olvídate de refactorizar por solo un segundo. Ese es el camino fácil, el camino hacia el lado oscuro. Quiero que te des cuenta de que, como ingeniero, tienes una gran responsabilidad contigo mismo y con la empresa, y es aumentar el valor de la empresa creando valor comercial. Sé que esto suena un poco como una mierda corporativa, pero he estado haciendo esto exactamente durante 20 años, así que escúchame:

Nos guste o no, hay muchas, MUCHAS compañías muy exitosas cuya base de código apesta. Podría nombrar algunas empresas con valoraciones multimillonarias cuyos ingenieros me han dicho cara a cara lo grave que es la situación internamente. Así que date cuenta de esto: tu empresa no necesita una base de código perfecta.

¿Entonces lo que hay que hacer?

En primer lugar, identifique las causas de la inestabilidad y la cantidad mínima de cambio en el código que se requiere para solucionarlo. Ejerza una autodisciplina extrema: no realice cambios en el código más allá de los necesarios para solucionar los problemas.

Luego, escriba una serie de pruebas de unidad / integración para detectar regresiones de inestabilidad.

Luego, asegúrese de comprender la visión del producto para su empresa. Y, a medida que el producto evoluciona, aproveche las oportunidades altamente estratégicas para refactorizar solo las piezas de código que necesita cambiar para facilitar la entrega del siguiente valor comercial.

Nuevamente, recuerde, su trabajo es entregar valor, no refactorizar o limpiar la base de código. La limpieza de la base de código debe hacerse con mucho cuidado para que no altere la estabilidad del sistema ni altere significativamente la capacidad de la compañía para entregar valor a los clientes, quienes, recordemos, no nos importa una mierda la calidad de la base de código.

Con el tiempo, a medida que aumenta la cobertura de código para las pruebas y realmente aprende la base de código y cómo debe cambiar el producto, puede volverse un poco más agresivo con respecto a la refactorización, pero siempre debe priorizar las necesidades de los clientes por encima de las suyas.

HTH

Editar: Quiero agregar algo aquí, ya que dices que hacer que el código sea estable tendrá que reestructurarse mucho y que toda la presión recae sobre ti.

Aquí hay un posible problema de comunicación y colaboración. En primer lugar, reúna al equipo de ingenieros y llegue a un acuerdo sobre el conjunto mínimo de cambios viables necesarios para estabilizar la base de código. Esta es una reunión importante, por lo que requiere que el equipo llegue a un consenso, sin embargo, muchas reuniones pueden ser una mierda.

Con un acuerdo sobre lo que se debe hacer, debe haber un acuerdo sobre quién es el propietario del trabajo y, posiblemente, un ejercicio de costo en ese trabajo. Esto hará surgir cualquier peso indebido sobre usted. Difundir el equipo extenderá la propiedad de los elementos de trabajo (que probablemente debería rastrear en algún lugar, por ejemplo, en Trello), aumentará el conocimiento compartido, etc. Ahora, aquí hay un montón de preguntas abiertas, como si usted es la única persona en La empresa con la habilidad de estabilizar la base de código. Si esto es realmente cierto, entonces hay algunas otras conversaciones que deben ocurrir. Probablemente implicando contratación, compensación y equidad.

Carreras @ MuleSoft

Esta es una situación muy compleja en la que te encuentras y es un gran problema para resolver. Pero, ¿qué haces cuando estás lidiando con un gran problema? ¡Simplemente lo divide en muchos problemas más pequeños!

El primer paso sería un buen análisis de código. Necesita una descripción general de todas las funciones, clases y métodos dentro del código y lo necesita razonablemente rápido. Si no hay herramientas de análisis disponibles, debería tomar alrededor de dos horas escribir un analizador simple que lea todos los archivos fuente y extraiga esta información. Simplemente déjelo hacer un volcado genérico en un archivo de texto y úselo como una descripción general de todo el proyecto. Puede ayudar a identificar todos los problemas más pequeños en convenciones de nombres, errores estructurales y todo lo demás.

El siguiente paso es priorizar cada pequeño problema y determinar qué problemas deben resolverse primero. Esto significa que básicamente crea una lista de errores (hoja de Excel o herramienta de informe de errores JIRA) y esta lista será útil para determinar cuánto tiempo llevará resolver todo. Hacer esta lista se hace mejor como trabajo en equipo, por lo que usar algún software de informe de errores y hacer que todos informen de los errores es mejor que simplemente usar una hoja de Excel y compartirla con todos.

Una vez que tenga una lista de todos los errores y problemas y los haya priorizado, puede comenzar a solucionarlos. Puede mostrar esta lista para demostrar cuánto trabajo tendrá que hacer y la startup sabrá que no puede superar sus límites.

Evite reestructurarlo, ya que generalmente es más trabajo. Es una startup, por lo que necesitan un producto realmente rápido o de lo contrario están en quiebra. La primera versión puede tener fallas estructurales siempre que haga lo que debe hacer. Una vez que puedan vender el producto y así obtener algún beneficio, será interesante reestructurar el código o incluso reescribirlo desde cero. Pero en este momento, debe hacer lo más difícil que los desarrolladores a veces tienen que hacer: ¡obtener un diseño estructuralmente defectuoso para que funcione correctamente con un mínimo de cambios!

Yo mismo tuve que hacer esto muchas veces y prefiero comenzar un proyecto desde cero y luego tomar el control de algún proyecto que alguien más ha creado, especialmente si ese otro desarrollador escribió algún código incorrecto. Solo tiene que encontrar soluciones rápidas …

Compárelo con las carreras de caballos … Su equipo tiene un caballo viejo con varios problemas médicos, pero todavía necesita correr simplemente porque el dueño del caballo no tiene suficiente dinero para comprar uno nuevo. Por lo tanto, cada truco se utiliza para obtener el mayor beneficio posible del caballo viejo antes de que se pueda comprar el nuevo caballo. Solo unas pocas carreras más antes de que el caballo viejo se pueda enviar a pastos verdes y se pueda comprar un caballo nuevo.

El viejo caballo es el código actual y malo y el nuevo caballo es tu nuevo código reestructurado … Primero tienes que competir con el caballo viejo por un tiempo …

Bueno, me he encontrado con tal situación, y la decisión que tomé hace 8 años cuando me encontré con esta situación me ha llevado a una mejor posición en la que estoy ahora.

La razón principal por la que estoy haciendo esto es porque el producto fue utilizado por clientes muy prometedores (en términos de sus grandes presupuestos para gastar en software), pero comenzaron a mostrar cada vez menos interés debido a los errores interminables, que Lo sé, causado por una forma amateur de desarrollar el software. Yo era el desarrollador junior, pero en mi corazón, al ver que el código se construía cada vez más todos los días, parece que tomó giros incorrectos aquí y allá, hasta que se convirtió en un monstruo mugriento, tuerto, flácido, horrendo ( perdóname por exagerar: p).

Decidí reescribir toda la base de código desde cero, en mi propio tiempo, elegir una plataforma diferente, un SDK diferente, un enfoque diferente en la técnica de codificación a un estilo OOP (era muy popular en ese entonces), una forma diferente de acceder a la base de datos (básicamente fue como crear mi propio ORM porque no había bibliotecas de ORM como hoy en día), etc. Pero aún mantenía las características principales, y también agregué más funciones que el cliente realmente quería, y a veces agregué funciones en las que el cliente no había pensado pero podría hacerles la vida más fácil. Esto realmente depende de cuánto comprenda el proceso comercial de sus clientes y de cómo se implementan en su producto.

En cuanto a mi trabajo principal en la empresa, las cosas han comenzado a ponerse feas, porque el cliente no pagará ninguna tarifa hasta que se corrijan los errores encontrados, lo cual es muy difícil de hacer porque el cambio necesario era muy fundamental y podía llevar mucho tiempo. hora de arreglarlo. El impacto fue que la compañía se disparó casi hasta la bancarrota y no pudo pagar los salarios (incluido el mío). Los salarios se pagarían tarde durante los primeros meses y continuarán empeorando en los meses posteriores.

Afortunadamente, mi propio producto acaba de terminar, se los mostré a los clientes de mi empresa y les encantó. Rápidamente querían reemplazar el software de mi empresa y probarlo durante unos meses, y estaban muy contentos de que el reemplazo fuera mucho mejor. Lo que sucede a continuación es que los contratos están activados para mí (como desarrollador único) y, por supuesto, renuncié oficialmente a mi trabajo. Además, con mi producto, eventualmente encuentro otros clientes, y continuamente renuevo y actualizo las funciones para todas las necesidades de mis clientes. Entonces, la moraleja de la historia es (creo), había una oportunidad de mercado (clientes con grandes presupuestos) que puedo aprovechar (sé cómo mejorarla).

Sin embargo, todavía soy un profesional independiente, todavía no tengo mi propia compañía, todavía soy un desarrollador único (a veces trabajo con otros como equipo), pero la vida es bastante buena y no tengo nada de qué quejarme: D.

Independientemente del camino que tome (para el registro, no creo que simplemente tomar el camino más corto para solucionarlo sea la respuesta correcta, que generalmente arroja dinero malo tras dinero malo, lo cual es terrible en la medida en que proporciona valor), necesita para saber dónde estás parado.

– ¿Eres responsable de que la aplicación sea estable, como en, es tu trabajo? O, ¿es solo tu trabajo arreglar lo que se te dice que arregles cuando se te dice que lo arregles, pero alguien más está pendiente de toda la historia?

Nunca más volveré a aceptar un trabajo en el que, si soy responsable del resultado (como en el caso, puedo ser despedido por no cumplir con métricas dadas que no sean las mías), me dicen cómo ejecutarlo sin considerar objeciones razonables.

Ejemplo: “La aplicación necesita alimentar al doble de usuarios y, en general, mejorar el rendimiento”.

Apenas sirve lo que tenemos. Es todo parches y cuñas. Por el amor de Dios, la interfaz de usuario todavía está construida en Flash. Si desea que duplique la capacidad y llegue a más dispositivos, necesitamos instalar una nueva planta baja.

“No. Harás algunas pequeñas mejoras incrementales. Y tienes seis semanas para hacerlo. Eres responsable de esta entrega. Cualquier problema, trabajas hasta que esté hecho. Tu rendimiento, bonificación, etc. se basarán en gran medida en esto ejecución.”

UH Huh. Claro que lo intentaré … a medida que actualice mi currículum y empiece a hablar con los reclutadores.

Tenga en cuenta que es mejor que esté seguro de lo que está tomando. No puede ser solo una cuestión de opinión; el hecho de que no te permitan hacerlo a tu manera no significa que su camino sea incorrecto. Pero si tiene todas las razones para creer que no se le está dando una oportunidad justa de tener éxito, póngalo por escrito. Dependiendo de cómo reaccionen, es posible que desee seguir adelante.

Olvídese del código, verifique el crecimiento de los ingresos y las métricas de tracción para el inicio, si es SaaS, entonces es aún mejor. ¿Qué tan rápido está creciendo o qué tan rápido está duplicando el MRR? “La tracción triunfa sobre todo”. Si está creciendo saludable, entonces quédate quieto o salta la nave.

En cada Startup encontraría la misma historia, si hay un producto / mercado adecuado como lo que @pmarca dice https://www.linkedin.com/pulse/m … entonces nada más importa. Debería quedarse y la caballería está en camino a medida que la empresa crece. Consulte mi última publicación Egnyte Architecture: Lecciones aprendidas al construir y escalar un sistema distribuido de múltiples petabytes – Alta escalabilidad – y puede ver que ya rediseñamos piezas centrales varias veces a medida que las versiones no escalan a medida que crece la demanda de los clientes. Muchas partes del código que eran buenas cuando tenías 100 000 usuarios no se escalarían cuando tenías 1 millón de usuarios y los refactorizaremos implacablemente a medida que llegue el momento.

También recomendaría la evolución incremental sobre la revolución, siempre trato de hacer una refactorización menor / mayor en el código que estoy tocando para cualquier implementación de error / función, es como dejar la mesa más limpia que cuando te sentabas a almorzar. De esta manera, con el tiempo, el código mejorará y agregará pruebas unitarias a su disciplina y construirá su conjunto de pruebas con el tiempo, si es disciplinado, más de un año 40 pruebas crecerán a 2000 y ni siquiera lo sabrá. En mis últimas 3 pruebas de unidad de Startups fue una de las únicas formas más efectivas de controlar la bestia del código con errores.

Ah sí, la startup en pánico. Su expectativa es que tomará su código POS con errores y rociará un poco de polvo mágico de duendes, realizará el baile mágico del código vudú en su teclado, y todo estará bien. He estado involucrado con varios de estos. Nunca funciona

La realidad es que necesita tener una conversación con ellos sobre la calidad del código. Esto generalmente sucede cuando han pasado por varios desarrolladores que no pueden entregar. La preocupación es que usted será el próximo. Les demostraría por qué esto es un problema con su producto para los clientes. Llevé una vez el sitio web de una startup a 7 usuarios potenciales en su grupo demográfico. 7 de 7 no pudieron crear un inicio de sesión para ingresar al producto. Uno de los tipos que lo construyeron estaba allí y quería discutir conmigo. Yo: si los usuarios no pueden ingresar al producto, ¿a quién le importa su producto?

La realidad es que normalmente tienes que empezar de nuevo y alguien tiene que pagar. Lo siento tanto como puedo ser que el producto anterior tenía errores, pero eso no es mi culpa. Te quitarán sus frustraciones, pero debes defenderte y no permitir que eso suceda. Mantén la calma, sé amable, pero no dejes que te intimiden. Tu startup necesita un producto que funcione. Sus usuarios necesitan un producto que funcione y sea confiable, de lo contrario irán a otro lado.

Como inicio, asumir una deuda técnica es tan inevitable como obtener un préstamo estudiantil más fresco. Pero como muchos estudiantes, esta es la primera de muchas deudas que comienzan a acumularse y, a menos que se administren adecuadamente, pueden paralizar el crecimiento futuro.

He aquí una gran cita de Martin Fowler: “Al igual que una deuda financiera, la deuda técnica incurre en pagos de intereses, que vienen en la forma del esfuerzo adicional que tenemos que hacer en el desarrollo futuro debido a la elección de diseño rápida y sucia. Podemos elegir continuar pagando los intereses, o podemos pagar el principal refactorizando el diseño rápido y sucio en el mejor diseño. Aunque cuesta pagar el principal, ganamos con pagos de intereses reducidos en el futuro ”

Algunas cosas a considerar sobre la deuda técnica que la hacen aún más aterradora que la deuda financiera.

1. No hay bola de cristal : no puede predecir el costo real de la deuda que está asumiendo.

2. La deuda técnica sufre un crecimiento compuesto con una tasa de interés creciente. Lo que puede tomar algunas semanas para arreglar en los primeros días puede tomar fácilmente meses después.

3. Alguna deuda nunca se paga .

4. Se convierte en la excusa más adelante en la línea . Los equipos cambian, la responsabilidad cambia con el tiempo. Aquellos que tomaron la licencia de la deuda y los recién llegados se quedan con el préstamo, luego usan esta deuda como una excusa (legítima) para largos plazos de entrega.

Todo dicho y hecho, como una nueva empresa necesita asumir una deuda técnica. Debe enviar el producto rápidamente, debe probar el mercado para ver si el producto se ajusta al mercado, solo tiene un pequeño equipo, por lo que no puede entregar el diseño limpio perfecto, necesita lanzar bibliotecas (aunque no es como si estuvieran saliendo de moda) en lugar de construir desde cero. Pero todas estas decisiones se suman y, en algún momento, tendrá que reducirse.

Traté de explicarle esto a mi esposa; Como estamos haciendo algunos trabajos de construcción, utilicé la analogía de construir una casa.

Puedes construir una casa muy rápido. Puede comenzar a construir las paredes, colocar algunas puertas, ventanas, agregar un techo. Te mudas y te encanta. En algún momento en el futuro que desee tener una familia, necesita más espacio para buscar construir una extensión. Ahora tiene un presupuesto mayor, por lo que contrata arquitectos, diseñadores, ingenieros estructurales, etc., que echan un vistazo a los cimientos, la electricidad y los materiales utilizados en la construcción original. Y luego vienen las respiraciones profundas, las caricias en la barbilla, las miradas preocupadas y las excusas. “Bueno ‘amor’, si hubieras construido la casa correctamente en primer lugar, este trabajo sería pan comido, pero no tienes cimientos, tus paredes están hechas de bloques de brisa barata y tus constructores originales probablemente fueron más adecuado para lego ”

Y dónde están los constructores originales para ayudar, se han ido, trabajando en un nuevo proyecto.

Tienes dos opciones.

1. Construye sobre la construcción pobre original. Si agrega otro piso, esta nueva construcción se construyó y diseñó correctamente, pero su construcción tarda el doble de lo que debería (pero no tanto como la alternativa). Cuando se completa, aún tiene problemas, las paredes se mueven, los sistemas eléctricos siguen soplando, la tubería original comienza a gotear y constantemente está llamando al servicio de asistencia.

2. Descomprime la compilación original (o al menos parte de ella), es decir, comienza de nuevo. Por supuesto, esto aumenta su costo y los plazos de su proyecto. Una vez que comience de nuevo, construye los cimientos, usa la caldera del tamaño correcto, la caja de fusibles correcta y usa ladrillos, no bloques de brisa para soportar la casa de nuevo tamaño, y lo que es más importante, esto respalda un mayor crecimiento sin dejarlo con el dolor de cabeza de las constantes llamadas al fontanero, al electricista y a los constructores.

Según nuestra experiencia, no existe una regla dura y rápida, pero en algún momento tendrá que morder la bala y pagar parte de su deuda técnica (o al menos parte de ella). Esto significará que el desarrollo del producto se detendrá, pero en el gran esquema de cosas, estará en una mejor posición después y cuando mire hacia atrás, estará agradecido.

Aquí hay algo más a considerar:

Probablemente habrá muchos lugares en el código que manejan casos de esquina, cosas que el codificador agregó después de ver el rendimiento del sistema en situaciones reales. Al refactorizar, tenga cuidado de no eliminar estos comportamientos sin pensarlo detenidamente.

Una situación común es que alguien “limpie” el código, vea que funciona bien en la mayoría de las situaciones comunes y luego descubra demasiado tarde que ha eliminado gran parte del desarrollo que se realizó para manejar casos inesperados.

Comprométete a ser parte de la solución o renuncia y no los pongas en un mal lugar en el proceso *. Muchas startups comienzan sin circunstancias ideales. También lo hacen muchas empresas. Pero no permita que la falta de fundamentos ideales o incluso buenos lo estresen más allá de lo razonable. Otras veces, los fundadores intentan lograr demasiado sin los recursos adecuados o la capitalización. Si tienen demasiadas funciones para construir, soportar, etc., entonces probablemente sea una buena idea ayudarlos a encontrar alternativas. Es posible que esa no sea una opción, pero si ese es el caso, vuelve a comprometerse o salir.

Además, mira las recompensas intrínsecas. ¿Tienes la oportunidad de ganar experiencia que no tendrías en otro lugar? ¿Te gusta el equipo con el que estás trabajando? A veces los equipos trabajan juntos en una cosa que falla, pero se reenfocan o vuelven a unirse en algo que es un gran éxito.

* Hay startups fundadas por personas para las que es malo trabajar, tienen expectativas completamente irracionales (por ejemplo, mi sitio web de Drupal será el próximo Facebook, mi equipo de desarrollo trabajará 80 horas por 40k / año), que no pueden trabajar bien con otros, en cualquier circunstancia, que ceban y cambian (por ejemplo, su compensación no es la misma el primer día que en la oferta que aceptó). Si te encuentras en esta situación, considera las circunstancias un poco más cuidadosamente.

Bueno, tienes muchas opciones. Pero como con todo lo técnico dentro de una empresa, asegúrese de que sus prioridades se alineen con las prioridades del negocio … o asegúrese de que el negocio valore las prioridades técnicas lo suficiente como para que las prioridades comerciales y tecnológicas se alineen. Puedes pelear una batalla cuesta arriba solo … o con apoyo. Con soporte definitivamente es mejor. Teniendo en cuenta que se le ha encomendado la tarea de estabilizar las cosas, parece que los comienzos del soporte están ahí.

Dado que es nuevo en la empresa, probablemente ya haya hecho algunas observaciones sobre la dinámica de los líderes y sus respectivos equipos: sus actitudes, sus hábitos, su ética de trabajo, quienes contribuirán con los pocos minutos adicionales para evitar agregar horas a deuda de tecnología más tarde, etc. Si no lo ha hecho, entonces definitivamente es algo que querrá manejar.

Parece que has echado un vistazo a la base de código. Tiene problemas. Esta bien. Tiempo de triaje. ¿Cuáles son las frutas bajas? ¿Cuáles son las correcciones de tipo de objetivo de rango medio? ¿Cuáles son las correcciones de objetivos a largo plazo? Póngalo todo en papel (o documento compartido) para que tenga un argumento de costo / beneficio para cada artículo que va a abordar. Sepa quién posee las áreas de código y cuál es su participación en él. Hay personas que toman bien las críticas, y hay quienes no. Su enfoque hará una gran diferencia en si tiene apoyo y puede hacer un trabajo corto de las cosas o si luchará con la gente con uñas y dientes en una batalla pasiva-agresiva.

En general, básicamente tienes dos campos y las variaciones intermedias:

1) Los ingenieros que saben lo que están haciendo y debido a circunstancias (mala gestión, recursos limitados, plazos restringidos, cambios de prioridad, etc.) terminan creando código que no es representativo de su mejor trabajo. Saben esto y se sienten mal por esto, pero su carga de trabajo, la interrupción del trabajo como la extinción de incendios y / o la acumulación de pedidos les impide hacer lo que hay que hacer.

2) Ingenieros que no saben que están inyectando problemas en el sistema … o tal vez no les importa. Es decir, la característica se desarrolló e implementó para producir. No me importa si puede manejar la carga real / etc. Es mucho más difícil convencer a estas personas, ya que creen que tienen razón y, debido a que eliminan características muy rápidamente, pueden verse como súper estrellas altamente productivas.

[Nota: me doy cuenta de que hay más que esto, pero por el bien de evaluar una situación, estoy usando estas dos personas con fines ilustrativos. Hay grandes equipos que se encuentran muy por fuera de los 2 grupos enumerados anteriormente y, en la mayoría de los casos, solo tener un chat a la hora del almuerzo puede provocar / desencadenar cambios. Situación ideal. 🙂]

Con el primer grupo, es cuestión de tiempo / gestión de recursos. Disminuya su carga de trabajo o reduzca la presión para que puedan descomprimirse, luego trabaje con ellos para abordar los problemas de deuda tecnológica y estabilidad paso a paso.

Con el segundo grupo, ese es un cambio más grande: la cultura. Si la compañía está compuesta principalmente por el segundo grupo y tiene el apoyo total de la administración, simplemente no es realista tratar de estabilizar las cosas cuando pueden anularlo.

Si estuviera en su situación, la evaluación anterior es lo que haría primero … básicamente, determinar si las personas y el entorno permiten arreglar la base de código. Si no es así, entonces la tarea es una tarea tonta y es mejor que solicite otra tarea o busque otro trabajo. Si el entorno no es completamente contrario al objetivo de estabilizar el entorno, entonces tendrá que construir su caso, determinar cuáles son los obstáculos y los problemas para los ingenieros que están escribiendo el código, y ver si puede conseguir que la gerencia compre -en / soporte para cualquier idea que quiera implementar. Dado que cualquier limpieza / arreglo sería casi todo el costo de carga frontal en tiempo y recursos humanos para una ganancia de estabilidad y productividad en el futuro. Su propuesta de cambio debe identificar estos costos y riesgos, así como las recompensas.

No indicó su rol real o el nivel de influencia. Por lo tanto, parte o la totalidad de lo anterior puede no ser aplicable. Sin embargo, creo que es clave entender la situación con las personas y cómo las cosas llegaron al punto en que lo hicieron.

¡Buena suerte en tus esfuerzos!

Me uní a una startup recientemente y descubrí que su aplicación no es estable, no es escalable, tiene muchos errores, demasiadas correcciones de parches y su interfaz de usuario me sorprende muchísimo, pero tienen miles de clientes.

Mi colega y yo, que resulta ser el arquitecto recién incorporado, solo tenemos un trabajo en la mano y es hacer que este producto sea estable y escalable. Solucionamos cientos de errores en poco tiempo, pero finalmente decidimos que teníamos que volver a escribir todo desde cero. Reutilizamos el esquema de la base de datos y los algoritmos con cambios menores, pero todo lo demás es nuevo, teniendo en cuenta que vamos a contratar a muchos buenos ingenieros en el futuro y no queremos que se quejen de código de mierda. Incrementamos la interfaz de usuario, estructuramos el código correctamente, redujimos el número de llamadas a la API, eliminamos marcos y bibliotecas no deseados que solo hacían que el producto fuera más lento y están escribiendo pruebas unitarias en todas partes.

¡Vale la pena el tiempo!

Pero si no tiene el tiempo o el permiso para volver a escribir, concéntrese solo en las pruebas de la Unidad. Escriba tantos como sea posible para evitar futuros errores.

Esto es lo que haría:

1. Obtenga “números” y “estadísticas”

1. métricas de calidad de software (use herramientas automatizadas para analizar el código para encontrar “áreas problemáticas”: complejidad, dependencias cíclicas, etc.)
2. recuentos de errores históricos, es decir, ¿está aumentando el número de errores reportados? ¿Qué “áreas” de la base del código han sido (históricamente) malas, qué desarrolladores / aspectos del código necesitan mayor atención?

1. Teniendo en cuenta lo que sabe sobre los problemas que acechan sobre el código, prestando especial atención a:

1. código / componentes que parecen estar en constante flujo (cambia cada versión, muchas correcciones o errores abiertos / corregidos)
2. código de manejo de excepciones (cómo se informan las excepciones).
3. Errores / revisiones reabiertas: (quién sigue registrando el código que no funciona)

1. Averigüe qué (código) y quién (desarrolladores) necesitan ayuda … (Aquí puede darse cuenta de que algún desarrollador pobre se “quedó” atascado con un código incorrecto que no escribió originalmente, “los entrevistaría” sobre por qué su código es en el estado en que se encuentra (con suerte, saben que su código es malo, si no tiene otro problema)
2. Priorizar qué código necesita ser refactorizado

1. El mayor beneficio para el dinero es “arreglar” cómo se informan las excepciones, que lo ayudarán a identificar lo que está mal más rápido para que pueda corregir los errores más rápido.
2. asegúrese de comenzar a aumentar las pruebas funcionales en torno a lo que parece romperse mucho. (lo ideal es que cada vez que solucione un error se realice una prueba funcional que cubra el escenario que ocurrió) …

1. Explique que lo mejor para ellos es ser proactivo (salir adelante) de los errores y cómo (continuar en el camino actual) es insostenible (eventualmente se ahogará en errores y no tendrá espacio para mejorar la aplicación)
2. “Véndelos” con la idea de que esto no solo generará una inversión por el valor comercial de dinero, sino que fortalecerá al equipo y mejorará la aplicación. Establecer objetivos / metas alcanzables

1. reducir el tiempo promedio para corregir errores en un 15%
2. disminuir el recuento de errores de reapertura en un 50%
3. Disminuir la tasa de errores que se abren en un 10%

Con base en los comentarios, decida si esta compañía es adecuada para usted … Espero que pueda presentarles una razón racional para solucionar estos problemas. Es posible que la administración necesite convencer, tal vez quieran programar esta acción en el futuro … Pero si te obstruyen y no puedes convencer a tus gerentes de que este es un curso de acción razonable, es posible que desees considerar cambiar de trabajo … No perdería mi tiempo con una empresa que le ofrece:

• Desventaja (la responsabilidad de la corrección de errores) sin
• Upside (la autoridad para mejorar las cosas para ustedes mismos)

La única solución posible es “empezar de nuevo”.

Ok, hay una segunda solución: refactorizar el código existente.

Y hay un tercero: hacer las dos cosas.

Empiezas de nuevo y piensas cómo te gustaría que se viera el código. Te das cuenta de que tendrás que codificar mucho.

Luego, lee el código existente e intenta refactorizarlo. Sacas las piezas y las vuelves recargables.

Tal vez pueda tomar algunas de las piezas, ponerle algunas pruebas y luego reutilizar ese código en su propio código.

Ir y venir haciendo ambas cosas. Conceptualiza el problema y la solución, reutiliza los bits que le gustan, refactor, refactor, refactor. Prueba todo

Te aseguras de que el código funciona, ¿verdad?

Si no funciona, “comience de nuevo”. Probablemente no hay nada bueno allí de todos modos.

Érase una vez que trabajé en un proyecto exactamente así. Nada tiene sentido. No hay requisitos escritos, los requisitos dados eran A + B = C, pero A era un Excel sin ningún concepto de negocio, lo mismo para B, lo mismo para C. Los operadores + y = se definieron libremente.

Varias ecuaciones como esa escritas en lenguaje natural y nadie podía explicar exactamente lo que significaban.

No hay forma de probarlo, pero el proceso tuvo muchos Heisenbugs.

También había un motor de flujo de trabajo dentro del proyecto, modificado, y no había una indicación clara de cómo se modificó. Además, todos sabían que el flujo de trabajo no era necesario, solo se usaba para impresionar a los clientes.

Y sí, nada funcionó. ni siquiera podía compilar en un solo paso, tenía que hacer 11 pasos manualmente. ¿Me he perdido algo?

En algunos casos, una reescritura es la única solución. Pero no puede reescribir si no tiene requisitos claros.

También casi me olvido: sin control de código fuente, sin máquina de compilación, sin máquina de preparación para hacer pruebas manuales (puede haber errores en las pruebas unitarias automáticas también) y necesita reprobar cuando llega un informe de error.

Sé honesto, pero no seas pesimista.

Una de las cosas más aterradoras para las personas no técnicas es depender de una persona técnica que sigue diciendo cosas aterradoras sobre el código. Los directores ya están preocupados, lo que quieren es tranquilidad y resultados positivos, no descripciones aterradoras de los problemas en los que ya saben que están.

A veces, el código es realmente horrible, pero solo me he enfrentado a una situación imposible una vez, cuando estaba trabajando en un código donde * cada * método suprimía todas las excepciones.

Hay una diferencia entre desordenado e inestable. El código desordenado es frecuentemente inestable, pero a veces es desordenado.

Vea si puede extraer registros de fallas del código, encontrar los peores puntos de inestabilidad y combatir incendios. Continúe hasta que las excepciones dejen de suceder.

Si puede estabilizar el código, explique que será muy difícil trabajar con el código hasta que lo refactorice. Luego, deje que el cliente decida cómo quiere que pase su tiempo.

Es bastante simple. La calidad promedio del código y los productos de software asociados es, en el mejor de los casos, deficiente. Raramente veo proyectos que hagan algo relacionado con el análisis de problemas o la ingeniería de requisitos o incluso el proceso de construcción, prueba y mantenimiento correcto.

Internamente, he sido testigo de equipos que afirman sentarse frente a un proyecto problemático, los problemas de defectos aumentan e incluso los defectos críticos se clasifican solo para informar una mejor situación a la gerencia. Básicamente, la mayoría de las veces hay un punto en el que las personas comienzan a maquillar al cerdo que está en producción.

Hay muchas cosas mal con la industria.

Por otro lado … funciona. Todavía me sorprende cada vez que soy testigo de esto. Lo envían, se informan algunos problemas, la prensa a veces pone los dedos en las heridas, las relaciones públicas y el paso de administración superior frente a las cámaras y dicen que “es un producto nuevo, todavía tiene algo que solucionar, dale tiempo, su complejo yadda yadda “Pero sobre todo esto funciona.

Y no preguntes por la seguridad. Apenas hay un producto que incluso tenga las medidas de seguridad más básicas correctas.

Por lo tanto, como regla general, sea honesto solo con su gerente directo / líder de equipo. Déjalo hablar. Centrarse solo en el producto. El objetivo no es obtener defectos ni producir un muy buen producto. Su objetivo es producir un producto lo suficientemente bueno. El resto se trata de marketing y correr la voz. No gana el mejor producto, pero sí el que tiene el mejor marketing.

Cuando sienta la necesidad de mejorar, encuentre un punto donde pueda separar las partes. A la parte de nivel inferior agregue algunas pruebas más. Cuanto mejor se pruebe la base, más probabilidades hay de evitar que sea difícil detectar y corregir defectos (que son los costosos).

Las más problemáticas son las situaciones en las que soluciona un problema y crea dos nuevos. Se llama el tren del dolor o la situación de la hidra. Si ve que el tren del dolor se acerca sigilosamente, analice los últimos arreglos y cambios. ¿Qué partes de la aplicación se cambian / arreglan con frecuencia? Enfoque para mejorar la calidad solo donde el pasado ha demostrado que existe un problema serio de calidad.

–

Como ejemplo, solo piense en el framework Spring (solo conozco el puerto Java). Si marca la implementación, es uno de los trabajos más pobres que he revisado. Fue pobre en el año 2003/4 y desde entonces no se ha hecho nada al respecto. Pero adivinen que todo este ‘desastre’ es un gran éxito. El año pasado tuve un puesto de contrato con Spring (nuevamente). Hizo el trabajo, pero en cuanto a calidad, Spring empeoró las cosas. Pero gracias a Spring ahorras mucho más tiempo que no te importa el efecto negativo de calidad que tiene Spring.

Así que apégate a la meta. Haga un producto lo suficientemente bueno, identifique los puntos calientes por la frecuencia de cambio, sepárelos si puede, aumente la cobertura de prueba en la base para evitar los defectos y los defectos restantes sean más fáciles de detectar y reparar. El resto no es nada de qué preocuparse. La industria simplemente funciona de esta manera.

Sí, bienvenido a escribir software.

Simplemente pones las horas, aplicas lo básico y listo.

Tome buenas decisiones sobre qué solución, en orden. No reescriba grandes secciones del sistema de una sola vez. Esa es una idea terrible. En cambio, elija algo que desee que haga el producto, por ejemplo, desde la perspectiva del usuario, e impleméntelo.

Si ve áreas para limpiar a medida que avanza, para esa característica única, haga algo de eso. Tendrá que hacer eso, naturalmente, porque cambiar el código siempre requiere reescribir el código existente. Eso es casi una verdad …

De todos modos, eliminas las cosas de una en una, y el producto mejorará lentamente.

El truco es darse cuenta de que incluso si reescribió todo el sistema usted mismo para que sea su mejor trabajo, y luego regresó a él 10 años más tarde, le parecería terrible, suponiendo que no se aflojó durante esos 10 años.

La calidad del código se basa en la perspectiva. Siempre estamos atrapados con una mala infraestructura. Solo trata con eso.

Siempre estamos reestructurando el código. Eso es lo que hacen los programadores. Eso es lo que nos pagan por hacer. ¿Te pagan? Yo espero que sí. De lo contrario, también me quejaría.

No refactorice ni reescriba el código, no chorro.
Por malo que sea, a nadie le importa mientras funcione.

En su lugar, comience a escribir pruebas (unidad, integración …) para detectar los errores más grandes conocidos o los que más molestan a los usuarios. Necesitas mantenerlo funcionando.

Una vez que tenga una prueba replicando el error, puede comenzar a solucionarlo. Pero haga esto con un mínimo esfuerzo y cambios.

No subestimes el tiempo y el esfuerzo invertidos en la base de código existente, por pobre que sea. El código está lleno de conocimientos ocultos y suposiciones que están entrelazadas. Un cambio importante en una parte puede colapsar varias otras partes, y obtendrá un efecto dominó, arreglando cosas por todas partes.

Vaya despacio y sea metódico al respecto, no se apresure a reescribir, ya que no vale la pena.

Mira, bienvenido a las startups. Lo siento si mis suposiciones son erróneas, pero supongo que la compañía está en la etapa de pasar de la semilla a la ronda A o de alrededor de 10 empleados a 30. En primer lugar, los ingenieros o, de hecho, los ingenieros que crearon esta cosa en primer lugar Probablemente no apestaba. Por lo general, hay una barra bastante alta para el fundador técnico y el primer ingeniero. Lo que definitivamente estaban era bajo el arma, severas limitaciones de tiempo. Las opciones eran probablemente algo así como

1. Puede tener errores y tener muchos problemas
2. No puede existir en absoluto

El trabajo de los primeros ingenieros es dar vida a algo de la nada o peor que nada, un mapa de productos en constante cambio en muy, muy poco tiempo. Gracias a estos esfuerzos, la compañía ahora puede contratar a personas como usted para que vengan con los anteojos para adultos y que realmente funcionen sin problemas. Así que déjelos un poco, al menos los que todavía están allí recuperando el aliento y aún no se han mudado a otra startup.

Sí, hay muchas cosas, grandes cosas que abordar en un corto período de tiempo en las startups. Parece que sabes lo que debe suceder para que esto pueda encaminarse. Parece que sientes que será un desafío. Bueno, adivina qué, eso es exactamente lo que deberías estar haciendo entonces. ¡Solo arremángate y hazlo! Use un entorno de sandbox para no desmantelar todo lo que otras personas están usando. Una vez que empiece, puede descubrir que el estrés comienza a desaparecer. Eso es lo bueno de las startups, grandes desafíos con plazos cortos pero las consecuencias son completamente diferentes. Si no tienes éxito, pero todos te vieron haciendo lo mejor que puedes, no deberías o no deberías culparte demasiado, pero si tienes éxito y llevas a toda la compañía de los primeros días de los errores a la maquinaria de ingeniería para adultos, entonces oye, deberías ser bien recompensado. Tal vez no en $$ porque podrían no tener mucho, pero al menos serás un miembro del equipo muy valorado.

Recuerde, pueden fingir pero la gente sabe que es difícil. Saben que esos primeros ingenieros eran inteligentes y saben que debe ser un fastidio arreglar sus agujeros.