Los principios de programación más extraños que nunca has oído hablar

Anuncio

Ya te hemos guiado por el principios de programación más esenciales 10 principios básicos de programación que todo programador debe seguirSiempre escriba código que pueda ser mantenido por cualquier persona que pueda terminar trabajando en su software. Con ese fin, aquí hay varios principios de programación para ayudarlo a limpiar su acto. Lee mas necesita saber, pero hay otra clase de principios de programación que pueden probar aún más beneficioso que aquellos.

Mientras que los principios antes mencionados le enseñan cómo ser inteligente con su código, los siguientes principios le enseñarán a ser sabio con tu código Algunos de ellos son extraños, y muchos de ellos son humorísticos, pero todos son igualmente prácticos e importantes. ¡Cuidado!

1. El principio de hinchazón

Esta tiene tantas variaciones que es difícil elegir una como la principal. Quizás la versión más "oficial" es la Ley de Desarrollo de Software, más comúnmente llamada Ley de Zawinski, llamado así por Jamie Zawinski y mencionado en El arte de la programación UNIX:

“Cada programa intenta expandirse hasta que pueda leer el correo. Aquellos programas que no pueden expandirse son reemplazados por otros que sí pueden ".

Se trata de la tendencia de los programas a atraer más y más funciones con el tiempo e inevitablemente derivar hacia una complejidad creciente. Puedes saber esto como característica de fluencia, que es la incorporación continua de nuevas características que no tienen nada que ver con el objetivo principal del programa. El arrastre de características conduce a la hinchazón, y la hinchazón a menudo es indeseable.

Esto también puede aplicarse al rendimiento del software:

"El software se expande para consumir todos los recursos disponibles".

En los años 90, los discos duros, las CPU y la RAM eran mucho más restrictivos de lo que son hoy en día, y los programadores trabajaron arduamente para ajustarse lo más posible dentro de los límites. Sin embargo, ahora que tenemos unidades más grandes y CPU más rápidas y más RAM, todavía nos cuesta respetar los límites. Todo se hincha con el tiempo. Es su trabajo mantener eso bajo control.

2. La mentalidad de "peor es mejor"

Casi como en respuesta al Principio de hinchazón, tenemos el Peor es mejor mentalidad, acuñado por primera vez por Richard P. Gabriel en un ensayo que escribió sobre la calidad del software:

"El software que es limitado, pero fácil de usar, puede ser más atractivo para el usuario y el mercado que lo contrario".

En otras palabras, es aconsejable descubrir el un problema su software tiene como objetivo resolver y luego ser muy bien en esa única cosa. Mantenlo simple. Cuanto más se separe, más inmanejable será el proyecto y más indeseable será para los usuarios.

¿Qué sucede cuando ignoras esto? Terminas con el Principio de software de Peter:

"Un proyecto demasiado complejo eventualmente se volverá demasiado complejo para ser entendido incluso por sus propios desarrolladores".

Proviene del Principio Peter más amplio, que establece que cuando los empleados son promovidos en función de su actual competencia y no su competencia esperada en su próxima posición, todos los empleados finalmente terminan en una posición de incompetencia. Tome ese principio y aplíquelo al software, y verá por qué un software peor a menudo puede ser mejor.

3. Ley de Eagleson

"Cualquier código propio que no haya visto durante seis o más meses bien podría haber sido escrito por otra persona".

Este refrán aparentemente desmotivador es en realidad algo que aceptar. El hecho es que nadie es perfecto. Puedes pensar que eres un programador genio en este momento, pero hay siempre algo más que puedes aprender, siempre Más espacio para crecer. Si alguna vez recuerdas el código antiguo y te avergüenzas, probablemente signifique has aprendido algo nuevo desde entonces.

Dicho de otra manera: si mira hacia atrás en un proyecto antiguo y no puede ver nada que pueda mejorar o haría de manera diferente la próxima vez, es probable que se haya estancado como programador.

4. Principio de menos asombro

"Si una característica necesaria tiene un alto factor de asombro, puede ser necesario rediseñar la característica".

Publicado por primera vez en IBM Systems Journal En 1984, este principio sigue siendo sorprendentemente relevante hoy, tal vez más que nunca.

Esencialmente toca el delicado equilibrio entre innovación y familiaridad: si una pieza de software es Demasiado diferente de otros de su clase y no se ajusta a las expectativas del usuario, entonces probablemente no lo adopten. Es mejor luchar por mejoras incrementales que sean lo suficientemente grandes como para ser impresionantes pero lo suficientemente pequeñas como para mantenerse familiarizadas.

5. Ley de entomología cibernética

"Siempre hay un error más".

Llamado a menudo Ley de entomología cibernética de Lubarsky, no está claro quién es este Lubarsky en realidad. Sin embargo, su principio suena cierto para todos los programadores: no importa cuán limpiamente escriba su código, no importa cómo prueba de manera sólida sus módulos, no importa con qué frecuencia refactorice sus clases, siempre habrá otro error.

En cierto modo, este es un principio de liberación. Si bien definitivamente deberíamos esforzarse para un código libre de errores, también es importante recordar que el perfeccionismo es el enemigo del bien. Busque errores, corríjalos cuando surjan y luego continúe.

6. Ley de Kernighan

“La depuración es dos veces más difícil que escribir el código en primer lugar. Por lo tanto, si escribe el código de la manera más inteligente posible, por definición, no es lo suficientemente inteligente como para depurarlo ”.

Brian Kernighan, el mismo coautor la biblia del lenguaje de programación C Por qué vale la pena aprender la programación en CC no es un lenguaje muerto. De hecho, la revista IEEE Spectrum lo clasificó como el idioma número 2 en 2017. Aquí hay cinco razones por las cuales. Lee mas , es famoso por esta ley perspicaz. El quid de la cuestión es este: escribir bueno código, escribir legible código, escribir simple código, cualquier cosa siempre que no sea inteligente código.

Intentar flexionar los músculos de programación con la complejidad de la torre de marfil es exactamente lo contrario de lo que significa escribir código limpio y mejor 10 consejos para escribir un código más limpio y mejorEscribir código limpio parece más fácil de lo que realmente es, pero los beneficios valen la pena. Así es como puede comenzar a escribir código más limpio hoy. Lee mas . Cuanto más difícil sea comprender su código, más difícil será depurarlo cuando se rompa inevitablemente.

Y como Robert C. Martin explica que tampoco se trata solo de depurar:

“De hecho, la proporción del tiempo dedicado a leer versus escribir es bastante superior a 10 a 1. Estamos constantemente leyendo el código antiguo como parte del esfuerzo para escribir código nuevo... [Por lo tanto,] facilitar la lectura hace que sea más fácil escribir ”.

7. Depuración de pato de goma

Este no es tanto un principio como una técnica, pero es tan útil y extraño que sería negligente dejarlo de lado.

Primero contado en El programador pragmático, depuración de pato de goma es cuando depura el software dañado explicando su código a un objeto inanimado (por ejemplo, un pato de goma) una línea a la vez. Funciona porque el acto de explicación desencadena diferentes partes de tu cerebro y es más probable que descubras inconsistencias y descubras dónde te equivocaste.

Por esta razón, un pato de goma puede ser un regalo sorprendentemente ingenioso para programadores Los mejores regalos geek para programadores: 20 ideas para codificadores y nerds¿Buscas un regalo para un programador? Aquí están los mejores regalos geek, que van desde teclados mecánicos hasta escritorios de pie y más. Lee mas , ya sea que lo compre para usted o para un amigo de programación suyo.

8. La regla de los noventa y noventa

“El primer 90 por ciento del código representa el primer 90 por ciento del tiempo de desarrollo. El 10 por ciento restante del código representa el otro 90 por ciento del tiempo de desarrollo ".

Este descarado y pequeño proverbio de Tom Cargill llega al corazón de por qué la programación puede ser tan frustrante: no importa cuán cerca creas que estás de haber terminado, estás mucho más lejos que incluso tus mejores estimaciones. Cuando crees que has terminado, solo estás a medio camino.

Va de la mano con la Ley de Hofstadter:

"Siempre lleva más tiempo de lo esperado, incluso cuando se tiene en cuenta la Ley de Hofstadter".

9. Ley de Parkinson

"El trabajo se expande para llenar el tiempo disponible para su finalización".

Este principio, acuñado por Cyril Northcote Parkinson, es un principio más amplio que se aplica absolutamente a la programación y va de la mano de la Regla Noventa y Noventa anterior: sin embargo, el tiempo que tenga para terminar un proyecto es exactamente cuánto tiempo va a durar tomar. En el desarrollo de software, "terminar temprano" es prácticamente un mito.

La Ley de Parkinson es la razón por la cual los plazos adecuados son cruciales si desea finalizar y enviar su software. Es por eso que los programadores profesionales modernos a menudo recomiendan principios ágiles de gestión de proyectos Cómo utilizar los principios de gestión ágil de proyectos para organizar su vidaAgile, mejor conocido como método de gestión de proyectos, es un gran marco para administrar su vida personal. Le mostraremos qué principios puede tomar prestados, ¡incluida la descarga gratuita de la hoja de trabajo! Lee mas y herramientas de gestión de proyectos como Asana Trello vs. Asana: La mejor herramienta gratuita de gestión de proyectos es ...Elegir entre Trello y Asana es difícil. Aquí comparamos los planes gratuitos y lo ayudamos a decidir qué herramienta de gestión de proyectos es mejor para su equipo. Lee mas .

10. Ley de Brook

"Agregar mano de obra a un proyecto de software tardío lo hace más tarde".

La próxima vez que llegue tarde a un proyecto, probablemente debido a que la mayoría de los proyectos de programación necesitan más tiempo del asignado, recuerde que agregar codificadores no lo resolverá más rápido.

De hecho, probablemente tomará más completar. No solo necesita actualizar los nuevos codificadores, sino que probablemente se enfrenten con los codificadores existentes. Será necesario documentar más cosas, se necesitará más burocracia para mantener a todos en la misma página, y surgirá más fricción de toda la experiencia de la crisis.

Avanzando como programador

Ahora que conoce estos principios, en realidad está mejor preparado para mundo real de programación, no solo lo que has encontrado en la escuela, en un curso web o en un campamento de entrenamiento. Estos principios provienen de años y años de experiencia y fracasos.

Con esta nueva sabiduría, ahora puede establecer un carrera de programación de alta demanda 10 trabajos de programación de computadoras que están en demanda ahoraDado que conseguir un trabajo de programación puede ser difícil en el panorama actual, considere centrarse en una de las siguientes concentraciones para mejorar sus posibilidades de éxito. Lee mas con expectativas más realistas Para eso, aprende a maximice sus oportunidades de carrera en programación Cómo mejorar sus oportunidades de carrera en programaciónSi espera comenzar, reiniciar o mejorar su carrera de programación, no es fácil. Si estás en la universidad, ahora es el momento. Aquí hay algunos consejos que pueden llevarlo lejos. Lee mas . Y si decides que la programación no es para ti, no te preocupes, considera uno de estos trabajos tecnológicos sin codificación en su lugar La codificación no es para todos: 9 empleos tecnológicos que puede obtener sin ellaNo se desanime si quiere ser parte del campo tecnológico. ¡Hay muchos trabajos para personas sin habilidades de codificación! Lee mas .

¿Cuál de estos principios te suena más verdadero? ¿Conoces otros principios de programación extraños que nos perdimos? ¡Háganos saber en los comentarios a continuación!