Cómo planear ser arquitecto de software junto con mis actividades de desarrollo de software

eh? ¿Junto con tus actividades de desarrollo? ¡No estoy muy seguro de en qué mundo estás viviendo! Si tiene que ser arquitecto, debe ser un “desarrollador”. (punto) ¡Incluso como arquitecto, debe producir prototipos y otros ejemplos sobre cómo está integrando sistemas! ¿Crees que solo por tu conocimiento teórico los desarrolladores entenderán lo que hay que hacer?

Ser un arquitecto es tener una mente abierta independientemente de las tecnologías (a saber, Java, C #, ASP, C, C ++, iOS, Android, Symbian, etc.). Incluso si desprecias lo que no sea con lo que te sientas cómodo. Debe * comprender * todos los matices de su sistema que está integrando. Esta no solo es su capacidad técnica, sino también la comprensión del negocio al que está brindando una solución. Confía en mí, siempre es diferente.

Mantenga su mente abierta, comprenda cada tecnología cómo funciona, sus patrones y antipatrones. Tenga en cuenta que si es bueno en los patrones si es bueno, pero conocer los antipatrones puede llevarlo al siguiente nivel.

Pocas cosas puedes hacer para ser arquitecto.

1. Intenta y define qué es
2. ¿Alguna vez ha escrito un artículo técnico basado en su experiencia?
3. ¿Cuántas preguntas has respondido en foros técnicos?
4. ¿Algún documento técnico?
5. ¿Cuáles crees que son las mejores prácticas para un desarrollador a seguir?
6. ¿Qué herramientas utilizas y por qué? Si ha sugerido algo, ¿puede justificarlo?
7. ¿Puede debatir sobre una arquitectura dada por su colega / gerente / cliente o quien sea arquitecto?
8. ¿Qué tan receptiva es su arquitectura para el cambio?
9. ¿Qué tan fácil es el código escrito para cambiar en caso de cambio arquitectónico?
10. ¿Usted o su equipo entienden los requisitos comerciales?
11. ¿Usted o su equipo saben por qué lo están haciendo y cómo pueden improvisar el proceso?
12. ¿Cuál es la curva de aprendizaje si su cliente decide usar otra tecnología?
13. ¿Cuál es su proceso de construcción y administración de versiones?
14. ¿Qué herramientas utiliza usted o su equipo para mejorar el rendimiento del individuo?
15. ¿Con qué frecuencia usted o sus desarrolladores escriben un caso de prueba? (¡pregunta equivocada! ¡Sé esto de hecho! Es algo que no está bajo mi control jeje)
16. ¿Puedes sugerir una tecnología para un problema dado? En caso afirmativo, ¿puedes justificar?
17. ¿Cuán escalable es la arquitectura que ha creado / construido? ¿Cómo reacciona ante un cambio importante en las reglas comerciales? ¿Cómo lo manejas?

Es un conjunto interminable de preguntas, las posibles respuestas son ……………. (infinito)

Si es desarrollador, piense en las preguntas anteriores y más.
Si es un aspirante a arquitecto, manténgalo simple y tenga una mente abierta. Aprende a escuchar y desarrollar 🙂

Si aún tiene preguntas, no dude en comentar.