Permalink
Find file
Fetching contributors…
Cannot retrieve contributors at this time
277 lines (167 sloc) 17.4 KB

Mejores Prácticas de la Programación - Tidbits

Una colección de citas y frases obtenidos de la web para programadores

Utilice su propio juicio en su aplicación.


Nunca construyas aplicaciones grandes

El secreto para construir aplicaciones grandes es nunca construir aplicaciones grandes. Divide tus aplicaciones en piezas más pequeñas. Entonces, ensambla esas piezas del tamaño de un mordizco que pueden ponerse a prueba, dentro de tu aplicación grande.

Justin Meyer, autor de JavaScriptMVC.

Fuente.

La calidad importa

Cuando escucho "¡SÓLO LIBERA DE UNA VEZ EL CÓDIGO QUE YA FUNCIONA!" pienso en todas las aplicaciones que dejé de usar porque gradualmente perdieron la habilidad de iterar.

Avdi Grimm

Fuente.

No escribas código

No escribas código (escribe nuevo código solamente cuando todo lo demás falle) es la lección más importante que todo desarrollador debería aprender. La cantidad de código duplicado y basura que existe (en todos los proyectos) es abrumadora. En muchos casos los desarrolladores ni se molestan en echar un vistazo. Lo único que quieren es escribir código.

Fuente

Reducir la cantidad de código en tu producto debería ser una meta

"Odio el código, y quiero tan poco código como sea posible en nuestro producto."

Jack Diederich

Fuente

Mantén las dependencias al mínimo

El viejo dicho "No reinventes la rueda" no aplica cuando la rueda es del motor de una locomotora.

Fuente

Deja de escribir clases

La señal de que "esto no debería ser una clase" es cuando la clase tiene dos métodos, y uno de ellos es el constructor. Cuando quiera que veas estas señales, significa que probablemente deberías haber escrito sólo una función.

Jack Diederich

Fuente

Olvida nuevas funcionalidades, simplemente haz lo mismo pero mejor

El problema: es muy fácil perder de vista lo que más importa a los usuarios, que es el rendimiento y la usabilidad de las aplicaciones y las funcionalidades que usan más a menudo.

Tim Anderson

Fuente

Reinventa la rueda

Inventar tus propias ruedas te da un mayor aprecio y entendimiento de cómo funcionan las ruedas y qué hace que una sea buena.

Fuente

No hagas cosas difíciles, haz cosas sencillas

  • Simple es mejor que complejo.
  • Complejo es mejor que complicado.
  • Plano es mejor que anidado.
  • La legibilidad cuenta.
  • Si la implementación es difícil de explicar, es una mala idea.
  • Si la implementación es fácil de explicar, puede que sea una buena idea.

El Zen de Python

Fuente

Reescribir > Refactorizar

Si vas a cambiar más del 25% de una clase o método, considera simplemente reescribirlo. Escribirás código más limpio.

Refactorizar > Reescribir

Excusas comunes para reescribir software

  1. El código apesta
  2. "Ahora somos mucho más listos"
  3. Escogimos la plataforma y/o lenguaje equivocado

Por qué (casi) nunca es buena idea reescribir

  1. Tardará más de lo que piensas
  2. Los mercados cambian
  3. Los clientes existentes se frustran
  4. Puedes limpiar el código refactorizando
  5. No controlas la reescritura, ella te controla a ti

Fuente

Acepta que no tienes idea de cómo esto va a crecer

La clave es reconocer desde el principio que no tienes idea de cómo esto va a crecer. Cuando aceptes que no lo sabes todo, empezarás a diseñar el sistema defensivamente... Deberías invertir la mayor parte de tu tiempo en pensando en interfaces en vez de implementaciones.

Nicholas Zakas, autor de "High-performance JavaScript websites"

Fuente

Reconocimiento a Addy Osmani

Evita código que apesta

Fuente

Fuente

Escribe pruebas unitarias

Todo programador sabe que debería escribir tests para su código. Pocos lo hacen. La respuesta universal al "¿Por qué no?" es "Tengo mucha prisa." Rápidamente esto se convierte en un círculo vicioso. Cuanta más presión sientas, menos pruebas escribirás. Entre menos pruebas escribas, serás menos productivo y tu código se volverá menos estable. Entre menos productivo seas, mayor presión sentirás. Los programadores se desgastan con esos ciclos. Romperlos requiere de una influencia externa. Encontramos esa influencia externa en un simple framework de pruebas que nos deja hacer pequeñas pruebas que hacen una gran diferencia.

Fuente

[Sin las pruebas unitarias] no estás refactorizando, sólo estás cambiando porquería. — Hamlet D'Arcy

Para escribir pruebas unitarias efectivas, debes escribir código que se pueda probar

Falla #1: El constructor hace trabajo real

Señales de alerta

  • Existe new en un constructor o en la declaración de un atributo.
  • Static method calls in a constructor or at field declaration
  • Se hace algo más que solo asignar en los constructores.
  • El objeto no esta completamente inicializado cuando el constructor termina (cuidado con los métodos 'para inicializar')
  • Control de flujo en un constructor (existe un condicional o un bucle)
  • Code does complex object graph construction inside a constructor rather than using a factory or builder
  • Adding or using an initialization block

Falla #2: Digging into Collaborators

Señales de alerta

  • Objects are passed in but never used directly (only used to get access to other objects)
  • Law of Demeter violation: method call chain walks an object graph with more than one dot (.)
  • Suspicious names: context, environment, principal, container, or manager

Falla #3: Brittle Global State & Singletons

Señales de alerta

  • Adding or using singletons
  • Adding or using static fields or static methods
  • Adding or using static initialization blocks
  • Adding or using registries
  • Adding or using service locators

Falla #4: La clase hace demasiado

Señales de alerta

  • Al resumir lo que hace la clase se incluye el conector "y".
  • La clase sería difícil de leer y captar para nuevos miembros del equipo.
  • La clase tiene atributos que son utilizados sólo en algunos métodos.
  • La clase tiene métodos estáticos que sólo operan sobre párametros

Fuente

Fuente

Desarrollo guiado por pruebas con Inversión de Control

Incluso si no estás probando tu código, deberías escribir código que pueda probarse. IoC permite código "testeable". Inyecta dependencias que faciliten las pruebas o "mocks" al tiempo de probar a fin de aislar la unidad bajo prueba.

Evita mezclar la creación de objetos con la lógica de aplicación

Fuente

Evita crear deuda técnica

"Aunque el código inmaduro funcione bien y sea totalmente aceptable al cliente, cantidades excesivas del mismo harán que un programa sea indomable, conduciendo a programadores extremadamente especializados y, finalmente, a un producto inflexible. [...] Un poco de deuda acelera el desarrollo siempre y cuando se pague prontamente con una reescritura. [...] Cada minuto que se gasta en código no muy bien escrito cuenta como interés en esa deuda. Organizaciones enteras de ingeniería pueden detenerse bajo la deuda de implementación sin consolidar" (Cursivas mías)

Fuente

La optimización prematura es la raíz de todos los males

"Los programadores desperdician mucha cantidad de tiempo pensando o preocupándose sobre el rendimiento de partes del programa que no son críticas y estos intentos realmente tienen un poderoso impacto negativo cuando consideramos el mantenimiento y la depuración. Deberíamos olvidarnos de las pequenas optimizaciones, digamos el 97% del tiempo: la optimización prematura es la raíz de todos los males"

Fuente

Planifica, Planifica, Planifica

Es mucho más barato hacerlo correctamente la primera vez que rehacerlo posteriormente. Mientras más pronto se identifica y soluciona un problema, es más barato hacerlo.

"El general que gana una batalla hace muchos cálculos en su templo antes del fragor la batalla. 

El general que pierde una batalla hace pocos cálculos con antelación. Hacer muchos cálculos lleva a la victoria y pocos cálculos a la derrota: ¡cuánto más ningún cálculo en absoluto! Por dar atención a este punto yo puedo preveer quien es probable que gane o pierda"

"Los planes son inútiles, pero la planificación lo es todo" - Sir Winston Churchill

For this to work, everyone involved has to listen, everyone has to be open, everyone has to be responsive. Or we could keep flailing away with the fucked up attitude that “it has to be this way” because the sacred project plan says it’s this way. Because that really is a lot of fun, isn’t it?

Programar también envuelve enseñar a tu equipo

... un equipo de programadores mediocres, sin experiencia que trabajan juntos y escriben para el beneficio del equipo tiene la capacidad de convertirse en un gran equipo, y pueden tomar este enfoque para crear otros grandes equipos. Todo se resume en si el eqiupo ve su trabajo como sólo escribir código, o escribir con el objetivo de tanto codificar como aprender" (Cursivas mías)

Reginald Braithwaite

Fuente

"El elemento más importante del desarrollo de software con éxito es aprender"

Cuando todo el equipo alcanza un cierto nivel de competencia, existe una superficie expuesta de aprendizaje muy grande y el equipo es capaz de absorber más información.

Fuente

"...hay mentiras, mentiras descaradas, y estimaciones de desarrollo de software"

Software can only partially be designed in advance. ... requirements suffer from observation, that the act of building software causes the requirements to change. ...technical factors cannot be perfectly understood, that only the act of trying to build something with specific components will reveal all of the gotchas and who-knews associated with a chosen technology strategy. ...software design is an iterative process, starting with a best guess that is continually refined with experience. the normal case for software projects is that tasks are rarely completed exactly as estimated, but that as a project progresses, the aggregate variance from estimates falls.

Fuente

Nobody likes to look stupid. If you’re a professional and someone puts you on the spot to answer “how long will this take?” it’s only human to want to provide an answer. Whether you call it professional pride or ego, it’s a powerful driver. Good IT workers really don’t like saying “I don’t know.” If they say it, they probably mean it. So stop pushing for a definitive answer when one doesn’t exist.It’s perfectly reasonable to want some sort of plan up front. I’m actually one of those funny types who believe up front planning is a necessity. So long as everyone understands an estimate is just that: an estimate. You learn as you go along and discover more detail. So you revise the estimate accordingly.

The mess we're in

Joe Armstrong, autor de Erlang

Your architecture should resemble your domain

So what does the architecture of your application scream? When you look at the top level directory structure, and the source files in the highest level package; do they scream: health care system, or accounting system, or inventory management system? Or do they scream: rails, or spring/hibernate, or asp?

La arquitectura no debería ser dada por el framework. Los frameworks son herramientas para utilizarlas, no arquitecturas a las que haya que conformarse. Si tu arquitectua está basada en frameworks, entonces no puede estar basado en tus casos de uso.

Uncle Bob Martin, "Screaming Architecture"

Fuente

Sigue los principios de X

  • No añadir nueva funcionalidad a menos que un desarrollador no pueda completar una aplicación real sin ella.
  • Es tan importante decidir qué no es parte del sistema, como decidir que sí lo es. No respondas a las necesidades de todo el mundo; en lugar de eso, haz el sistema extensible para que las necesidades adicionales puedan cubrirse de una manera compatible ascendente.
  • La única cosa peor que generalizar a partir de un ejemplo, es generalizar a partir de ningún ejemplo.
  • Si un problema no es comprendido completamente, probablemente es mejor no proporcionar ninguna solución.
  • Si puedes conseguir el 90 por ciento del efecto deseado para el 10 por ciento del trabajo, utiliza la solución más simple.
  • Aísla la complejidad tanto como sea posible.
  • Proporcionen un mecanismo en vez de una política. En particular, pongan la interfaz de política en las manos de los clientes.

Fuente

Sigue los principios de Unix

"Esta es la filosofía de Unix: escribe programas que hagan una sola cosa y la hagan bien. Escribe programas para trabajar colectivamente. Escribe programas para manejar flujos de texto, porque esta es una interfaz universal."

Doug McIlroy, citado en "A Quarter Century of Unix" [Salus]. Addison-Wesley. 1994. ISBN 0-201-54777-5.

  • Regla de Modularidad: Escribe partes simples conectadas por interfaces limpias.
  • Regla de Claridad: La claridad es mejor que la habilidad y el ingenio.
  • Regla de Composición: Diseña programas para ser conectados a otros programas.
  • Regla de Separación: Separa la política del mecanismo; separa las interfaces de los motores.
  • Regla de Simplicidad: Diseña pensando en la simplicidad; agrega complejidad solamente donde debas.
  • Regla de Parsimonía: Escribe un programa grande solamente cuando es claro por demostración que ninguna otra cosa funcionará.
  • Regla de Transparencia: Diseña pensando en la visibilidad para hacer la inspección y la depuración más fácil.
  • Regla de Robustez: La robustez es la hija de la transparencia y la simplicidad.
  • Regla de Representación: Pliega el conocimiento dentro de los datos de tal manera que la lógica del programa pueda ser estúpida y robusta.
  • Regla de la Mínima Sorpresa: En el diseño de interfaces, siempre has la cosa menos sorprendente.
  • Regla del Silencio: Cuando un programa no tiene nada sorprendente que decir, no debería decir nada.
  • Regla de Reparación: Cuando debas fallar, falla ruidosamente y tan pronto como sea posible.
  • Regla de Economía: El tiempo del programador es costoso; consérvalo en preferencia al tiempo de máquina.
  • Regla de Generación: Evita el hackeo manual; escribe programas para escribir programas cuando puedas.
  • Regla de Optimización: Haz prototipos antes de pulir. Haz que funcione antes que lo optimices.
  • Regla de Diversidad: Desconfía de todas las pretensiones para "una vía verdadera".
  • Regla de Extensibilidad: Diseña para el futuro, porque estará aquí más pronto de lo que piensas.

Eric S. Raymond, "The Art of Unix Programming"

Fuente

Bitdeli Badge