¿Cómo evito las preocupaciones de complejidad de los marcos al tiempo que mantengo a mi equipo en condiciones de ventas?

7

Al decidir cómo diseñar un proyecto de software con mis colegas, la mayoría de las sugerencias tienden a ser para usar marcos específicos "porque es popular en el mercado laboral" o "ese es el marco que pone a los reclutadores en el teléfono" y nunca qué. Busco cuál es "porque es una buena opción para el proyecto, ya que hace que el sistema sea más adaptable a los cambios futuros y facilita la vida de los desarrolladores".

No empecé a ver los proyectos de esta manera hasta que empecé a leer sobre el diseño basado en dominio. Descubrí que el dominio real está oculto en lo profundo de los marcos utilizados y es difícil conocer los procesos de negocios que el producto de software ha implementado.

¿Hay una manera de casar los dos objetivos en competencia: exponerse como un equipo de desarrollo y, al mismo tiempo, evitar la complejidad? ¿Son los marcos que comprometen, o existen otras soluciones?

    
pregunta Desolate Planet 28.09.2011 - 21:35

3 respuestas

7

No creo que los marcos sean una causa de ingeniería excesiva. La mayoría de las veces, los marcos eliminan el código de plantilla y simplifican el código base que le queda por mantener.

También estoy de acuerdo con el comentario de Thorbjorn de que es una mala idea esperar una API para todo. Mucho mejor es que el entorno de ejecución se centre en las cosas que aparecen en casi todas las aplicaciones y sea lo suficientemente flexible como para permitir que se agreguen marcos donde se resuelven otros problemas comunes.

Sin embargo, he visto instancias (fuera del mundo Java) en las que los marcos se utilizan con el fin de utilizar un marco. Veo por qué crees que esto es malo, y si complica demasiado el producto, entonces lo es. Pero debe tenerse en cuenta que si se le da espacio a un desarrollador para mejorar su CV, verán más razones para quedarse y aprender aún más.

Siempre que un desarrollador retroceda si encuentra que un marco no le está ayudando, hay buenas razones para dejarlos ir.

Pero al leer su historia, veo un problema mayor: no entender el dominio de negocios. Se escriben demasiados productos sin tener en cuenta los problemas comerciales reales, solo se intenta producir algo que los desarrolladores creen que debería ayudar. Esto no es culpa de los marcos en ningún sentido, es culpa de los desarrolladores, pero necesita ser arreglado de alguna manera.

Cómo hacerlo depende mucho de la estructura del equipo. Pero haga muchos comentarios como "¿No cree que estaríamos más satisfechos en nuestros trabajos si pensáramos que estábamos escribiendo un software que mejoraría la vida de las personas?"

O haga arreglos para que los desarrolladores se sienten con las personas que usarán el software y verán los problemas que enfrentan todos los días y ofrecerán soluciones.

O, si se trata de ello, juega al ángulo de la carrera. Me refiero a quién quiere ir a su próxima entrevista y decir "sí, hicimos todo lo posible, pero nunca fue el producto que el cliente quería", en lugar de "así que fui al negocio e investigué el modelo y usé técnicas de DDD para convertir eso en un modelo de software "?

    
respondido por el pdr 28.09.2011 - 22:14
4
  

¿Son los marcos el catalizador de muchos de los proyectos sobre diseñados por ahí?

No.

  ¿

o es algo mucho más simple?

Sí.

  

Si ha encontrado estos problemas en un proyecto de software, ¿cómo lo ha solucionado?

Ignóralo.

  

¿Hay algún buen indicador clave a tener en cuenta cuando un proyecto se está diseñando en exceso?

Sí.

¿Quieres algunas sugerencias?

¿O fue la pregunta simplemente retórica?

Un indicador importante de la ingeniería excesiva es la gente que se queja de la ingeniería excesiva. Seriamente. Otras personas que se quejan.

Sobre-ingeniería significa esto:

Se incorporan funciones adicionales para las que no hay requisitos.

La flexibilidad, la escalabilidad, la disponibilidad y todos los demás requisitos no funcionales se suelen incluir en un proyecto porque los usuarios (o propietarios de productos) solo se preocupan por los requisitos funcionales.

A algunas personas realmente les gusta discutir los requisitos no funcionales con gran profundidad. Añadiendo todo tipo de cosas.

A algunas personas les gusta dejar de lado los requisitos no funcionales. Eliminación de características esenciales para que el software sea "más liviano" o "más transparente" o similar.

Lo esencial de una persona es opcional de otra persona.

Ya que todos están equivocados, todos también tienen razón, también. Hay un término medio en alguna parte.

Lo importante es que los marcos proporcionan un conjunto estándar de requisitos no funcionales a un costo esencialmente cero. Claramente, eso no es divertido. ¿Quién quiere centrarse en los requisitos confusos del usuario?

Evitar un marco significa que todo el conjunto estándar de requisitos no funcionales debe construirse desde cero. Claramente, eso es más divertido. Evitar los requisitos reales del usuario para centrarse en los requisitos no funcionales es más como la programación real.

    
respondido por el S.Lott 28.09.2011 - 22:10
1

Al elegir marcos, considera esto:

  1. Cuántas dependencias hay en el marco. Qué otras librerías, programas, entornos, ordenadores o sistemas requiere. ¿Cuánto esfuerzo cuesta mantener todas las dependencias? Menos esfuerzo es mejor.
  2. Una vez que el desarrollador original del marco desaparezca, ¿qué sucederá? Es imposible mantener el marco, es difícil, requiere un equipo de 1000 personas
  3. ¿Es lo suficientemente popular como para que siempre haya personas que se preocupen por el marco y ofrezcan su tiempo y dinero para mantenerlo, incluso si es un trabajo aburrido y / o molesto, mientras que todo el mundo cree que hay mejores marcos (ya ) disponible
  4. ¿Cuál es el tiempo antes de que el marco desaparezca y se considere obsoleto?
  5. cuál es el tamaño de la interfaz que vas a usar. Lo pequeño es mejor.
  6. ¿Las convenciones de marco intentan dividir su código en 22 piezas de formas diferentes? ¿Hace cumplir alguna convención en su código? Tenga cuidado con las devoluciones de llamada que deben implementarse. Tenga cuidado también con las convenciones de nombres / administración de memoria / api que se extienden alrededor de su código su .
  7. ¿El marco de trabajo movió parte molesta o pesada del trabajo de desarrollo a su responsabilidad, o trata de manejarlo y simplificarlo?
  8. ¿Puede usar la funcionalidad de todo el marco, o es lo que está planeando usar solo una pequeña parte del marco? Si solo está utilizando una pequeña parte, entonces el marco puede ser demasiado pesado para mantenerlo para usted.
  9. ¿En qué lenguajes de programación o entornos se basa el marco? ¿Ese ambiente estará disponible en el futuro? ¿Varios proveedores que proporcionan el medio ambiente?
  10. ¿Hay una manera fácil de aislar el marco a un cuadro que se puede cambiar?
  11. ¿Cuántos de sus archivos de origen necesitan usar el marco? Un número más pequeño es mejor.
  12. ¿Cuánto esfuerzo ahorra cuando decide utilizar el marco? ¿Qué problema resuelve? Cuánto esfuerzo adicional debe hacer para utilizarlo y mantenerlo para siempre.
respondido por el tp1 12.11.2011 - 19:16

Lea otras preguntas en las etiquetas