JH Rainwater "Como pastar gatos": do outro lado do desenvolvimento

Continuamos compartilhando trechos do manual para aqueles que estão se preparando para liderar a equipe de desenvolvimento. Na parte anterior, conversamos sobre tudo o que é estranho, que aguarda o líder técnico na nova posição, agora voltamos às coisas familiares e familiares - a própria programação. Aqui, o desenvolvedor de ontem pode sentir seu elemento, mas ele não precisa relaxar - a área de responsabilidade está crescendo e mudando. Sob cat, apresentamos uma breve visão geral de todas as novas responsabilidades e dicas de adaptação que Rainwater traz em seu livro.

A diferença fundamental está em duas nuances. Em primeiro lugar, a liderança muito antes entra no processo e não a encerra até o fim vitorioso. Em segundo lugar, enquanto o desenvolvedor está focado na tarefa restrita que é definida para ele, seu chefe analisa o produto por inteiro, sem esquecer de entrar em detalhes quando a situação o exigir. Vamos juntos com o autor em ordem e tentar descrever o papel do líder da equipe em cada estágio da criação do aplicativo.

Definição de requisitos e especificações

Um bom teclado começa a trabalhar com o produto mesmo quando ele está no estado perinatal - ou seja, na forma de uma idéia geral, solicitação ou lista de funções. No entanto, aqui você precisa esclarecer imediatamente: a Rainwater acredita firmemente que o desenvolvedor não deve se envolver no trabalho de um profissional de marketing ou gerente de produto - ou melhor, ele deve evitar esse cenário com toda a força. Não que fosse impossível ou repreensível para o "técnico" entender a realidade do mercado e os requisitos comerciais, mas combinar essas duas funções é muito difícil. Entre outras coisas, há um risco maior de que o desenvolvedor interno vença e as características do produto sejam adaptadas aos interesses da equipe do programador, e não ao usuário final. É muito mais fácil e seguro trabalhar quando a visão geral do produto em termos de funcionalidade já está preparada e testada quanto à viabilidade por pessoas conhecedoras.

Para a mistura dos dois papéis, os desenvolvedores que em nossa classificação geralmente pertencem à raça dos cowboys costumam advogar - eles anseiam por momentos de "garagem" em que pequenas equipes produziam todo o produto de e para e não havia necessidade de interação externa. O autor tem pressa de dissipar todas as ilusões sobre essa pontuação: nas condições modernas, a interação entre grupos técnicos e não técnicos deve ocorrer regularmente, durante todo o ciclo de vida do aplicativo. As primeiras reuniões são realizadas para a preparação conjunta de especificações. O gerente de desenvolvimento (ou um dos principais desenvolvedores) se familiariza com a descrição do produto, exclui tudo que lhe parece injustificado ou irrealista do ponto de vista técnico e escolhe o plano final para traduzi-lo para o idioma da tecnologia. Em seguida, os grupos se reúnem de tempos em tempos para “verificar o relógio” e garantir que a implementação não se desvie muito do plano original.

A frequência recomendada para essas reuniões é de cerca de uma vez por semana, embora, é claro, você precise fazer ajustes no ritmo geral de desenvolvimento e nos recursos da organização dos processos de uma empresa em particular.

Reuniões regulares também serão necessárias por outro motivo - as tentativas de se desviar do curso original provavelmente virão não apenas do lado do desenvolvimento. A maioria dos aplicativos, para permanecer competitiva, cresce constantemente com ferramentas e recursos adicionais. Portanto, o processo de considerar, avaliar e abandonar idéias pode ser repetido ad infinitum, apenas em uma escala menor do que para as especificações principais. É extremamente importante para Tehlid manter-se a par dos planos de desenvolvimento de produtos - isso não apenas lhe dá espaço de manobra do ponto de vista organizacional (alocação de responsabilidades, determinação de termos), mas também permite que você calcule antecipadamente as conseqüências para o sistema como um todo, sua harmonia e sustentabilidade.

Antes de concordar em assumir uma nova função para o trabalho, você deve fazer uma série de perguntas:

• Qual o impacto da mudança proposta na arquitetura do sistema a curto e longo prazo?
• Como a mudança proposta afetará a infraestrutura de rede em que ocorrerá?
• Como a alteração proposta afetará a capacidade do usuário de interagir de maneira eficaz e produtiva com este produto?
• Qual o impacto da mudança proposta sobre as ações dos funcionários que precisam trabalhar em estreita colaboração com ele - implementar, acompanhar?

Tais reflexões ajudarão a identificar armadilhas e a definir orientações gerais para o diálogo com outros grupos.

Desenho

Quando os requisitos são aprovados e abençoados por todos os participantes do processo, chega a hora do que a Rainwater chama de coordenação das decisões de arquitetura e design. Em outras palavras, o guia técnico precisa descrever o sistema que executará as funções especificadas no estágio de especificações e refletir sobre os componentes responsáveis ​​por procedimentos específicos. É fundamental agir nesta ordem:

Arquitetura primeiro, depois componentes.

O autor enfatiza isso muitas vezes, porque muitos desenvolvedores que não estão familiarizados com a arte do design de produtos caem nessa armadilha. Parece lógico fazer uma lista de requisitos, prescrever os componentes necessários para cada um e considerar o produto como uma simples combinação deles. Mas, na realidade, essa abordagem mecanicista dá origem a monstros rígidos e aleatoriamente organizados que sugam todos os sucos dos desenvolvedores envolvidos no suporte ao projeto. Para evitar isso, você precisa seguir o outro caminho, do todo para o particular. Você já tem uma visão funcional comum do produto com uma perspectiva de desenvolvimento - é necessário "espelhá-lo" em sua visão técnica geral com uma perspectiva de desenvolvimento, ou seja, arquitetura.

Arquitetura de construção

Se recorrermos a uma metáfora falsa, a arquitetura é o esqueleto do produto, no qual a carne das decisões privadas sobre a implementação dos procedimentos é então construída. Revivemos um pouco essa metáfora, acrescentando um esclarecimento: o esqueleto deve ser afiado para crescer novos membros. Os dois principais requisitos para arquitetura são uma organização lógica clara de componentes e flexibilidade que adicionará novos à medida que o projeto cresce.

Talvez esse estágio do desenvolvimento possa ser considerado o mais responsável - os especialistas dizem que é precisamente a negligência dos problemas de arquitetura que geralmente leva ao colapso dos projetos. Entre as causas comuns de falha, elas mencionam:

• Falta de pensamento, organização desleixada (ou sua completa ausência).
• Rigidez e franqueza excessivas do sistema, impedindo sua expansão de acordo com as necessidades comerciais.
• Interconectividade excessiva de componentes, falta de flexibilidade na configuração.
• Complexidade excessiva nos níveis superiores, dificultando a modificação dos componentes básicos.

Consequentemente, a tarefa de construir arquitetura deve ser encarada com toda a seriedade, sem poupar recursos. Lembre-se de que você está estabelecendo as bases com as quais deve trabalhar até o fim - ele deve suportar todas as mudanças que aguardam o projeto no futuro. Esse processo é amplamente criativo e visionário, mas métodos padrão de estruturação são úteis para equilibrar o sistema. Por exemplo, desenhe um diagrama de blocos com um conjunto completo de conexões ou implemente um layout simples (um conjunto de componentes de baixo nível com stubs e valores de retorno) para garantir que a arquitetura funcione em uma projeção vertical. O último é muito desejável antes de iniciar o desenvolvimento de componentes reais e completos - eliminar bugs com elementos "brinquedos" é muito mais fácil e mais simples.

Ao final do trabalho, nesta etapa, você deve estar pronto para responder às seguintes perguntas:

• Como o usuário irá interagir com o sistema?
• Quais componentes precisam ser montados para que o sistema funcione?
• Qual será o mecanismo para a interação de componentes que garante o funcionamento do sistema?
• Quais tecnologias são mais adequadas para criar este aplicativo?
• Como ele deve entregar o sistema ao cliente?

Planejamento de componentes

Quando a estrutura geral é desenvolvida, é hora de investigar em particular e implantar os componentes atualmente relevantes na estrutura orgânica. A principal dificuldade aqui é suportar a medida necessária de conexão. Por um lado, os componentes não devem ser considerados como recipientes estritamente isolados para conjuntos específicos de operações - mas como um sistema de órgãos, cada um dos quais se comunica com os outros, mas desempenha suas funções. Ao mesmo tempo, deve-se evitar uma forte interdependência entre as regiões, como resultado da modificação de um componente que levará a toda uma cadeia de mudanças, ou mesmo mau funcionamento, em todo o sistema.

A pilha de tecnologia foi descrita na última etapa, agora você precisa compreendê-la em detalhes. Na escolha da linguagem, das bibliotecas e, além disso, faz sentido ser guiado não apenas por motivos profissionais, mas também estritamente pragmáticos. Digamos, você terá pessoal competente suficiente para suportar sistemas construídos com base em tecnologias avançadas, raras ou complexas? E vice-versa, se você preferir tecnologias mais antigas, quão promissor é: elas continuarão funcionando durante todo o ciclo de vida, os problemas de compatibilidade começarão a surgir? Todos os problemas relacionados a soluções de hardware, criação, configuração e manutenção de infraestrutura devem ser considerados com o mesmo cuidado.

Desenvolvimento e controle de qualidade

Assim, o planejamento está finalmente concluído e o projeto começa a funcionar - o desenvolvimento real do aplicativo começa. O papel do líder técnico nesse processo consiste principalmente no monitoramento, para que tudo corra de acordo com os termos e normas; ele está diretamente envolvido na criação de código, como regra, apenas em situações de força maior. Na maioria das vezes, o chefe desempenha as funções de uma polícia de código, ou seja, realiza revisões críticas regulares do código para garantir que não contradigam a estrutura arquitetônica e os princípios básicos de programação.

Durante as inspeções, um líder técnico pode encontrar diferentes tipos de erros. A água da chuva concentra o leitor em duas variedades:

• Violação de padrões . Isso inclui estilizar, nomear, comentar - em geral, tudo o que ajuda terceiros a entender o que está acontecendo no código, além de negligência no espírito de vários pontos de saída ou odiados operadores de GoTo. É necessário garantir que todos os participantes do processo de desenvolvimento falem o mesmo idioma - isso torna o código transparente e permite desvendar rapidamente movimentos errados. Os nomes dos parâmetros e variáveis ​​devem indicar claramente seu conteúdo, os comentários devem ajudar a rastrear o código dos pensamentos de um desenvolvedor, justificar suas decisões. A propósito, se alguém da equipe teimosamente se recusar a comentar o código, vale a pena considerar o porquê. Muitas vezes, isso é apenas preguiça ou uma peculiaridade de pensamento, mas em alguns casos pode ser um sintoma de que o próprio funcionário não entende realmente o que está fazendo - confuso ou apenas copiando partes do código de outra pessoa por um bom motivo. Também é necessário monitorar cuidadosamente aqueles que negligenciam regularmente o tratamento de erros: a incapacidade de identificar fontes de erros é uma falha séria para o desenvolvedor.
• Conectividade fraca e forte interdependência são duas áreas de perturbação que podem ser consideradas juntas, uma vez que a presença de uma implica a presença da outra. Aqui, de fato, tudo depende do grau de ramificação e de seu tipo. Com um alto grau de ramificação em termos de produção, o funcionamento do procedimento envolve o acesso a muitos outros procedimentos, o que, é claro, é indesejável. A ramificação na entrada, pelo contrário, tem um efeito positivo, pois indica encapsulamento rigoroso. Se você tiver dúvidas ao analisar o código para esses parâmetros, seria bom elaborar um diagrama de blocos com uma hierarquia marcada de objetos. Ele revela imediatamente tudo o que você precisa saber: é possível rastrear o pedigree do objeto, existe lógica na disposição das setas ou tudo parece bagunçado.

Se a polícia do código detectou violações nessas e em outras áreas, o procedimento de prisão é assim: o código é enviado de volta ao desenvolvedor com os comentários necessários, o trabalho no componente correspondente é suspenso até que os defeitos sejam corrigidos. É altamente desejável que o desenvolvedor lide com isso sozinho, embora com dicas - se você fizer tudo por ele, o componente de orientação da inspeção do código será perdido.

Não adie a revisão até tempos melhores. Primeiro de tudo, ele pode voltar fortemente no futuro e exigir muito mais recursos para corrigir toda a bola de neve de problemas. Em segundo lugar, a teoria das janelas quebradas também funciona na programação - código confuso e desarrumado gera código ainda mais desarrumado e confuso, simplesmente porque parece válido.

Finalmente, falando sobre controle de qualidade, não se pode deixar de abordar o problema do notório fator humano. A Rainwater recomenda que o gerente tome uma posição intermediária. Algum grau de resistência à interferência com o código é natural e benigno. Uma disposição completa em seguir as instruções de outra pessoa e aceitar a opinião de outra pessoa deve alertá-lo - geralmente isso significa que o desenvolvedor, de fato, não se importa com o que ele libera. Por outro lado, a incapacidade de perceber críticas sólidas dificulta o crescimento profissional e o trabalho em equipe. Assim, o técnico terá que crescer uma pele mais espessa e não ter medo de insistir por conta própria, sem ter uma reação negativa ao coração.

Teste

Aqui, é importante que o líder tenha em mente duas regras básicas: o teste deve ser realizado e a organização de sua conduta é de sua responsabilidade. Se a empresa tiver um departamento de testes naturalmente envolvido nos processos, não haverá problemas com isso. Caso contrário, você terá que alocar um recurso de suas próprias reservas para esse assunto.
No segundo cenário, segundo o autor, existem certas vantagens: testar é uma habilidade útil para o desenvolvedor. É especialmente útil atrair recém-chegados para essas tarefas, para que eles adquiram qualificações rapidamente. Inicialmente, você pode executar tarefas de teste por até metade do tempo de trabalho.

Caso contrário, para garantir uma boa qualidade da inspeção, é necessário garantir que o produto não cozinhe o tempo todo no mesmo grupo - idealmente, ele deve ser testado “ao lado”. Se uma empresa possui várias equipes de desenvolvimento, pode fazer sentido concordar com outros líderes para criar um grupo misto.