Foto de Veronica Benavides en Unsplash
En este artículo voy a describir qué es una Entidad desde el punto de vista de Domain Driven Design, qué características tiene y cómo implementarla en c#.net.
Foto de Anastasiya Romanova en Unsplash
A menudo me he encontrado con que en el mundo del desarrollo de software, a cualquier cosa se le llama lógica de negocio o lógica a secas.
En este artículo voy a explicarte qué entiendo por lógica y qué tres tipos básicos podemos distinguir.
Photo by Claudio Schwarz on Unsplash
Aquí tienes un ejemplo real de un método deshonesto en c# y un par de opciones para mejorarlo.
Fotografía de Nathan Dias en Unsplash
Para comprender patrones de diseño básicos como Command Query Separation CQS o la base teórica detrás de la programación funcional es necesario saber qué son los efectos secundarios en programación y cuándo se producen. En inglés se conocen como side effects.
En el post anterior definí lo que era el estado de la aplicación, te recomiendo tenerlo presente para comprender mejor este texto.
Para generar código mantenible es fundamental comprender el concepto estado, puesto que la mayoría de principios y prácticas se refieren a él constantemente.
Espero que este post te ayude a conocerlo un poco mejor.
El encapsulamiento es el principio fundamental que te va a ayudar a crear código mantenible. Aquí tienes su definición y tres herramientas sencillas que puedes aplicar para encapsular con sentido.
Voy a iniciar una serie de posts sobre conceptos y teoría para escribir código mantenible. Empezaré por los conceptos más básicos y continuaré siguiendo un orden de complejidad que permita entenderlos todos e ir subiendo de nivel.
Cuando un cliente me explica una funcionalidad suele utilizar frases del tipo 'si tenemos esta situación entonces haz X, pero si es esta otra haz Y'. Uno de los reflejos inmediatos es intentar plasmar esta misma lógica en el código utilizando cláusulas switch.
En este post voy a explicar por qué debes sospechar de los switch de tu código y qué puedes hacer para minimizarlos.
Hará unos 5 años que me uní a un equipo de programación para extender las funcionalidades de un CRM.
Uno de los compañeros me espetó:
Aquí programamos en español, si programas en inglés no se entiende nada.
Mi primera reacción fue de rechazo: toda la documentación en internet está en inglés, cualquier proyecto con el que te encuentres estará en inglés, hay multitud de palabras que no son traducibles, etc. Me parecía algo retrógrado.
Pero tras pensarlo detenidamente, tampoco era un idea tan descabellada, escribir código es como escribir en un lenguaje, ¿por qué no escribirlo en el propio?
En este post voy a explicar mi experiencia programando en español, ventajas y desventajas y cómo decido al final el idioma que utilizaré.
Muchas veces estoy trabajando y le pregunto a mi mujer (compartimos despacho): ¿tú cómo llamarías a algo que hace X en un contexto Y?
Poner un nombre en programación es un proceso que hay que tomarse seriamente y cualquier ayuda, punto de vista o idea es bienvenida para seleccionar el más adecuado.
"En software los nombres están en todas partes. Ponemos nombre a las variables, a las funciones, a los argumentos, a las clases y a los paquetes. Ponemos nombre a los archivos de código fuente y a las carpetas que los contienen. Ponemos nombre a nuestros ficheros jar, war y ear. Ponemos nombres y nombres y más nombres. Lo hacemos tantas veces que sería deseable hacerlo bien” Robert C. Martin
En este post voy a recordar la primera regla que Robert C.Martin propone para generar buenos nombres y comentar algunas de las experiencias que he tenido al aplicarla.