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

16

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í)?

Konrad Morawski
fuente
24
"Dame seis horas para cortar un árbol y pasaré las primeras cuatro afilando el hacha". --Abraham Lincoln "Afila tu hacha a tu propio ritmo". - La mayoría de los jefes
JeffO
15
Algo de confusión aquí para mí causado por el título, como cuando leí 'fluido'I.ThinkOf(this).KindOfThing()
Benjol
¿Le has preguntado a este desarrollador senior la razón por la que hizo estas cosas? Como ya indicó, la aplicación tiene errores. Entonces, tal vez el desarrollador principal estaba limitado en lo que podía hacer con dicha aplicación con errores. Si su código solo funciona "la mayor parte del tiempo", entonces contiene errores y debe ser reemplazado y / o reparado.
Ramhound
@Ramhound: no, ya que había dejado la compañía antes de que me uniera. Él fue la última persona en trabajar en eso antes de que lo abordara. Sé por compañeros de trabajo que solía tener prisa, ya que arreglar la aplicación era una prioridad debido a muchas quejas de los clientes. Pero no estaba haciendo un muy buen trabajo en términos de gestión del tiempo, ya que claramente estaba atravesando una puerta abierta de vez en cuando. Por cierto, creó su propia biblioteca para localizar aplicaciones WPF y Winforms.
Konrad Morawski
1
Muy relacionado: esto y esto . Algunas (muchas) personas se quedan atrapadas en esta etapa ...
BlueRaja - Danny Pflughoeft

Respuestas:

22

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.

pdr
fuente
1
También he sido ese tipo, y no estoy de acuerdo con la segunda oración. Ser capaz de resolver la mayoría de los problemas no significa que sus soluciones sean robustas, mantenibles, flexibles, escalables ... o incluso que la implementación inicial se desarrolle tan rápido. Muchas de las mejores ideas que aprende fuera de los manuales de referencia de idiomas / bibliotecas son cosas que son "¿por qué no pensé en eso?" simple, y también flexible, escalable, etc. Una de las peores cosas: darse cuenta de que estaba expuesto a una idea antes, pero la descarté como un absurdo académico sin sentido sin uso práctico, así que cuando la necesitaba ...
Steve314
66
En algunas organizaciones, obtener la aprobación para usar una biblioteca de terceros puede llevar seis meses o más. En algunos casos, puede esperar los seis meses y ser rechazado al final, de todos modos. He creado un ORM único antes porque no quería perder el tiempo lidiando con la burocracia cuando ya estaba en un corto plazo.
Toby
2
@Toby: punto justo. Pero esas compañías generalmente están más allá de ahorrar de todos modos.
pdr
Sin mencionar que la Fuerza Aérea de EE. UU. Es la misma que las compañías que mencionó @Toby. Intentamos empujar a Ruby on Rails, pero no les gustó.
Travis Pessetto
@Toby hay algunos casos en los que reinventar la rueda es lo correcto, la clave es asegurarte de que entiendes por qué estás
jk.
14

• 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.

Christopher Bibbs
fuente
1
Si de hecho. Y supongo que me opondría más a las personas de este tipo si no me hubiera ganado la vida durante los años que vinieron a limpiar después de ellos ... ;-)
Mike Woodhouse
4

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.

JeffO
fuente
Exactamente mi pensamiento. Si el objetivo principal de la empresa es entregar lo más rápido posible, las personas a menudo trabajan hasta tarde y hacen cosas que no harían si se les permitiera trabajar sin presión. Te sientes más "productivo" y útil si escribes muchos códigos en los que piensas mientras escribes. Reclinarse para pensar, o incluso para conversar con colegas sobre un problema problemático ... ese tipo de cosas fácilmente te hacen sentir como si estuvieras retrasando el proyecto. Podrías estar codificando en ese momento, ¿verdad? ;-).
deadsven
He tenido suerte Me permitieron trabajar desde casa después de mudarme. Todos quieren saber si está hecho y no estoy trabajando. No voy a ser castigado por saber la respuesta.
JeffO
3

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.

l0b0
fuente
1

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!" :)

Scott C Wilson
fuente
1

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 '

Daniel Pereira
fuente
0

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.

MPelletier
fuente
¿Cómo responde esto a la pregunta que se hace?
mosquito
@gnat La pregunta es "¿Qué piensas de eso?", mi respuesta fue lo que pensé. Sigo teniendo la misma opinión: la fluidez (por lo tanto, poder hacer soluciones rápidas, hacks, etc.) puede conducir a un código dañino a largo plazo. No solo puedes hablar un idioma con fluidez, tienes que saber cómo organizar el código.
MPelletier