Hola, ahora te diré lo que sucederá con un proyecto prometedor, si desde el principio recurro a soluciones preparadas a la Wordpress, Open Cart y cualquier CMS, pensando que esto es MVP. Me basaré en una experiencia de tres meses trabajando en uno de los proyectos en GitHub que en los últimos 8 meses no ha perdido un solo compromiso en la rama de producción.
Receta para VP / OC / CMS hinchado a órbita geoestacionaria
1. Elija cualquier CMS confeccionado
En ningún caso, no llame a arquitectos y olvídese de los microservicios y la arquitectura adaptada a sus necesidades. Nuestra tarea es hacer posible girar el panel de administración 5 minutos después de que el desarrollador encienda la PC, y no hacer que el desarrollo sea fácil de administrar. Un verdadero MVP debe consistir completamente en soluciones llave en mano. Después de todo, es en nuestro proyecto que los complementos nunca entrarán en conflicto y ya están diseñados para cargas de cualquier intensidad.
2. Prohibir documentar cualquier cosa
Ni un solo cms necesita ser documentado. Prohibir documentar cualquier cosa. Especialmente modificaciones del kernel. Después de todo, después de 3 meses, el profesional independiente se convierte en un guardián del conocimiento sagrado sobre cómo funciona esta bola de masa de esmeralda, y con las técnicas mágicas de iniciar un servidor, que, naturalmente, es uno, y nadie lo ha recreado desde la instalación inicial del conjunto de utilidades. La clave para una gestión decente es la dependencia de los empleados y, por supuesto, de un único servidor que funcione.
3. ¡Llama a GURU!
Después de que las soluciones para los conflictos entre los complementos 234 y 417 comenzaron a tomar al menos 10 veces más tiempo que la introducción de nuevas funciones, su forma correcta es buscar un GURU, sabio por experiencia, que refactorizará (reescribirá) sin esfuerzo un pequeño código en una semana, y los siguientes 500 complementos ocuparán el lugar que les corresponde. Por cierto, tuve la "suerte" de desempeñar el papel de un gurú que convierte la tecnología y, por lo tanto, este es un historial médico real.
4. Su proyecto debe consistir en un área de responsabilidad
Desde el principio, utilizamos microservicios de manera segura y consciente, y después de 5 meses es hora de contratar un nuevo programador. Y que sea responsable del diseño. Bueno, un poco más para el backend, porque los tenemos mezclados. Bueno, para bases de datos, porque cómo responder para un backend sin bases de datos. Bueno, seamos responsables de las soluciones. Y más ... y más ... y más ...
5. Trello + Jira + Slack + Excel + ... + Skype
Gracias a los buenos mil quinientos complementos que YA existen, hay 5 errores cada día, cuya resolución requiere 2 días. La velocidad de escritura de las funciones disminuye exponencialmente. Obviamente, estamos arrojados por un tiempo desarrollado. Y debe presentar un tercer administrador de tareas. (Sí, los proyectos clínicos generalmente tienen dos administradores de tareas). Trello, Jira y Excel son solo la base del control. Algunos asistentes también utilizan administradores de tareas intra-corporativos, mensajes de chat anclados e instrucciones repentinas no planificadas.
6. Transcripciones de conferencias de voz
Los desarrolladores nos guían por la nariz y, por lo tanto, todas las conferencias de voz para la aprobación de correcciones de errores deben archivarse, guardarse en la nube y escucharse regularmente. Después de todo, siempre se trata de desarrolladores ...
Consejo 1: Las pruebas fueron exitosas: descarte urgentemente las soluciones preparadas y escriba una arquitectura adecuada.
Consejo 2: Si no eres solo una startup motivada y tienes recursos o una estrategia financiera, asegúrate de incluirla desde cero. De todos modos, entregue este asunto a los profesionales o al director técnico. (Es importante que este fuera un programador y no un profesor del instituto de investigación, de lo contrario no recibirá tarjetas perforadas)
¿Qué pasa si YA y usted está a cargo?- Reescribir.
¿Qué pasa si YA y usted no está a cargo?- Explicar la esencia del problema a la gerencia y reescribir.
PD El proyecto usó Yii2, pero incluso con él hubo estos problemas. Lo que le sucede a WP es un desastre en absoluto.
PPS La razón, por supuesto, es la incompetencia de la administración, aunque la arquitectura monolítica tampoco se hace a un lado.