¿Cuál considera que es el primer principio de la programación?

Siempre me ha gustado preguntarme "¿cuál es el (los) primer (s) principio (s) de esto?" después aprendí las cosas básicas de algo (por ejemplo, programación). Es una pregunta inspiradora, OMI, que puede obligarlo a pensar en los principios más importantes detrás de algo, especialmente una habilidad como la programación.

Entonces, ¿cuál crees que es el primer principio de la programación? Daré mi respuesta a continuación un poco más tarde.

1. BESO - Mantenlo simple estúpido
2. SECO - No te repitas
3. YAGNI - No lo vas a necesitar

Escriba el código como si fuera usted quien tendría que mantener ese código.

Sé lo más vago posible.

Zen, parte I: la programación es solo el camino, no el camino.

La programación es solo la técnica para enseñarle a una computadora lo que debe hacer. Tener éxito en la creación de software rápido y confiable significa conocer sus algoritmos, mejores prácticas y todo lo demás que no necesariamente está conectado a su Programación (lenguaje).

Zen, parte II: si tienes prisa, camina lentamente. Si realmente tiene prisa, haga un desvío.

Suena tonto, pero no te metas en compromisos que (realmente) pueden molestarte después. Tengo una regla: si estás en el centro de un programa, trata de ser lo más preciso y bueno posible. Si está utilizando métodos del núcleo que son profundos en su software, intente ser más rápido en la codificación. Si está codificando por encima de estos dos, incluso puede ser un poco más descuidado.

Los errores de diseño son los más difíciles de encontrar y / o corregir, el siguiente paso son los errores de programación en partes en las que todos confían, luego las "partes reales del software de exhibición". Si necesita corregir un error de diseño al final de un proyecto, mmm, eso no es bueno ... ;-)

Zen, parte III: Conoce tu camino, Neo.

Conozca su entorno, las herramientas y las cosas en las que confía a diario y clasifíquelas para que funcionen para usted. Es mejor si usa su "entorno" de programación tan natural que ni siquiera tiene que pensar en ello. Si tiene que hacer un trabajo, no introduzca "cosas nuevas y elegantes", sino que haga su trabajo. Esto se puede introducir en un nuevo proyecto, es decir, cuando tenga tiempo para prepararlo y usarlo.

BESO (que sea simple, estúpido).

De hecho, plantea la pregunta "¿Cómo define simple?" Y también "¿Cuándo es algo demasiado simple para la tarea en cuestión?" Es por eso que no puedes convertirte en un buen programador simplemente conociendo el primer principio de programación.

La optimización prematura es la fuente de todos los males. - Donald Knuth

No reinventes la rueda.

¡Entiende el problema primero!

YAGNI - No lo vas a necesitar . La idea detrás de YAGNI es programar para sus requisitos, no para posibles características potenciales. La premisa es que al cumplir con lo que necesita programar, (entre otras cosas) reducirá la acumulación de código, reducirá la complejidad, evitará el arrastre de características y reducirá las restricciones sobre lo que se puede hacer (y cómo se puede hacer) en el futuro.

Supongo que funciona en conjunto con el diseño modular: las características futuras se pueden aumentar sin rediseñar el código existente.

Saber cuándo no programar.

Café adentro, código afuera.

Si no fue probado, está roto.

Hay dos formas de construir un diseño de software: una es hacerla tan simple que obviamente no haya deficiencias, y la otra es hacerla tan complicada que no haya deficiencias obvias. El primer método es mucho más difícil.

- Charles Antony Richard Hoare

1. Distinguir entre causa y efecto (trabajar con computadoras)

2. Distinguir entre hecho y opinión (trabajar con personas)

3. Tan simple como sea posible, pero no más simple (diseño)

La programación es un medio, no un fin. O tal vez, "Can no significa que debería".

1. Comprende por qué el programa hará feliz a alguien (de lo contrario, ¿por qué no estás afuera jugando con todos los otros niños?). (Esta persona puede ser usted).
2. Desarrolle un modelo conceptual del dominio comercial que capture toda la complejidad necesaria, y nada más.
3. Desarrolle un modelo conceptual de la arquitectura de software que capture toda la complejidad necesaria, y nada más.
4. Despiadadamente, evita toda otra complejidad.

En mi opinión, el principio más importante es la reducción de la complejidad mediante la creación de buenas abstracciones .

Esto incluye

• entendiendo el problema a resolver,
• diseñando una solución adecuada para ello y
• implementandolo,
• preferiblemente de una manera que mantenga el código comprensible y sostenible

pero también la determinación del punto donde dejar de crear abstracciones y llegar a las propiedades fundamentales de las tecnologías de implementación (por ejemplo, sistema de base de datos, lenguaje de programación) para evitar la creación de una complejidad adicional evitable.

Programa con una audiencia en mente. Con eso, no asumas que nada de lo que escribes será leído y mantenido por ti u otra persona.

Un corolario de eso: demuestre que comprende el problema que está tratando de resolver nombrando bien sus variables, funciones y clases.

no funciona hasta que lo demostraste en una prueba

Piensa primero, codifica después.

No eres tan inteligente como crees que eres. Hacer preguntas. Aprende a valorar a tus compañeros.

Al depurar, la primera respuesta casi siempre será incorrecta.

El código que escribes con la intención de desechar tiende a convertirse en la piedra angular de procesos mucho más grandes. Nunca dejes nada escrito al azar.

Cualquier problema puede resolverse con otra capa de indirección.

Conoce tus herramientas.

Principio: El software es captura de conocimiento .

Consecuencias: muchas técnicas para la representación del conocimiento, todas basadas en la abstracción . Nos da capas, niveles, encapsulación, separación de preocupaciones.

Muchas técnicas para la representación de procedimientos, todas basadas en Secuencia , Elección , Repetición .

Escribe el código para el próximo chico.

Siempre escriba el código como si la persona que lo mantendrá es un asesino en serie psicótico que sabe dónde vive

Además, nunca pienses que sabes todo sobre programación, sigue aprendiendo

Me metí en la programación estudiando electrónica digital, así que supongo que para mí las puertas lógicas básicas (no, y, o, o, implica) fueron los primeros principios de la programación.

Se trata del usuario.

Entrada de basura - Salida de basura No importa cuán agradable sea su interfaz de usuario si los datos son incorrectos.

SECO, casi todo lo demás se genera. KISS es el otro extremo del acto de equilibrio para asegurarte de que no buscas la elegancia del software a niveles de locura.

Comience con la salida y trabaje hacia atrás.