Existe um paradigma de programação que promove tornar as dependências extremamente óbvias para outros programadores?

Trabalho em um Data Warehouse que origina vários sistemas através de muitos fluxos e camadas com dependências semelhantes a labirintos que vinculam vários artefatos. Praticamente todos os dias eu me deparo com situações como essa: eu corro algo, não funciona, passo por um monte de código, mas horas depois percebo que consegui conceituar o mapa do processo de uma pequena parte do que agora sei mais tarde, é necessário, portanto, pergunto a alguém e eles me dizem que esse outro fluxo deve ser executado primeiro e que, se eu verifiquei aqui (indicando alguma parte aparentemente arbitrária de uma pilha enorme de outras dependências codificadas), eu teria visto isso. É incrivelmente frustrante.

Se eu pudesse sugerir à equipe que talvez fosse uma boa idéia fazer mais para tornar as dependências entre os objetos mais visíveis e óbvias, em vez de incorporá-las profundamente em níveis recursivos de código ou mesmo nos dados que precisa estar presente devido ao fato de ser preenchido por outro fluxo, talvez referindo-se a um paradigma de software conhecido, experimentado e testado - para que eu possa tornar meu trabalho e todos os demais muito mais simples.

É meio difícil explicar os benefícios disso para minha equipe. Eles tendem a aceitar as coisas do jeito que são e não 'pensam grande' em termos de ver os benefícios de poder conceituar todo o sistema de uma nova maneira - eles realmente não vêem isso se você puder modelar um sistema enorme com eficiência, torna menos provável que você encontre ineficiências de memória, interrompa o fluxo de restrições exclusivas e chaves duplicadas, dados sem sentido, porque é muito mais fácil projetá-lo de acordo com a visão original e você não encontrará mais tarde todos esses problemas que agora estamos experimentando, o que eu sei ser incomum em empregos passados, mas que eles parecem pensar como inevitável.

Então, alguém conhece um paradigma de software que enfatiza dependências e também promove um modelo conceitual comum de um sistema, com o objetivo de garantir a adesão a longo prazo a um ideal? No momento, praticamente temos uma bagunça gigante e a solução que todo sprint parece ser "apenas adicione algo aqui e aqui e aqui" e eu sou o único preocupado com o fato de as coisas realmente começarem a desmoronar.

Descoberta

Sua ausência atormenta muitas organizações. Onde está a ferramenta que Fred construiu novamente? No repositório Git, com certeza. Onde?

O padrão de software que vem à mente é Model-View-ViewModel. Para os não iniciados, esse padrão é um completo mistério. Expliquei a minha esposa como "cinco widgets flutuando acima da mesa conversando entre si por alguma força misteriosa". Entenda o padrão e você entende o software.

Muitos sistemas de software falham em documentar sua arquitetura porque eles assumem que ela é auto-explicativa ou emerge naturalmente do código. Não é, e não é. A menos que você esteja usando uma arquitetura bem definida, novas pessoas se perderão. Se não estiver documentado (ou conhecido), novas pessoas se perderão. E os veteranos também se perderão, depois de ficarem longe do código por alguns meses.

É responsabilidade da equipe criar uma arquitetura organizacional sensata e documentá-la. Isso inclui coisas como

• Organização da pasta
• Referências do projeto
• Documentação de classe (o que é, o que faz, por que existe, como é usado)
• Projeto, módulo, montagem, qualquer documentação.

É responsabilidade da equipe tornar as coisas organizadas e descobertas para que a equipe não reinvente constantemente a roda.

A propósito, a noção de que "o código deve ser auto-documentado" está apenas parcialmente correta. Embora seja verdade que seu código deve ser claro o suficiente para que você não precise explicar cada linha de código com um comentário, os relacionamentos entre artefatos como classes, projetos, montagens, interfaces e similares são não óbvios e ainda assim precisa ser documentado.

A melhor maneira de abordar esses tipos de problemas é incrementalmente. Não fique frustrado e proponha mudanças arquitetônicas amplas e abrangentes. Essas nunca serão aprovadas e o código nunca melhorará. Isso pressupõe que você possa determinar as mudanças arquitetônicas amplas e abrangentes corretas a serem feitas, o que é improvável.

O que é provável é que você pode determinar uma mudança menor que teria ajudado com o problema específico que você acabou de resolver. Talvez invertendo algumas dependências, acrescentando alguma documentação, criando uma interface, escrevendo um script que avisa de uma dependência em falta, etc. Então, proponho que a mudança menor em seu lugar. Ainda melhor, dependendo da cultura da sua empresa, eles podem tolerar ou até esperar que você faça melhorias como essa como parte de sua tarefa original.

Quando você faz essas alterações menores uma parte regular do seu trabalho e, pelo seu exemplo, incentiva outras pessoas a fazerem isso, elas realmente aumentam com o tempo. Muito mais eficaz do que reclamar de mudanças maiores que você não tem permissão para fazer.

Arquitetura.

Não existe um princípio ou prática único, específico e universal que resolva os problemas de descoberta e manutenção que se aplicam a todos os aspectos de todo software. Mas, o termo amplo para as coisas que tornam um projeto são é arquitetura.

Sua arquitetura é todo o corpo de decisões em torno de cada ponto de confusão potencial (ou histórica) - incluindo a designação de como as decisões arquitetônicas são tomadas e documentadas. Tudo relacionado ao processo de desenvolvimento, estrutura de pastas, qualidade do código, padrões de design etc. são coisas que podem entrar na sua arquitetura, mas nenhuma delas é uma arquitetura.

Idealmente, essas regras são unificadas por uma singularidade da mente.

Uma equipe pequena certamente pode criar arquitetura de forma colaborativa. Mas, com opiniões variadas, isso pode levar rapidamente a uma arquitetura muito esquizofrênica que não serve para manter sua sanidade. A maneira mais simples de garantir que sua arquitetura, e os muitos TLAs e padrões nela, sirvam ao sucesso da equipe com uma singularidade de mente é tornar uma única mente responsável por eles.

Agora, isso não requer necessariamente um "arquiteto" para pontificar . E, embora algumas equipes possam querer que uma pessoa experiente tome essas decisões, o ponto principal é que alguém precisa possuir a arquitetura, especialmente à medida que a equipe cresce. Alguém mantém o dedo no pulso da equipe, modera discussões arquitetônicas, documenta decisões e monitora decisões e trabalha no futuro para conformidade com a arquitetura e seu espírito.

Eu não sou um grande fã de qualquer pessoa tomando todas as decisões; mas identificar um "arquiteto" ou "proprietário técnico do produto", responsável por moderar as discussões sobre arquitetura e documentar decisões, combate um mal maior: a difusão da responsabilidade que não leva a nenhuma arquitetura discernível.

Bem-vindo à engenharia de software (nos dois sentidos);) Essa é uma boa pergunta, mas realmente não há respostas fáceis, como tenho certeza de que você está ciente. É realmente um caso de evoluir para melhores práticas ao longo do tempo, treinando as pessoas para serem mais hábeis (por definição, a maioria das pessoas na indústria tem competência medíocre) ...

A engenharia de software como disciplina sofre por construí-la primeiro e projetar a mentalidade conforme o uso, parte por conveniência e parte por necessidade. É apenas a natureza da besta. E, é claro, os hacks são construídos com o passar do tempo, à medida que os codificadores mencionados anteriormente implementam soluções funcionais rapidamente que resolvem as necessidades de curto prazo, muitas vezes à custa da introdução de dívidas técnicas.

O paradigma que você precisa usar é essencialmente melhorar as pessoas, treinar as pessoas que você tem bem e enfatizar a importância de dedicar tempo ao planejamento e à arquitetura. Não se pode facilmente ser tão "ágil" quando se trabalha com um sistema monolítico. Pode ser necessário um planejamento considerável para implementar até pequenas mudanças. A implantação de um excelente processo de documentação de alto nível também ajudará as pessoas-chave a entender o código mais rapidamente.

As idéias nas quais você poderia se concentrar seriam (com o tempo, gradualmente) isolar e refatorar partes-chave do sistema de uma maneira que as torne mais modulares e dissociadas, legíveis e mantidas. O truque é trabalhar para atender aos requisitos comerciais existentes, para que a redução da dívida técnica possa ser feita simultaneamente com a entrega de valor comercial visível. Portanto, a solução é parte de melhorar práticas e habilidades e parte de tentar avançar mais em direção ao pensamento arquitetônico de longo prazo, como posso dizer que você já o é.

Observe que eu respondi a essa pergunta da perspectiva da metodologia de desenvolvimento de software, e não da perspectiva da técnica de codificação, porque esse é realmente um problema muito maior que os detalhes da codificação ou mesmo do estilo arquitetural. É realmente uma questão de como você planeja a mudança.

Gosto da ideia de convenções de RobertHarvey e acho que elas ajudam. Eu também gosto da idéia de @ KarlBielefeldt de "documentar conforme você avança" e sei que isso é essencial, porque essa é a única maneira de manter a documentação atualizada. Mas acho que a ideia abrangente é que é importante documentar como encontrar todas as partes do seu código, compilar e implantá-las!

Recentemente, enviei um e-mail para um projeto de código-fonte aberto significativo que tinha alguma configuração XML que gerava código totalmente sem documentos. Perguntei ao mantenedor: "Onde está documentado esse processo de geração de código XML? Onde está documentada a instalação do banco de dados de teste?" e ele disse: "Não é". É basicamente um projeto de colaborador único e agora eu sei o porquê.

Olha, se você é essa pessoa e está lendo isso, eu realmente aprecio o que você está fazendo. Eu praticamente adoro os frutos de seus trabalhos! Mas se você passou uma hora documentando como suas coisas realmente criativas são reunidas, eu poderia passar alguns dias codificando novos recursos que poderiam ajudá-lo. Quando confrontados com a parede de tijolos da "falta de documentação não é um problema", eu nem vou tentar.

Em uma empresa, a falta de documentação é um enorme desperdício de tempo e energia. Projetos como esse costumam ser direcionados a consultores que custam ainda mais, apenas para descobrir coisas básicas como "onde estão todas as peças e como elas se encaixam".

Em conclusão

O que é necessário não é tanto uma tecnologia ou metodologia, mas uma mudança de cultura; uma crença compartilhada de que documentar como as coisas são construídas e por que é importante. Deveria fazer parte das revisões de código, um requisito para mudar para a produção, vinculado a aumentos. Quando todos acreditam nisso e agem de acordo, as coisas mudam. Caso contrário, será como minha falha na contribuição de código aberto.

Para responder à pergunta como ela é colocada (em vez de aconselhá-lo para sua situação específica):

O paradigma de programação conhecido como programação funcional pura requer que tudo que afeta a saída de uma função seja especificado nos parâmetros de entrada. Não há dependências ocultas ou variáveis ​​globais ou outras forças misteriosas agindo invisivelmente na base de código. Não há "você precisa fazer isso primeiro" acoplamento temporal.

Cada armazém de dados é diferente, mas há muito o que você pode fazer para facilitar as coisas para si.

Para começar, cada linha no banco de dados tinha um DATE_ADDED e DATA_UPDATED coluna para que pudéssemos ver quando ele foi adicionado ao banco de dados e quando foi alterado. Também tínhamos uma coluna SOURCE_CODE para poder rastrear onde cada bit de dados entrava no sistema.

Em seguida, tínhamos ferramentas comuns que funcionavam em todos os nossos data warehouses, como classificações, correspondências de tabelas, segmentações e segmentações, etc.

O código sob medida foi mantido no mínimo absoluto e, mesmo assim, ele teve que confirmar vários estilos de codificação e relatório.

Eu vou assumir que você já está familiarizado com as suítes ETL . Hoje em dia, existem muitas funcionalidades que você obtém de graça que não estavam presentes quando eu estava no jogo cerca de uma década atrás.

Você também pode consultar os data marts para apresentar uma versão mais amigável e higienizada do seu data warehouse. Obviamente, não é uma bala de prata, mas poderia ajudar com certos problemas, em vez de ter que reconstruir / corrigir seu data warehouse.

Não sei o quanto é relevante para o seu caso, existem algumas estratégias para tornar as dependências mais visíveis e a manutenção geral de códigos.

• Evite variáveis ​​globais, use parâmetros. Isso também se aplica a chamadas em vários idiomas.
• Evite alterar / alterar os valores das variáveis, tanto quanto possível. Faça uma nova variável e use, quando precisar alterar o valor, se possível.
• Faça o código modular. Se não for possível descrever o que a parte (não como) está realmente fazendo em uma frase simples, divida-a em módulos que satisfaçam a condição.
• Nomeie as partes do código corretamente. Quando você pode realmente descrever o que uma parte do código está fazendo em termos simples, esses termos se tornam o nome da parte. Assim, o código se torna auto-documentado por meio de nomes de módulos / classes / funções / procedimentos / métodos etc.
• Teste seu código. Teste se as entidades no seu código justificam seus nomes, discutidas no ponto anterior.
• Registre eventos no código. Mantenha pelo menos dois níveis de log. O primeiro é sempre ativado (mesmo em produção) e registra apenas eventos críticos. E use o outro para registrar basicamente tudo, mas pode ser ativado ou desativado.
• Encontre e use ferramentas adequadas para navegar, manter e desenvolver sua base de código. Mesmo uma simples opção "Pesquisar tudo" do Visual Studio Code facilitou muito minha vida em certos casos.