¿Ser estricto o pragmático?

Estoy empezando a darme cuenta de que el desarrollo de software es (entre otros) un proceso de preguntarse constantemente. Preguntas sobre la calidad del código, separación de preocupaciones, minimización de dependencias, ...

Pero la pregunta principal es: ¿hasta dónde puede llegar sin terminar en un hospital psiquiátrico?

Estoy solicitando un nuevo trabajo. Ayer estaba con un posible futuro empleador que quería probar mis capacidades de programación. Uno de los ejercicios fue: explicar qué hace este código. Revisé un código de la aplicación (winforms en vb.net) que desarrollan (es una aplicación administrativa para un hospital). Esto me dio la oportunidad de ver cómo abordan las cosas y fue bastante decepcionante.

Algunos ejemplos:

• Vi en alguna parte: Llamar [insertar el nombre de la subrutina aquí] -> Me llamó la atención: ¿no es algo de VB6?
• Tienen una capa de datos separada, que usa ado.net, pero un método que tuve que examinar devuelve un conjunto de datos a la capa de llamada. Por lo tanto, separe o no la capa de datos, la aplicación está vinculada a ado.net (que tampoco podría ser un problema si nunca cambian a otro enfoque de acceso a datos).
• Ese conjunto de datos se lee tal cual, por lo que sigue siendo un enfoque centrado en los datos (por supuesto, uno puede discutir cuánta lógica / comportamiento puede poner en clases como "Paciente" o "LabAnalysisRequest".
• También creo haber visto la construcción de una consulta sql por concatenación de cadenas.
• Utilizan procedimientos almacenados (lo que, para mí, significa: dispersión de la lógica)
• sin mención de vistas / controladores: todo depende de la forma
• Lo más feo que vi fue:

      Si TestEnvironment.IsTesting entonces
         someVar = [algún valor codificado]
      más
         someVar = [algún valor recuperado dinámicamente]
      terminara si
      [resto de la función aquí]
  

Todo es muy diferente de lo que aprendí en la escuela: capa de dominio (agnóstico de persistencia), capa de persistencia, capa de presentación, pruebas unitarias, ...

Entonces reformulo mi pregunta: ¿cuán fundamental o dogmático debería ser uno? ¿Hasta qué punto debe un programador apegarse a sus principios o simplemente escribir código que haga el trabajo?

Sé que eso no responde directamente a su pregunta, pero sigo sintiendo que esto vale más que un comentario:

Cuando haces una entrevista de trabajo, los estás entrevistando tanto como a ti . Rompe el hábito de ver una entrevista como algo a lo que te arrastras sobre tu vientre rogándoles que te ofrezcan algo. Te pagan, pero tú también los revisas . Si no les gustas, no te contratarán. Si no te gustan, no vayas a trabajar allí.

Sí, en la industria, con una base de código heredada de diez años que ha sido pirateada con el tiempo por tres docenas de desarrolladores con diferentes antecedentes, habilidades y pasión, impulsada por plazos ajustados, falta de recursos y restricciones financieras, el código nunca Mire la forma en que (debería) haber aprendido que debería verse. Tendrás que hacer algunas concesiones. Pero cuántos, y dónde trazas la línea, depende totalmente de ti.
Por supuesto, los trabajos son más difíciles de encontrar con menos concesiones. Pero podrían ser más agradables.

FWIW, hasta ahora (> 10 años en la industria) nunca trabajé en una gran empresa con muchos desarrolladores (~ 30 desarrolladores fue la mayoría, una docena de la norma), porque es mucho más probable que cambie algo en una pequeña empresa. Mientras gane suficiente dinero para no matar de hambre a los niños, no quisiera ser una pequeña rueda dentada en una gran empresa, donde todo lo que tengo que hacer es girar en sincronía con el resto de los engranajes.
Rechacé las ofertas de trabajo después de ver las pruebas que querían que pasara. Soy un desarrollador de C ++, y hay muchas pruebas de C ++ que son tan malas que hace que tus uñas de los pies se curven con disgusto, y no quiero pasar mi tiempo luchando contra molinos de viento porque contrataron a imbéciles que no pueden escribir código limpio.
También dejé puestos de trabajo después de unos meses porque su filosofía de programación (objetivos a corto plazo, no importa el próximo año) no encajaba con mis habilidades (estabilidad del código a largo plazo), a pesar de que dijeron diferentes en la entrevista.

Nunca escriba código que simplemente haga el trabajo. Sin embargo, esté igualmente dispuesto a examinar su doctrina. Solo porque lo aprendiste en la escuela, no significa que sea un pensamiento actual, o incluso un pensamiento válido. El ciclo de vida del diseño de software se ha vuelto obsoleto debido a que la programación tiene que ser más reactiva al mundo de los negocios. A veces, las soluciones de software vinculadas de manera incómoda están vinculadas de manera incómoda porque las piezas se reemplazaron según el tiempo permitido.

Aquí hay una lista de problemas que he compilado que determinará qué tan bien encaja en el estilo de vida de codificación de una empresa.

1. Cuánto valoran dejar de lado el tiempo para refactorizar y actualizar su base de código. La forma en que ven la actualización de la base del código será un factor determinante en la forma en que encajan.
2. ¿Con qué frecuencia compran terceros en lugar de codificarlos internamente?
3. ¿Qué piensan del software de código abierto? ¿Se dan cuenta de que tienen flexibilidad para alterar el código? ¿Lo ven de la misma manera que comprando a terceros?
4. Trabajarás en una determinada capa de abstracción. ¿El equipo con el que interactúa determina su interfaz para usted? Qué capa / equipo / lado de la interfaz tiene más poder en la toma de decisiones.
5. ¿Cuánto escuchan los supervisores a los programadores cuando toman decisiones? Cuando un programador arroja una bandera roja, el supervisor se detiene y revisa su decisión.
6. ¿Considera la gestión de programadores experimentados? ¿Cómo ven su experiencia? ¿Es válida su experiencia? ¿Están dejando que la experiencia obsoleta afecte la toma de decisiones?
7. ¿Qué tan pegajoso es el código base?
8. ¿Con qué frecuencia actualizan sus herramientas de programación (IDE, etc.)

Las respuestas a estas preguntas se ajustan mejor a cómo valorará su estilo de vida de programación, que ver si coinciden con su dogma.

El dogma inevitablemente se romperá (simplemente no tenemos tiempo para actualizar X). Sin embargo, las prioridades definirán cuánto choca con su estilo y la toma de decisiones.

Creo que hay que sopesar esto como parte del todo. Recuerdo que uno de mis primeros trabajos fue un puesto en un grupo que me dijo que estaban haciendo C ++ orientado a objetos, que era lo que acababa de hacer varios años en la escuela.

Su autoevaluación estaba equivocada: estaban haciendo una C. algo gruesa. Todavía tenía un diseño muy funcional en la naturaleza y tuve que ir a buscarme un libro en C para enseñarme printf y getf y otros mecanismos de C que nunca había aprendido. El hecho de que nadie en el equipo se haya dado cuenta de cómo a C le gustaba su código indica cuán fuera de lugar había caído este "diseño C ++". Mi objetivo en ese momento era desarrollar OO, así que esto fue un poco desagradable.

Pero al final me alegro de haberme quedado con el equipo. Eran un grupo dinámico de personas muy inteligentes y me mojé los pies con muchos problemas difíciles, pude trabajar todo el ciclo de vida y las cosas que aprendí sobre el dominio del problema (PKI) han impulsado mi carrera desde entonces. El trabajo que el equipo estaba haciendo en el espacio funcional fue increíble y todavía pienso con mucho cariño en ese producto y esa experiencia laboral. Mejor aún: sigo trabajando con algunas de esas personas hoy (varias compañías más tarde), siguen siendo una inspiración y todavía estamos haciendo un buen trabajo.

No creo que la implementación perfecta de las mejores prácticas de un lenguaje de codificación sea el resultado de una buena experiencia laboral o un buen equipo: el trabajo que impulsa una carrera es mucho más que eso, y si el producto es decente calidad, el equipo tiene condiciones de trabajo decentes (como la prueba de Joel) y el equipo está lleno de personas que son inteligentes y hacen las cosas, entonces la perfección de la implementación es secundaria. Elimine factores como el buen trabajo, la buena gente, las buenas condiciones de trabajo, y no vale la pena quedarse, independientemente de si el código está extrañamente elaborado.

¿Cuán fundamental o dogmático debería ser uno? ¿Hasta qué punto debe un programador apegarse a sus principios o simplemente escribir código que haga el trabajo?

Lo más importante para recordar aquí es ¿cuál es su propósito ?

En la mayoría de las empresas, su propósito en la vida no es escribir código perfecto. Su propósito es entregar valor para el usuario. Escribir un buen código suele ser la mejor manera de entregar un buen producto que también sea fácil de mantener, solucionar problemas y desarrollar.

Un buen código es una herramienta que debe aplicar donde le da un buen ROI.

Algunos ejemplos:

1. Pasaría mucho tiempo diseñando y codificando mis API, especialmente la API de mi nivel empresarial. Muchos otros programadores los van a usar y les ahorrará mucho tiempo y problemas si están diseñados adecuadamente
2. Relajaré un poco las reglas en mi capa de presentación. Allí estaré más inclinado a sacrificar la "perfección" del código a favor de agregar más funciones

En pocas palabras, debe tener principios, pero también debe ser lo suficientemente flexible como para romper esos principios cuando traen más daño que valor.

Trabajé para un minorista de comercio electrónico durante algunos años. Cuando comencé allí, el código para sus aplicaciones internas estaba escrito en VB para MS Access, y fue horrible por decir lo menos. Tenía un equipo de 3 desarrolladores, y en los próximos años reemplazamos esto con las aplicaciones VB.Net adecuadas.

Pero como mi presupuesto de contratación era extremadamente limitado, solo podía permitirme a programadores junior. Y, por supuesto, el código que produjeron no era tan bueno. Pero funcionó, y la compañía utilizó estas aplicaciones para ganar dinero, todos los días.

Y luego comencé a trabajar con mis muchachos. Un poco de capacitación en OOD, en diseño de bases de datos, en MVC y C #. Y con los años, las cosas mejoraron. Cuando me fui después de 4 años, la base de código todavía no era excelente, pero era 100 veces mejor que cuando comencé.

Una situación como la que usted describe es a menudo la consecuencia de tener que conformarse con los recursos disponibles. No vivimos en un mundo ideal. Al mismo tiempo, esta es una gran oportunidad para marcar la diferencia.

Por cierto: algunas de estas aplicaciones todavía están en uso, prácticamente sin cambios desde hace aproximadamente 3 años, y todavía ganan dinero.

Creo que apegarse a tus principios es muy importante. Siempre debe esforzarse por producir el mejor código posible dentro de las restricciones dadas. Sin embargo, si agrega "nunca debería tener que leer o cambiar un código incorrecto" a su lista de principios, tendrá muchas dificultades para encontrar trabajo. Recuerde que el 50% de los programadores se graduaron en la mitad inferior de su clase. Incluso en un equipo unipersonal, "hoy usted" está mejor calificado para resolver un problema que "el mes pasado". Poder trabajar con código no ideal es solo parte del trabajo.

Muchos empleadores reconocen eso, por lo que el código que le dan para leer puede ser representativo del peor código en su base de código, en lugar de ser el mejor. Si eso no está claro por el contexto, debe preguntar. Un colega con el que a veces entrevisto tiene una página de código que escribió mal a propósito solo para usarla como una pregunta de entrevista.

En el 99% de los casos, debe atenerse al «dogma» como lo llama. El dogma está hecho por personas experimentadas durante años de práctica, y lo que parecería pragmático en algún momento, a menudo no lo es. Esto suele ser más relevante que el hecho de que no eres lo suficientemente bueno para manejar ese problema correctamente.

Sin embargo, no sigas el dogma a ciegas. Recuerde qué conclusiones llevan a las personas a seguir ese dogma. Porque encontrarás una pequeña porción de casos en los que no se debe seguir. De todos modos, esos casos serán muy raros y siempre debe discutir con otros programadores experimentados antes de tomar tal decisión.

Sé estricto cuando sea importante. ¿Estilo de llaves (u otras convenciones de codificación)? No importa. Use el que usa la tienda. ¿Romper la encapsulación (u otros principios fundamentales de programación) sin una buena razón? No es tan trivial

Stack Exchange usa tablas para el diseño (al igual que muchos de los otros sitios web importantes que están haciendo dinero ). ¿Eso hace que salga humo de los oídos puristas? Claro que si. Pero el pragmatismo vence a la pureza, siempre. El producto de envío gana sobre conseguirlo perfecto, siempre.

Toda la capa de dominio, la capa de persistencia, la capa de presentación, la prueba de unidad todavía es relativamente nueva, desde un punto de vista histórico. Hay muchas cargas de software que todavía usan un modelo Cliente / Servidor, y no se cambiarán al último estilo arquitectónico solo porque es "mejor".