Si un codificador fluido no tiene en cuenta las buenas prácticas, ¿su fluidez no funciona en su contra? [cerrado]

Estoy trabajando en una aplicación bastante grande y con errores, y debido a la forma en que está escrita (te ahorraré detalles, pero viola las reglas en la mayoría de las áreas que se te ocurran), es casi imposible desarrollarla sin una refactorización importante.

Una parte importante de la aplicación fue creada por pasantes, n00bs, etc .; pero también ha habido un programador en el rango de Desarrollador maestro, y con toda humildad, el código que dejó también es dudoso, quizás de una manera diferente, pero aún así.

Por supuesto, su código tiende a hacer el trabajo, la mayoría de las veces, pero generalmente es críptico, reinventando la rueda (por ejemplo, un gran método personalizado que logra una copia de seguridad de SQL db bastante común), etc. Básicamente, confusión innecesaria y mucha ingeniería excesiva.

Y me hizo pensar que ser un programador altamente calificado (deliberadamente no uso la palabra "desarrollador", suponiendo que indica un conjunto más amplio de habilidades), si no está acompañado de otras cualidades, en realidad puede ser algo venenoso.

Suponiendo que sea cierto, algunas de las razones por las que podría pensar son:

• si está codificando con facilidad, se siente (o en realidad lo es, a corto plazo) simplemente más rápido para obtener sus propias soluciones en el acto, sin recurrir a bibliotecas, funcionalidad preexistente, etc.
• Si uno tiene la experiencia suficiente para mantener fácilmente una imagen mental de un programa complejo, uno está menos inclinado a dividirlo en módulos, capas, etc.

Entonces, mi punto es que si un codificador con fluidez es un mal desarrollador, su fluidez no solo no compensa a este último, sino que en realidad hace aún más daño.

¿Qué piensa usted de eso? ¿Es cierto (en qué medida si es así)?

si está codificando con facilidad, se siente (o en realidad lo es, a corto plazo) simplemente más rápido para obtener sus propias soluciones en el acto, sin recurrir a bibliotecas, funcionalidad preexistente, etc.

Si. He sido ese chico. Y he aprendido que es algo terrible.

Todo está muy bien para ti, no tienes que aprender algo nuevo.

¿Pero qué hay del resto de tu equipo? Se vuelven muy dependientes de ti. No pueden buscar en Google "Clive's Quicky ORM" para obtener ayuda sobre el mapeador de objetos relacionales que ha escrito.

Y luego llega el día en que necesitan contratar a alguien nuevo y no pueden buscar personas con experiencia en Quicky ORM de Clive.

Y finalmente llega el día en que te vas y alguien nota un error en tu ORM. Y estará allí, porque no tienes una comunidad completa de personas probando y reparando tu producto.

Sí, aprender Hibernate podría haber tomado más tiempo que escribir algo liviano. Pero el beneficio de hacerlo es demasiado grande como para ignorarlo, en mi humilde opinión.

• si está codificando con facilidad, se siente (o en realidad es, a corto plazo) simplemente más rápido para obtener sus propias soluciones en el acto, sin recurrir a bibliotecas, funcionalidad preexistente, etc.

Experto en el idioma pero no en las herramientas. Eso ni siquiera es ser un codificador fuerte. Es solo pulir una habilidad (conocimiento del idioma) y permitir que otra se oxide (conocimiento de la biblioteca). Al revés es igual de malo, pero más fácil de detectar.

• si uno tiene la experiencia suficiente para mantener fácilmente una imagen mental de un programa complejo, uno está menos inclinado a dividirlo en módulos, capas, etc.

Eso es solo pereza disfrazada de habilidad. No se necesita mucho esfuerzo para mantener lo que estás trabajando activamente en tu cabeza. Se necesita habilidad para encontrar las costuras adecuadas y dividir el código a lo largo de ellas. Los programadores que dicen que fue más rápido o mejor dejar todo en un lugar a menudo no pueden ver qué elementos dividir.

Solo asegúrese de que esto no se deba a que ha estado trabajando en un entorno "Si su teclado no está haciendo clic, no está trabajando". Todos miramos hacia atrás en el código y nos preguntamos qué estábamos pensando. Además, ¿esta tienda está en la práctica de refactorizar su código? Eso puede haber sido un lujo que no le dieron.

Sin embargo, necesitamos separarnos de nuestra primera idea (la que puede simplemente sentarse y martillar) y hacer un poco más de planificación, investigación y pensamiento. La tentación de eliminar cada pequeño problema es tentador y todo el proyecto está plagado de esta práctica. Nadie quiere pagarle a la gente para arreglar cosas que "no están rotas", entonces, ¿por qué refactorizar?

Editar: Asegurémonos de no castigar a aquellos que saben las respuestas. Hay quienes hablan con fluidez y escriben un buen código con rapidez. La clave es no abordar todos los problemas de esta manera.

100%

La forma cínica de ver esto sería que este tipo de codificadores realmente mantienen a la mayoría de los desarrolladores en el trabajo, corrigiendo errores que son tan fundamentales que puede absorber miles de horas de desarrollador sin llegar a la mitad de un proceso estable, flexible y seguro , modular o [su propiedad de software favorita] del sistema. Estos sistemas tienen tantas idiosincrasias que la sola idea de migrar a otra cosa, incluso con el 95% de las características ya implementadas y una comunidad vibrante detrás, se considera algo ridículo y motivo de despido.

En resumen, los codificadores con fluidez pueden hacer más daño que una horda de competidores, pero el precio generalmente se paga durante muchos años. Y, por lo general, simplemente estaban haciendo su trabajo (como lo definió otra persona).

¿Cómo saber si eres un desarrollador o un codificador? Supongo que es imposible, pero cada vez que encuentra una manera de simplificar su código sin reducir la calidad , ha dado un paso más hacia la iluminación.

El problema que describió fue básicamente NIH ("no inventado aquí"). ¿Hay otros síntomas?

A veces, los NIH, particularmente si están aislados para una o dos personas, pueden tratarse en una discusión grupal ("Joe tiene experiencia en hacer copias de seguridad de SQL utilizando bibliotecas estándar, ¿qué te parece, Joe?"). Esto podría ser menos conflictivo que simplemente dirigirte directamente a la persona y decirle "¡Hey! ¡Usa la biblioteca estándar, tonto!" :)

Después de haber estado en su situación y haber causado situaciones similares, entiendo su frustración, pero creo que la respuesta a su pregunta es un rotundo "no". La fluidez no garantiza que un programador produzca código mantenible. A menudo, las organizaciones obligan a los programadores a entregar software mal diseñado e implementado debido a presupuestos ridículos y limitaciones de tiempo. Es posible que el programador fluido esté cortando esquinas solo a los programadores les importa entregar algo que a los clientes sí les importa. Obviamente, esto no es bueno en la práctica, pero lamentablemente es una realidad que la mayoría de los programadores tienen que enfrentar en algún momento de su carrera. También existe la posibilidad de que un programador fluido sea simplemente perezoso o complaciente. Puedo hablar un inglés perfecto, pero es más fácil y divertido usar jerga.

En cuanto al uso del código de otros o la elaboración de su propio argumento, creo que realmente se reduce a lo que hace el trabajo mejor. A veces, "mejor" no tiene en cuenta cosas como el estilo y la facilidad de mantenimiento si "mejor" significa entregar un proyecto de seis semanas en dos semanas. Es por eso que refactorizamos y refinamos. Además, el desarrollador debe estar al tanto de lo que está disponible en términos de código de terceros y debe saber cómo usarlo y confiar en que funcionará y será compatible / mantenido adecuadamente. Dado que hay miles de marcos, bibliotecas y API opcionales para cualquier paradigma de desarrollo popular que use tales cosas, puede terminar costando más tiempo, energía y estrés que simplemente crear el suyo. Además, encuentro casos en los que el código de terceros simplemente no hace exactamente lo que necesito que haga, que es cuando '

Estoy en ese bote (código heredado escrito con fluidez) y fui del tipo fluido por un tiempo.

El mayor obstáculo para las soluciones "rápidas y sucias" siempre es cuando necesita agregar más más adelante. Cuando necesitas más funciones. Solo hay mucho que puedes hacer sin estructura. Después de eso, se rompe y es costoso reorganizarlo (pero satisfactorio, pero no realmente apreciado).

Básicamente, debe protegerse contra CUALQUIER HACK que podría convertirse en una "solución viable", lista para ser vendida por un vendedor ansioso. Es el viejo "¡No está listo! - Pero funciona, ¿no?" adivinanza.