Sinopsis Editorial:

As the application of object technology–particularly the Java programming language–has become commonplace, a new problem has emerged to confront the software development community. Significant numbers of poorly designed programs have been created by less-experienced developers, resulting in applications that are inefficient and hard to maintain and extend. Increasingly, software system professionals are discovering just how difficult it is to work with these inherited, “non-optimal” applications. For several years, expert-level object programmers have employed a growing collection of techniques to improve the structural integrity and performance of such existing software programs. Referred to as “refactoring,” these practices have remained in the domain of experts because no attempt has been made to transcribe the lore into a form that all developers could use. . .until now. In Refactoring: Improving the Design of Existing Code, renowned object technology mentor Martin Fowler breaks new ground, demystifying these master practices and demonstrating how software practitioners can realize the significant benefits of this new process.

 

With proper training a skilled system designer can take a bad design and rework it into well-designed, robust code. In this book, Martin Fowler shows you where opportunities for refactoring typically can be found, and how to go about reworking a bad design into a good one. Each refactoring step is simple–seemingly too simple to be worth doing. Refactoring may involve moving a field from one class to another, or pulling some code out of a method to turn it into its own method, or even pushing some code up or down a hierarchy. While these individual steps may seem elementary, the cumulative effect of such small changes can radically improve the design. Refactoring is a proven way to prevent software decay.

 

In addition to discussing the various techniques of refactoring, the author provides a detailed catalog of more than seventy proven refactorings with helpful pointers that teach you when to apply them; step-by-step instructions for applying each refactoring; and an example illustrating how the refactoring works. The illustrative examples are written in Java, but the ideas are applicable to any object-oriented programming language.

El mero hecho de querer leer este libro o de haberlo leído ya te identifica como un profesional con unas inquietudes superiores a la media. Este libro es para mejorar tu código, para aprender a reescribir tu código para que sea más mantenible, más comprensible, más coherente y cohesionado. Habla de refactorizar, es decir, reescribir tu código para conseguir lo anterior sin añadir, cambiar o eliminar ninguna funcionalidad existente.

Martin Fowler es una de las personalidades actuales en el campo de la ingeniería del software, un profesional que sienta cátedra con cada uno de sus escritos. Su página web es digna de leerse de principio a fin. Quizás este libro no destaque especialmente por su complejidad o profundidad, es un libro de buenas prácticas, de consejos para reescribir el código, sin embargo el nivel de profundidad al que llega es digno de agradecer.

Valoración: IMPRESCINDIBLE

Una de las habilidades más importantes con la que debe contar todo desarrollador de software es saber escribir código que otros puedan entender, incluso que uno mismo sea capaz de entender meses después de escribirlo. Después de unos años trabajando en esto, he leído mucho código y podría decir que el nivel medio es mediocre, incluso bajo me atrevería a decir; por suerte, hay excepciones. Probablemente, yo no sea el mejor ejemplo, pero sí que me preocupo por mejorar esta carencia y me alegra reconocer que hoy escribo mejor código que ayer.

Clean Code: A Handbook of Agile Software Craftsmanship debe ser uno de esos libros que debes comprar cuando acabes la carrera, o cuando empieces a trabajar. Intenta introducirte lo antes posible en el desempeño de buenas prácticas, incorpóralas a tus hábitos de trabajo e intenta convencer al resto del equipo para que las adopte. Intenta comprender porqué es mejor hacer algo de una forma que de otra, así dispondrás de argumentos que defiendan objetivamente un cambio y darás pie a un coloquio del que todos saldréis ganando, todos.

Este libro se divide en 17 capítulos y 3 apéndices. Cada capítulo habla de un aspecto muy concreto, exponiendo los principales errores y su solución más adecuada. Aunque algunos capítulos puedan dar la sensación, a priori, de poco interesantes por su trivialidad, nada más lejos de la realidad. No juzgues nada antes de conocerlo. Aspectos, tan poco tenidos en cuenta, como los comentarios, los nombres o el formato son examinados al detalle, así como otros más habituales: funciones, clases, excepciones o tests. Si eres un desarrollador experimentado reconocerás, en mayor o menor medida, las casuísticas que describe el libro, ello no quita que sirva como refresco de conocimientos.

Valoración: LECTURA OBLIGATORIA

Una parte fundamental dentro de la especificación OSGi es el conjunto de metadatos que deben ser situados en el fichero MANIFEST.MF y que permitirán a la implementanción OSGi instalar el bundle dentro del entorno de ejecución, resolver sus dependencias y publicar todo aquello que queramos sea visto por otros bundles.

Me voy a basar en el documento que define la especificación OSGi 4.1 para listar todas las cabeceras disponibles actualmente, su finalidad y sus características.

La lista de cabeceras, por orden alfabético, es la siguiente:

• Bundle-ActivationPolicy
• Bundle-Activator
• Bundle-Category
• Bundle-Classpath
• Bundle-ContactAddress
• Bundle-Copyright
• Bundle-Description
• Bundle-DocURL
• Bundle-Localization
• Bundle-ManifestVersion
• Bundle-Name
• Bundle-NativeCode
• Bundle-RequiredExecutionEnvironment
• Bundle-SymbolicName
• Bundle-UpdateLocation
• Bundle-Vendor
• Bundle-Version
• DynamicImport-Package
• Export-Package
• Export-Service
• Fragment-Host
• Import-Package
• Import-Service
• Require-Bundle

Bundle-ActivationPolicy
Especifica como el framework debe activar el bundle. Si debe hacerlo de forma normal cuando arranca el framework o de forma perezosa, no se activará hasta que no sea cargada una clase.
Valores permitidos : lazy
Valor por defecto : ninguno. Si no se incluye esta cabecera se activará el bundle al arranque del framework.
Ejemplo

Bundle-ActivationPolicy : lazy

Bundle-Activator
Nombre de la clase usada para arrancar y parar el bundle. La clase debe implementar la interfaz BundleActivator.
Ejemplo

Bundle-Activator : es.jmac.osgi.infrastructure.Activator

Bundle-Category
Lista de nombres de categoría, separadas por comas.
Valores permitidos : libre, valores separados por comas. OSGi recomienda utilizar los valores de una lista predefinida.
Valor por defecto : ninguno. Si no se incluye esta cabecera se activará el bundleal arranque del framework.
Ejemplo

Bundle-Category : example, device, testing

Bundle-Classpath
Define un lista, separada por comas, de rutas de ficheros JAR y directorios (dentro del bundle) con las clases y recursos del bundle. El “.” especifica el directorio raiz del JAR del bundle.
Valor por defecto : .
Ejemplo

Bundle-Classpath : lib/commons-logging-1.1.1.jar, . , resources/html

Bundle-ContactAddress
Dirección de contacto del proveedor.

Bundle-Copyright
Especificación de copyright y licencia para el bundle.

Bundle-Description
Descripción corta del bundle.

Bundle-DocURL
URL con la documentación del bundle.

Bundle-Localization
Esta cabecera debe contener el fichero base dentro del bundleque defines las información multi-idioma.
Valor por defecto : OSGI-INF/l10n/bundle
Esta ruta la resuelve el framework como OSGI-INF/l10n/bundle.properties, por tanto cada fichero de idioma debe tener el siguiente nombre : bundle_es.properties, bundle_de.propertie
Ejemplo

Bundle-Localization : resources/labels

Bundle-ManifestVersion
Define que versión de la especificación OSGi debe seguir el bundle.
La versión 1 del Manifest es para la release 3.
La versión 2 es para la release 4, la actual.
Valor por defecto : 1
Ejemplo

Bundle-ManifestVersion : 2

Bundle-Name
Nombre corto para el bundle. Puede contener espacios.
Ejemplo

Bundle-Name : Pruebas OSGi

Bundle-NativeCode
Esta cabecera contiene una especificación de las librerías de código nativo contenidas en el bundle.
Ejemplo

Bundle-NativeCode : /lib/http.DLL; osname = QNX; osversion = 3.1

Bundle-RequiredExecutionEnvironment
Contiene una lista, separada por comas, de los entornos de ejecución que deben estar presentes en la Plataforma de Servicio.
Ejemplo

Bundle-RequiredExecutionEnvironment : CDC-1.0/Foundation-1.0

Bundle-SymbolicName
Especifica un nombre único, dentro de la VM, para el bundle. El nombre debería seguir la convención de dominio inverso. Esta cabecera es obligatoria.
Ejemplo

Bundle-SymbolicName : es.jmac.osgi.infrastructure

Bundle-UpdateLocation
Especifica la URL a partir de la cual se recuperarán las actualizaciones para el bundle. Si el bundle es actualizado, esta ruta debería ser usada si está presente, para recuperar el fichero JAR actualizado.
Ejemplo

Bundle-UpdateLocation : https://justoaguilar.com/repo/osgi

Bundle-Vendor
Descripción del proveedor del bundle.
Ejemplo

Bundle-Vendor : Justo Aguilar

Bundle-Version
Especifica la versión del bundle. La versión debe seguir obligatoriamente el formato :

version ::=
major( '.' minor ( '.' micro ( '.' qualifier )? )? )?
major ::= number // See 1.3.2
minor ::= number
micro ::= number
qualifier ::= ( alphanum | ’_’ | '-' )+

Valor por defecto : 0.0.0
Ejemplo

Bundle-Version : 1.0.1.Built20090801-143221

DynamicImport-Package
Esta cabecera contiene una lista, separada por comas, de nombres de paquetes que deberían ser dinámicamente importados cuando se necesiten.
Ejemplo

DynamicImport-Package : es.jmac.osgi.*

Export-Package
Contiene la declaración de los paquetes a exportar.
Ejemplo

Export-Package : !es.jmac.osgi.infrastructure, es.jmac.osgi

Export-Service
Obsoleto. (Deprecated)

Fragment-Host
Define el bundle maestro para este fragmento.
Ejemplo

Fragment-Host : es.jmac.osgi.infrastructure;version="[1.0.0,2.0.0)"

Import-Package
Especifica los paquetes a importar por este bundle.
Ejemplo

Export-Package : !es.jmac.osgi.infrastructure, es.jmac.osgi

Import-Service
Obsoleto. (Deprecated)

Require-Bundle
Especifica la lista de bundles (paquetes) obligatorios a utilizar en este bundle.
Ejemplo

Require-Bundle : org.apache.commons.logging;version="1.1.1",org.springframework.context;version="(2.0.0,3.0.0)"