Trade-off: a única medida razoável

Engenharia de software envolve decisões. Decisões sobre organização, decisões sobre processos e, principalmente, decisões sobre tecnologia. No caso dessas últimas,  as opções em cada nível costumam ser muitas, desde a escolha do sistema operacional até a escolha da plataforma de hospedagem, passando por linguagens de programação (ou mais precisamente línguas, em homenagem ao meu colega Evandro), frameworks, tipos de armazenamento de dados, entre outras coisas.

Nesse cenário, discutir cada opção torna-se extremamente valioso. Mas pode tornar-se também um mero exercício de reforço de preferências pessoais, dependendo da postura das pessoas envolvidas. Aliás, é bastante comum entrarmos numa reunião desse tipo e constatarmos que ela rapidamente começa a se assemelhar mais a um jogo de futebol, com cada um torcendo apaixonadamente pela vitória da sua tecnologia preferida, do que a uma avaliação científica e imparcial, como deveria ser.

Ter preferências é absolutamente normal, não se pode impedir que cada um se sinta mais confortável usando determinada tecnologia em lugar de outras. O problema começa quando essa inclinação pessoal interfere a tal ponto que o engenheiro ou desenvolvedor não consegue perceber os pontos fracos daquilo que gosta e defende. Consequentemente, ele passa também a não conseguir apreciar os pontos fortes de outras abordagens. Por fim, essa postura culmina numa incapacidade de discernir quando e como aplicar cada tecnologia a favor do objetivo do projeto. Com isso, o indivíduo acredita plenamente que as tecnologias de sua preferência servem para resolver qualquer problema, não importa as circunstâncias. Da mesma forma, menospreza todas as outras propostas, sem se dar ao trabalho de refletir a respeito. É nessas horas que ouvimos frases como "Pra quê discutir sobre isso? Basta usar X e pronto, está resolvido!" ou "Usar Y? Jamais!".

Recentemente, conversando o Myhro, meu colega de trabalho, sobre esse assunto, ouvi dele um comentário que sintetiza bem a minha opinião a respeito: em se tratando de escolha de tecnologias, o trade-off é a única medida razoável. Em outras palavras, não importa o quanto você goste de X ou Y, na hora de tomar decisões sobre qual tecnologia usar, é preciso recorrer à boa e velha lista de prós e contras, levando sempre em conta o resultado que deve ser atingido. Essa é a postura analítica e científica que se espera de todo bom profissional da área de computação.

Think about behavior, not data

Databases are implementation details! Considering the database should be deferred as long as possible. Far too many applications are inextricably tied to their databases because they were designed with the database in mind from the beginning. Remember the definition of abstraction: the amplification of the essential and the elimination of the irrelevant.

Robert C. Martin, "The Payroll Case Study: Iteration One Begins", in Agile
Software Development: Principles, Patterns, and Practices, 194.

The point is that, as far as the application is concerned, databases are simply mechanisms for managing storage. They should usually not not be considered as a major factor of the design and implementation. As we have shown here, they can be left for last and handled as a detail. By doing so, we leave open a number of interesting options for implementing the needed persistence and for creating mechanisms to test the rest of the application. We also do not tie ourselves to any particular database technology or product. We have the freedom to choose the database we need, based upon the rest of the design, and we maintain the freedom to change or replace that database product in the future as needed.

Sometimes the nature of the database is one of the requirements of the application. RDBMSs provide powerful query and reporting systems that may be listed as application requirements. However, even when such requirements are explicit, the designers should still decouple the application design from the database design. The application design should not have to depend on any particular kind of database.

Robert C. Martin, "The Payroll Case Study: Implementation", in Agile
Software Development: Principles, Patterns, and Practices, 249.

Compromise, perfection and the Liskov Substitution Principle

There are rare occasions when it is more expedient to accept a subtle flaw in polymorphic behavior than to attempt to manipulate the design into complete LSP compliance. Accepting compromise instead of pursuing perfection is an engineering trade-off. A good engineer learns when compromise is more profitable than perfection. However, conformance to the LSP should not be surrendered lightly. The guarantee that a subclass will always work where its base classes are used is a powerful way to manage complexity. Once it is forsaken, we must consider each subclass individually.

Robert C. Martin, "LSP: The Liskov Substitution Principle", in Agile Software
Development: Principles, Patterns, and Practices, 122.