Laboratorios de prácticas con Docker

Diseño de sistemas

  • March 24, 2017
  • tuxotron
  • Diseño de sistemas

    Cuando alguien me pregunta en que consiste la programación, respondo que consiste, 80% es pensar y el 20% es escribir código. Desde mi punto de vista y experiencia, los errores de programación en comparación con los errores de diseño son ínfimos. Cambiar algunas líneas de código o re-escribir una función es mucho más fácil que un cambio en el diseño.

    El primer paso a la hora de diseñar un sistema es conocer el dominio del mismo, quién lo va a usar, cuántos usuarios va a tener, qué cantidad de datos vamos a manejar, tiene que ser escalable, qué tipo de persistencia necesitamos, etc. Una vez tenemos esos datos o al menos los sufuciente, es hora de crear algunos esquemas, identificar y diseñar los componentes principales del mismo. Luego, cada componente tiene sus problemas específicos, por ejemplo, si estamos hablando con una base de datos relacional, nos debemos preguntar cosas como: replicación, sharding, denormalización, etc. Si hablemos de bases de datos no relacionales, necesitamos bases de datos de documentos, pares de valores, en memoria, necesitamos mayor rendimiento en operaciones de lectura o escritura, etc. Lo mismo con el resto de componentes que podamos necesitar: cachés, colas de mensajes, seguridad, etc.

    Todo esto y más puedes encontrar en este proyecto llamado The System Design Primer alojado en Gtihub. En él se recogen todo tipo de información relacionada con el tema del diseño de sistemas. La información está muy bien organizado y es plena. El contenido está en forma de vídeos, esquemas gráficos, ejmplos reales de diseños comunes, etc. Dicha documentación es perfecta para el diseñador o arquitecto de sistemas y para aquellos que aspiron a ello. De hecho, parte de las motivaciones del autor del proyecto es el de la preparación para entrevistas de trabajo, sobre este tema obviamente.

Guías de estilo de programación de Google

  • March 24, 2017
  • tuxotron
  • Coding style

    Cuando escribimos software, está claro que el objetivo final es que el mismo sea funcional y que cumpla con los requisitos del sistema. Aparte de la funcionalidad en sí, es importante escribir código que sea fácil de mantener, y esto es especialmente importante si es desarrollado en equipo. Incluso si tu eres el único, te vas a hacer un favor grandísimo escribiendo código bien estructurado y que seas capaz de entender cuando vuelvas a él meses más tarde.

    Dejando aparte el tema de patrones de diseño, tests, revisiones, etc, es importante y común, que los equipos de trabajo sigan algún tipo de guía de estilo, por ejemplo: como nombrar las variables, funciones, definición de tipos, clases, etc.

    En Google obviamente siguen este tipo de prácticas y por suerte para muchos, han publicado varias guías de estilo de programación:

    Incluso tienen un guía de estilo para la creación de documentos XML. También puedes usar cpplint, una herramienta para ayudarte a seguir dichas guías o google-c-style.el, un fichero de configuración para EMACS, con el estilo definido para C/C++.