rules - questions - Estoy compilando reglas de mentalidad de programación para mi equipo: ¿cuáles son las suyas?
tag questions structure (30)
He estado trabajando en una lista por un tiempo que me ayuda a compartir el porqué del enfoque de programación y el pensamiento tanto como cómo hacer algo.
Para esto, quería construir una lista de cosas que son:
- mejores prácticas,
- mejor pensamiento,
- mejor enfoque ...
que ayudan a la capacidad de un programador para analizar, pensar, abordar, resolver e implementar de la manera más efectiva.
He visto docenas de comentarios increíblemente valiosos en preguntas a lo largo de Stack Overflow, pero no he podido encontrar un lugar donde los mantengamos unidos. Existe la opinión más controvertida sobre Stack Overflow. Sin embargo, solo busco ideas sensatas que puedan compartirse y ayudar a mi equipo, y abordo y resuelvo problemas mejor a través de una mejor programación.
Con un poco de suerte, este puede ser un lugar para reunir uno o dos revestimientos que sean concisos, profundos y fáciles de compartir, repetir, revisar. Si lo mantenemos en una regla por respuesta, puede ser más fácil votar arriba / abajo.
Comenzaré con el primero.
SECO - No repetirlo - En código, comentarios o documentación.
Build Breaker compra almuerzo
La mejor práctica: use su cerebro
No sigas ninguna tendencia / principio / patrón sin pensarlo
Menos código es mejor que más, siempre que tenga más sentido que un montón de código.
No optimice a menos que haya un problema demostrable.
La mayoría de las veces, cuando las personas intentan optimizar el código antes de que se demuestre que es necesario, gastan una gran cantidad de recursos, hacen que el código sea más difícil de leer y mantener, y no logran ningún efecto notable. A veces incluso lo empeorarán.
"Deberíamos olvidarnos de pequeñas eficiencias, digamos el 97% de las veces: la optimización prematura es la raíz de todo mal".
- Donald Knuth
No tengas miedo de admitir "No sé" y pregunta.
¡10 minutos preguntando a alguien que podría ahorrar un día sacándose el pelo!
Siempre deje el código un poco mejor que cuando lo encontró.
Sigue los principios SÓLIDOS :
Principio de Responsabilidad Individual (SRP)
Nunca debe haber más de una razón para que una clase cambie.
Principio Abierto Cerrado (OCP)
Las entidades de software (clases, módulos, funciones, etc.) deben estar abiertas para la extensión, pero se deben cerrar para su modificación.
Principio de sustitución de Liskov (LSP)
Las funciones que usan punteros o referencias a clases base deben ser capaces de usar objetos de clases derivadas sin saberlo.
Principio de segregación de la interfaz (ISP)
Los clientes no deben ser forzados a depender de interfaces que no usan.
Principio de Inversión de Dependencia (DIP)
A. Los módulos de alto nivel no deberían depender de módulos de bajo nivel. Ambos deberían depender de las abstracciones.
B. Las abstracciones no deberían depender de los detalles. Los detalles deben depender de las abstracciones.
Todo lo que pueda afectar la forma en que se ejecuta la aplicación debe tratarse como código, y eso significa ponerlo en control de versiones. Especialmente compilar scripts y esquemas de bases de datos y archivos de datos (.sql).
¿Qué tan difícil puede ser?
No dejes que ningún problema te intimide.
KISS: mantenlo simple, estúpido.
Elija la solución más simple que funciona .
No hagas las cosas (demasiado) complicadas antes de que tengan que serlo.
El hecho de que todos los demás estén utilizando un marco complicado para resolver su problema no significa que deba hacerlo.
Comprenda las herramientas que usa
No use un patrón hasta que haya entendido por qué lo está usando; no use una herramienta sin saber por qué; ¡no confíe en que su marco de trabajo o diseñador de lenguaje siempre será el adecuado para su situación, pero tampoco suponga que están equivocados hasta que se demuestre que lo es!
Es tanto lo que dices como la forma en que lo dices
No tiene sentido tener grandes ideas si no las comunicas de manera efectiva.
a través del programador pragmático
Hábitos del codificador perezoso
La primera vez que se le pida que haga algo, hágalo (derecha).
La segunda vez que se le pida que lo haga, cree una herramienta que lo haga automáticamente.
Y la tercera vez, si la herramienta no funciona, diseñe un lenguaje específico de dominio para generar más herramientas.
(no debe tomarse demasiado en serio)
No reúna los requisitos, atrévete con ellos
Los requisitos raramente se encuentran en la superficie. Están enterrados profundamente debajo de capas de suposiciones, conceptos erróneos y política
a través del programador pragmático
No se asuste al depurar
Toma una respiración profunda y PIENSA! sobre qué podría estar causando el error.
a través del programador pragmático
Participe en el desarrollo de código abierto
Si está utilizando código de código abierto en sus proyectos, recuerde publicar sus correcciones de errores y mejoras a la comunidad. No es una mejor práctica de desarrollo per se , pero definitivamente es una mentalidad de programador a la que aspirar.
Publique temprano, publique a menudo
Puede copiar y pegar para que funcione, pero no puede dejarlo así.
El código duplicado es un paso intermedio, no un producto final.
Sea un catalizador para el cambio
No puedes forzar el cambio en las personas. En cambio, muéstreles cómo podría ser el futuro y ayúdelos a participar en la creación.
a través del programador pragmático
Siempre codifique como si la persona que termina manteniendo su código es un psicópata violento que sabe dónde vive.
De: Coding Horror
Alguien más no lo arreglará.
Si se le ocurre un problema, tome la propiedad lo suficiente como para garantizar que se cuide de una manera u otra.
Test Driven Development (TDD) hace que los codificadores duerman mejor por la noche
Solo para aclarar: algunas personas parecen pensar que TDD es solo una forma de cojera incompetente de cojear de A a B sin poner demasiado a todo, y que si sabes lo que estás haciendo, eso significa que no hay necesidad de (unidad) metodologías de prueba. Eso falla por completo el punto de desarrollo impulsado por prueba. TDD es aproximadamente tres (actualizar: aparentemente cuatro) cosas:
Refactorando la magia . Tener un conjunto completo de pruebas significa que puedes hacer acrobacias de refactorización de locos, haciendo malabares con toda la estructura de tu aplicación sin perder ni uno solo de los doscientos efectos secundarios sutiles y locos que resultan de ello. Incluso los mejores programadores son reacios a refactorizar sus clases principales e interfaces sin una buena cobertura de prueba (unidad), porque es casi imposible rastrear todos los pequeños ''efectos dominantes'' que causa sin ellos.
Detectando trampas temprano . Si está escribiendo pruebas de la manera correcta, significa forzarse a sí mismo a considerar todos los casos adicionales. A menudo, esto conduce a mejores opciones de diseño una vez que comienza el desarrollo real, porque el codificador ya ha considerado algunas de las situaciones más complicadas que pueden requerir una estructura de herencia diferente o un patrón de diseño más flexible. La necesidad de estos cambios a menudo no es aparente -o intuitiva- durante la planificación y el análisis inicial, pero esos cambios exactos pueden hacer que la aplicación sea mucho más fácil de extender y mantener más adelante.
Asegurando que las pruebas se escriban . TDD requiere que escribas las pruebas antes de escribir el código. Claro, eso puede ser un dolor de cabeza, ya que escribir pruebas es tedioso en comparación con escribir códigos reales , y a menudo también lleva más tiempo. Sin embargo, hacerlo es la única forma de asegurarse de que las pruebas se escriban en absoluto. Si crees que recordarás escribir las pruebas una vez que se haya hecho el código, casi siempre estás equivocado.
Te obliga a escribir un mejor código . Como TDD obliga a que todo el código sea comprobable (no se escribe el código antes de que haya una prueba), se requiere escribir más código desacoplado para que pueda probar los componentes de forma aislada. Entonces, TDD te obliga a escribir un mejor código. ( Gracias, Esko )
La capacidad de mantenimiento es importante.
Escriba el código como si la persona que terminará manteniéndolo está loca y sabe dónde vive.
Google antes de preguntarle a su colega e interrumpir su codificación.
Constrúyalo correcto primero. Hazlo rápido en segundo lugar.
Creo que casi todo lo que se incluye en "El zen de Python" se aplica a todas las listas de "Reglas de mentalidad de programación". Comience con ''python -c'' import this '''':
El Zen de Python, por Tim Peters
- Hermoso es mejor que feo.
- Explícito es mejor que implícito.
- Simple es mejor que complejo.
- Complejo es mejor que complicado.
- Flat es mejor que anidado.
- Sparse es mejor que denso.
- La legibilidad cuenta
- Los casos especiales no son lo suficientemente especiales como para romper las reglas.
- Aunque la practicidad supera a la pureza.
- Los errores nunca deberían pasar silenciosamente.
- A menos que esté explícitamente silenciado.
- En vista de la ambigüedad, rechace la tentación de adivinar.
- Debería haber una, y preferiblemente solo una, forma obvia de hacerlo.
- Aunque de esa manera puede no ser obvio al principio a menos que seas holandés.
- Ahora es mejor que nunca.
- Aunque nunca es a menudo mejor que ahora.
- Si la implementación es difícil de explicar, es una mala idea.
- Si la implementación es fácil de explicar, puede ser una buena idea.
- Los espacios de nombres son una gran idea: ¡hagamos más de eso!
El código no existe hasta que se ingresa en un sistema de control de versiones .
Convención sobre configuración
Especialmente donde las convenciones son fuertes y se puede sacrificar algo de flexibilidad.
Si debería haber una función para él en la biblioteca central, probablemente lo haya.
Revisiones frecuentes de códigos de conducta
La revisión del código y, en consecuencia, la refactorización es una tarea constante. Aquí hay algunas cosas buenas sobre la revisión del código en mi opinión:
- Mejora la calidad del código.
- Ayuda a refactorizar códigos reutilizables en bibliotecas reutilizables.
- Te ayuda a aprender de tus compañeros desarrolladores.
- Le ayuda a aprender de sus errores y actualizar su memoria sobre un código de genio que ha escrito antes.