Dio la casualidad de que la mayor parte de mi vida consciente la programo en PHP. Nuestro cerebro, al percibir información de cualquier fuente, lo hace sin interrupción por parte de la autoridad de esta fuente. Hablando en términos generales, si amas PHP, automáticamente agregaste puntos de credibilidad al autor de este artículo, y si no te gusta, automáticamente se los quitaron. Este proceso tiene lugar en un nivel inconsciente y es esencialmente un prisma de percepción, que por un lado nos protege de caer en un análisis interminable de información de cualquier grado de autoridad, pero por otro lado nos limita en la búsqueda de información nueva y más relevante. Lo peor es que la credibilidad de la fuente rara vez se verifica a nivel consciente (porque lleva tiempo y recursos en forma de calorías preciosas), puedo ser con la misma probabilidad un desarrollador plus, un cocinero de ama de casa, un fontanero sin princesa o genéticamente modificado gato No juzgues estrictamente mi artículo, tengo patas.
Lo mismo se aplica a leer el código de otra persona: si su autor se sienta a la izquierda de su trono, ha estado trabajando en su empresa durante más de 10 años y gana un cero más que usted, esto no es absolutamente lo mismo que el autor que fue despedido por algo. eso es malo, y fuiste contratado en su lugar. Pero, de hecho, el código aquí y allá es solo un conjunto de bytes que sería útil evaluar sin referencia a la autoridad de la fuente.
Cuando leemos el código de otra persona, nos puede visitar una gran variedad de emociones: admiración, risa, irritación, desilusión, rechazo total. Es útil saber que la manifestación de cualquier emoción en cualquier contexto es una respuesta automática del nivel inferior (primer) del sistema nervioso, formado de forma evolutiva, necesario en un entorno primitivo. La tarea principal de tal respuesta, en el caso de una emoción "negativa", es lanzar el mecanismo de acción "golpear o correr" con un solo objetivo: sobrevivir. En nuestro entorno de oficina actual, al analizar el código de otra persona, dicha respuesta se vuelve bastante inútil e incluso dañina, ya que gasta un tiempo y recursos valiosos en ella, además de contaminar su cerebro con neurotransmisores que reducen su ingenio rápido en aras de la velocidad de reacción. La buena noticia es que esta respuesta puede reprogramarse. Puede suprimir las reacciones emocionales negativas, o puede inventariarlas, por ejemplo, reírse donde solía estar enojado. La risa, a diferencia de la ira, arroja al cerebro neurotransmisores buenos, sabrosos y útiles que dan placer, refuerzan la experiencia y lo motivan a seguir trabajando.
Para reprogramar la emoción, debes ir mentalmente a una meta posición para evaluar tu propia situación y evaluarte a ti mismo en lugar de condenar el código de otra persona. ¿Por qué me disgusta este fragmento del código de otra persona? ¿Es realmente que el aficionado lo escribió, y ahora tengo que sufrir tan bien y con experiencia? Si soy tan bueno y experimentado, ¿por qué estoy teniendo problemas para entender el código de otra persona y reescribirlo como mejor me parezca? ¿Tal vez simplemente no tengo suficiente RAM para realizar este fideo? ¿Quizás el autor de esta pieza sabe algo que yo no sé?
Las herramientas de desarrollo modernas le permiten transformar el código de otra persona en estructuras más comprensibles y agradables casi sobre la marcha. Una función o variable tiene un nombre pobre: ctrl + shift + R y en un par de segundos se llama para siempre. Pestañas en lugar de espacios, inconvenientemente, sangrías inusualmente dispersas y llaves de apertura en el estilo egipcio: ctrl + shift + F y el formato restaurado. El comentario es redundante u obsoleto - ctrl + D y no lo es. Si cambia el prisma de la percepción, leer el código de otra persona puede convertirse en un divertido juego de detectives interactivo.
El código es solo una herramienta. No importa cuán mal y terriblemente haya sido escrito, en un momento específico y en un lugar en particular resolvió con éxito un problema específico, lo que significa que ya está "justificado". Algo ha cambiado en los requisitos comerciales, algo no se ha tenido en cuenta: el código se ha roto o no está actualizado, y esto es normal. El código tiene la capacidad de evolucionar en una variedad de formas: y gradualmente, cubierto de capas y revolucionario, escribiendo desde cero. Por supuesto, es bueno cuando el programador prevé el futuro y en las etapas iniciales establece en el código las posibilidades para su desarrollo posterior. Pero este hacha es aguda en dos lados, puede cometer un error al predecir el futuro, el futuro puede no llegar y el tiempo y los recursos se perderán irremediablemente. Es importante comprender el código en qué grado de calidad se requiere de usted. Si este es un gran sistema distribuido, cuyos módulos son programados por sus colegas de todo el mundo en compañías débilmente conectadas con la suya, entonces sí, tiene sentido usar patrones de moda, para envolver módulos en contenedores de servicio incluso donde no puede imaginar por qué esto es así. Necesito Pero si se trata de un CRM local pequeño para una compañía, cuyos módulos dependen tan rígidamente entre sí que deshabilitar cualquier módulo esencialmente detiene el funcionamiento de todo el sistema ... en este caso, es justificable llamar directamente a los métodos de otras personas, esto reducirá el número de clases y facilitará su funcionamiento memoria y reducir el tiempo de depuración de problemas. Pero aquí surge una situación cuando un pequeño CRM local se convierte en algo expandible que su empresa quiere poner en el dominio público y vender. Los requisitos comerciales han cambiado. ¿Se debería culpar al programador por no prever esto?
Estandarización
El código es solo una herramienta, pero su creación es pura creatividad. Cualquier problema puede resolverse mediante un número infinito de las formas más diversas. Algunos de ellos son más productivos que otros, un ejemplo de una evaluación objetiva. Algunos de ellos son más legibles que otros, un ejemplo de evaluación subjetiva. Incluso si convence a toda la oficina de que algún código no es legible, habrá al menos un autor que no esté de acuerdo con usted. La estandarización del código tiene como objetivo transformar la creatividad pura en el conjunto de acciones más rutinario para que sea más fácil para otros programadores entender su código. Es decir, de hecho, para que pueda ser reemplazado por otro especialista, más dócil y más barato. Y después de un par de décadas, es una inteligencia completamente artificial. Vale la pena recordar que si algún estándar es contrario al sentido común, puede tener sentido violarlo en algunos lugares, o incluso abandonarlo por completo o reemplazarlo por otro más adecuado.
Los estándares maduros se venden desde la posición de "al elegir un estándar, preste atención a la popularidad de la comunidad". Me pregunto cómo se vendieron cuando salieron. La idea principal es que la popularidad de un estándar en particular no es un factor que le gustaría considerar en primer lugar al elegir. La popularidad y las comunidades son muy inertes y pueden rechazar durante muchas décadas estándares nuevos y mejores. Especialmente si son revolucionarios.
Se presta especial atención a los estándares que se han establecido completamente en la cultura simplemente porque surgieron antes que otros estándares similares. Un ejemplo canónico es la guerra santa entre los diseños de QUERTY y Dvorak. El segundo, obviamente, es mejor, pero el primero tiene un golpe (sigue siendo más popular) simplemente debido a la masa crítica de usuarios que no quieren volver a capacitarse en uno nuevo.
Se encuentran ejemplos similares todo el tiempo y en la cultura de la programación. El estándar PSR representa 4 espacios en lugar de pestañas, ignorando el hecho obvio: el entorno de desarrollo de la mayoría de los programadores PHP ha cambiado de editores de consola a IDEs completos, en los que la tabulación es más conveniente de muchas maneras: es más fácil eliminarlo presionando Retroceso una vez, y puede configurar longitudes individuales Pestañas al gusto.
Al aplicar este o aquel estándar, haga la pregunta: ¿a quién lo hace más conveniente? ¿Quién está más incómodo? ¿Quién se beneficiará de la regla "nombra los nombres de los métodos del lowerKamelKeysom"? Obviamente solo para aquellos que están acostumbrados a llamarlos así. Todos los demás se sentirán incómodos, tendrán que adaptarse, y esta pérdida de tiempo y recursos es absolutamente desde cero, dado el hecho de que
a) ahora tenemos IDEs mágicos que resaltan diferentes elementos del código en diferentes colores,
b) los programadores tienen la capacidad de saltar de un proyecto a otro, codificando estándares que pueden variar.
Personalmente, cuando desarrollo mis proyectos uso:
- CamelCase para nombrar clases y métodos
- $ CamelCase para nombrar variables que contienen una instancia de un objeto
- $ snake_case para nombrar variables que contienen tipos simples
No tengo ningún problema para distinguir un nombre de clase de un nombre de método ya que el primero es un sustantivo y el segundo es un verbo. Además, la luz de fondo ayuda. Pero este es mi gusto personal, no se lo impongo a nadie. Este es un prisma personal de percepción, es individual para cada cabeza individual. Alguien tuvo la "suerte" de sumergirse inmediatamente en el estándar popular, alguien tuvo "mala suerte" al comenzar su carrera con alternativas, y alguien generalmente desarrolló el suyo propio. Te llevo al hecho de que, en lugar de volver a capacitar a otros, puede tener sentido volver a capacitarte para percibir el código en cualquier estándar. O incluso más allá de los estándares.
Por supuesto, los partidarios de la estandarización en este lugar estarán indignados y me arrojarán muchas razones en contra. Este artículo no es para ellos, lo estoy escribiendo para aquellos que estén interesados en comprender la esencia de las cosas, tratando de imaginar lo que el autor realmente tenía en mente y qué propósito persiguió.
Capacidad para comprender el código de otra persona.
El desencadenante que causa los impulsos de vómito en la gran mayoría de los programadores (un ejemplo de una evaluación subjetiva). ¿Nunca le pareció extraño que a menudo nos sea más fácil reescribir todo el código desde cero que comprender el de otra persona? En cualquier otra industria, actuamos de manera diferente: primero aprendemos a leer, luego a escribir; primer uso (electrodomésticos, edificios), luego diseñarlos. Me parece que todo el punto está en nuestra educación (específicamente en el campo de la programación). Se nos enseña a alcanzar el objetivo de la manera más directa y rápida, utilizando algunos conocimientos recién adquiridos. Como resultado, los combinamos (conocimiento) exactamente hasta que "funciona", probamos un poco y se lo enviamos al maestro para moderación. En mi opinión, sería bueno agregar un paso adicional a este proceso, en el que comparamos nuestro código con el código maestro, que aunque no es el ideal y el único correcto, pero proporciona una solución alternativa, a menudo más óptima y legible.
En cuanto al disparador, para apagarlo, es suficiente colocarse mentalmente en el lugar del cliente, que ha estado observando a los programadores que se van y vienen toda su vida, alegando que el trabajo de sus predecesores son las heces y que necesita reescribir todo para que sea bueno. El cliente no tiene la competencia para averiguar si usted está diciendo la verdad o simplemente es perezoso para comprender el código de otra persona. Para ganarse su confianza en este asunto, debe profundizar en el código de otra persona y encontrar un par de agujeros de seguridad gigantes y mostrárselos al cliente. Pero incluso en esta situación, desde el punto de vista empresarial, puede ser más rentable "endurecerse". Especialmente si se trata de una subcontratación con plazos específicos y dinero. ¿Se debe culpar al programador por esto?
Conclusión
Que, shcha escribe con la letra I. En lugar de desayunar, beba café y mantequilla a través de una licuadora.
Mira más profundo, piensa más, busca alternativas. Nunca dejes de desarrollar.