Edición de equipo de arquitectura y marco

Question

Estamos en el proceso de planificación para una reescritura de una de nuestras aplicaciones fundamentales. Está basado en la web, y estamos bloqueados en PHP. Sin embargo, no es un sitio web 2.0. Está más cerca de una aplicación empresarial.

No es de ninguna manera simple. Hay al menos 2 interfaces principales (creo que hay 4, pero ese es otro tema). Necesita ser altamente configurable y altamente personalizable. Esperaría entre 50 y 200 instalaciones por año, por lo que la facilidad de mantenimiento es una gran preocupación.

El problema viene en la arquitectura. Primero quiero hacer una arquitectura formal de alto nivel. Antes de nada. Después de eso, elegiríamos un marco adecuado (uno que se ajuste a la arquitectura) o seleccionaremos uno y lo usaremos como un conjunto de bibliotecas. Siento que esta metodología garantizará un sistema viable a largo plazo (ya que al menos se considera la arquitectura completa)

Sin embargo, el resto del equipo quiere elegir primero un marco (quieren usar YII) y omitir el arquitectura de alto nivel completamente. Su argumento es que el marco hizo primero la arquitectura de alto nivel y permite "comenzar a codificar".

Básicamente, creo que esto es como poner el carro antes que el caballo, o construir su casa sin cimientos sobre un pozo de lodo. Sé que este punto de vista es popular en los días posteriores al ROR de rápido desarrollo de aplicaciones, ya que se puede hacer más rápido. Pero realmente temo que para una aplicación central de misión crítica, esto sea corto de miras en el mejor de los casos (y negligente en el peor).

Realmente temo que vayamos por el camino equivocado.

La dirección me considera un desarrollador sénior. Entonces, técnicamente, puedo anular a la mayoría de los demás. Pero no estoy por encima de ellos, así que en la práctica hacerlo sería malo. Mot para mencionar que hay una gran barrera del idioma (hablan polaco, hablo inglés).

Y creo que debería mencionar que realmente no me gusta la mayoría de los frameworks RAD PHP. No porque sean malos de ninguna manera, sino porque tienden a (IMHO) imponer la mentalidad de que la arquitectura no es importante, ya que lo hacen por usted. Sin mencionar que, por lo general, quieren que trabajes a su manera (Rails es famoso por eso) en lugar de una forma que tenga sentido para el proyecto en cuestión. Por lo tanto, normalmente solo uso un marco como un conjunto de bibliotecas. Usar las clases cuando tienen sentido, y construir las mías cuando los requisitos del proyecto así lo exigen).

Así que mis preguntas son las siguientes:

1. Estoy en lo cierto en mi preocupación? ¿O tienen razón y estoy reaccionando demasiado?
2. Si estoy en lo cierto, ¿hay algún consejo sobre cómo manejar la situación?
3. ¿Cómo puedo poner al equipo de mi parte sin provocar un motín?

Answer 1

Puede que le interese mi reciente publicación en el blog: Don't Put the Cart Before the Horse donde le hablo sobre la importancia de definir el problema que está tratando de resolver antes de decidirse por cualquier elección de arquitectura.

En cuanto a poner al equipo de su lado, existen múltiples soluciones debido a que existen múltiples razones para la resistencia.

Recomiendo este libro: Driving Technical Change: Why People On Your Team Don't Act On Good Ideas, and How to Convince Them They Should por Terrence Ryan. Saldrá pronto, pero puede solicitar el e-book beta de inmediato, y esto se aplica al e-book final cuando esté listo.

(disclaimer:. He revisado un proyecto de ese libro, y está publicado por la misma empresa que puso a cabo mi propio libro)

Answer 2

Tengo problemas para imaginarse la arquitectura de alto nivel sin ningún tipo de información detallada, pero por lo que vale, esto:

Primero quiero hacer una arquitectura formal de alto nivel. Antes que nada

suena muy cuerdo conmigo. Antes de elegir un marco, debe quedar claro si su estructura es adecuada para lo que debe hacer, sin tener que doblarlo tanto que ya no sea ese marco.

En cuanto a cómo ... Estoy seguro de que otros están más capacitados para responder que yo. Sin embargo, si el tiempo es esencial, y la mayoría del equipo quiere ir a la ruta "vamos a comenzar de inmediato", trataría de convencerlos de hacer al menos un pequeño número de sesiones de arquitectura primero, y si es solo una o dos tardes

Si realmente no tiene autoridad sobre ellos (e incluso si tiene), pídales que le den un sentido del humor por un tiempo limitado. En mi experiencia, las deficiencias y problemas arquitectónicos tienden a aparecer bastante rápido una vez que ingresas ("Necesitamos hacer xyz. ¿Cómo hacemos esto en Framework X?"). Una sesión intensiva de simulación de escenarios (y problemas) podría hacer que las personas quieran pensar dos veces sobre qué plataforma elegir.

Answer 3

Yo diría que ambos tienen razón. Teniendo en cuenta que la arquitectura está bien. Pero los arquitectos a menudo tienden a complicar demasiado las cosas. No es raro que los desarrolladores acusen a los arquitectos de vivir en una torre de marfil, mientras están en las trincheras. Sin embargo, estar en una trinchera es bastante bajo, por lo que los desarrolladores a menudo no ven el bosque para los árboles, lo que puede llevar a arquitecturas ad-hoc igualmente indeseables o soluciones insulares que no se conectan demasiado bien.

En cuanto a los marcos que ya ofrecen una arquitectura de nivel superior, bueno, sí. Ellas hacen. Pero eso no significa que sea la arquitectura que necesita. Las cosas que encontrará en los marcos (con suerte) se modelan después de los patrones de diseño establecidos. Los patrones de diseño son soluciones sugeridas para problemas comunes. Si no necesita resolver estos problemas, tampoco utiliza un marco para resolverlos. Es la elección incorrecta. Ahora, eso es bastante genérico, pero entiendes la idea.

Mi consejo sería no abusar de su posición de desarrollador sénior y forzar una decisión sobre ellos. Encontrar un compromiso. Involúcralos en la decisión, pero espera que ellos lo discutan. No conozco el entorno de trabajo en su lugar, pero tal vez considere la posibilidad de adoptar algunos procesos ágiles, como Scrum. Tal vez haga primero una codificación exploratoria con diferentes marcos para ver cuál es el mejor. Es mejor fracasar con un marco de trabajo antes que darse cuenta de que es el caballo equivocado al final.

Answer 4

En el estado en el que se encuentra, todos saben que necesita construir un edificio de 40 pisos. Pero nunca construyes una superestructura en la arena. Obtener un consenso solo demora todo. El mejor enfoque es conseguir que todos creen una prueba de concepto en el menor tiempo posible con todas las funciones que pueda obtener del producto esperado utilizando la misma línea de base/fecha límite. Luego, obtenga un equipo de revisión independiente para ver sus enfoques. Entonces toma una decisión. Los marcos y las celosías son solo estructuras de soporte para su fundación.

Answer 5

¿Alguno de los otros desarrolladores ha implementado una aplicación en YII similar a la que necesita construir ahora? Si no, al menos tiene algunos motivos para retroceder y a) averiguar cuáles son las fortalezas y debilidades de YII (pídales que le digan) yb) cómo se ajustan a los requisitos de su proyecto.

Está bien ir directamente a la codificación si está utilizando un marco que ya conoce, que tiene un historial probado para construir el tipo de aplicación que desea, pero con un nuevo marco (que no es familiar para su equipo) tiene sentido evaluarlo primero, con al menos un prototipo esquelético, como parte de su diligencia debida, especialmente si se trata de una aplicación comercial de misión crítica. Asegúrese de que pueda cumplir con todos y cada uno de sus requisitos comerciales.

En términos de retroceder, siempre puede pedirle al negocio que plantee la pregunta al equipo de desarrollo "díganos (justifiquen) por qué estamos usando este marco para construir nuestra aplicación de misión crítica".

Answer 6

Usted y su equipo no están de acuerdo, pero ambos tienen razón. Vas a escribir algo de documentación, y les dejas comenzar a cortar los dientes en un marco como CakePHP o lo que sea. Idealmente, debería obtener experiencia con más de un marco. Esto le permitirá tomar decisiones más informadas sobre cómo elegir su plataforma.

La razón por la que desea hacer un montón de trabajo de diseño primero es muy buena, necesita saber lo que está haciendo antes de hacerlo. Pero también es bastante válido para otros desarrolladores comenzar a aprender y usar los marcos. Ese conocimiento lo ayudará a tomar decisiones, y también le permitirá a su equipo comenzar a producir resultados más rápidamente.

Te recomiendo que no te preocupes demasiado por poner el carrito delante del caballo. Piensa en las primeras semanas como educarte a ti mismo y crear prototipos, con la intención de descartar tus primeros resultados. La parte más difícil de usar un nuevo marco o metodología es aprenderlo, volviéndose lo suficientemente competente como para estar pensando en su aplicación más que en el medio en el que está trabajando. Su gente puede comenzar a trabajar mientras contempla problemas de diseño. .

Es posible que incluso pueda descifrar algunos de los modelos de datos con anticipación y les permita comenzar a crear las páginas de la interfaz de usuario para ellos. Por supuesto, tendrá que cambiarlos a medida que perfecciona el diseño, pero lo fácil que es hacer tales cambios es parte de lo que hace un buen marco.

El riesgo de creación de prototipos es la tendencia natural de las personas a apegarse demasiado a algo que está "funcionando" y no querer descartarlo. Pero también existen riesgos al hacer demasiado trabajo de diseño en abstracto sin tener nada concreto con lo que interactuar y generar ideas.

No me sumergiré en un tratado sobre Cascada versus iterativo. Pero sí recomiendo que desatienda el entusiasmo de su gente para bucear, y que se adelanten a probar y aprender un par de marcos mientras hace el trabajo de diseño. Luego puede reunirse como un equipo, discutir su arquitectura y tener una discusión más educada sobre qué marco desea usar.