Programadores que necesitan mucha “ayuda externa”: ¿es esto malo? [cerrado]

7

¿Es una práctica un tanto pegajosa o deficiente cuando los programadores usan una cantidad inusual de bibliotecas / marcos para realizar ciertas tareas? Estoy trabajando con alguien en un proyecto de programación relativamente simple que involucra consultas de geolocalización. El chico me parece un aficionado. Para el software del servidor, este tipo utilizó Python, Django y un montón de otras bibliotecas locas ("PostGIS + gdal, geoip, y algunas otras bibliotecas espaciales", escribe) para crearlo. Escribió el programa completo en un método (en views.py, sin embargo, facepalm ), y es casi ilegible.

¿Esto es malo? ¿Es esto realmente vulgar y amateur? ¿Soy el único minimalista que hay en estos días?

    
pregunta dkaranovich 09.03.2011 - 06:58

10 respuestas

11

La escritura de un programa completo en un método es probablemente mala. Dicho esto, utilizar herramientas que ya existen puede definitivamente ayudar a acelerar los tiempos de desarrollo. Espero haber malinterpretado su redacción, ya que parece implicar que Python o Django deben ser considerados como ayuda externa. Ambas son herramientas extremadamente útiles para los desarrolladores. Creo que podemos estar de acuerdo en que, en la mayoría de los casos, un desarrollador que implementa una lista vinculada para usar en lugar de usar un estándar proporcionado es una mala idea. Esto también puede aplicarse a cosas más complejas, como sockets TCP e incluso GeoIP.

De acuerdo, a veces, cuando las personas incorporan módulos / bibliotecas externas en un producto, las cosas pueden complicarse, especialmente cuando hay varios módulos y empiezas a tener pesadillas dependientes. Estos deben administrarse de manera adecuada, y sí, a veces es mejor codificar las cosas por su cuenta. No juzgaría a un desarrollador por si usan "ayuda externa", tanto como cómo usan ayuda externa y la integran con el resto del sistema.

    
respondido por el Jeff 09.03.2011 - 07:43
5

En general, eso se considera bueno si el programador está expuesto a una multitud de bibliotecas. Si puede realizar la tarea utilizando un algoritmo escrito de manera eficiente que ya está disponible en la biblioteca, ¿no le ahorra tiempo y esfuerzo? Pero dependería de la situación si las bibliotecas y las dependencias deben ocultarse y no se ajustan a los requisitos de diseño o si la tarea se puede realizar con una rutina simple. El ahorro de tiempo es definitivamente un factor.

    
respondido por el Aditya P 09.03.2011 - 07:16
5

Prefiero que las personas utilicen las herramientas existentes, probadas y probadas para crear cosas que salir y escribir todo desde cero, con los riesgos inherentes de hacerlo, el tiempo adicional necesario para probar cosas que podemos saber son probadas por proveedores si lo compramos, etc. etc.

    
respondido por el jwenting 09.03.2011 - 08:31
4

Usar herramientas existentes es bueno y recomendable (en realidad, no usar herramientas externas suele ser un problema para los programadores junior)

Sin embargo, el uso de muchas de estas herramientas para un proyecto relativamente pequeño puede indicar que cada herramienta es una exageración para lo que se utiliza y puede generar una gran sobrecarga de integración

    
respondido por el Ophir Yoktan 09.03.2011 - 08:20
4

Escribir un programa en un método: definitivamente malo (a menos que sea un programa trivial, pero no creo que te refieras a eso).

Uso de muchas bibliotecas: depende.

Se debe lograr un equilibrio entre volver a inventar la rueda y hacer cero trabajo. Si la actitud es "a menos que haya una biblioteca para [x], no la estoy implementando", eso es ciertamente malo. Solo tenga en cuenta que el otro extremo es (por ejemplo) "Sé que jQuery puede hacerlo en tres líneas, pero voy a rodar mis propias funciones [y]".

Básicamente:

  • Use marcos y otras abstracciones donde reducen significativamente el esfuerzo y los errores
  • No use marcos como una forma de evitar aprender sobre lo que implementan
  • No utilice la falta de un marco como excusa para evitar abordar una tarea

De lo contrario, (IMO) lo estás haciendo mal.

    
respondido por el Inaimathi 09.03.2011 - 16:25
3

Estoy totalmente de acuerdo. Si bien me inclino por "reinventar la rueda" con demasiada frecuencia, hay un punto en el que tienes que poder pensar por ti mismo.

La mayoría de los proyectos necesitan un puñado, como máximo, de bibliotecas bien escritas y adecuadas. Si su proyecto resulta ser poco más que una colección de widgets y el código de otras personas, por lo general no es muy bueno.

Hay ... algunas excepciones, pero prefiero no aceptar eso.

Conocer las bibliotecas y los marcos es bueno, pero confiar en ellos casi por completo, no es una buena señal en mi experiencia.

    
respondido por el Garet Claborn 09.03.2011 - 07:17
3

Apoyo altamente el uso de bibliotecas y marcos. Sin embargo, hay un límite donde se usan porque existen, en lugar de porque son necesarios. El uso de varias bibliotecas geoespaciales me lleva a creer que se están usando en exceso.

Lo que más me preocupa es la naturaleza ilegible del código. Algunas características que busco en buen código:

  • Borrar código fácil de leer. (Un administrador con una comprensión mínima del idioma debe poder entender el código).
  • Los módulos pequeños que tienen un propósito claro y dependencias limitadas. (alta cohesión y bajo acoplamiento).
  • Código bien formateado que es fácil de escanear.
  • Comentarios que explican lo que se está haciendo cuando es necesario.
  • Duplicación de código limitada, sin duplicación de funcionalidad.
  • Uso coherente de las bibliotecas estándar de idiomas.
  • Uso apropiado de marcos y bibliotecas. (Estos deben ser estándares de proyecto / organización.)

Desafortunadamente, hay muchos desarrolladores que no se han inclinado al valor de los factores anteriores. No importa cuán complejo sea el problema, debe dividirse en componentes más simples que se ensamblan en una solución. Cualquier componente que permanezca complejo debe tener una razón documentada de por qué se hace de la manera que es. (Debe haber una razón válida.)

EDITAR: Si la solución completa tiene menos de 60 líneas de largo, entonces puede ser apropiado hacerlo de una manera El archivo fuente debe tener varios métodos, todos los cuales son de un tamaño razonable. Si hay métodos más largos, es probable que necesiten una re-factorización. Me preocupa la cantidad de bibliotecas geoespaciales que se utilizan para un problema simple. (Sin embargo, he visto algunos problemas simples para los cuales la solución es muy compleja).

    
respondido por el BillThor 09.03.2011 - 16:12
0

Una cosa más a tener en cuenta: ¿está su colega utilizando la herramienta como una muleta para compensar el hecho de que no entienden el dominio del problema tan bien como deberían? Esta podría ser una buena oportunidad para sentarse con él / ella para repasar qué herramientas usan, por qué, y tener una idea de cómo buscan abordar el problema. O bien realmente no saben lo que están haciendo y simplemente lanzan herramientas al problema. O si lo hacen, entonces esa caja de herramientas podría ser algo que le interesaría agregar a su propio conjunto de herramientas.

    
respondido por el spade78 09.03.2011 - 17:01
0

¿Qué pautas de diseño se le dieron a este programador antes de que él / ella comenzara?

Si no dejaste nada, eres tan culpable como el programador de crear más basura.

    
respondido por el user19714 09.03.2011 - 23:38
0

¿Cuánto tiempo duró el método único? Si fueron diez líneas, eso es mucho mejor de lo que este tipo debe haber estado escribiendo:

  

En mi trabajo anterior, estábamos portando un   Sistema UNIX a Windows NT utilizando   Microsoft VC ++.       Un colega mío, que estaba en proceso de trasladar su porción de   el código vino       para mí, luciendo realmente molesto.

     

Colega: "¡Eh! Odio estos   Chicos de Microsoft! Que podrido   ¡compilador! Sólo           acepta 16,384 variables locales en una función! "

(Consulte enlace )

    
respondido por el compman 09.03.2011 - 17:52

Lea otras preguntas en las etiquetas