¿Cómo puede un desarrollador de software convertirse en arquitecto de software?

En verdad, no sé cómo es posible ser desarrollador sin ser arquitecto de software. ¿Cómo se puede usar decir “desarrollador” y no solo decir “codificador”?

Creo que si crees que no eres arquitecto como desarrollador, debes tener algún problema con la autoestima. Pero, entonces, alguien en algún lugar de la industria ha creado este límite artificial, probablemente para poder pagar más dinero a sus amigos, y luego la gente comenzó a usarlo después de que él y sus amigos se jactaran de ello.

Entonces, aquí hay algunos puntos sobre la arquitectura de software, como he visto si aumentan con los años.

1. La mayor parte de la terminología es hocus pocus. Está compuesto por personas que valoran más su propia importancia que otras. Aunque, tengo que estar de acuerdo en que conocer algunos términos comunes es bueno.
2. Todos esos términos conocidos pueden describir formas de hacer cosas que podría usar, pero entonces podría ser mejor no usarlas. Esto no se debe a que definen límites reales y su proyecto requerirá solo algunos de los términos geniales. Pero es más probable que definan límites como si fueran ideas fijas cuando, de hecho, las ideas son mutables. Probablemente necesites tus propias ideas.
3. Podría escribir una biblioteca completa que invierta el control. Pero, en serio, ¿por qué lo harías? ¿Y qué ganas haciendo eso? La idea es que realmente no deberías hacer un patrón de diseño, bendecido por algunos tipos molestos, como la característica más importante de la biblioteca.
4. Debe comprender claramente que debe organizar el código de manera clara para resolver su problema y permitir un trabajo fácil y comunicativo con otras personas. Entonces, deberías estar haciendo eso como desarrollador. Y, debe comprender su lenguaje natural lo suficientemente bien como para desarrollar esta comunicación.
5. Los patrones de diseño populares no se corresponden necesariamente con los requisitos de un sistema en lo que se refiere al mundo físico o al mundo de los negocios. La relación del código con su área temática es mucho más importante que el seguimiento de ciertos patrones de restricción.

Entonces, eso es solo algunas cosas en las que pensar. Puede parecer que estoy sugiriendo que es bueno diseñar sus propios patrones y hacer un uso realmente bueno de un lenguaje natural, como el inglés. Soy. No ignoraría el pensamiento de otras personas sobre los patrones de diseño. Pero no los llamaría evangelio.

Si crees que no puedes encontrar patrones mejores que algunos de los que encuentras en esos libros sobre ellos. Entonces, es probable que seas una persona de baja autoestima. Considérate mejor y piensa por ti mismo.

Ahora, después de todo eso, ser inteligente y bueno en arquitectura probablemente no te conseguirá un trabajo, porque serás entrevistado por un idiota que piensa que todos los patrones escritos son gospel y que también es un sagaz para su jefe. Se necesita mucho tiempo para conseguir fanáticos religiosos para un tipo de programación y súplica en el trabajo. Entonces, si piensa fuera de la caja, es probable que lo vean como una amenaza o estúpido o indisciplinado. Entonces, si haces toda la conversión, y optas por ser ese tipo de esclavo, entonces tendrás más poder, ya que tendrás un cheque de pago. Pero, nuevamente, las personas que trabajan en la industria del porno tienen cheques de pago, y también las personas que recogen la basura (donde eso es un trabajo). No olvides elegir a tu jefe sabiamente.

La distinción puede no ser tan buena, dependiendo del tipo de sistema de software que desarrolle. En general, en arquitectura, se centrará más en la descomposición de su sistema de software y buscará asegurarse de tener una base estable para cumplir con sus requisitos.

Es solo en equipos más grandes que el rol de arquitecto, distinto del desarrollador, podría comenzar a tomar forma. En ese caso, el arquitecto se asegurará de que los diferentes desarrolladores estén escribiendo módulos que se integran y funcionan de acuerdo con las decisiones de diseño en la arquitectura.

Entonces, para pasar a ser ‘arquitecto’, te sugiero que analices qué tan bien trabajas con los demás y qué tan bien puedes coordinar el trabajo entre diferentes desarrolladores.

El primer paso puede ser: comprar el libro Gang of Four sobre el patrón de diseño.

Amazon.in: compre patrones de diseño: libro de elementos de software orientado a objetos reutilizables en línea a precios bajos en India

¿Entonces eres un desarrollador de software que no piensa en arquitectura? Entonces has hecho algo mal en los últimos 11 años. Todo lo que quieres hacer es reemplazar dos palabras. Al desarrollar cosas, siempre debe pensar en la arquitectura y el clima, su código encaja en el lugar donde debe escribirlo. Siempre debe ver el panorama general, aunque no debe codificar cosas prematuras. Para mí no hay diferencia entre un desarrollador de software y un arquitecto de software, excepto la redacción. Lo siento si eso no era lo que esperabas. Pero si lo desea, podemos continuar esa discusión.

Lo que haría es una autoevaluación utilizando el CV de Arquitectura de Software de iSAQB. Esto podría ayudarlo a evaluar cómo sus habilidades se ajustan a un conjunto de habilidades de Software Architect.

Las expectativas para el papel de “Arquitecto” varían ampliamente entre los empleadores.

Un arquitecto puede escribir código todo el día o nunca escribir código, puede asistir a reuniones la mayor parte del día o casi ninguna reunión formal, puede interactuar principalmente con desarrolladores o propietarios de productos, puede tener el poder de hacer cumplir los estándares o simplemente hacer recomendaciones, puede tener antecedentes en manos en desarrollo o antecedentes académicos.

El punto es que el papel del arquitecto es realmente una atracción para cualquier tipo de liderazgo técnico. Realmente no sabrá si encaja bien hasta que hable con el gerente de contratación.

No importa cuál sea la expectativa técnica, el papel del arquitecto de software siempre requiere una excelente comunicación y habilidades de las personas. En mi experiencia, este es un gran cambio cultural de trabajar en el desarrollo de software.

Sencillo. Trabajando duro e impresionando a su gerente.