¿Ser estricto o pragmático?

Sé que no responde directamente a tu pregunta, pero sigo creyendo que vale más que un comentario:

Cuando haces una entrevista de trabajo, los estás entrevistando tanto como lo están entrevistando a ti . Rompa el hábito de ver una entrevista como algo que se arrastra en su barriga suplicando que le ofrezcan algo. Ellos lo comprueban a usted, pero usted les paga a ellos también. 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 heredado de diez años de antigüedad que ha sido pirateada a lo largo del tiempo por tres docenas de desarrolladores con diferentes antecedentes, habilidades y pasión, impulsados por plazos ajustados, falta de recursos y restricciones financieras, el el código nunca se verá de la manera en que usted (debería) haber aprendido que debería mirar. Tendrás que hacer algunas concesiones. Pero cuántos, y dónde trazas la línea, eso depende totalmente de ti.
Por supuesto, los trabajos son más difíciles de encontrar con menos concesiones que haces. Pero podrían ser más agradables.

FWIW, hasta ahora (> 10 años en la industria) nunca he trabajado en una gran empresa con muchos desarrolladores (~ 30 desarrolladores era lo máximo, una docena de la norma), porque es mucho más probable que cambies algo en una pequeña empresa. Mientras gane el dinero suficiente para no matar de hambre a los niños, no me gustaría ser una pequeña rueda dentada en una gran empresa, donde todo lo que tengo que hacer es sincronizarme con el resto de los engranajes.
Rechacé las ofertas de trabajo después de ver las pruebas que querían que aprobara. Soy un desarrollador de C ++, y hay muchas pruebas de C ++ que son tan malas que hacen que las uñas de los pies se enrosquen de disgusto, y no quiero perder mi tiempo luchando contra los molinos de viento porque contrataron a idiotas 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 año que viene) no encajaba con mis habilidades (estabilidad del código a largo plazo), a pesar de que dicen algo diferente en la entrevista.

Nunca escriba el código que simplemente hace 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, ni siquiera un pensamiento válido. El ciclo de vida del diseño del 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 torpe se vinculan de manera incómoda porque las partes se reemplazaron según el tiempo permitido.

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

1. Cuánto valoran el tiempo de configuración aparte del refactor y la actualización de su base de código. La forma en que vean la actualización de la base de código será un factor determinante en la forma en que encaja.
2. ¿Con qué frecuencia compran terceros en lugar de la codificación interna?
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 compran terceros?
4. Estarás trabajando en una cierta capa de abstracción. ¿El equipo con el que te relacionas determina tu interfaz para ti? La 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 lanza una bandera roja, el supervisor se detiene y revisa su decisión.
6. ¿Consideras la gestión de programadores experimentados? ¿Cómo ven su experiencia? ¿Es válida su experiencia? ¿Están dejando que la experiencia desactualizada afecte la toma de decisiones?
7. ¿Qué tan pegajosa es la base de código?
8. ¿Con qué frecuencia actualizan sus herramientas de programación (IDE, etc.)?

Las respuestas a estas preguntas se ajustan mejor a la forma en que valorará su estilo de vida de programación, en lugar de 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 enfrentas con su estilo y toma de decisiones.

Creo que tienes 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 en la escuela durante varios años.

Su autoevaluación estaba equivocada: estaban haciendo algo grueso C. Todavía tenía un diseño funcional en la naturaleza y tuve que conseguir un libro de 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 lo que le gusta a C de su código fue lo que indica que fuera de la marca este "diseño de C ++" había caído. Mi objetivo en ese momento era estar desarrollando OO, así que fue algo desagradable.

Pero me alegro, al final, de que me quedé con el equipo. Eran un grupo dinámico de personas muy inteligentes y me mojé los pies con muchos problemas difíciles, tuve que trabajar todo el ciclo de vida y las cosas que aprendí sobre el dominio del problema (PKI) han alimentado mi carrera desde entonces. El trabajo que el equipo estaba haciendo en el espacio funcional fue increíble y aún pienso con mucho cariño en ese producto y en esa experiencia laboral. Mejor aún: sigo trabajando con algunas de esas personas hoy (varias empresas más adelante), 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 fundamento de una buena experiencia laboral o un buen equipo: el trabajo que alimenta una carrera es mucho más que eso, y si el El producto tiene una calidad decente, 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 con ellos, ya sea que el código esté extrañamente unido o no.

  

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

Lo más importante que debes recordar aquí es ¿cuál es tu propósito ?

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

El código bueno es una herramienta que debe aplicar donde le proporciona un buen retorno de la inversión.

Algunos ejemplos:

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

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

Trabajé para un minorista de comercio electrónico durante algunos años. Cuando comencé allí, todo el código para sus aplicaciones internas estaba escrito en VB para MS Access, y era horrible por decir lo menos. Tuve 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 pagar los programadores junior. Y, por supuesto, el código que produjeron no era tan bueno. Pero funcionó, y la compañía usó estas aplicaciones para ganar dinero, todos los días.

Y luego empecé a trabajar con mis chicos. 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, el código base aún no era muy bueno, 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 realmente hacer una diferencia.

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

Creo que seguir 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 el 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 de un solo hombre, "hoy usted" está mejor calificado para resolver un problema que "el mes pasado". Ser capaz de trabajar con un código no ideal es solo una 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 su mejor. Si eso no está claro en el contexto, deberías preguntar. Un colega con el que a veces me entrevisto tiene una página de código que escribió mal a propósito para usar como una pregunta de entrevista.

En el 99% de los casos, debe atenerse al «dogma» como lo llama. El dogma es hecho por personas experimentadas durante años de práctica, y lo que parece pragmático en algún momento realmente no lo es. Por lo general, esto es 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. Recuerda qué conclusiones llevan a las personas a seguir ese dogma. Porque encontrarás una pequeña porción de casos donde no se debe seguir. De todos modos, esos casos serán muy raros y siempre se debe discutir con otros programadores experimentados antes de tomar una decisión de este tipo.

Sé estricto cuando importa. ¿Estilo de refuerzo (u otras convenciones de codificación)? No importa. Usa el que usa la tienda. ¿Rompiendo la encapsulación (u otros principios fundamentales de programación) sin ninguna buena razón? No es tan trivial.

Stack Exchange utiliza tablas para el diseño (al igual que muchos de los otros sitios web importantes que son ganar dinero ). ¿Eso hace que salga humo de las orejas puristas? Claro que sí. Pero el pragmatismo vence sobre la pureza, siempre. El envío del producto gana a la perfección, en todo momento.

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