El Grado de Desarrollador de Código Limpio

No se trata sólo de convertirse en un desarrollador de código limpio. No se trata de memorizar unas cuantas reglas, se trata de aprender las Sistema de valores CCD para interiorizarlo realmente. Esto requiere tiempo y práctica. Por eso hemos dividido el sistema de valores del DIRCE en etapas, que los desarrolladores van subiendo de una en una. Sin embargo, vemos todo el proceso como un círculo: una vez superados todos los niveles, se vuelve a empezar desde el principio.

A cada etapa de desarrollo se le asigna un color. Y a todo aquel que trabaje como desarrollador de código limpio en un nivel se le asigna un color. Pulsera CCD como signo de su voluntad de dominarlo. A diferencia del judo, el color no corresponde a un grado alcanzado, sino a un grado en progreso.

Negro 0º grado

En grado negro tiene todo aquel que aún no ha emprendido este viaje. Por tanto, un brazalete negro sólo indica que estás interesado en el DIRCE. Puedes llevarla si aún no cumples todos los requisitos para el primer grado real.

Rojo 1er grado

El verdadero camino para convertirse en un Clean Code Developer comienza con el grado rojo. La práctica comienza con el grado rojo. Por lo tanto, sólo contiene elementos del sistema de valores CCD que son absolutamente esenciales. Empezar debería ser lo más fácil posible. Por lo tanto, este nivel no trata tanto de los principios de desarrollo de software como de la creación de una actitud fundamental hacia el desarrollo de software y el Desarrollador de Código Limpio.

Naranja 2º grado

Una vez sentadas las bases del proceso de mejora continua en el grado rojo, la siguiente etapa es el grado naranja para aplicar algunos principios fundamentales al código y adquirir experiencia inicial con el medio número uno de aumentar la productividad: la automatización de procesos. Dado que sólo un código correcto es un buen código, la automatización se utiliza para comprobar la corrección. No se trata, por tanto, de una propiedad del código que es bueno tener, sino de su esencia.

Amarillo 3er grado

En Grado amarillo se trata de pruebas automatizadas. El nivel naranja seguía tratándose de pruebas de integración que podían aplicarse externamente. Esto no requería necesariamente ninguna intervención en el código. A partir del nivel amarillo, sin embargo, ya no es posible sin pruebas por debajo de la superficie. Y no sólo eso: hay que probar las unidades más pequeñas posibles, no sólo los pinchazos funcionales. Esto supone un cambio en la práctica de codificación, porque de lo contrario no se pueden probar clases individuales de forma aislada, es decir, independientemente de los servicios utilizados. Por eso el nivel amarillo también incluye principios orientados a objetos, porque sólo con ellos es posible desvincular el código que se va a probar de su "fondo".

Verde 4º grado

En el grado verde la automatización continúa. Es sencillamente la clave de la productividad y la capacidad de respuesta. Sólo cuando el mayor número posible de actividades de desarrollo de software están automatizadas puede el CCD concentrarse en lo esencial: aplicar los requisitos del cliente. Sin automatización, el desarrollo depende a menudo de detalles menores, lo que cuesta tiempo. Las comprobaciones de corrección y las versiones son entonces más un castigo que un medio para alcanzar el éxito. Sin embargo, tras la automatización de las pruebas, la producción pasa a estar en el orden del día. Probar el código en el puesto del desarrollador es una cosa. Otra es compilarlo y probarlo con éxito en un ordenador independiente. Es la única manera de encontrar dependencias más o menos sutiles en las estaciones de trabajo individuales de los desarrolladores. A esta práctica se añaden otros principios para la estructuración del código y una herramienta para mejorar las arquitecturas.

Azul 5º grado

Con el grado azul estamos entrando en la recta final del sistema de valores CCD. Hay que dar un paso más en la automatización. Tras la traducción y las pruebas, el despliegue está ahora en el programa. Pero, sobre todo, el grado azul se refiere ahora a aspectos del desarrollo de software que van más allá del código y las herramientas: El CCD no sólo se ocupa de las buenas estructuras a pequeña escala, sino que también las planifica a gran escala desde el principio. Así que todo gira en torno a la arquitectura. Sin embargo, como somos conscientes de que ninguna planificación puede definir una solución perfecta, no sólo la arquitectura, sino el desarrollo de software en su conjunto también incluye un modelo de proceso adecuado. Éste es iterativo y debe practicarse durante el trabajo sobre el grado azul.

Blanco 6º grado

En el grado blanco todos los principios, reglas y prácticas fluyen juntos. Al igual que todos los colores están contenidos en la luz blanca, el nivel blanco contiene todos los demás niveles. Un CCD sólo funciona al nivel del grado blanco si tiene constantemente a la vista todo el sistema de valores del CCD. Esto deja claro que sólo los desarrolladores de software realmente avanzados, con varios años de experiencia y en un entorno adecuado, pueden trabajar con el nivel blanco.

Significado de los grados

Los grados no expresan un valor. Alguien que trabaja en el grado azul no es "mejor" o está "más lejos" que alguien que trabaja en el grado naranja. Los grados no son más que una herramienta didáctica para que la totalidad del sistema de valores sea "más fácil de digerir". Los numerosos componentes básicos pueden aprenderse mejor en pequeños bocados que de una sola vez.

Por eso es importante para nosotros que todos los futuros alumnos empiecen por el nivel rojo. Por razones didácticas, es el mejor lugar para empezar, incluso si cree que ya aplica otros valores en su trabajo diario. Independientemente de la práctica actual del proyecto, es ciertamente novedoso tratar principios y prácticas de forma tan consciente. En particular, reflexionar sobre ellos a diario probablemente no sea todavía un hábito. El nivel rojo es, pues, adecuado para practicarlos en el contexto de "simples" bloques de construcción.

Aunque entendemos que cualquiera que quiera Sistema de valores Si una persona ve algo por primera vez y quiere marcar lo que ya se toma a pecho, en última instancia esto es irrelevante. La práctica consciente en el marco del sistema de valores es siempre nueva, y cualquiera que piense que "merece" el nivel blanco debería empezar por el nivel rojo. No se trata de "ganar", sino de iteraciones y pequeños bocados. Los títulos son mirillas para ver el panorama general.

¿Quién fue el primer Pulsera así que es mejor pedir la pulsera roja.

Formación continua

En Sistema de valores y los bloques de construcción pueden parecer rígidos, como cincelados en piedra. Pero no lo son. Siempre es provisional hasta que nosotros o la comunidad consideremos que hay que cambiar algo. Sin embargo, el mundo de las herramientas y los materiales a los que debe aplicarse el sistema de valores es aún más cambiante. Los lenguajes de programación, los IDE, los marcos de trabajo, las plataformas y los productos de servidor cambian constantemente, se añaden o se eliminan. Hay una tendencia a que lo que potencialmente podría ser conocido y hábil se convierta en más, en mucho más. En el pasado, estabas bien servido con un lenguaje de programación y su biblioteca estándar. Hoy, eso ya no basta.

Dado que profesionalidad significa tomar decisiones con conocimiento de causa, el DCN no tiene más remedio que someterse a una formación continua. De hecho, el desarrollo de software es probablemente el sector que más lo necesita. Por ello, la formación continua forma parte de varias titulaciones (Naranja, Amarillo, Verde). Queremos dejar claro que la formación continua es siempre una cuestión, pero también debe seguir una evolución. No es posible pasar de 0 a 100 en un solo programa de formación. No sólo hay que practicar el desarrollo de software, también hay que aprender a formarse.

Sin embargo, los títulos sólo se refieren a distintas formas de formación (lectura, trabajo en red, publicación). No especifican cuánto tiempo debe dedicarles un CCD. La razón: en nuestra opinión, no se trata de formas específicas. La formación debe representar al menos 20% del tiempo de trabajo, independientemente de la forma.

Sí, lo decimos en serio. 20% del tiempo de trabajo debe ser tiempo de formación. Así que 1 día por semana de 5 días sólo para formación. Nada menos. Google demuestra que esto funciona: "Esto significa que cada empleado puede dedicar el 20% de su tiempo de trabajo a proyectos que no estén directamente relacionados con su trabajo. Esto no se controla". (FuenteEntrevista con Phillip Schindler, Director de Europa del Norte en Google, Hamburger Abendblatt, 7 de noviembre de 2007)

20% sigue pareciendo mucho. Pero no se preocupe, la formación no es tan mala para los que tienen que pagarla. Al fin y al cabo, la formación no es lo que se asocia a primera vista:

La formación no es una fiesta
La formación continua no es una ausencia del puesto de trabajo
La formación no significa que no se creen beneficios para los proyectos
La formación no requiere necesariamente un presupuesto elevado para formación o software

Por encima de todo, formación significa margen de error. Dicho de otro modo: Durante las horas de trabajo 20%, un desarrollador de software profesional no debe tener miedo de cometer errores. En casos extremos, esto significa que los 20% no aportan ningún beneficio directo a un proyecto. Compare la formación con el tiempo de ensayo de un músico. El músico tiene que actuar en el escenario, preferiblemente sin cometer errores. Sin embargo, para mantener o incluso mejorar sus habilidades, un músico debe practicar. Los errores están expresamente permitidos, ya que de lo contrario no sería posible ningún desarrollo posterior. Por tanto, se necesitan dos "modos de funcionamiento" diferentes.

Sólo sobre la base de tal margen de error se plantea la cuestión de cómo podría rellenarse. El único requisito para un posible contenido debe ser que se reconozca una conexión con el trabajo. Quien utilice el margen de maniobra 20% para realizar búsquedas privadas de propiedades en Internet o practicar deporte en el gimnasio de la propia empresa, en realidad no está continuando su formación.

Ejemplos de contenidos de formación

Estudio de publicaciones especializadas (en línea/fuera de línea, blog/revista/libro/vídeo)
Poner a prueba lo que has leído
- Tecnologías
- Procedimiento
- Herramientas
Asistencia a actos especializados (formación, conferencia, acto comunitario)
Publicación de su propia experiencia
- en los medios propios de la empresa (por ejemplo, wiki del proyecto)
- en plataformas públicas (blog, revista, libro, conferencia especializada)

Que las lecturas, experimentos o publicaciones estén directamente relacionados con un proyecto es secundario. Pueden estarlo, pero no tienen por qué. Un DCN puede evaluar una tecnología con vistas al proyecto de la empresa o simplemente por interés general. En ambos casos (¡!) se obtienen beneficios para el proyecto. Una vez directamente, otra indirectamente. Porque cualquier conocimiento de una tecnología o proceso, aunque su uso en el proyecto aún no sea previsible, amplía el horizonte, es decir, te hace más experimentado y te da más opciones.

Nota para los responsables de la toma de decisiones: los desarrolladores que siguen una formación continua son una ventaja. Tienen más experiencia, son más innovadores y más flexibles. Esto beneficia a sus productos.

Nota para los desarrolladores de software: Los que siguen formándose son más valiosos. Adquieren experiencia, no se quedan atascados en un nicho y no son objeto de exageraciones. Esto favorece la "empleabilidad".

Práctica de ejercicios

Convertirse en un desarrollador de código limpio lleva tiempo. Creemos que no lleva menos de 21 días por titulación. Porque según la psicología, la gente necesita 21 días (o 3 semanas) para integrar cosas nuevas o cambios en general en su vida como hábitos.

Por lo tanto, toda persona que trabaje en un nivel de DCC debe proceder del siguiente modo: Al anochecer de cada jornada laboral, el CCD reflexiona sobre si ha respetado los principios de su grado (y de los inferiores). En caso afirmativo, mantiene el brazalete en el brazo donde está. En caso negativo, cambia el brazalete al otro brazo. Esto es importante porque el acto de cambiarlo hace que el promotor sea consciente de que necesita interiorizar aún mejor los principios.

En cuanto un desarrollador haya trabajado en un nivel durante 21 días sin cambiar de pulsera, podrá considerar que domina el nivel, pasar al siguiente y ponerse su pulsera.

Por supuesto, no existe un control formal de si realmente se han observado todos los principios durante una jornada. Por lo tanto, dejamos en manos de la honestidad de cada promotor hacia sí mismo y hacia la comunidad del CCD el emitir un juicio según su leal saber y entender. Dado que ninguna calificación es "mejor" o "peor" que otra, no vale la pena hacer trampas de todos modos. Suponemos que los desarrolladores que hayan dominado el nivel blanco volverán a empezar con el nivel rojo. De este modo, demuestran su convicción de que el desarrollo de software es un aprendizaje continuo.