En el campo del desarrollo de software, a menudo hay tesis como "
A nadie le importa su código " (traducción: "
Su código no le interesa a nadie "), "El código es solo una herramienta" y situaciones de malentendidos completos por parte de las empresas por qué deberíamos tomar tiempo y dinero para algún tipo de "refactorización" del código que ya funciona.
Quiero decirle a qué puede conducir el "énfasis en las características", en lugar de preocuparse por la calidad del código, y por qué no solo los programadores necesitan un buen código.
Apoyo
La tesis principal, sin la cual el artículo actual, en principio, no tendría sentido:
Lo que ha estado sucediendo en el mundo de la programación durante décadas, por el cual se crean lenguajes, paradigmas y enfoques más avanzados, para los cuales distinguen varias plantillas y se encargan del diseño del código, de hecho, son dos cosas: aumentar la velocidad de desarrollo y facilitar el soporte de la base de código (que esencialmente la velocidad de desarrollar nuevas funcionalidades).
Y estas son las cosas que las empresas necesitan.
Por supuesto, se puede argumentar que ellos mismos necesitan las metodologías que aumentan la eficiencia del trabajo de los programadores para vender su trabajo más caro, poder hacer más por unidad de tiempo, pero porque la situación cuando los programadores solicitan un gran proyecto terminado de inmediato sin la necesidad de más apoyo es muy es raro, y generalmente la funcionalidad se ordena gradualmente, al comienzo del proyecto no sentirá los efectos nocivos del diseño deficiente, es más bien una inversión en el futuro.
Hay una imagen del
blog de Martin Fowler sobre este tema, que muestra la velocidad de introducir nuevas funciones en un proyecto dependiendo de su tiempo de existencia (es decir, qué tan grande es).
El eje horizontal es la vida útil del proyecto, el eje vertical es la funcionalidad agregada.
La línea roja ilustra la velocidad de desarrollo de un proyecto con un buen diseño, y la línea azul ilustra un proyecto que se escribe sin restricciones en forma de requisitos para la calidad del código.
Por lo tanto, si cree que su aplicación está condenada al fracaso y no se desarrollará, o se está preparando exclusivamente para algún evento próximo, no necesita pensar en el diseño del sistema. En la situación opuesta, un buen diseño es probable que valga la pena, y que valga la pena muchas veces.
A veces puede escuchar la opinión de que al comienzo de un proyecto no tiene que pensar en la calidad del código y volver a escribirlo después de una presentación exitosa a clientes / inversores, pero en la gran mayoría de los casos esto es un error al iniciar proyectos y la forma más fácil de ganar
deuda técnica en los años venideros.
El código no es una herramienta; el código es un producto final
Una
compañía de software no usa el código como herramienta. Este es el producto principal de la empresa, es el código final del programa que determina su calidad, velocidad, cumplimiento de los requisitos de funcionalidad. No se puede tomar y reemplazar por completo sin incurrir en pérdidas temporales y materiales, como se podría hacer con las Metodologías de Computación / IDE / Desarrollo, que ya serán esencialmente herramientas para crear el producto.
Sobre "Centrarse en el rendimiento"En el artículo al que me referí, se expresó el siguiente pensamiento: debe comunicarse con el cliente / Gerente de proyecto a nivel de preparación del proyecto, y el siguiente ejemplo fue lo contrario:
Imagina que el diseñador comenzará a contarte sobre las capas que usó en Photoshop, sobre cuántos objetos tiene allí, qué gradientes se usan en qué pinceles y qué geniales guiones de animación escribió. No te interesa. ¿Le interesa saber si ya es posible tomar fotos?
Entonces aquí. Hay una diferencia por la cual no
se puede proyectar simplemente en la situación con el soporte de un producto de software: todas estas capas y pinceles en Photoshop se vuelven innecesarios para cualquiera justo después del resultado del trabajo (imágenes), y de todos modos son una herramienta para lograr el resultado , no el producto final.
Por lo tanto, al elaborar los requisitos para las imágenes finales, el cliente no puede preocuparse por lo que se utilizará en el proceso. En el caso del software, si el cliente (empresa) solo exigirá la funcionalidad de la aplicación, corre el riesgo de obtener exactamente lo que quería: nueva funcionalidad, pero no había duda de que necesitaría mantenerse y desarrollarse.
Desafortunadamente, este es un problema bastante común en el outsourcing, cuando una empresa vende solo el tiempo de sus desarrolladores y los clientes no pueden evaluar objetivamente la calidad del sistema y el tiempo requerido para resolver sus problemas. Cuando el costo de cambiar el código aumenta exponencialmente, solo beneficiará a la propia empresa al subcontratista (se pueden monetizar más horas humanas y la empresa que ordena el producto ya estará en apuros) es demasiado tarde para reescribir el sistema engorroso e inconveniente, ya que requiere grandes inversiones y detiene la entrega de nuevas funciones eso no se puede permitir.
Código - lugar de trabajo del programador
Durante todo el tiempo que el artículo estuvo en copias preliminares, pensé mucho si este artículo debería incluirse en él, pero después de una pequeña observación de las prioridades de los candidatos que buscan trabajo, me di cuenta de que este momento es realmente importante.
El código es algo con lo que un programador tendrá que trabajar todos los días, su producto creativo, lo que crea, pero crea no solo uno, sino en un equipo, y a menudo no desde cero. Necesita aceptar la parte ya existente del proyecto, desarrollarla en función de la funcionalidad que se escribió antes. Es muy probable que un empleado sea desagradable trabajar en un producto que se crea mal.
En primer lugar, en mi opinión, es el equipo trabajando juntos en el proyecto. La calidad del producto resultante depende directamente de cómo se construye el trabajo en equipo, de las reglas internas y de los requisitos establecidos dentro de él.
En segundo lugar está la tecnología. Un marco inconveniente elegido o heredado irreflexivamente, herramientas obsoletas y de baja calidad, las bibliotecas clavadas en el lugar del proyecto con todas sus muletas y errores que tiene que soportar, y la falta de personas con suficientes competencias y tiempo para eliminar los enfoques heredados pueden ahuyentar fácilmente el nuevo potencial trabajadores Además de las razones indicadas anteriormente, este también es un número menor de perspectivas y oportunidades para el desarrollo de programadores, porque en lugar de estudiar las herramientas modernas y más efectivas, es necesario desarrollar accesorios para adaptar las soluciones a los problemas actuales debido a razones históricas.
¿Por qué es todo esto?
Desafortunadamente, los requisitos para aplicaciones reales rara vez se pueden formar al 100% y no requieren revisión durante el desarrollo. Además, la situación es casi imposible cuando el proyecto no tiene que ajustarse a los nuevos requisitos después del lanzamiento. El negocio se expande, se desarrolla, requiere funcionalidad que no se discutió antes, ingresa a nuevos mercados.
Es casi imposible construir una arquitectura ideal y pensada para cada pequeño detalle en tales condiciones, y, a menudo, no es necesario, porque su costo en este caso es irrazonablemente alto para la etapa inicial del proyecto.
Ciertamente, escribir un buen código no debería ser un dolor de cabeza para quienes solicitan software de los programadores, y es poco probable que alguien que no pueda escribirlo pueda verificarlo.
Sin embargo, una empresa que desarrolla un producto de software, si quiere hacerlo cualitativamente, debe comprender que una parte tan importante del producto como su código fuente afecta directamente su éxito, y cosas como refactorizar el código fuente y modificar la arquitectura a los nuevos requisitos también deben sea un presupuesto, se debe asignar tiempo a los programadores. Si alguien está interesado en la calidad del producto, por supuesto.
Sin embargo, la industria de TI se está desarrollando, los productos, las empresas, las herramientas se están desarrollando, los usuarios se están volviendo más selectivos, la competencia está aumentando y existe la esperanza de que el futuro seguirá siendo con productos de alta calidad.
Conclusión
De hecho, el tema del artículo es, por supuesto, muy controvertido.
El gráfico anterior no responde a la pregunta en qué momento el diseño del sistema comienza a dar sus frutos.
La deuda técnica para eso y la deuda, que le permite obtener un poco más de tiempo ahora y devolverlo con intereses más tarde, y su principal problema es extremadamente simple y se parece mucho a un fenómeno similar en la economía, es la incapacidad de pagar las deudas y la incapacidad de estimar con precisión los ingresos futuros.
La calidad del código también es algo muy subjetivo y, desafortunadamente, prácticamente no está formalizado, de lo contrario los programadores ya podrían ser reemplazados por robots.
En cualquier caso, lo más importante es lograr compromisos competentes y encontrar ese punto medio, que nos permitirá no ahogar el proyecto en el pozo de la deuda técnica en busca de funcionalidad, y no ceder un nicho interesante a los competidores, haciendo el diseño del sistema en lugar de la funcionalidad.