software - architecture traduccion
Llegar a un nivel de arquitecto de aplicaciones (5)
Creo que estás preguntando cómo avanzar en la escala de una empresa, y ese es un proceso diferente al que están discutiendo los comentadores anteriores. También es muy diferente de una compañía a la siguiente, pero todavía hay habilidades y prácticas que son importantes en todos los ámbitos.
Lo más obvio es amplitud de visión. Tienes que estar familiarizado con todas las partes del sistema que estás discutiendo. Eso significa que debe tener el deseo de trabajar en diferentes áreas del código, aunque no sepa tanto sobre ellas como el área en la que ha estado trabajando. Tienes que estar dispuesto y ser capaz de ayudar a otras personas con cosas que sabes. Eso no significa presionar su información sobre ellos, significa responder amablemente cuando preguntan. Si tu consejo es útil, la gente vendrá a ti. El lugar obvio para comenzar con esto es ayudar a las personas que han asumido la responsabilidad de algo de lo que te has alejado recientemente.
Los arquitectos hablan con personas que trabajan en otros proyectos, tanto porque se les ha preguntado su opinión sobre ese otro proyecto, como porque descubren quiénes son los otros expertos y les hacen preguntas cuando la otra persona tiene más experiencia en un área.
Y, por supuesto, el código y los proyectos que deja atrás hablan por usted. Si su código no es legible y robusto, entonces no importará cuántos proyectos haya visitado. Tu propio trabajo tiene que ser impresionante también.
He sido desarrollador por aproximadamente 10 años. Quiero saber cómo puedo considerarme un técnico de nivel archiect? ¿Cómo puede el desarrollador pasar del desarrollo del nivel de código al arquitecto?
Obviamente quiero avanzar en la escalera tecnológica, y la arquitectura parece atractiva.
Una segunda pregunta sería, ¿cómo puedo aprender sobre la arquitectura de la aplicación (panorama general), en términos de 3.5 framework?
Cualquier consejo es apreciado.
Hay dos criterios para ser un arquitecto de software:
(1) Tienes que llamarte uno.
(2) Debe convencer a alguien para que le pague al software de arquitecto.
Todo lo demás es solo andamiaje. Si eres bueno en el desarrollo y la planificación "a gran escala", intenta venderte como arquitecto en tu próxima búsqueda de trabajo. Si alguien lo compra, eres un arquitecto.
Ser un arquitecto no es más que un estado mental. Hay connotaciones potencialmente malas que vienen junto con tener el estado de Arquitecto . Particularmente porque nadie puede responder realmente la pregunta: "¿Qué es un arquitecto?"
Primero y ante todo...
- ¿Significa esto que se trazan soluciones pero realmente no las implementa ?
Si es así, creo que es algo en lo que se debe trabajar, pero ¿cómo se trabaja para lograrlo simplemente "elaborando soluciones"? La experiencia práctica es un requisito previo y debe. Un programador verdaderamente bueno en última instancia tiene buenas habilidades para resolver problemas. Un buen solucionador de problemas finalmente sabe cómo construir buenas soluciones.
En mi opinión, si uno se enfoca en convertirse en un excelente programador , las habilidades para resolver problemas naturalmente comienzan a desarrollarse. Es inevitable que esto sea reconocido. Una vez reconocidos, las personas comenzarán a pedir opiniones sobre las mejores formas de resolver el problema X. Cuando uno comienza a recibir este tipo de preguntas, uno se convierte inherentemente en arquitecto.
En organizaciones corporativas, uno puede pasar a este estado mental y potencialmente tener un título físico (y pago potencial) para representar este estado mental. Pero no debemos olvidar que requiere un desarrollo REAL de buenas soluciones a los problemas. Esto es lo que finalmente nos lleva a este estado mental.
Al final, es solo una palabra que dice muy poco detrás de la persona que lleva el título.
Si tiene que hacer la segunda pregunta, todavía no está listo para ser arquitecto.
Leer y escribir el código Sea un generalista, no un especialista. Eche un vistazo a una descripción general de 3.5 y asegúrese de haber hecho algo en todas las áreas. Solo lo suficiente para reconocer los problemas y saber dónde y a quién buscar respuestas. Eche un vistazo fuera de .net y vea cómo problemas similares se resuelven en otros entornos (cacao, java, rieles, vidrio, LAMP, delphi, flex)
A riesgo de exponerme a los quisquillosos y analizadores de palabras,
Ser un "Arquitecto" significa que tiene que ser capaz de diseñar "Sistemas" de software, que consisten en múltiples "componentes" trabajando juntos de una manera débil para resolver un problema comercial bastante complejo y poder "dirigir" o "orientar" otros desarrolladores en la construcción de dicho sistema.
Además de ser experto en la (s) tecnología (s) necesaria (s) para resolver el problema, esto también significa que debe ser capaz de entender el problema comercial en cuestión, desde una perspectiva comercial, y ser capaz de comunicarse con fluidez al respecto, tanto con el negocio expertos de dominio (usando su lenguaje) y con los desarrolladores que construirán los componentes (en su idioma)