Crecer sobre los hombros de gigantes
Por cierto, un amigo que ha sido programador durante 17 años ha trabajado como arquitecto en un equipo de clase mundial como HP y Amazon durante 10 años, y también ha sido líder técnico de pequeñas y medianas empresas. Usando CSDN para compartir sus ideas de trabajo, resúmenes de éxito y reflexiones sobre algunos fracasos, dejemos de pisar pozos innecesarios y crecer sobre los hombros de gigantes.
"Pregunte el problema" primero, luego "resuelva el problema"
Como programador, estoy acostumbrado a enfrentar problemas y ansioso por resolverlos. Rara vez pienso en soluciones de diseño como emisor, y rara vez veo el problema de manera integral. La contradicción típica común en proyectos de equipo es la contradicción entre el equipo de producto y el equipo de I + D . Como equipo de I + D, a menudo me quejo de las necesidades irracionales del equipo de producto y de la falta de conocimientos técnicos. De hecho, puede intentar hacer avanzar su trabajo , no solo para diseñar la arquitectura y darse cuenta de las necesidades del producto, sino también para tratar de darse cuenta de las necesidades de los clientes e incluso descubrir necesidades potenciales. ¡No dude en curar su cabeza y pies, esté ansioso por completar la tarea sin mirar el problema como un todo e ignorando los problemas potenciales, lo que provocará conflictos en el futuro!
Y si se convierte en una persona que hace preguntas en diseño , descubrirá que al hacer preguntas , también necesita el mismo pensamiento profundo en muchos casos . Diseñar un buen problema es incluso más difícil que resolverlo.
Entonces, primero "hacer preguntas" y luego "resolver el problema".
De hecho, incluso Frederick P. Brooks Jr. (el autor de "El Mito del Mes del Hombre") en el campo del desarrollo de software tendría el mismo suspiro.
"La parte más difícil del diseño es decidir qué diseñar".
- 《El diseño del diseño》, por Frederick P. Brooks Jr.
Ten el coraje de decir no a los "malos pensamientos"
Debido a la codicia humana, siempre hay muchos "pensamientos malvados", o inercia humana, que hace que el cerebro produzca muchos "pensamientos malvados" erróneos, inoportunos, cómodos y poco fiables. Para los sistemas de software, también necesita querer más: más funciones, mejor rendimiento, mejor escalabilidad, escalabilidad, etc., pero al mismo tiempo, también estará en sus propias preferencias y algunos diseños egoístas ("pensamientos malvados" "), esto requiere que diga que no. Como arquitecto de software, debe comprender que el diseño de la arquitectura de software es un compromiso o equilibrio . Cuando todo el mundo le está agregando cosas, el arquitecto debe ser la persona que diga "no" .
Hay muchas compensaciones en el proceso de diseño y definición de software, tales como:
- El compromiso entre perfeccionar funciones y liberar lo antes posible .
- El compromiso entre escalabilidad y rendimiento .
El principio CAP es una buena estrategia de guía para la selección
El conocido principio CAP es una buena estrategia de guía para la selección. Para tomar mejores decisiones y mantener la consistencia del estilo arquitectónico, el arquitecto debe definir algunos principios de elección basados en las necesidades reales del sistema al principio, tales como:
- La coherencia de los datos tiene la máxima prioridad.
- La publicación anticipada de las funciones principales es mejor que la versión completa, etc.
- Los requisitos no funcionales determinan la arquitectura
Debido a que el software está diseñado para cumplir con los requisitos funcionales de los clientes , muchos diseñadores pueden pensar que la arquitectura está determinada por los requisitos funcionales a implementar . Pero, de hecho , son los requisitos no funcionales los que realmente determinan la arquitectura del software.
Los arquitectos deben prestar más atención a los requisitos no funcionales . Los requisitos no funcionales comunes incluyen : rendimiento , escalabilidad , escalabilidad y capacidad de mantenimiento , e incluso incluyen requisitos de nivel técnico del equipo y tiempo de lanzamiento . Siempre hay muchos diseños que pueden realizar funciones, y se puede seleccionar el diseño más adecuado después de considerar los requisitos no funcionales.
El patrón de arquitectura anterior proviene del primer volumen de "Arquitectura de software orientada a patrones". Este conjunto de libros ha sido un clásico de lectura obligada para los arquitectos durante muchos años . El modelo orientado a la arquitectura proporciona una buena referencia y orientación para diferentes requisitos no funcionales . El modo Micro-Kernel en la imagen presta más atención a la escalabilidad y disponibilidad (aislamiento de errores).
"Simple" no es "fácil"
Se suele recomendar a muchos arquitectos que lo mantengan simple , pero a veces mezclamos lo simple y lo fácil . Simple y fácil son también dos palabras "simple" y "fácil" en inglés .
“Lo simple puede ser más difícil que lo complejo: tienes que trabajar duro para tener un pensamiento limpio y hacerlo simple. Pero al final vale la pena porque una vez que llegas allí, puedes mover montañas. Para ser realmente simple, tienes que ir muy profundo ".
--SteveJobs
Algunos métodos realmente simples provienen de una comprensión más profunda del problema y la tecnología . Estos esquemas a menudo no son métodos superficiales fácilmente disponibles . Se puede decir que hay una gran habilidad en ello.
Primero, revisemos la proporción de consumo de costos en cada etapa del ciclo de vida del software . El siguiente es un informe de análisis de un conocido organismo de estadística. Podemos ver que la parte de mantenimiento representa la mayor proporción , y la simplificación de esta parte tendrá la mayor importancia global.
Comparte la experiencia de los arquitectos
Una vez desarrollado un sistema de gestión de dispositivos , los operadores móviles utilizan este sistema para gestionar dispositivos móviles y realizar funciones de gestión, incluido el registro automático de dispositivos , la sincronización de firmware y software . Estas funciones se realizan a través de algunos protocolos de interacción predefinidos entre el sistema de gestión y el dispositivo móvil .
Los expertos en telecomunicaciones ajustarán y agregarán estos protocolos interactivos de acuerdo con los escenarios y necesidades comerciales . En un primer momento se adoptó un método fácil de implementar , es decir, la ingeniería de software del equipo implementaría el protocolo como código correspondiente según las instrucciones del experto en telecomunicaciones. Pronto descubrimos que de esta manera nuestro trabajo era menos simple.
"Creo que la parte más difícil de los proyectos de software, la fuente más común de fracaso del proyecto, es la comunicación con los clientes y usuarios de ese software".
--Martin Fowler
Como mencionó el gurú del desarrollo de software MartinFowler, la " comunicación" a menudo es la causa principal del fracaso del proyecto de software .
El mayor problema con el proyecto anterior es que en la fase de operación y mantenimiento después de que el sistema esté en línea , los expertos en telecomunicaciones y los ingenieros de desarrollo continuarán comunicándose sobre las modificaciones y adiciones de nuevos protocolos , y su conocimiento de dominio y vocabulario son muy amplios. Diferencia , que afectará en gran medida la eficiencia de la comunicación.
Por lo que este periodo, del sistema de operación y mantenimiento (protocolo modificado) ha llegado a ser muy difícil , no sólo la actualización del protocolo de -line tiempo es lento , y la ingeniería de software, debido al acuerdo de telecomunicaciones limitado nivel de comprensión, una gran cantidad de problemas, para estar en la línea utilizan realmente a ser de telecomunicaciones Los expertos han descubierto que ha provocado muchos intercambios y repeticiones.
Resolver el problema
En respuesta a los problemas mencionados anteriormente , más tarde trabajamos con expertos en telecomunicaciones para diseñar un lenguaje de diseño de protocolo (y proporcionar herramientas visuales ) Este lenguaje de diseño utiliza un vocabulario familiar para los expertos en telecomunicaciones. Luego, mediante un programa similar a un compilador, el modelo de protocolo definido por el experto en telecomunicaciones se convierte en una estructura Java en memoria.
De esta manera , la operación y mantenimiento de todo el proyecto se vuelve simple y eficiente, eliminando la comunicación ineficiente y la conversión manual inexacta.
para resumir
Se puede ver inicialmente seguir las instrucciones de los expertos en telecomunicaciones, la implementación directa del acuerdo es la forma más fácil , pero en todo el ciclo de vida del software mirarlo no es una forma sencilla y eficiente .
Mantenga siempre la pasión por la codificación
Los arquitectos también son programadores . El código es la realización final del software . Detener la programación te hará olvidar gradualmente cómo te sientes como programador y , lo que es más importante, olvidar el "dolor" que conlleva , que puede conducir fácilmente a diseños poco realistas.
Es posible que haya oído hablar de Distinguish Engineers (como James Gosling, el padre de Java) en el nivel de vicepresidente senior de Amazon. Su volumen de codificación anual también es muy grande, a menudo más de 100.000 líneas.
Tome riesgos primero, nunca ponga los riesgos al final
Un punto muy importante en el diseño de la arquitectura es identificar los posibles riesgos , especialmente los riesgos de la realización de requisitos no funcionales .
Debido a estos riesgos, a menudo requisitos no funcionales, tan fáciles de encontrar en las primeras etapas , pero corregido el precio, por lo general , los requisitos funcionales de corrección de la relación son muchos y pueden incluso conducir al fracaso del proyecto, anteriormente también mencionamos que los requisitos no funcionales determinan Arquitectura mejorada , como requisitos de coherencia de datos , requisitos de demora de respuesta, etc.
Deberíamos aprobar el prototipo , o en las primeras iteraciones , identificar los riesgos, capaces de abordar el marco legítimo .
Nunca ponga el riesgo al final , incluso si un proyecto falla , déjelo fallar rápidamente, esto también es una especie de agilidad.
Empiece por pensar en "problemas" en lugar de apresurarse a empezar con "tecnología"
Los técnicos tienen una pasión innata por las nuevas tecnologías, siempre están dispuestos a aprender nuevas tecnologías y también les apasiona más el uso de nuevas tecnologías.
Pero también es probable que conduzca a un problema común, es decir, "cuando tenemos un martillo cuando el clavo para ver qué es ", el uso de alguna de la tecnología no es adecuado para resolver el problema en cuestión , a menudo conduce a complicar la simple pregunta.
Una vez, un equipo mantuvo un servicio tan simple. Al principio, era un servicio simple que usaba MySQL como almacenamiento de datos, que fue desarrollado y mantenido por un miembro del equipo. Más tarde, un miembro se interesó en el nuevo DynamoDB en ese momento y adquirió conocimientos relevantes.
Entonces sucedió algo como esto:
Reemplazó MySQL con DynamoDB.
Pronto se descubrió que DynamoDB no admitía bien las funciones de transacción . En ese momento, solo había una biblioteca de cliente con un rendimiento extremadamente deficiente para respaldar las cosas . Debido al uso del método de cliente , se introdujeron una gran cantidad de interacciones adicionales , lo que resultó en una diferencia de rendimiento de hasta 7 veces. .
Resolver el problema
En este momento, este estudiante ha adoptado la tecnología de consistencia eventual que fue muy popular en el campo NoSQL en ese momento , a través de una cola de mensajes bar-Sub para lograr consistencia final ( es decir, cuando el valor de un objeto cambia, se generará un evento , y luego siga La lógica de este cambio , se suscribirá a esta notificación , y cambiará sus datos asociados , con el fin de lograr acuerdo final diferentes datos).
Desde entonces DynamoDB no proporciona consultas SQL como sistema de máquina fácil , con el fin de lograr el análisis de datos, y nuevamente la introducción de EMR / MapReduceJob.
para resumir
En este punto, puede ver que se implementa la misma función, pero la complejidad ha aumentado mucho y el trabajo de mantenimiento ha cambiado de una persona a un equipo.
Demasiado ocupado te mantiene atrás
Para la gente de TI, el ajetreo se ha convertido en un hábito , y a menudo se habla de horas extra. El sistema de trabajo "996" parece haberse convertido en un símbolo de la eficiencia de la empresa.
Y de hecho te hace demasiado ocupado por detrás .
A menudo me encuentro con algunos amigos, en una empresa de día y de noche hice unos años , no me quedé para aprender un poco de tiempo para ti . Unos años más tarde, pero agregó la empresa más "leal", pero el trabajo ajetreado, al mismo tiempo también llevó a no tener tiempo para actualizar sus conocimientos , por lo que se han quedado atrás , e incluso la capacidad de salto de trabajo y el coraje han perdido .
Estar demasiado ocupado resultará en poco tiempo para aprender y actualizar sus conocimientos . Especialmente en esta era de rápido desarrollo, en la experiencia laboral, encontrar que estar demasiado ocupado generalmente trae los siguientes problemas:
La falta de aprendizaje no ha llevado a ninguna mejora en la capacidad para el trabajo , mientras que los problemas enfrentados se han vuelto cada vez más complejos .
En términos de tecnología y negocios, no hay mayor ventaja y solo puede ponerse al día pasivamente . Imagínese, si ha estado liderando la industria durante cinco años , ¿ todavía le importaría, se libera un mes antes trabajando horas extras?
A su vez, los problemas anteriores harán que estés más ocupado y menos tiempo para mejorar tus habilidades técnicas , lo que rápidamente formará un círculo vicioso .
Amigos que tienen conocimientos de fitness practicado que el ejercicio por sí solo no es suficiente . Suplementos nutricionales y el ejercicio son igualmente importantes.
El crecimiento técnico personal es en realidad el mismo. La práctica y el aprendizaje son igualmente importantes. Cuando trabajas en un campo durante un período de tiempo, el trabajo es principalmente práctica para ti . A medida que te familiarizas con el campo, puedes aprender Cada vez habrá menos tecnología.
Asegure suficiente tiempo de estudio, no olvide la intención original, mantenga el ingenio
Por eso, espero que todo técnico se asegure suficiente tiempo de estudio , de lo contrario es fácil convertirse en una rana en el fondo del pozo , para no caer en el círculo vicioso mencionado anteriormente ; espero que el verso del gran poeta Qu Yuan anime a todos: “El camino es largo y largo. Buscaré de arriba a abajo ”, ¡espero que todos no podamos olvidar nuestra intención original y mantener nuestra originalidad!