Vamos con algo suave. Tengáis la formación que tengáis si vais a afrontar por vez primera la programación con más o menos seriedad os vais a encontrar con una serie de carencias. Por diversos motivos, porque vuestra educación fue especializada en exceso y en rara vez te enfrentarás una y otra vez a los mismos retos para los que te has especializado o al contrario tienes una formación tan amplia y abarcable que sabes un poco de todo y mucho de nada… En definitiva el problema será la experiencia, porque con tiempo de todo se aprende. Vamos a ver si os ahorro el susto de los primeros meses (o a unas prácticas infernales) con algunos consejos y avisos.

Y aviso para navegantes: Estos consejos son por supuesto, mi opinión, sobre cosas que considero nunca está de más aprender/hacer para sacar el trabajo adelante y que en mi experiencia con más o menos frecuencia uno no aprende en su educación, es obvio que hay excepciones y puedo equivocarme. Pueden parecerte consejos muy tontos o por completo innecesarios. Por si acaso ahí los dejo. También aclarar que mi día a día durante años ha sido Java™ y aunque intentaré ser lo más generalista posible siempre es posible que alguno de los consejos no sea aplicable en vuestro trabajo.

  1. Utiliza un control de versiones

    Para nóveles (explicación casera) los sistemas de control de versiones (SCV para abreviar) permiten subir cualquier archivo a un servidor donde llevar un registro al día de quien lo ha subido, modificado, que se modificó en concreto, etc. Su propósito es tanto por seguridad (conservar una copia de tu trabajo sin importar en donde trabajes y cualquier desastre que le suceda a tu equipo) como concurrencia (si tenéis que trabajar varias personas sobre el mismo archivo al mismo tiempo saber en todo momento quien hizo qué y cuando para evitar perder el trabajo de todos).

    Si ya sabéis que es un control de versiones puede que en un momento dado os parezca una estupidez utilizarlo. ¿Soy la única persona que toca el proyecto? ¿Es tan pequeño que da vergüenza subirlo a ningún sitio? ¿Pierdo más tiempo haciendo ‘commit’ que programando? Puede que tengáis razón y sea una estupidez o perdida de tiempo pero incluso sin necesidad de concurrencia la seguridad está siempre bien. Recuperar datos perdidos, versiones antiguas… valorarlo.

    Apunte: Aunque hablemos de consejos para programar un sistema de control de versiones puede gestionar cualquier archivo (aunque las herramientas que incluyen para comparar versiones no suelan funcionar con nada que no sea texto plano). Fuera de la programación puede resultar de utilidad en otros ámbitos como la escritura o la ilustración.

  2. Utiliza tu control de versiones bien

    Lo peor que se puede hacer con un sistema de control de versiones es utilizarlo mal y lo sé por experiencia propia. Suena a obviedad pero puede no serlo, porque puede no ser obvio que le estás dando un mal uso hasta que sea demasiado tarde. El problema de este consejo es que el uso que hacemos en un entorno profesional en el que tu eres la persona con menos experiencia será, con mayor frecuencia, el que nos dicte otra persona (“aquí trabajamos así”) con mayor o menos acierto. Presupongamos a partir de aquí que por un momento tienes alguna capacidad de toma de decisiones en este aspecto.

    Saltémonos de momento la parte de escoger cual es el SCV más indicado para nuestro proyecto. No porque no exista la posibilidad de que tu voz sea tenida en cuenta sino porque partimos de que no tienes experiencia con estos mismos programas (si la tienes no entras en el público objetivo de este párrafo). Llegados a este punto la cuestión es “¿como utilizo mi control de versiones?” y claro, así en plan genérico no puedo daros una respuesta aunque si puedo daros un consejo, buscar alguien que ya haya pensado esto antes. Si por ejemplo nos da por usar Git un buen punto de partida, en inglés, sería ‘A successful Git branching model’ que da unas pautas de trabajo y organización para utilizar nuestro mencionado control de versiones distribuido. Procurad informaros primero, no confiéis ciegamente en vuestro sentido común y sobre todo no apliquéis la metodología de un SCV a otro distinto. Ya os adelanto que no suele acabar bien.

  3. Organiza tu trabajo.

    Lo sé, parece una frase de revista “15 consejos para ser más eficiente en tu trabajo” pero este punto no es fruto de la falta de originalidad sino de un análisis más o menos serio de donde he metido la pata durante años. La parte evidente de este punto es que con frecuencia tendréis muchas cosas que hacer en un mismo instante de tiempo. Habrá llegado el momento de anotar que tienes que hacer, considerar cuales son tus prioridades en dicho momento y tomar un curso de acción, con mucha probabilidad empezar por lo más urgente/necesario.

    No depositéis todo el peso de un proyecto en vuestra memoria. Puede que para un programa sencillo dejar un comentario en la última línea de código que no compile sea la herramienta perfecta para recuperar a la mañana siguiente el hilo de lo que estabas haciendo pero no os confiéis, tarde o temprano los problemas y las responsabilidades se amontonarán. Hace unos años probé Trello, antes intentamos usar un tablero Kanban de corcho…

    Tened en cuenta que en este punto hablo de organizar vuestro propio trabajo, no el de vuestros compañeros, por más que muchas ideas puedan aplicarse al grupo. La organización de vuestro proyecto en conjunto (si la tiene) vendrá impuesta. Si esta organización te ayuda a llevar tu día a día bienvenido sea pero no contaría con ello.

  4. Adquiere buenas prácticas de programación

    Cuando estás un tiempo trabajando en lo mismo lo normal es estancarse, aprender cosas nuevas cada vez con menos frecuencia y coger un montón de vicios. La informática y en concreto la programación tiene de esto por un tubo. La experiencia pulirá las lagunas dejadas por nuestra ignorancia pero no impedirá que hagamos cosas de forma chapucera por repetición. Mi consejo es tratar de aprender buenas prácticas de programación del lenguaje con el que estemos trabajando. Cuando antes empecemos mejor.

    Si por casualidad trabajáis con C++ o Java montarte un servidor de Sonar puede venir al pelo. ¿Qué os estoy vendiendo? Una herramienta de análisis de calidad del código (y gratis). Siguiendo una serie de reglas configurables, muchas interpretaciones directas de estándares de calidad existentes, valorará posibles incidencias en el código y te las señalará en rojo para que sepas que indistintamente tu código haga lo que debe hacer (porque Sonar no va a compilarlo ni va a hacerte prueba alguna) siempre hay algo mejorable. Cuando os haya dicho por enésima vez que las comparaciones con constantes se escriben al revés para evitar posibles NullPointerException ya veréis como empezáis a escribir bien solo por hacerlo callar.

    No lo he dicho pero es una obviedad que en una situación real, con plazos de entrega, una organización que se te escapa y poca voz y menos voto habrá momentos en los que no habrá tiempo para innovar y es comprensible que no lo intentes. Acabar con la complejidad ciclomática de tu aplicación escapará con frecuencia de tus posibilidades. Valora y prioriza pero no te olvides de la calidad de tu código (por más que sean criterio más o menos cuestionables).

Y eso va a ser todo por esta vez. Quizás en otra ocasión haga 2ª parte, si logro pensar algo (esto me pasa por no organizarme cuando estaba inspirado y tuve la idea de escribir la entrada).

Un saludo,

PD. La imagen de la cabecera es de la película Kung Fury (2015) y no guardo ninguna titularidad sobre los derechos de la misma. Puede que considerar su uso parte del derecho a cita contemplado en la legislación española sea excederse un poco.  Necesito un abogado.

Referencias:
  1. Andersson, L. (Producer), Young Antonia, E. (Producer), & Sandberg, D. (Director). (2015). Kung Fury [Motion Picture]. Sweden: Laser Unicorns, Lampray
Anuncios