MuroDev

Los buenos programadores usan sus cerebros, pero unas buenas directrices nos ahorran de tener que hacerlo en cada caso. — Francis Glassborow Algo importante en las comunidades Open Source , es crear un código legible a nivel de comprensión, que se pueda entender por otros desarrolladores, alargando así la vida de nuestro software, al poder identificar problemas y bugs en el código mucho mas rápido, y dando la oportunidad a otros programadores a participar Para eso se han creado unas convenciones de código que detallan un estándar de buenas practicas y define una guía de "diseño" del código, mirando aspectos como el nombramiento de funciones y variables, la identación o sangrado, posición de los elementos respecto a otros, etc Esto no quiere decir que un código que sea diferente a estas directrices este mal, de hecho algunos equipos de desarrollo/desarrolladores establecen las suyas propias, pero podemos usarlas como una buena base para crear las nuestras o para c

Hace poco hablamos sobre Git y Github , y de lo util que podria resultar llevar un control de versiones .  Para optimizar este proceso de documentacion del nivel de desarrollo de nuestro proyecto, podemos ayudarnos del versionado de software , esos numeros que vemos en algunas aplicaciones como " v1.0.0 ", " v0.7.3-beta ", etc Normalmente, esta informacion suele ser interna, y aunque existe un estandar o sentido semantico (que es con el que trabajaremos nosotros), algunos equipos de desarrollo tienen su propio sistema para crear este dato. Este sistema de control de nuestra aplicacion consta de cuatro partes basicas: mayor.menor.micro-fase mayor : Se indican cambios importantes dentro de la aplicacion, como funcionalidades nuevas o cambios importantes de codigo, cambios total en el diseño, etc. Esta dato sera 0 si nuestro producto aun no esta en su version final: 1 .menor.micro-fase menor : Correccion de errores e inclusion de mejoras no importantes. En l