Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

https://github.com/timoxley/best-practices

Tidbits of developer best practices from around the web
https://github.com/timoxley/best-practices

Last synced: 3 months ago
JSON representation

Tidbits of developer best practices from around the web

Lists

README 

        
# 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](http://bitovi.com/blog/2010/11/organizing-a-jquery-application.html).



## 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](https://twitter.com/#!/avdi/status/180747721852985344).



## 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](http://blogs.agilefaqs.com/2009/10/19/biggest-stinkers)



#### 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](http://pyvideo.org/video/880/stop-writing-classes)



#### 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](http://www.reddit.com/r/programming/comments/1bcebh/programming_best_practices/c9616mn)



## 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](http://pyvideo.org/video/880/stop-writing-classes)



## 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](http://www.itjoblog.co.uk/2011/06/making-better-software.html)



## 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](http://nodejs.debuggable.com/2011-02-26.txt)



## 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](http://www.python.org/dev/peps/pep-0020/)



## 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](http://en.wikipedia.org/wiki/Hofstadter's_law)

2. Los mercados cambian

2. Los clientes existentes se frustran

3. Puedes limpiar el código refactorizando

4. No controlas la reescritura, ella te controla a ti



[Fuente](http://onstartups.com/tabid/3339/bid/2596/Why-You-Should-Almost-Never-Rewrite-Your-Software.aspx)



## 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](http://radar.oreilly.com/2011/06/big-javascript-apps-teams.html)



[Reconocimiento a Addy Osmani](http://addyosmani.com/largescalejavascript/)



## Evita código que apesta



[Fuente](http://www.codinghorror.com/blog/2006/05/code-smells.html)  



[Fuente](http://web.archive.org/web/20120130234037/http://stackoverflow.com/questions/114342/what-are-code-smells-what-is-the-best-way-to-correct-them)



## 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](http://junit.sourceforge.net/doc/testinfected/testing.htm)



#### [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](http://misko.hevery.com/code-reviewers-guide/)



[Fuente](http://misko.hevery.com/presentations/)



## 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](http://misko.hevery.com/2008/09/30/2008/07/08/how-to-think-about-the-new-operator/)



## 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](http://en.wikipedia.org/wiki/Technical_debt)*. Organizaciones enteras de ingeniería pueden detenerse bajo la deuda de implementación sin consolidar"

(Cursivas mías)



[Fuente](http://c2.com/doc/oopsla92.html)



## 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](http://c2.com/cgi/wiki?PrematureOptimization)



## 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](http://www.theserverside.com/tt/articles/article.tss?l=ProgrammingisAlsoTeachingYourTeam)



### "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](http://weblog.raganwald.com/2007/06/which-theory-first-evidence.html)



## "...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](http://weblog.raganwald.com/2007/06/which-theory-first-evidence.html)



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](https://cloud.githubusercontent.com/assets/43438/4344401/0ddd5fc8-408f-11e4-8887-b0bfbce91dc7.png)](https://www.youtube.com/watch?v=lKXe3HUG2l4)



*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](http://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Architecture.html)



## 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](http://en.wikipedia.org/wiki/X_Window_System_protocols_and_architecture#Design_principles)



## 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](http://www.catb.org/esr/writings/taoup/html/ch01s06.html)



[![Bitdeli Badge](https://d2weczhvl823v0.cloudfront.net/timoxley/best-practices/trend.png)](https://bitdeli.com/free "Bitdeli Badge")