¿Qué hace que un desarrollador senior... sea senior?

Trabajé con tantos desarrolladores durante más de once años de mi vida y sigo trabajando con muchos de ellos. He visto desarrolladores junior con veinte (sí, 20) años de experiencia y desarrolladores senior con solo cinco años en la industria.

Cuando recién comenzaba, me preguntaba qué diferenciaba a los desarrolladores senior de los demás.

También daré consejos en el camino para que los desarrolladores junior los ayuden a ascender.

El desarrollo comienza antes de la codificación. En realidad, si no administra la parte antes de codificar lo suficientemente bien, es posible que tenga dificultades para crear un buen software.

Índice
  1. Requisitos de software para un desarrollador Senior
  2. Hablemos sobre el diseño de software o arquitectura
  3. Debes usar los principios SOLID
  4. Cuando utilizar los principios SOLID
  5. Palabras finales

Requisitos de software para un desarrollador Senior

Como desarrollador, algunas personas siempre te darán algunos requisitos sobre los proyectos en los que estás trabajando.

Si los requisitos son razonables y lo suficientemente claros, es bueno. Pero, para ser honesto, es raro. Por lo tanto, es probable que no tenga grandes requisitos.

Esto puede deberse a diferentes razones, pero vi dos razones principales: 1-La gente de negocios no sabe lo que quiere en términos de software 2-La gente de software pospone las cosas para escribir requisitos razonables.

En realidad, la solución es bastante fácil. Te sientas con los requisitos y las personas que los escribieron y haces preguntas. Puede llevar algo de tiempo, pero llevará más tiempo si no lo haces con anticipación.

Las preguntas que debe hacer pueden variar de una tarea a otra, pero la idea principal es la siguiente: deberá comprender qué sucede exactamente y cuándo. Recuerde que también necesitará los casos fallidos, no solo lo que sucede cuando todo va bien. derecho.

Hablemos sobre el diseño de software o arquitectura

El framework para lograr un excelente diseño de software será el proceso más difícil. Después de tener grandes requisitos, es más fácil tener un diseño de software inclusivo. Siempre tendrás espacio para mejorar en este tema.

Como dice el tío Bob: “Un buen arquitecto maximiza el número de decisiones que no se toman”.

También será responsable de cambiar el software en el camino, por lo que es mejor que lo diseñe para recibir los cambios tanto como sea posible.

Diseñar un software excelente es un proceso desafiante y le sugiero que aprenda todo lo que pueda sobre él. Es un buen punto de partida para mejorar su organización y su software en general. Porque cuando diseña un software excelente, todas las personas con las que trabaja lo notarán. , y tratarán de actuar como tú.

Sin embargo, diseñar un buen software también es suficiente para convertirse en un gran diseñador de software. No dejes de mejorar en eso, no puedo enfatizar esto lo suficiente.

Debes usar los principios SOLID

Verás principios aquí y allá cuando quieras crear un gran software. Principios como DRY (Don't Repeat Yourself) y SOLID. Déjame explicarte los principios SOLID con ejemplos para que entiendas por qué son necesarios. También tengo analogías.

1- S: Principio de responsabilidad única

Definición: Una clase debe tener una sola razón para cambiar.

Explicación: Cuando tienes algo, tiene que tener un solo trabajo, si tienes una cosa que calcula, no debe presentar también la cosa que calcula, todo debe tener su propio trabajo, y solo un trabajo.

Metáfora:

R: ¡Tú también deberías hacer esto!

B: No.

2-O: Principio Abierto-Cerrado

Definición: Las entidades deben estar abiertas a la extensión pero cerradas a la modificación.

Explicación: Puedes ampliar la funcionalidad de algo que tienes en otro lugar, pero no deberías necesitar modificarlo, por lo que debería ser algo pequeño que hace una sola cosa tan bien que no necesitarás modificarlo.

Metáfora:

R: ¡Puedes volar con este nuevo traje!

B: ¡Yay!

R: ¡Además, puedes ser invisible si te cortas las uñas!

B: no.

3-L: principio de sustitución de Liskov

Definición (simplificado): Debería poder reemplazar subclases con superclases.

Explicación: Subclasificará tantas clases. Para mantener la base de código lo suficientemente sana, debe usar las superclases cuando necesite pasar algo. De esta manera, puede usar cualquier subclase que desee con la implementación concreta. Así que diseña en consecuencia.

Metáfora:

A: ¿Eres tú, tu hermano o tu padre en esta foto?

B: No importa, todos compartimos la misma sangre.

4-I: Principio de segregación de interfaces

Definición (simplificado): No tendría que implementar lo que no usará.

Explicación: Usarás interfaces (o protocolos) y tus clases implementarán esas interfaces. Deja que esas interfaces sean lo más pequeñas posible, para que nadie implemente algo innecesario.

Metáfora:

A: (Fútbol) ¡Pasarás, dispararé!

B: ¡Vamos, equipo!

Principio de inversión de 5 dependencias

Definición: Las entidades deben depender de abstracciones, no de concreciones.

Explicación: Depende de las interfaces (o protocolos), pasa las interfaces a los constructores siempre que sea posible, si no, hazlo posible.

Metáfora:

A: Me encanta la idea de amarte.

B: ¿Qué tal si hago esto esto movimiento de baile?

R: Difícil de abrazar, pero aún así está bien.

Cuando utilizar los principios SOLID

Aún debe aprender a ver cuándo necesita usar estos principios en su código base. Se trata de prueba y error, lo que mejora el reconocimiento de patrones, también llamado experiencia.

Sí, tengo que decir eso. Debes escribir pruebas. Para ser un desarrollador senior, no tienes que seguir los principios del desarrollo basado en pruebas (TDD), pero es una buena práctica de todos modos.

El mejor efecto secundario de TDD es que elimina la depuración casi por completo. Si se hace correctamente, le da confianza para que pueda tener lanzamientos más frecuentes y tranquilidad (sí, eso es realmente posible).

Palabras finales

Hay demasiados detalles involucrados en todos los puntos anteriores. Sin embargo, traté de darle un cuadro para pensar por dentro y por fuera. La cuestión es que, si es curioso y paciente, puede ser un desarrollador senior en un tiempo récord. La experiencia es El punto clave es a qué patrones te acostumbras, así que elige sabiamente.

Con eso, quiero que sepas que escribiré todo lo que pueda y lo publicaré aquí. Entonces, si quieres seguirme, será un honor. Hasta la próxima.

Aprende más de programación:

Si quieres conocer otros artículos parecidos a ¿Qué hace que un desarrollador senior... sea senior? puedes visitar la categoría Consejos.

Leonel Jiménez

Apasionado de la programación. Trabajando en este rubro de la programación desde hace 11 años. Ahora compartiendo contenido de programación esperando aportar valor a otros programadores. No olvides visitar mi canal de youtube

Deja una respuesta

Subir

Para ofrecer las mejores experiencias, utilizamos tecnologías como las cookies para almacenar y/o acceder a la información del dispositivo. El consentimiento de estas tecnologías nos permitirá procesar datos como el comportamiento de navegación o las identificaciones únicas en este sitio. No consentir o retirar el consentimiento, puede afectar negativamente a ciertas características y funciones. Más Información