Um documento de descrição da arquitetura é uma violação do princípio DRY?

11

O princípio DRY (não se repita) afirma que "todo conhecimento deve ter uma representação única, inequívoca e autorizada dentro de um sistema". Na maioria das vezes, isso se refere ao código, mas também é estendido à documentação.

Dizem que todo sistema de software possui uma arquitetura, independentemente de você ter escolhido ou não. Em outras palavras, o software que você constrói possui uma estrutura e essa estrutura "como construída" é a arquitetura do software. Como um sistema de software incorporado vem com uma arquitetura, a criação de uma descrição da arquitetura desse sistema é uma violação do Princípio DRY? Afinal, se você precisa conhecer a arquitetura, pode sempre olhar o código ...

— Michael
fonte

Você realmente acredita que pode discernir a arquitetura olhando o código? O código informará todos os requisitos funcionais e não funcionais, as compensações arquitetônicas, os problemas de implantação, o contexto comercial, os cenários de casos de uso, etc, etc? Se você codificar realmente pode lhe dizer isso, esse é um sistema trivial.

— Luis.espinal 12/10/10

@ luis.espinal, É possível discernir estruturas estáticas e dinâmicas do código e do sistema em execução, respectivamente. Se essas estruturas são equivalentes à arquitetura de um sistema dependerá da sua escola de pensamento. Como você apontou, ainda falta alguns grandes blocos, incluindo drivers de arquitetura e justificativa por trás das decisões de design.

— Michael

Que verdadeira escola de pensamento iguala estruturas derivadas de código à arquitetura de um sistema? Se soubermos que sentiremos falta de alguns grandes blocos, incluindo quaisquer drivers de arquitetura, estaremos perdendo toda a arquitetura. Isso prova trivialmente que as estruturas estáticas e dinâmicas que podem ser discernidas apenas a partir do código não representam toda a arquitetura (independentemente da escola de pensamento). Se observarmos definições bem estabelecidas de sistemas e arquitetura de software (por exemplo, SEI's INCOSE), eles são claros em que o código é apenas uma fração de uma arquitetura.

— Luis.espinal 13/10/10

caso em questão. A arquitetura de um sistema pode exigir que eu implante em um número específico de máquinas, com interfaces externas sendo desativadas e ativadas em uma ordem específica. Estruturas estáticas e dinâmicas derivadas apenas do código dificilmente capturam isso (se é que existem.) Claramente, porém, elas fazem parte dos aspectos operacionais e de implantação de uma arquitetura de sistema. E qualquer estrutura derivada de código pertencerá apenas à realização de aspectos estáticos de uma arquitetura de aplicativo (ou componente) de software . Nunca pode ser para uma arquitetura de sistemas .

— Luis.espinal 13/10/10

1

@ luis.espinal, convido você a enviar uma resposta a esta pergunta! Parece que você traz uma excelente perspectiva que acho que agregaria algum valor real a esse tópico. Você está pregando ao coral sobre isso, então por que não criar uma resposta que explique completamente seu pensamento para que todos possam se beneficiar? É por isso que fiz a pergunta em primeiro lugar.

— Michael

11

A duplicação de seus pensamentos no código viola o princípio DRY?

Nossa, se você pudesse conhecer a arquitetura olhando para o código, não haveria "documentos de descrição da arquitetura" em primeiro lugar. Não é uma repetição, é outro nível de descrição do sistema , que não pode ser deduzido trivialmente do código e vice-versa. Portanto, ele tem todo o direito de existir, mesmo que você adote o DRY.

— P Shved
fonte

7

Não tome DRY como uma regra rígida e rápida. É uma coisa boa, mas você só pode aproximar isso na prática.

Também acho que não está bem escrito. "Não se repita" não parece cobrir o caso igualmente importante de que, para fazer uma mudança semântica ou funcional, você teria que editar o texto-fonte em vários lugares, dizendo coisas diferentes, mas coordenadas.

Em vez de tomar como mandamento não ser violado, é melhor entender por que é uma boa ideia e fazer escolhas sensatas a respeito. A razão pela qual é ruim ter que fazer edições coordenadas em vários lugares é que você, o editor, comete erros. Você não é 100% confiável para fazer as alterações sem erros. Se você tiver que fazer 10 alterações diferentes no texto de origem e conseguir apenas 9 delas corretamente, você corrigiu . É por isso que é bom organizar o texto de origem para minimizar o número de alterações coordenadas. Minimiza erros.

Nós não pertencemos a uma religião em que DRY é um dos mandamentos. É apenas uma maneira prática, embora um pouco enganadora, de encapsular algum senso comum.

— Mike Dunlavey
fonte

4

Uma Arquitetura Descrição, ou Design de Software Descrição faz violar DRY. No entanto, em uma organização grande, onde os projetos duram anos, os desenvolvedores vêm e vão, e o sistema é muito grande para qualquer pessoa manter todos os detalhes em mente, é um documento crítico. A quantidade de "repetição" necessária para mantê-lo sincronizado vale totalmente a pena pelo esforço que economiza durante a próxima atualização ou manutenção.

— AShelly
fonte

1

Essa é uma incompreensão ou aplicação cega do DRY. Uma descrição arquitetônica não é uma violação dela. Se alguém aplicar cegamente o DRY dessa maneira, qualquer coisa, exceto o código, é uma violação dele ... e, claramente, essa não era a intenção daqueles que tiveram a ideia dele.

— Luis.espinal

2

Uma descrição da arquitetura não viola o princípio DRY.

Seu sistema de software vem com uma arquitetura, com certeza. E está espalhado por muitos arquivos, em muitas classes, com muitos detalhes estranhos e desnecessários para uma visão geral.

Seu documento de arquitetura deve ser como o primeiro parágrafo de uma reportagem: é um esboço, um resumo, um roteiro do projeto.

— Frank Shearar
fonte

1

Se você datar o documento, ele descreverá a arquitetura no momento da redação.

Considerando que o código representa a arquitetura no momento presente.

Duas coisas separadas - não o mesmo conhecimento.

Contanto que você declare que o documento representa a arquitetura no momento da redação, você não está duplicando o IMO do conhecimento, porque seu conhecimento é diferente sobre o sistema em outro momento.

— Ninguém
fonte

Código nunca representa arquitetura. É apenas uma manifestação da arquitetura. O código que foi alterado hoje ainda pode representar a arquitetura de ontem. Além disso, pode não representar a arquitetura pretendida (ou contratualmente requerida), que é o que você mais precisa se preocupar. O código não informa se está certo ou errado, apenas que é executado. Para saber se está certo ou errado, é necessário examinar a arquitetura pretendida e os requisitos que impulsionaram o sistema.

— Luis.espinal