Books

# Object-Oriented Reengineering Patterns

[Este libro](https://www.amazon.es/Object-Oriented-Reengineering-Patterns-Engineering-Programming/dp/1558606394)
es una magnífica colección de heurísticos y estrategias para ayudarnos a
comprender un sistema de software complejo y ser eficaces a la hora de poder
evolucionarlo y mantenerlo.

Los últimos capítulos están dedicados a estrategias de diseño de software que
permitan extender un modelo ya existente, y son los únicos donde se hace
referencia a orientación a objetos. Personalmente, también son los que menos
valor me han aportado, quizás porque ya han sido desarrollados ampliamente en
otro libros
([Practical Object-Oriented Design](https://www.amazon.es/Practical-Object-Oriented-Design-Agile-Primer/dp/0134456475),
por poner un ejemplo).

Un libro muy interesante si te toca unirte a un proyecto ya en marcha o te
enfrentas a un cambio de trabajo, ya que independientemente del objetivo final
(reingeniería) sus consejos son muy útiles para poder entender bases de código
relativamente grandes, utilizando las herramientas y actores adecuados (que se
cubren en profundidad en la parte II: _Reverse Engineering_).

> A culture of continuous reengineering is a prerequisite for achieving ﬂexible
> and maintainable object-oriented systems.

- «_It is easy to get seduced by focussing on the technical problems that
  interest you the most, rather than what is best for the project._»
- «_Other engineering disciplines rely on the laws of nature to hide irrelevant
  details, but software engineering must build on less solid foundations.
  Consequently, it is essential to pay attention to the details. The only
  question is how to filter out those details that do not matter, because you
  cannot possible investigate everything._»
- «_Documentation is almost always out of date with respect to the actual
  situation. [...] Consequently, avoid to make important decisions based on
  documentation only —first verify your findings by other means (in particular,
  Read all the Code in One Hour and Interview During Demo)_»
- «_As a rule of the thumb, assume that a single team can reengineer as much
  code as they can write from scratch._»
- «_If you fail to deliver good initial results, you will learn a lot, but you
  risk losing credibility. It is therefore critical to choose carefully initial
  tasks which not only demonstrate value for the customer, but also have a high
  chance of success. Therefore, take great care in estimating the effort of the
  initial tasks._»
- «_Nevertheless, even outdated information may be useful, because at least it
  tells you how the system was supposed to behave in the past. This is a good
  starting point to infer how it is used today._»


📚 Object-Oriented Reengineering Patterns

# A Philosophy of Software Design

Durante las últimas semanas he estado leyendo este maravilloso libro escrito por
John Ousterhout y me gustaría compartir algunas conclusiones que he podido
extraer tras su lectura.

Lo primero, es que el libro me ha parecido un contrapunto muy interesante a
[_Clean Code_](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882).
Básicamente, ambos presentan estrategias para reducir la complejidad en el
diseño, desarrollo y mantenimiento de software (y la complejidad es un término
sobre el que se discute largo y tendido en
[_A Philosophy of Software Design_](https://www.amazon.com/Philosophy-Software-Design-John-Ousterhout/dp/1732102201))
pero lo hacen, bajo mi punto de vista, desde dos ópticas diferentes.

Robert C. Martin (y mucha de la literatura que hay por ahí fuera) pone el foco
especialmente en **reglas** y **principios**: tamaño de las entidades
(¡funciones de menos de 10 líneas!), el número de responsabilidades de una
abstracción, código sobre documentación, evitar duplicidades, etc. Sin embargo,
en _A Philosophy of Software Design_ nos encontramos un par de capítulos
dedicados en exclusiva al “arte” de escribir buenos comentarios y a las ventajas
de invertir tiempo en expresar, a través de los mismos, aspectos relacionados
con el diseño de software que son prácticamente imposibles de describir
utilizando únicamente código (por ejemplo, el conocimiento del dominio que nos
lleva a aplicar ciertos patrones o arquitecturas, _workarounds_ para lidiar con
_known issues_, etc).

De todos, el capítulo 10: _Define Errors Out Of Existence_, me ha parecido una
delicia, y creo que introduce conceptos muy interesantes para lidiar con los
casos esquina y errores de cualquier aplicación.

Del mismo modo, algunos pasajes hablando sobre la ventaja de definir
abstracciones “profundas” (_deep_) en lugar de “planas” (_shallow_) ilustran
bastante bien los problemas de llevar técnicas de _Clean Code_ al extremo, sin
aplicar un buen criterio.

Creo que la lectura de este libro me ha servido para adoptar un enfoque más
pragmático a la hora de escribir código, alejado de dogmatismos y poniendo el
foco en lo que realmente importa, tratar de reducir al máximo la complejidad de
nuestras soluciones (lo que implícitamente nos llevará también a la aplicación
de buenas prácticas de diseño).


📚 A Philosophy of Software Design

# The Nature of Software Development

> \[...\] If you’ve been involved in software development, you too have probably
> often felt that all this should be simple, but somehow it gets all
> complicated.
>
> — <cite>Ron Jeffries</cite>

Llevaba unos cuantos meses con ganas de poder leer el libro _The Nature of
Software Development_ de Ron Jeffries y, por fin, este enero, he dedicado unas
cuantas horas a poder estudiarlo, disfrutarlo y compartirlo con varias personas
del equipo y colegas de profesión.

Para quien no le conozca,
[Ron Jeffries](https://en.wikipedia.org/wiki/Ron_Jeffries) es uno de los
creadores de _Extreme Programming_, firmante del
[manifiesto Agile](http://agilemanifesto.org/) y un profesional con dilatada
experiencia en el desarrollo de software. Un breve vistazo al índice de
contenidos o al resumen de la contraportarda ya es suficiente para entender que
el libro, aunque no mencione explícitamente niguna metodología concreta (más
allá del _Natural Way_ del propio Jeffries), va a ofrecer una lectura amena y un
tanto filosófica sobre el desarrollo de software desde una óptica Agile. En lo
personal, encontré la visión del libro muy alineada con mi propio entendimiento
sobre cómo se deberían desarrollar productos y proyectos digitales.

A través de sus páginas, Jeffries no sólo habla del proceso de implementación
(del que, realmente, apenas menciona más que la búsqueda constante de la
excelencia técnica y los beneficios de aplicar _Refactoring_ de manera regular),
sino que gran parte del libro está centrado en la própia definición de _valor_
(«lo que necesitas», en palabras del autor) y cómo se puede identificar y
alcanzar lo más rápido posible a través de la construcción de equipos de alto
rendimiento que tengan maestría en técnicas de entrega continua de valor,
_planning_ y _slicing_ de funcionalidades y capacidad para ejecutar y entregar
productos donde la calidad sea una máxima no negociable.

Como imagináis, construir un equipo de estas características requiere de
perfiles multidisciplinares donde personas de negocio y desarrollo trabajen codo
con codo compartiendo una filosofía común.

Sin duda, si trabajáis en una empresa de software (a cualquier nivel), este se
trata de un libro imprescindible.


Collection: Books

2020

2019

Browse all collections