No campo do desenvolvimento de software, muitas vezes existem teses como “
Ninguém se importa com o seu código ” (tradução - “
Seu código não interessa a ninguém ”), “O código é apenas uma ferramenta” e situações de completo mal-entendido por parte dos negócios, por que devemos levar tempo e dinheiro para algum tipo de "refatoração" do código que já funciona.
Quero dizer a você o que a “ênfase nas características” pode levar, em vez de se preocupar com a qualidade do código, e por que não apenas os programadores precisam de um bom código.
Suporte
A tese principal, sem a qual o artigo atual, em princípio, não teria sentido:
O que vem acontecendo no mundo da programação há décadas, para o qual são criadas linguagens, paradigmas e abordagens mais avançadas, para as quais distinguem vários modelos e cuidam do design do código, são de fato duas coisas: aumentar a velocidade do desenvolvimento e facilitar o suporte à base de código (que essencialmente a velocidade do desenvolvimento de novas funcionalidades).
E essas são as coisas que os negócios precisam.
Certamente, pode-se argumentar que eles mesmos precisam das metodologias que aumentam a eficiência do trabalho dos programadores para vender seu trabalho mais caro, podendo fazer mais por unidade de tempo, mas porque a situação em que os programadores solicitam um grande projeto finalizado imediatamente sem a necessidade de suporte adicional é muito grande. é raro e, geralmente, a funcionalidade é ordenada gradualmente; no início do projeto, você não sentirá os efeitos nocivos do mau design; é um investimento no futuro.
Há uma imagem do
blog de Martin Fowler sobre esse assunto, mostrando a velocidade de introdução de novas funcionalidades no projeto, dependendo do tempo de existência (ou seja, qual o tamanho).
O eixo horizontal é a vida útil do projeto, o eixo vertical é a funcionalidade agregada.
A linha vermelha ilustra a velocidade de desenvolvimento de um projeto com um bom design, e a linha azul ilustra um projeto que é escrito sem nenhuma restrição na forma de requisitos para a qualidade do código.
Portanto, se você acha que seu aplicativo está fadado ao fracasso e não se desenvolverá, ou se prepara exclusivamente para algum evento futuro, não é necessário pensar no design do sistema. Na situação oposta, um bom design provavelmente será recompensado e recompensado muitas vezes.
Às vezes, você pode ouvir a opinião de que, no início de um projeto, não precisa pensar na qualidade do código e reescrevê-lo novamente após uma apresentação bem-sucedida para clientes / investidores, mas, na grande maioria dos casos, é um erro iniciar projetos e a maneira mais fácil de obter
dívidas técnicas nos próximos anos.
Código não é uma ferramenta; código é um produto final
Uma
empresa de software não usa código como ferramenta. Este é o principal produto da empresa, é o código final do programa que determina sua qualidade, velocidade e conformidade com os requisitos de funcionalidade. Ele não pode ser tomado e substituído completamente sem incorrer em perdas materiais e temporárias, como poderia ser feito com as Metodologias de Computador / IDE / Desenvolvimento, que já serão essencialmente ferramentas para criar o produto.
Sobre "Foco no desempenho"No artigo a que me referi, o seguinte pensamento foi expresso: você precisa se comunicar com o cliente / gerente de projeto no nível de prontidão do projeto, e o exemplo a seguir foi o oposto:
Imagine que o designer começará a falar sobre as camadas que ele usou no Photoshop, quantos objetos ele possui, quais gradientes são usados em quais pincéis e quais scripts interessantes de animação ele escreveu. Não lhe interessa. Você está interessado em saber se já é possível tirar fotos.
Então aqui. Há uma diferença por causa da qual ela
não pode simplesmente ser projetada na situação com o suporte de um produto de software - todas essas camadas e pincéis no Photoshop tornam-se desnecessárias para qualquer pessoa logo após o resultado do trabalho (fotos), e, do mesmo modo, são uma ferramenta para alcançar o resultado , não o produto final.
Assim, ao elaborar os requisitos para as imagens finais, o cliente não pode se preocupar com o que será usado no processo. No caso de software, se o cliente (empresa) exigir apenas a funcionalidade do aplicativo, ele corre o risco de conseguir exatamente o que queria - nova funcionalidade, mas não havia dúvida de que precisaria ser mantido e desenvolvido.
Infelizmente, esse é um problema bastante comum na terceirização, quando uma empresa vende apenas o tempo de seus desenvolvedores e os clientes não podem avaliar objetivamente a qualidade do sistema e o tempo necessário para solucionar seus problemas. Quando o custo da alteração do código aumenta exponencialmente, isso só beneficia a empresa para o terceirizado - mais horas humanas podem ser monetizadas e a empresa que solicita o produto já estará no gancho - é tarde demais para reescrever o sistema complicado e inconveniente, pois exige grandes investimentos e interrompe a entrega de novas funcionalidades isso não pode ser permitido.
Código - o local de trabalho do programador
Durante todo o tempo em que o artigo estava em rascunho, pensei muito se esse item deveria ser incluído nele, mas depois de uma pequena observação das prioridades dos candidatos que procuram trabalho, percebi que esse momento é realmente importante.
Código é algo que um programador terá que trabalhar todos os dias, seu produto criativo, o que ele cria, mas cria não apenas um, mas em equipe, e muitas vezes não do zero. Ele precisa aceitar a parte já existente do projeto, desenvolvê-lo com base na funcionalidade que foi escrita antes dele. Um funcionário provavelmente será desagradável para trabalhar em um produto mal criado.
Em primeiro lugar, na minha opinião, é a equipe que trabalha em conjunto no projeto. A qualidade do produto resultante depende diretamente de como o trabalho da equipe é construído, das regras internas e dos requisitos estabelecidos dentro dele.
Em segundo lugar, está a tecnologia. Uma estrutura inconveniente escolhida ou herdada sem pensar, ferramentas desatualizadas e de baixa qualidade, bibliotecas pregadas no local do projeto com todas as muletas e bugs que você precisa suportar, e a falta de pessoas com competências e tempo suficientes para eliminar abordagens herdadas pode facilmente assustar novos potenciais trabalhadores. Além dos motivos expostos acima, esse também é um número menor de perspectivas e oportunidades para o desenvolvimento de programadores, porque, em vez de estudar ferramentas modernas e mais eficazes, é necessário desenvolver adereços para adaptar soluções às tarefas atuais que foram recebidas por razões históricas.
Por que isso é tudo
Infelizmente, os requisitos para aplicativos reais raramente podem ser formados em 100% e não exigem revisão durante o desenvolvimento. Além disso, a situação é quase impossível quando o projeto não precisa ser ajustado aos novos requisitos após o lançamento. O negócio se expande, desenvolve, requer funcionalidades que não foram discutidas antes, entra em novos mercados.
É quase impossível construir uma arquitetura ideal e pensada para todos os pequenos detalhes nessas condições e, muitas vezes, não há necessidade, porque seu custo nesse caso é excessivamente alto para o estágio inicial do projeto.
Certamente, escrever um bom código não deve ser uma dor de cabeça para quem solicita software de programadores, e é improvável que quem não pode escrevê-lo possa verificá-lo.
No entanto, uma empresa que desenvolve um produto de software, se quiser torná-lo qualitativamente, deve entender que uma parte significativa do produto, como seu código-fonte, afeta diretamente seu sucesso, e coisas como refatorar o código-fonte e modificar a arquitetura para os novos requisitos também devem Como um orçamento, o tempo deve ser alocado aos programadores. Se alguém está interessado na qualidade do produto, é claro.
No entanto, o setor de TI está se desenvolvendo, produtos, empresas, ferramentas estão se desenvolvendo, os usuários estão se tornando mais seletivos, a concorrência está aumentando e há esperança de que o futuro ainda esteja com produtos de alta qualidade.
Conclusão
De fato, o tópico do artigo é, obviamente, muito controverso.
O gráfico acima não responde à pergunta em que momento o design do sistema começa a dar frutos.
A dívida técnica para isso e a dívida, que permite que você tenha um pouco mais de tempo agora e devolva os juros mais tarde, e seu principal problema é extremamente simples e se assemelha fortemente a um fenômeno semelhante na economia, é a incapacidade de quitar dívidas e a incapacidade de estimar com precisão a renda futura.
A qualidade do código também é uma coisa muito subjetiva e, infelizmente, praticamente não formalizada, caso contrário, os programadores já poderiam ser substituídos por robôs.
De qualquer forma, o mais importante é alcançar compromissos competentes e encontrar o meio termo, o que nos permitirá não afogar o projeto no poço da dívida técnica em busca da funcionalidade e não abrir mão de um nicho interessante para os concorrentes, fazendo o design do sistema em vez da funcionalidade.