«La clave es ver las piezas de ajedrez no como pedazos de madera, sino como bloques de energía» Jonathan Rowson. Los Siete Pecados Capitales del Ajedrez.
La forma de hacer software ha ido evolucionando poco a poco y el objetivo siempre es el mismo: hacer código más legible. Al fin y al cabo, el código que escribimos va a ser leído y posiblemente modificado muchas veces, por lo que es importante que sea claro para evitar los menores bugs posibles. Para conseguir soluciones mantenibles y evolucionables es importante hacer un software modulable y fácil de entender.
Un ejemplo es como ASP.NET Webforms se ha transformado en ASP.NET MVC, para que el patrón de Modelo-Vista-Controlador ponga una reglas a la hora de generar código y ordenar el código espaguetti que se creaba con Webforms. El caos de JQuery y su document.ready en las páginas webs también ha evolucionado a frameworks de Front con un patrón MVC como Angular y su evolución posterior con la creación de componentes con React y Angular 2-4. Un código más legible es un código menos pesado de mantener y más sencillo de evolucionar.
Programar es picar líneas de código. Hay que escribir software como si estuviéramos escribiendo un libro. Cada línea de código tiene que tener su propio significado y el código en su conjunto debería poder leerse como si de la historia del proyecto se tratara. Siempre me ha gustado mucho esta comparación ya que aunque el objetivo de un equipo de desarrollo de software es crear un proyecto, se dan muchas situaciones en el proceso de implementar un proyecto que son comparables a la vida cotidiana. Al final cada proyecto es comparable a una aventura de un libro que se va a escribiendo poco a poco, con su introducción, nudo y desenlace.
Por eso son tan importantes los nombres que ponemos a las variables, porque pueden transmitir algo más que ser un entero, un string o un array. El nombre de la variable debe transmitir su objetivo, debe ser claro y conciso. Si los escritores siempre están buscando ese adjetivo con el que dar vida a sus personajes, creo que los desarrolladores de software siempre buscamos ese nombre que haga más amena una variable y con ello se consiga seguir su traza por el código de una manera más cómoda. Un buen nombre de una variable da dinamismo y energía al siguiente desarrollador que mantenga ese código; en cambio, un nombre puesto con hastío puede despistar y ser molesto para el que vuelve a leer esa parte del software. Incluso en la programación funcional ya se empieza a proponer la inmutabilidad de las variables, es decir, que no cambien de valor. ¿No es esto una artimaña más para que no perdamos el hilo de nuestras variables? Una variable que no va a cambiar siempre va a ser más fácil de nombrar que una que cambie con el paso de la ejecución y será más sencillo seguir todo el ciclo de vida que tiene esa variable.
Lo mismo ocurre con las funciones. La regla de oro de que una función no debe ser más grande que lo que ocupe la pantalla no es más que un truco literario más, una manera de hacer que el lector de nuestro código no pierda la atención sobre lo que está leyendo. Una función tiene mucho debajo y es importante asignarle un buen nombre, con parámetros claros para el que este leyendo sobre ella no tenga que ir debajo a ver que hay dentro si no le apetece, sino que de un vistazo sepa que es lo que hace esa función. Un buen nombre es el secreto de una buena abstracción, sin olvidar los detalles técnicos de su implementación.
El lenguaje que empleamos en el código que generamos es importante y tenemos que ser conscientes de ello y darle toda la energía que podamos a nuestros desarrollos. No es suficiente con que el código funcione bien sino que hay que hacer que sea mantenible, modulable y por qué no legible, dinámico e intenso.
Hace poco he tenido que mantener un proyecto lleno de clases static por todos lados. Todo el código era una clase estática con una función estática que llamaba a otras funciones estáticas como no puede ser de otra manera. Y voy a reconocerlo, esto afectó a mi estado de ánimo. Estaba enfadado con todo y con todos, no estaba cómodo. No podía hacer una mejora a aquel código ya que en cuanto me ponía hacer algún refactor me surgían en cadena otros 3 y podía estar todo el día solo refactorizando sin llegar al objetivo de terminar mis tareas. Tenemos que tener esta comunicación violenta que se da entre programadores en mente, ya que podemos sufrirla hasta de nosotros mismos si mantenemos un código que programamos en el pasado.
Lenguaje Imperativo vs Lenguaje Declarativo
Un lenguaje imperativo es un tipo de lenguaje basado más en las matemáticas y en la lógica mientras que los lenguajes declarativos, son más cercanos estos al razonamiento humano. Los lenguajes declarativos no dicen cómo hacer una cosa, sino, más bien, qué cosa hacer.
Un ejemplo de este tipo de lenguajes podemos verlo con LINQ. Para mí, si hay algo que me encanta destacar de C#, mi característica favorita, esa es LINQ. LINQ le da a C# un azúcar sintáctico que hace todo mucho más fácil de leer. Sin llegar a ser programación funcional, LINQ hace que nuestro código sea más declarativo y por tanto, más legible.
|
1 2 3 4 5 6 7 8 9 10 |
// Imperativo int maxNumbersPage = 0; foreach (var book in books) { if (book.Pages > maxNumbersPage) maxNumbersPage = order.Pages; } // Declarativo var maxNumbersPage = books.Max(book => book.Pages) |
La comparativa es brutal. Si leemos el foreach nuestra mente tiene que seguir la variable maxNumbersPage en todo su flujo para poder saber que es lo que está pasando con ella. Una vez más, es difícil asociar un buen nombre a dicha variable y su objetivo puede ser confuso. En el método con LINQ nuestra mente rápidamente asocia la función Max con la propiedad de ‘book’ Pages y es capaz de procesar lo que está pasando mucho mejor. Los dos métodos funcionan pero está claro que el lenguaje declarativo da más rendimiento y más calidad al código. La función lambda da energía a nuestras instrucciones y es mucho más sencilla de procesar. La mente es capaz de coger el objetivo de la función en seguida; en cambio, el foreach es muy tedioso y nuestra cabeza (al menos la mía) ya pone el modo de: «un foreach, puf a ver que es lo que hace en toda su iteración».
LINQ solo es un paso hacia la programación funcional. El lenguaje declarativo es mucho más potente que el imperativo y esto viene cogido de la mano con lo funcional. Vamos a cambiar nuestra manera de programar hacia este modelo, lo que hará que en nuestros códigos haya cada vez más programación funcional. El cambio siempre es difícil y habrá mucha gente que no se quiera bajar de su lenguaje imperativo en el código poniendo trabas; pero, en mi opinión, es algo que debería entrar en nuestra manera de programar de manera natural.
EcmaScript y C#7 están cada vez más yendo por esa vía intentando dar más legibilidad a nuestro código. Un ejemplo de es2015 en Javascript sería:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
// Imperativo var numbers = [1, 2, 3, 4]; var doubleNumbers = []; for(var i = 0; i < numbers.length; i++) { doubleNumbers[i] = numbers[i] * 2; } // Result => doubleNumbers: [2, 4, 6, 8] // Declarativo var numbers = [1, 2, 3, 4]; var doubleNumbers = numbers.map(number => number * 2); // Result => doubleNumbers: [2, 4, 6, 8] |
Y en .NetCore la inicialización en la clase Startup la quieren hacer toda con lenguaje declarativo.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 |
public class Startup { public IConfigurationRoot Configuration { get; } public Startup(IHostingEnvironment env) { var builder = new ConfigurationBuilder() .SetBasePath(env.ContentRootPath) .AddJsonFile("appsettings.json", false, true) .AddJsonFile($"appsettings.{env.EnvironmentName}.json", true) .AddEnvironmentVariables(); Configuration = builder.Build(); } public void ConfigureServices(IServiceCollection services) { services.AddMvc(); services.AddAutoMapper(); services.AddSingleton<IConfiguration>(Configuration); services.AddEntityFrameworkSqlServer() .AddDbContext<Context>(options => { options.UseSqlServer(Configuration.GetConnectionString("Context")); }); services.AddSingleton<IOrderService, OrderService>(); } public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) { loggerFactory.AddConsole(Configuration.GetSection("Logging")); loggerFactory.AddDebug(); if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); app.UseBrowserLink(); using (var serviceScope = app.ApplicationServices.GetRequiredService<IServiceScopeFactory>().CreateScope()) { var context = serviceScope.ServiceProvider.GetService<context>(); var configuration = serviceScope.ServiceProvider.GetService<IConfiguration>(); var hostingEnvironment = serviceScope.ServiceProvider.GetService<IHostingEnvironment>(); context.Database.EnsureDeleted(); context.Database.Migrate(); DatabaseInitializer.Seed(hostingEnvironment, configuration, context).Wait(); } } else { app.UseExceptionHandler("/Home/Error"); } app.UseStaticFiles(); app.UseMvc(routes => { routes.MapRoute( "default", "{controller=Home}/{action=Index}/{id?}"); }); } } |
Un día en la oficina
Si usted pudiera pasear por una oficina de una empresa de desarrollo de software creo que se encontraría la misma estampa que me encontré el otro día en la mía. Traté de observar desde fuera, con una perspectiva externa y me di cuenta de lo que reímos los programadores escribiendo código. Nos gusta pensar y nos gusta programar pero realmente… ¿es divertido?
A los programadores nos encanta discutir y discutimos sobre todo. Como haríamos esta clase, como haríamos esta estructura, por donde va a salir el Sol mañana e incluso a veces hablamos con nuestros objetos. Aunque por encima de todo, nos encanta resolver puzzles y encajar las tecnologías para hacer algo viable. Programar para nosotros es divertido y lo reflejamos en nuestros rostros cuando por fin conseguimos nuestro objetivo: ¡compila y funciona!
No les voy a mentir, en mi oficina también había gente con caras largas. Es el otro lado de la programación: la frustración. No compila, no funciona, estos de arriba por que han hecho esto así, por que ahora me han metido esta tecnología aquí, etc. etc. etc. Programadores que miran a sus pantallas indignados y enfadados con el mundo, como yo el otro día con esa clase estática a la que no le podía hacer ni un test debido a la estructura de la misma.
Los desarrolladores que trabajan juntos tienen sentimientos encontrados entre ellos y Scrum trata de hacer equipo, que personas colaboren ante un objetivo. Pero a mí me gustaría ir más allá y si nosotros mismos tenemos estos sentimientos encontrados con el código que tenemos delante, que estamos desarrollando, ¿no deberíamos también hacer equipo con nuestras propias instrucciones? ¿que responsabilidad tenemos con el código que no es nuestro y nos ha tocado mantener/desarrollar? y más aún si encima es nuestro código de hace unos meses.
«Enfadarse» ante un código que no está correctamente escrito creo que es positivo, siempre que sea controlado. Tenemos que controlar las mariposas que tenemos en el estómago, tanto las buenas como las malas y tener la responsabilidad de cada vez que hagamos una tarea pasando por un código dejar ese código un poquito mejor de lo que estaba. La queja al aire o en nuestra cabeza no es positiva, hay que predicar con el ejemplo y piedra a piedra ir mejorando, no caer en la metáfora de la casa con las ventanas rotas y como está todo roto ir dejándolo igual o peor.
Al fin y al cabo, si el código genera estos sentimientos entre desarrolladores, deberíamos ser conscientes de ello y tratar de tener una Comunicación No Violenta no solo en la vida como nos propone Marshall Rosenberg sino también en nuestro código para que ningún loco maníaco de esos que hacen software toquen nunca a nuestra puerta con una pistola en la mano. Y considero que para ello tenemos que tener siempre presente que:
«El proyecto que vamos a desarrollar es importante, que hay (esperemos) cosas más importantes en la vida y que (esperemos) seguirán estando en su sitio cuando el proyecto haya terminado».
Es esencial disfrutar programando. Disfrutar cada día escribiendo un código mejor. Si realmente te gusta programar, hacer un buen código tiene que formar parte de ese placer y no hay nada más natural que buscar esa excelencia. Pero si lo único que quieres es «acabar ese proyecto ya», las decisiones que vas a ir tomando se convertirán en un fardo muy pesado que va a dificultar mucho tanto disfrutar la experiencia de crear software como que el proyecto salga de manera satisfactoria para el cliente como para ti.
Happy Coding!
Deja un comentario