Para desenvolvermos software, devemos entender toda uma ideia de um problema que é exposto, nos levando, então, a pensar em como construir uma solução para ele.

Antes de escrevermos qualquer linha de código, devemos ser capazes de expressar qualquer solução de software através de outras formas, sejam pequenos textos, diagramas ou desenhos.

Conseguir expressar o problema e a solução de tais maneiras para um cliente ou para um time torna a reunião mais rica em termos de informações que podem ser obtidas. Explorar formas de como buscar o melhor entendimento de um problema e de sua solução torna o conhecimento mais profundo e agrega valor à parte mais sensível de toda solução, o código.

Digo sensível pelo fato de estar no código todo o conhecimento obtido junto aos profissionais do domínio.

Quanto melhor entender o domínio ou subdomínio que se está trabalhando, mais claro e expressivo o código pode se tornar. A essência desse bom entendimento pode e deve ser expressa na solução que está sendo criada. Autores como Robert C. Martin (Código Limpo) e Eric Evans (Domain Driven Design) abordam assuntos interessantes em torno da escrita de um bom código, e de como se levar o conhecimento obtido junto a profissionais de domínio para dentro do software.

Um dos pontos mais interessantes para se pensar é como o software pode ser bem desenvolvido quando o bom entendimento de um requisito se torna capaz de expressar uma solução de código extremamente clara e condizente com seu domínio e objetivo.

A arquitetura e o código de um software são peças fundamentais para sua qualidade. Quando abstraído o bom entendimento do problema, o seu reflexo pode ser observado nas formas como podem ser expressas as soluções. É natural que nos primeiros momentos os pensamentos para uma solução não sejam os melhores, mas nem devem, pois nem o conhecimento adquirido em torno da ideia é maduro o bastante ainda. Quanto mais entender o domínio que se está desenvolvendo, mais claras passarão a ser as soluções para ele, e quando sentir que há um conhecimento a mais, e que esse conhecimento é capaz de simplificar alguma parte de seu código, então, refatore.

A qualidade do software não se diz respeito somente a enquanto se desenvolve seu código. Devemos ter uma preocupação ainda maior com o fato de como vamos manter esse código depois que ele for colocado em produção. Software segue um modelo de negócio e, se uma hora esse modelo de negócio mudar, o código deverá mudar para se adequar ao novo modelo. Logo, temos mais uma visão da importância de criarmos soluções de softwares que expressam o conhecimento de um dado domínio de forma simplificada, ou, ao menos, bem organizada.

A organização e a simplicidade da estrutura de seu código irão derivar do entendimento do requisito proposto – quanto melhor for o entendimento, mais simples e organizado se tornam os pensamentos em torno da solução. Quanto mais simples e organizado um projeto de software for, mais baixo será o seu custo com manutenção, e mais fácil será fazê-lo crescer e moldá-lo para novas necessidades, mantendo assim a qualidade esperada para o software.