¿Qué es un consejo para ser un desarrollador líder?

Answer 1

¿Quiere decir cómo convertirse en un desarrollador líder o cómo ser un buen desarrollador líder?

Para convertirte en un desarrollador líder debes conocer el código. Lo que significa que tienes que leer el código de otros proyectos y ver los méritos allí. Lee mucho código y descubre mejores maneras de hacer cosas. Aplica esas ideas en tu código.

Eventualmente, tus habilidades de codificación serán tan buenas que nadie te vencerá y podrás ayudar a otros.

Cree capas de abstracción para poder codificar las cosas más rápido y con menos errores.

Leer libros de programación.

Una vez que te conviertas en un desarrollador líder, ¿cómo puedes convertirte en un buen desarrollador líder?

Usted es un líder si tiene toda la responsabilidad, no solo de todo el código, sino de las personas que lo ayudan. Diriges el equipo, por lo que todo lo que hagas debe ser en beneficio del equipo, porque no puedes dirigir a las personas que no quieren ser lideradas, y si ven que ayudarlo no está en el mejor interés, no lo harán. seguirte.

Cosas que debes decirle a tu equipo:

1. El código debe ser entendible. Eso generalmente significa no más de 10 líneas de código por método. No más de 10 métodos por clase. No más de 3 variables de instancia por clase.
2. Prueba de unidad todo utilizando JUnit de similares.
3. Todo codificado utilizando programación de pares o haciendo revisiones de código.
4. Tenga un documento escrito de convención de código donde coloque las cosas que se revisarán durante las revisiones de código.
5. Recopilación de un solo paso utilizando ant, mven o gradle.
6. Ten cuidado al nombrar cosas, usa la intención revelando nombres.
7. La compilación de un paso debe compilar también la prueba y también ejecutarlos. Un fallo de prueba se confiere un fallo de compilación.
8. Configurar una máquina como repositorio de código fuente.
9. Configurar otra máquina como máquina de integración continua. Esa máquina debería compilar todo desde cero y también ejecutar las pruebas.
10. Configuración de despliegue continuo.
11. Los detalles deben depender de las abstracciones y la abstracción nunca debe depender de los detalles.
12. Aprende patrones de diseño y enséñalos a tu equipo.
13. No trabajar horas extras. Siempre. Si sale a las 5 pm y la máquina de integración demora 30 minutos en compilar y probar el código, nadie debe hacer ningún registro después de las 4 pm, porque si la compilación se rompe, no será agradable llegar al día siguiente para corregirlo. la ruptura de la construcción de alguien más. Cada desarrollador debe resolver sus propios descansos de construcción.
14. No escriba código antes de entender el diseño.
15. No diseñes antes de entender los requisitos.
16. Asegúrese de que los requisitos sean verdaderos, pero no los diseños hechos por personas no calificadas para resolver un problema que no conoce.

Answer 2

Menos es más. Busque el consenso para descomponer el sistema que se va a crear / mantener en subsistemas y diseñar interfaces de subsistemas. Cada subsistema debe ser lo suficientemente pequeño para que una persona lo implemente (de lo contrario, continúe la descomposición en subsistemas de forma recursiva). Dale a la gente una mano libre en los subsistemas en los que están trabajando, pero asegúrate de que todos estén vigilando todo. Solo imponga su propio pensamiento cuando exista una razón objetiva, significativa y al menos aproximadamente cuantificable para hacerlo, o cuando falte el consenso necesario. Esté muy disponible para brindar consejos no menospreciativos y recompensar a otros en el equipo que hagan lo mismo.