Buen día, llevo 8 años programando y programando en todas sus manifestaciones: desarrollando el lado del servidor en diferentes lenguajes de programación, desarrollando el lado del cliente, programando las redes, administrando Linux y optimizando el rendimiento. Y cuando ha estado ocupado con un negocio durante tanto tiempo, lo ama sinceramente y se esfuerza por el autodesarrollo, entonces inevitablemente comienzan a surgir varias relaciones causales en el campo correspondiente, comienza a ver esas relaciones que ni siquiera conocía antes o simplemente las consideraba insignificantes, Esto es lo que la gente llama experiencia.
Y se trata de una de estas relaciones causales que me gustaría compartir con ustedes en este artículo. Pensé en escribir que esta es una de las relaciones causa-efecto más importantes para ser un poco menos radical, pero aún no lo es, esta relación causa-efecto es la relación causa-efecto más importante en la programación por un amplio margen. Se ejecuta como un hilo a través de absolutamente todas las áreas de programación: escribir código, diseñar una interfaz, implementar una aplicación, organizar un equipo, mantener un rastreador de errores, etc. Y llamo a esta relación causal sagrada la
minimización de variables .
Por el término variable me refiero no solo a las variables ordinarias (que se declaran mediante las palabras clave
var ,
let ,
function ), sino también a las variables en un sentido más abstracto de la palabra: carpetas creadas en el árbol del proyecto, bibliotecas que se conectarán, número de llamadas ajax al servidor, número componentes en la interfaz, el número de protocolos que el programador debe seguir al confirmar el código (por ejemplo, revisión de código, cada función en un brunch separado) y así sucesivamente.
De hecho, todo el proceso de programación es una enumeración de variedades en la dirección de cómo implementar esto o aquello funcional utilizando el mínimo número posible de variables (al menos miro la programación desde esa perspectiva). El código que implementa la función con menos dependencias / archivos / líneas de código es mejor que el que implementa la misma funcionalidad con una gran cantidad de variables. Si una clase de utilidad contiene solo una función, debe deshacerse de esta clase de utilidad, si la función consta de una sola línea, debe deshacerse de esta función si solo hay 10 líneas de código en el componente; debe eliminar este componente si solo hay un archivo en la carpeta - necesita deshacerse de esta carpeta, y así sucesivamente. Y cuando se suman varios miles de estos cambios aparentemente insignificantes, el resultado es un código hermoso, conciso y minimalista que es muy fácil de leer. El diablo está en los detalles como dicen.
Aquí hay una lista de efectos positivos que aparecen cuando comienza a programar en base al principio de minimizar las variables:
- Menos errores Como se escribe menos código, el número de lugares donde puede cometer un error se reduce correspondientemente.
- Es más fácil presentar nuevas personas al proyecto. La complejidad del proyecto es directamente proporcional al número de variables en este proyecto, cuantas menos variables, más fácil es introducir nuevas personas.
- Más fácil agregar nueva funcionalidad. Dado que es necesario estudiar una cantidad menor de código, se hace más fácil "cargar" lo funcional en la cabeza y, como resultado, agregar nueva funcionalidad o modificar el código existente.
- Previsibilidad El proceso de programación se vuelve mucho más predecible, le resulta más fácil predecir cuánto tiempo llevará desarrollar una característica u otra debido al hecho de que disminuye el número de "gags". Por lo general, son los enchufes los que causan la mayor cantidad de problemas y provocan el retraso de los plazos.
Pero muy a menudo ocurre la situación opuesta, los programadores comienzan a afirmarse introduciendo nuevas variables. Presentamos 20 bibliotecas diferentes, marcos CSS, creamos una gran cantidad de abstracciones
multinivel como
UserFactoryManager (especialmente los programadores de Java pecan por alguna razón), creamos demasiados directorios, introducimos metodologías de desarrollo más avanzadas, agregamos más protocolos antes de comprometer archivos, Y así sucesivamente. Y la motivación detrás de tales decisiones se puede entender, porque crea la ilusión de profesionalismo, dicen que miren cuánto sé y qué complejas abstracciones puedo manejar. Pero a menudo esto causa un daño terrible al proyecto.
No me malinterpreten, no estoy en contra del uso de metodologías, marcos y tecnologías más avanzadas, solo digo que muy a menudo se introducen simplemente por exageración, y no porque esta tecnología resuelva ningún problema urgente en el proyecto.
La solución al problema de demasiadas cantidades de variables puede llamarse
sobreingeniería . Pero debe admitir que si describe esta situación como si el problema se resolviera con demasiadas variables, esta es una descripción mucho más precisa de este fenómeno.
A menudo, la introducción de nuevas variables se justifica por la escalabilidad, dicen que si crea una
UserManagerFactory aquí , entonces podemos tomar y agregar una función en cualquier momento si es necesario. Pero en realidad, la escalabilidad no es cuando se introducen muchas variables, sino más bien cuando hay pocas variables. ¿Piensa dónde le resultará más fácil escribir una nueva funcionalidad: en el motor del navegador Chrome o en un proyecto completamente nuevo que escriba desde cero?
La introducción de nuevas variables no conduce a la escalabilidad de la arquitectura. Lo que realmente mejora la escalabilidad de un proyecto es cuando elimina variables innecesarias y simplifica el código existente.
Una gran cantidad de variables innecesarias: esta es exactamente la razón por la que odio el lenguaje de programación Scala con odio feroz, y la razón por la que amo JavaScript. Scala es solo la quintaesencia de un sistema de tipos muy complicado y muy confuso, muchos conceptos que se duplican entre sí, conversiones implícitas, una gran cantidad de formas de hacer lo mismo. Cuando uso este lenguaje de programación, no pienso en
lo que hay que hacer, sino en
cómo hacerlo. Muy a menudo me encuentro ahora mismo, mi objetivo es simplemente callar el compilador. Por otro lado, JavaScript es exactamente lo contrario de Scala, es un orden de magnitud más minimalista, al usarlo gasto mucho menos esfuerzo mental para expresar uno u otro concepto. Por supuesto, esta simplicidad también tiene sus inconvenientes, por ejemplo, en Scala, el compilador informa un error en la etapa de compilación, mientras que en JavaScript solo puede reconocer un error en tiempo de ejecución y es fundamentalmente imposible para JavaScript escribir el mismo IDE funcional que para los tipos fuertemente tipados. idiomas, pero estas son las víctimas con las que estoy dispuesto a reconciliarme.
El principio de minimizar las variables debe aplicarse al diseñar interfaces, por ejemplo, comparemos las interfaces web para dos redes sociales competidoras para salir con
Tinder y
Badoo . De hecho, solo hay una página en la interfaz web de Tinder, el perfil de usuario, los chats activos y la búsqueda de nuevos conocidos se muestran en una página y no hay necesidad de cambiar a otras páginas, en esta interfaz todas las necesidades del usuario se satisfacen con un número mínimo de componentes. Mientras que en Badoo la funcionalidad de cambiar al perfil de usuario, la interfaz de mensajes y la página para encontrar pares se implementan como páginas separadas, el usuario debe realizar más acciones para satisfacer las necesidades y, en consecuencia, esta interfaz es menos eficiente. Por supuesto, este es solo un ejemplo muy pequeño, pero cuando hay docenas y cientos de tales ejemplos, todos juntos determinan si la interfaz está pensada o no.
Al diseñar la interfaz, es necesario crear un número mínimo de componentes para satisfacer las necesidades del usuario.Por la misma razón, no me gustan los enfoques que separan la lógica, los datos y la presentación, porque en este caso surge una situación en la que escribir una pieza de funcionalidad que necesita para crear tres archivos, luego el número de componentes comienza a crecer y cuando el proyecto ya se ha hecho grande, entonces el número de archivos comienza a pasar por encima de todos los límites razonables. Por ejemplo, al escribir interfaces web, los estilos generalmente se describen en archivos separados, mientras que los nodos a los que se adjuntan estos estilos están en otro archivo. Por extraño que parezca, la principal motivación para tal separación es la escala, por lo que si separa los nodos ellos mismos y sus estilos, será más fácil navegar en el proyecto y será posible desarrollar de forma independiente estas dos partes de lo funcional. Pero veamos qué variables se agregan con este enfoque: nuevos archivos con estilos para cada componente, selectores (describen a qué nodo se adjuntan los estilos), reglas en cascada (si varios selectores se dirigen al mismo nodo). Si bien si escribe estilos directamente en los nodos a los que se deben conectar estos estilos (por ejemplo, a través del atributo de estilo), todas estas variables adicionales ya no son necesarias, lo que simplifica en gran medida el código. Recientemente, este enfoque se ha vuelto cada vez más popular, hay muchas bibliotecas que le permiten escribir estilos directamente en el atributo de estilo.
Las nuevas variables siempre deben introducirse en el proyecto gradualmente. Por ejemplo, al principio, al escribir un proyecto, tengo todos los archivos en el directorio raíz, sin ningún subdirectorio, simplemente porque es más fácil, y solo cuando el número de archivos crece a 40-60 archivos, algunos archivos se agrupan en directorios. Al principio, no se necesita una metodología de desarrollo, simplemente ponga a todos los programadores en una pila, déles tareas, luego lo resolverán ellos mismos, si la metodología de desarrollo se introduce demasiado pronto, se sentirá como una especie de concepto sustituto. Cuando las variables se introducen antes de que sean necesarias, esto se denomina optimización prematura.
De la misma manera, es necesario minimizar las variables cuando escribo documentación / artículos, cuando escribo documentación, siempre pienso cuál es exactamente el número mínimo de oraciones que necesito para transmitir mis pensamientos. Literalmente analizo cada oración, y si me parece que esta oración no es necesaria, no soporta ninguna carga semántica adicional, entonces se elimina, como resultado se obtiene una página muy comprimida con documentación, que contiene la cantidad máxima de información necesaria en una cantidad mínima de texto.
De hecho, en general, cualquier variable tiene una presunción de culpa, no se necesita ninguna variable hasta que se demuestre lo contrario.
Puede objetarme, me dicen lo mismo, descubrió América, se conoce desde hace mucho tiempo y se describe por principios tales como:
navaja de afeitar Okama ,
SÓLIDO . Pero prefiero llamar a este concepto "minimización de variables", simplemente porque esta interpretación es muy sucinta en la cabeza y, en consecuencia, es mucho más fácil cumplirla en la práctica. ¿Cuántos de ustedes pueden jactarse de recordar cada punto del principio SÓLIDO?
Los principiantes escriben código simple porque no saben cómo escribir código complejo, los programadores promedio escriben código complejo, simplemente porque pueden, los profesionales escriben código simple porque no quieren escribir código complejo.
Debe recordarse que cualquier extremo es malo: si es fanático minimizar las variables hasta el nivel atómico, entonces este enfoque, además de introducir demasiadas variables, es un extremo. Y cualquier extremo, como saben, es malo, la verdad siempre está en algún punto intermedio.