Categoría: codigo

Publicado el

¿De verdad tenemos que hacer code review?

¿Todo tiene que ir en code review? ¿Hay que hacer la code review antes?¿por qué no la hacemos después de mergear? Si ya hacemos pair/mob programming ¿tiene sentido también una code review? Ya hemos hablado antes de como hacer code reviews con fundamento, de que las code reviews son algo más que código: son comunicación entre personas. También hemos visto cómo llevar a cabo una code review y qué puntos tener en cuenta. Las code reviews son un «estandar de mercado» todo el mundo las hace porque X. Dependiendo de nuestro contexto, de cada equipo, de cada empresa,… puede que haya otras prácticas ténicas que mejoren nuestra productividad y el flujo de valor hacia el usuario.

Partamos de la base de que esto que pongo aquí es mi opinión este post se basa en mi «cámara de eco» ( experiencia trabajando, opiniones compartidas, libros, artículos y recursos que he ido viendo,…) La idea de este post es que reflexionemos sobre las prácticas que tenemos en nuestro equipo y de que vez en cuando nos preguntémos el porqué de esas prácticas que utilizamos y si siguen teniendo sentido en el contexto actual.

¿Para qué sirve una code review?

Hablemos de que es lo que aporta una code review. En la industria, las code review tienen 2 objetivos principales: compartir conocimiento y mejorar la calidad del código.

Continúa leyendo «¿De verdad tenemos que hacer code review?»
Anuncio publicitario
Publicado el

Haciendo code reviews con fundamento

Aunque cada día veo que más gente hace pair programming, mob programming,… lo habitual es hacer pull request/merge request y tener que revisar el código (aka. code review) de los compañeros antes de integrarlo (lo de antes podemos discutirlo en otro post) en la rama principal. En este post vamos a tratar algunos puntos sobre cómo hacer code reviews con fundamento, sin opiniones, hablando de code smell.

Normalmente las pull request son una práctica que causa bastante fricción y a la que en mi opinión no le dedicamos la importancia que tienen: si hemos decidido hacer pull request antes de integrar, estas deberían ser el objetivo prioritario. El código de esta pull request/merge request está muy cerca de aportar valor. ¡Y qué no lo está haciendo porque no le estamos poniendo el cariño suficiente!

Hace tiempo ya estuvimos comentando en el blog Cómo llevar a cabo una code review y qué puntos tener en cuenta y que la code review involucra a lo más importante personas, por lo que la comunicación, los comentarios y la asertividad son importantes de cara a que podamos aportar feedback de calidad.

Para otro post dejaremos listar los que son en mi opinión los problemas principales de una code review, hoy, vamos a hablar un poco de cómo podemos mejorar nuestras code reviews como revisores. Vamos a partir de la base de que queremos aportar feedback accionable, de calidad y dejar de lado las opiniones y para ello nada mejor que conocer un poco más acerca de los code smells.

Continúa leyendo «Haciendo code reviews con fundamento»
Publicado el

Makefiles como dejar de memorizar comandos en docker – Developer Vago

Si has trabajado con docker, o si lo has probado, seguro que te has dado cuenta de la cantidad de comandos que tiene y la cantidad de opciones posibles. Para simplificarme un poco la vida he estado buscando información y lo que más util me resulta es crear un pequeño Makefile con los comandos que más utilizo.

making waves
Elizabeth Donoghue – making waves

Así que hoy voy a contar algunos trucos y consejos sobre Makefiles y para que veáis la cantidad de comandos que hay aquí os dejo la lista:

Continúa leyendo «Makefiles como dejar de memorizar comandos en docker – Developer Vago»

Publicado el

«Clean Code» sin escribir una linea de código

Como desarrolladores nuestro trabajo es escribir código que ayude a resolver problemas, ni más ni menos que eso. Resolver problemas. Leemos libros como Clean Code, Software Craftmanship,… estamos al día de las últimas tendencias sobre programación, conocemos lenguajes, frameworks, en definitiva intentamos cada día hacerlo un poco mejor.

Pero, ¿es todo escribir código? da igual que sea PHP, Python, Javascript o Java nuestro día a día es resolver problemas y hacerlo bien. Una de las razones podría ser no generar demasiada deuda técnica y que nuestro código tarde más en convertirse en legacy code.

8314862395_bfef0bb766_z
One Shell Square

Además debemos luchar contra los deadlines,  así que en este post vamos a ver una serie de consejos para escribir mejor código sin escribir código.

Continúa leyendo ««Clean Code» sin escribir una linea de código»

Publicado el

Don’t be STUPID: SOLID and GRASP

Has oído hablar de SOLID? Seguramente: Es un término que describe una colección de principios para «buen código» que fue acuñado por Robert C. Martin (aka «uncle bob«) nuestro gran evangelista del «clean code».

La programación está llena de acrónimos como este. Otros ejemplos son DRY(Don’t Repeat Yourself!) y KISS(Keep It Simple, Stupid!). Aunque obviamente hay muchos, muchísimos más.

Continúa leyendo «Don’t be STUPID: SOLID and GRASP»

Publicado el

Trabajando con parches, mejorando proyectos usando patch

Si necesitamos hacer un cambio en un proyecto que está dentro nuestro directorio vendor, ¿como hacer ese cambio de manera ágil y luego poder “transplantarlo/integrarlo”.

Todos tenemos dependencias en nuestros proyectos, seguro que os ha pasado, que estamos desarrollando una funcionalidad en un proyecto A y para poder completarla necesitamos “tocar” un proyecto B que es una dependencia de A. Tenemos al proyecto B dentro de nuestra carpeta vendor y tenemos que modificarlo, ¿cómo hacemos esto de manera ágil?

La manera más ortodoxa de crear una funcionalidad en el proyecto B que necesitamos para terminar una funcionalidad en A sería: abrir el proyecto B, crear una rama, realizar dichos cambios y testearlos, integrar la rama en master, subir de versión el proyecto B. Ir al proyecto A, crear una rama, modificar el composer, actualizarlo y empezar con la funcionalidad de B. Como veis, es sencillo pero un poco largo, es más puede que nos ea una funcionalidad, sino que tenemos que solucionar un bug importante, ¿como lo hacemos de manera más ágil? Creando un patch

Continúa leyendo «Trabajando con parches, mejorando proyectos usando patch»

Publicado el

Buenas prácticas y consejos para desarrollar en PHP (Recopilatorio)

Llevo algo de tiempo programando en PHP, al principio mi código era horrible pero poco a poco he ido aprendiendo más y más sobre buenas prácticas, SOLID, naming, uso de herramientas para mejorar el código (PHP Mess detector, PHP code Sniffer…). Además la serie de post sobre refactoring PHP legacy code he podido poner en práctica muchos de estos conocimientos.

Este post es un recopilatorio de buenas prácticas y consejos que he ido aprendiendo en estos últimos meses.

Instalación de PHP

Antes de empezar a desarrollar tenemos que tener bien configurado PHP y el archivo de configuración php.ini es esencial.

  • date.timezone -> tener bien definido la zona horaria nos evitará muchos quebraderos de cabeza.
  • charset -> trabajar con UTF-8.
  • error_reporting -> tener diferentes entornos (producción, desarrollo,…) y que cada uno notifique errores distintos.
  • Extensiones -> Instalar extensiones como XDebug,, mycript, intl,Imagemagick.*

Utilizar Composer

Existen miles de librerías en PHP, github esta lleno de componentes que puedes sernos muy útiles para ayudándonos en nuestro día a día. Librerías par manejar CSV, para log, para manejar peticiones HTTP,… Para gestionar todas estas dependencias creo que lo más útil es utilizar composer.

Continúa leyendo «Buenas prácticas y consejos para desarrollar en PHP (Recopilatorio)»

Publicado el

algunos comandos útiles para git

Hace ya tiempo vengo coleccionando algunos comandos útiles para Git, así que he decidido tenerlos por aquí para no olvidarme. Además haciendo una pequeña búsqueda buscando consejos sobre Git interesantes, como este post. Por ello vamos a escribir algunos consejos/trucos/comandos sobre Git.

Comprobar los merges

Si normalmente trabajamos con «una rama por tarea» o con varias ramas a la vez podemos tener el repositorio bastante «sucio». Así que lo mejor es de vez en cuando limpiarlo.
¿Como saber que rama podemos eliminar y cual no?

Continúa leyendo «algunos comandos útiles para git»

Publicado el

Review de generadores de sitios html estáticos

Llevo un tiempo dándole vueltas a  esto de WordPress. Actualmente escribo los post en Word (sí en Word) ya que hay veces que no dispongo de conexión a Internet y porque conozco algunos de los atajos rápidos de teclado. El problema es el formato, al pasarlo a WordPress no queda como me gustaría y además a veces Word es un poco “caprichoso” con el estilo.

Así que me he puesto a buscar soluciones alternativas y una de ellas es utilizar Markdown. Para quien no lo conozca es un lenguaje de marcado ligero con el que añadir formato fácilmente a textos web, para utilizarlo en WordPress solamente es necesario un plugin

.

Aunque me ha picado el gusanillo de utilizar alguna herramienta que genere páginas estáticas, como Jekyll(http://jekyllrb.com/ ), Hyde(https://github.com/hyde/hyde ), pelican (https://github.com/getpelican/pelican/), Nikola (http://getnikola.com/), secondcrack(https://github.com/marcoarment/secondcrack), Spress (https://github.com/yosymfony/Spress). Como podemos ver hay muchísimas, por ello vamos  a probar unas cuantas y comentar sus impresiones.

Jekyll

Es de los generadores estáticos más utilizados, está escrito en Ruby y por ello es necesario tenerlo instalado en Windows. Podemos utilizar Markdown y tiene muchos plugins. Aquí podemos encontrar una lista de personas que utilizan Jekyll https://github.com/jekyll/jekyll/wiki/Sites

Continúa leyendo «Review de generadores de sitios html estáticos»