Llevo muchos años programando, demasiados, más de los que mis compañeros de trabajo han vivido en total. Cualquiera podría concluir que estoy en la cumbre, después de todo lo que he pasado. Pero no me siento así.
En realidad, la experiencia como programador no se mide en años, sino en problemas resueltos. Y en ese sentido, no he resuelto tantos problemas como me gustaría. He resuelto muchos problemas, y no me refiero a problemas de programación, sino a problemas de negocio, de la vida real, lo que realmente importa.
Pero en lo que se refiere a mi forma de programar, me siento como un principiante, incapaz de hacer todo lo bien que me gustaría. Y no me refiero a que no sepa programar siguiendo los estándares de Clean Code, arquitecturas, XP, y demás. Me refiero a la estructura base del código.
El código ejecutable, por regla general, tiene una estructura secuencial: primero hago una cosa, luego compruebo otra, llamo aquí, llamo allá y devuelvo un dato. Y así, una y otra vez. Y no me gusta.
¿Cómo me gustaría programar?
Lo que me gustaría es un tipo de programación descriptiva. Es decir, que el código describa lo que quiero hacer y no cómo hacerlo, y que el lenguaje de programación me permita hacerlo. Por poner un ejemplo, tenemos a los modelos de ActiveRecord de cualquier proyecto Ruby on Rails:
class User < ActiveRecord::Base
belongs_to :merchant
acts_as_token_authenticatable
before_save :skip_confirmation_for_users
after_create :send_instruction_email
# Include default devise modules. Others available are:
# :confirmable, :lockable, :timeoutable and :omniauthable
devise :database_authenticatable, :registerable,
:recoverable, :rememberable, :trackable, :validatable,
:confirmable, :lockable, :omniauthable, omniauth_providers: [:google_oauth2]
validates_acceptance_of :tos_agreement, allow_nil: false, on: :create
USER_ROLES = [:root, :admin, :user ]
enum role: USER_ROLES
Es un estilo de programación donde describes lo que quieres; no describes la secuencia para resolver el problema, solo cuál es el problema. Imagínate programar diciéndole al compilador: “Quiero un login de usuarios pidiendo correo y password, pregunta al usuario si quiere mantener la sesión abierta por un mes, guarda el último correo siempre y preséntalo al usuario cada vez que acceda al login, pregunta al usuario si quiere guardar de manera segura el password. Autentica con Google, si no funciona presenta un mensaje de error; si funciona, invoca la funcionalidad X003”.
Esto es lo que quiero. No es exactamente lo que propone Rails, pero es lo que más se le parece.
Lo curioso de esto es que quizás estemos llegando a este paradigma gracias a las actuales herramientas de generación de código por inteligencia artificial.
DSL
Otra opción es la creación de DSL (Domain Specific Languages) o lenguajes específico de dominio. Estos proyectos pretenden simplificar el uso de ciertas utilidades o funcionalidades que ofrecen los lenguajes de programación o plataformas de desarrollo.
Un ejemplo de esto sería el fichero de configuración del proyecto Fastlane. Para quien no lo conozca, Fastlane es un gestor de publicaciones, test y construcción de proyectos móviles. Ejecutas $ fastlane ios release y te sube versión al App Store Connect.
(Aunque no lo parezca, esto es lenguaje Ruby)
default_platform(:ios)
platform :ios do
desc "Push a new release build to the App Store"
lane :release do
build_app(scheme: "ListaCompra2")
upload_to_app_store
end
desc "Launch the project tests"
lane :tests do
run_tests(scheme: "ListaCompra2")
end
desc "Increment build number in current dir"
lane :increment do
increment_build_number(xcodeproj: "ListaCompra2.xcodeproj")
end
end
El problema de estos DSL es que suelen estar siempre limitados por su propio alcance, ofreciendo pocas capacidades de extensión y nunca ofrecen el total de la funcionalidad del entorno que pretende simplicar. Y peor aún es la cantidad de tiempo necesaria para mantener estos DSL, ya que suelen ser muy sensibles a los cambios de versión de las herramientas que los utilizan.