Há algum tempo, observei uma distorção das técnicas aplicadas na produção de software. Tendo aprofundado os detalhes (aplicação do DDD), eu queria sugerir ao leitor que, seguindo a liderança do gerenciamento de corujas, não se pode cumprir o dever de engenheiro.

Um artigo recente de alto perfil sobre os reis nus da indústria me fez perceber que ainda quero expressar meu entendimento sobre que tipo de programador eu quero ser e o que quero ver por aí - engenheiros que entendem o contexto de seu trabalho, seu papel e quais métodos devem ser seguidos . Por baixo do corte, convido o leitor a pensar comigo sobre o que estamos fazendo em geral e o que isso impõe às limitações dos desenvolvedores em suas atividades.

Sobre a causa da contradição

Vou começar de longe - a partir do século XVIII. O desenvolvimento e a socialização da produção, juntamente com a concorrência, estimulam os produtores repetidamente a modernizar e automatizar a produção. Motores a vapor, tear Jacquard, transportadores, linhas de produção e robôs - todas essas melhorias desempenham seu papel econômico - proporcionam uma vantagem competitiva, como pré-requisito para ainda mais socialização do trabalho, a unificação das cadeias produtivas. Como resultado, a produção está em expansão, eles podem planejar seu desenvolvimento e automação para obter lucros ainda maiores.

Obviamente, qualquer empresa sempre tem uma alternativa aos métodos de lucro. Por exemplo, contrate mão-de-obra mais barata e gerentes eficazes, capazes de reduzir três peles desses trabalhadores. No entanto, se você, como eu acredito que a humanidade não deve parar, mas avançar em direção ao progresso, então você concorda comigo que essa não é uma opção que nos convém. Sim, todas essas lojas sem vendedores estão com muito medo, porque os drones estão cada vez mais entregando mercadorias, que a IA está pronta para substituir os drivers e assim por diante. Os economistas estão assustados com o surgimento de indústrias com custo zero. No entanto, engenheiros, designers, inventores, arquitetos e apenas cientistas ainda precisam fazer o seu trabalho - para reduzir o custo de produção, melhorando sua qualidade - esta é a nossa tarefa socioeconômica.

Para não falar de assuntos muito altos, proponho que abaixemos nossas atividades imediatas. Para os negócios, sempre há uma opção: colocar 10 pessoas em 10 unidades para realizar um trabalho simples, ou 4 pessoas em 25 unidades automatizarão esse trabalho e depois o servirão. E seu entendimento claro dos meandros das necessidades comerciais e dos requisitos de engenharia pode ajudar a fazer essa escolha em direção a um caminho intensivo de desenvolvimento. E o que significa para o cliente escolher esse caminho?

Parte do dia em que trabalhamos para nós mesmos e parte do dia para o empregador ou cliente. Permitirei-me expressar isso com a seguinte fórmula de custo:

onde

c é capital fixo , ou seja, ferramentas de organização que lhe permitam realizar suas atividades (computadores, software, etc.).
v - salários de funcionários.
m é o lucro nocional daqueles que possuem produção.

No caso do desenvolvimento de software, existem nuances - se o software é um serviço que faz parte de uma empresa que está em constante evolução, você deve trabalhar diretamente e não relacionado à solução de um problema comercial. Sinta a diferença - o que poderia ser gasto em poucas pessoas com menos habilidade é gasto " no trabalho em prol de trabalhos futuros ". Se transferirmos isso para a fórmula, significa que estamos trabalhando a favor do capital constante c , devemos gastar dinheiro com os salários de alguém v , com o lucro m ou com o custo dos bens W. Deve ser considerado com mais detalhes.

Por exemplo, se você propõe elaborar a arquitetura do seu monólito e dividi-la em microsserviços, mas seu cliente não tem uma necessidade direta disso, o que a sofisticação da engenharia lhe custará?

• m - o cliente pode desistir de seu lucro. O nome desse investimento, ou seja, risco controlado de maior lucro. Nesse caso, o risco deve ser reconhecido. Se você decidir aprender a criar complexos enormes para o dinheiro de outras pessoas - esse é um risco descontrolado. Outra coisa, como parte de uma retrospectiva, por exemplo, é realizar um pequeno experimento, avaliar os resultados e avançar ainda mais.

  
  

• W - o cliente pode aumentar o preço de seus produtos e serviços. Os monopólios podem muito bem se dar ao luxo de aumentar o custo e, muito provavelmente, o fazem. Mas o mais provável é que o cliente seja sempre abalado pelas condições do mercado.

  
  

• v - Você pode desistir do salário de outra pessoa e há opções.
  1) Você vai sacrificar o seu. Você processará ou fará um projeto de código aberto que o ajudará no trabalho.
  2) Você automatiza o trabalho de outra pessoa, o que permitirá que menos pessoas o usem.

  
  

  Pessoas ingênuas como eu escolhem a opção 1, infelizmente. Mas se você obtiver sucesso em 2, estará mudando qualitativamente a cadeia de produção: ele precisa de menos do que apenas mãos de trabalho e mais e mais pessoas com experiência que possam criar e modificar corretamente os processos.

  
  

O problema com a equipe é que ela não decide o que fazer. Mas isso pode levar a argumentos e os negócios não serão tocados por nada além de materiais - a beleza do código, a nova estrutura, a técnica da moda - não se trata de dinheiro. Há uma conexão em investimentos em complexidade tecnológica e necessidades de negócios. Um deve corresponder ao segundo.

Antagonismo de requisitos

O software é uma solução complexa que equilibra duas contradições dialéticas: arquitetura e requisitos de negócios. Ao avaliar a complexidade de projetar um sistema específico, pode ser extremamente simples ignorar os argumentos das partes opostas por sua natureza. É importante entender o contexto, que tipo de tarefa você está enfrentando, independentemente da sua função no projeto: Dono ou equipe do produto .

• O lado comercial (PO, SH) gostaria de trabalhar para gastar a menor quantidade de recursos nele. Infelizmente, apresentar essa posição é muito simples, porque penetrou não apenas em nossas vidas, mas também no folclore da TI - uma coruja é um gerente eficaz, o exemplo mais impressionante.
• Os executivos (equipe) precisam executar esse conjunto de trabalhos para garantir a solução dos principais aspectos da arquitetura para resolver um problema de negócios, sem acumular dívida técnica, idealmente, e ferramentas para solucionar problemas mais rapidamente. A equipe de negócios é a fornecedora de software e a arquitetura é o capital constante disponível para ela.

Para encontrar um denominador comum, sugiro fazer ao cliente as seguintes perguntas antes de cada novo projeto:

• O que exatamente estamos fazendo pelo cliente, qual é o benefício esperado?
• A frequência de aplicabilidade desta solução.
• A probabilidade de requisitos de mudanças / expansão.
• Existe uma conexão com outros sistemas / serviços / contextos?

O número de requisitos por parte dos negócios e da arquitetura deve ser proporcional; caso contrário, a classe da tarefa colocada e resolvida não é proporcional e, se os requisitos crescerem de um lado ou de outro, a solução poderá ser adiada ou reestruturada. Em outras palavras, para que o cliente possa resolver melhor seus problemas, também precisamos ter os meios adequados para resolver problemas de desenvolvimento. I.e. com solda a gás e uma marreta, ninguém construirá um foguete para astronautas.

Portanto, se a tarefa for pequena e o cliente precisar resolvê-la com uma quantidade mínima de recursos, se a tarefa não for repetida, não estiver conectada a sistemas grandes, a solução TransactionSript, um cliente inteligente e todos os antipadrões serão aceitáveis. Sejamos realistas - existem esses problemas e eles devem ser resolvidos da mesma maneira, às vezes com muita rapidez (mas não esquecemos de marcar isso com uma dívida técnica). Mas apenas neste caso, não se deixe enganar por modelos anêmicos em pipelins e outras meias medidas.

As tarefas associadas aos sistemas existentes podem ser resolvidas com base no sistema existente, fazendo uma análise mínima dos processos internos, se a tarefa não for expandida ou não forem esperadas alterações nos requisitos, a solução TableModule, Shared database, etc. é aceitável.

Requisitos comerciais significativos podem exigir muito da arquitetura (por exemplo, maior disponibilidade, autorização, tolerância a falhas, desempenho). Por sua vez, a arquitetura pode abrir oportunidades para resolver novos problemas (principalmente associados à transição para um modelo de arquitetura mais complexo e evitar cenários específicos).

Muitas vezes, em conferências e reuniões, os desenvolvedores perguntam aos palestrantes: como convencer nossos empregadores de que precisam dedicar tempo a algo (testes, arquitetura, documentação, etc.)? Para tarefas sofisticadas, provavelmente não há alternativa. A razão para isso é o ciclo de vida de produtos, serviços e organizações.

O ciclo tecnológico determina (ao mesmo tempo limites) o desenvolvimento - para entrar no próximo estágio de desenvolvimento, é necessário ir além dos limites do processo tecnológico atual. I.e. expanda suas práticas, tente algo novo, configure experimentos controlados.

Gradualmente, à medida que o número de soluções complexas de plataforma exceder uma certa quantidade, ele se transformará em crescimento qualitativo. Custos negativos para a dívida técnica, a arquitetura pode se tornar um investimento em tarefas mais complexas, negando o objetivo original.

Ágil, CI, DDD, etc. permitem que você ultrapasse os limites do processo. Essas áreas de conhecimento e metodologias, que ajudam a avaliar a complexidade das tarefas de várias maneiras, estabelecem o trabalho em equipe. Perceba corretamente essas coisas como holísticas , como uma oportunidade para muitos contribuírem muito para obter exatamente o resultado que você precisa!

Do equilíbrio de requisitos ao equilíbrio do trabalho

Ao falar sobre o ciclo de vida do software, treinadores da moda e treinadores Agile não se lembrarão do famoso diagrama de I. Adizes.

Tudo nele é bonito e agradável, mas é unilateral. Portanto, a subjetividade do modelo não reflete o processo interno da organização. Muitas equipes concordam com a empresa quanto tempo gastarão em dívidas técnicas e em vários aspectos da arquitetura. Eu ofereço meus pensamentos sobre esse assunto - o eixo do ciclo tecnológico (OTC).

O eixo da abscissa é tomado como a complexidade dos recursos de negócios. O eixo das ordenadas é a complexidade do trabalho arquitetônico. Por complexidade, quero dizer brega pontos da história. Atrasando o desempenho dos recursos neste gráfico, você pode ver o quão adaptável você é ao software lançado para alterações subsequentes.

• Quanto mais certo o último ponto do gráfico em relação ao OTC , mais cedo o produto será útil e mais difícil será o desenvolvimento de tarefas complexas.
• À esquerda do último ponto do gráfico em relação ao OTC , mais você se empolga com a plataforma e corre o risco de não fornecer software de trabalho dentro do prazo.
• Por conseguinte, vale a pena aderir ao desenvolvimento uniforme, isto é, movimento ao longo do eixo.

Na figura acima, minha idéia de como é o tempo gasto na implementação da oportunidade de negócios X e da arquitetura Y , onde o eixo Z reflete a utilidade do produto.

Conclusão

Se as tarefas de negócios exigirem arquitetura complexa, ela aparecerá e vice-versa, a arquitetura pode ser um driver para resolver problemas complexos, que, no entanto, devem ter pré-requisitos - a possibilidade de otimização do processo. Quando o cliente possui várias tarefas complexas difíceis de resolver com as ferramentas atuais, é possível que elas possam ser resolvidas com a ajuda de uma mudança qualitativa. Para chegar a uma mudança qualitativa, certas mudanças devem ser acumuladas sequencialmente. Por exemplo, para alternar para microsserviços, o monólito geralmente é dividido consistentemente em contextos e agregados limitados, e o IC é alcançado de forma consistente. E vice-versa, como casos em que é necessário adicionar funcionalidade ao código legado e, para isso, refatoração seqüencial.

Trabalho arquitetônico complexo - sua contribuição pode ajudar uma empresa a se tornar mais lucrativa e competitiva. Ao mesmo tempo, torna-se importante evitar compromissos e abordagens comprometedoras no design e na implementação em favor de benefícios rápidos e momentâneos. Hoje você elevará o KPI de alguém e amanhã não poderá fazer novas funcionalidades no prazo devido a problemas acumulados no produto.

Eu recomendo examinar a conexão entre ajuste e negócios em um relatório das guerras da Plataforma Cyril Skrygan (IDE) .