Motivos da Baixa Qualidade no Processo de Codificação
O mercado é regido por constantesmudanças que impactam no dia a dia das empresas. Sabe-se que tais mudanças serever tem em alterações, às vezes diárias, nos softwares e consequentemente afetamo ritmo de trabalho do time de desenvolvimento. Diante disso, é necessário que os desenvolvedores possam corresponder proporcionalmente a essa demanda, fazendo com que as organizações se mantenham, ou se tornem, mais competitivas perante o mercado. É comum que uma pressão recaia sobre o time, uma vez que todo o processo está associado à utilização de sistemas.
Neste cenário, a eficácia passa a ser um caminho natural para responder à demanda do mercado. A eficácia é o menor caminho para alcançar um objetivo. Neste contexto, o objetivo pode ser a correção de um erro que impede o andamento de um determinado processo ou a entrega de uma nova funcionalidade que irá gerar algum diferencial para a empresa.
Porém, nem sempre eficácia e qualidade andam juntas. A grande incidência de código mal escrito é resultado da eficácia buscada pelo time. Geralmente, isso ocorre quando uma demanda classificada como urgente é solicitada pelos gestores. O código de baixa qualidade geralmente tem características como inflexibilidade, fragilidade, alto nível de dependência ebaixo grau de entendimento.
Há outros fatores que podem contribuir para a produção de código de baixa qualidade. Considere uma provável necessidade de autoafirmação de um desenvolvedor que deseja mostrar que pode atender comrapidez o que lhe é solicitado. Em situações como essa, é evidente a influênciade fatores psicológicos, como, por exemplo, o ambiente de competitividade notime de desenvolvimento.
Consequênciasda Má Qualidade de Código
Priorizar somente a eficácia no processo de codificação é prejudicial e insuficiente, se tornando uma prática válida apenas para gestores que buscam soluções imediatistas. Conforme mencionado anteriormente, a eficácia resulta em um aumento na incidência de código malescrito, o que é bastante prejudicial a todos os envolvidos. Para exemplificar este prejuízo, podemos destacar:
- Improdutividade resultante da manutenção de códigos complexos.
- Compromete psicologicamente a equipe, devido à sensação de não corresponder às expectativas dos envolvidos.
- Proliferação de código de má qualidade.
- Expõe a reputação profissional do desenvolvedor, pois deixará uma má evidência do seu trabalho.
- Aumento do custo do projeto.
Devido a pouca evolução do projeto, é comum que os gestores exerçam uma cobrança mais efetiva visando alcançar os resultados, o que resulta em maior pressão ao time de desenvolvimento. Além disso, os gestores passam a adotar as seguintes práticas:
- Contratação de novos desenvolvedores objetivando maior produtividade da equipe.
- Maior fiscalização sobre as atividades de cada desenvolvedor.
- Propostas de hora extra, buscando reduzir o prazo de entrega.
- Desligamento de membros do time.
Tais ações geralmente não implicam namelhoria da produtividade. Pelo contrário, resultam na insegurança, desmotivação, inchaço da equipe e ainda menor evolução no andamento do projeto.
Utilização das Práticas Ágeis neste Contexto
Adotando o SCRUM como framework, o desenvolvimento de um grupo de funcionalidades (Sprint Backlog) sempre estaráassociado a um tempo predefinido. Isto garante que a equipe possa realizar oseu trabalho com boa qualidade, em um período que pode variar de duas a quatro semanas.
Neste modelo, há um espaço de tempo definido para a entrega de uma funcionalidade, sendo que a complexidade do trabalho é diretamente proporcional a esse tempo. O conceito de Time Box fazcom que o tempo, que antes era um fator crítico, passe a ser aliado do desenvolvedor ao realizar o seu trabalho. O fator tempo passou a ser controlável, uma vez que o time pode mensurar a relação entre trabalho desenvolvido e o tempo gasto ou tempo restante.
A adoção das Time Boxes favorece a produção de código de qualidade, obedecendo a boas práticas e convenções específicas do projeto ou da empresa. Quando adotamos o SCRUM, favorecemos ao desenvolvimento de um ritmo de trabalho uniforme, ao aumento da produtividade além de contribuirmos para uma melhora considerável no ambiente de trabalho.
Além do uso de Time Boxes, outro pilar do SCRUM que favorece a qualidade de código é a inspeção. O fato de haver inspeção constante faz com que ocorra diminuição de inadequações no código já que o mesmo será previamente detectado e corrigido. Nesse contexto, devemos salientar que a interdisciplinaridade e autogerenciamento do time dedesenvolvimento permitirá que todos possam inspecionar o código, contribuindo para o aprendizado constante e para a prevenção de erros do release.
A programação pareada proposta pelo XP Extreme Programming, permite a refatoração de código quase que de maneira automática. A análise do código de um segundo desenvolvedor é importantee permite que a utilização de determinados métodos ou variáveis seja questionada, repensada e otimizada.
Como Atender as Constantes Demandas do Mercado
Entregar releases de forma contínua significa manter o projeto em conformidade com as características do mercado que está em constante mudança. Definir as features que irão compor o próximo Sprint Backloge saber alinhá-las aos interesses da gerência ou de outros stakeholders é um artifício que permite atendê-los de maneira convincente. O dimensionamento dotempo para desenvolvimento e entrega de releases deve estar associado aos anseios do mercado. Isso está intimamente relacionado à criação de um elo confortável entre a forma de trabalho do time e as expectativas da gerência. Ter um código legível e fácil de manter é um dos requisitos necessários para que o time possa entregar software de forma contínua e em curtos espaços de tempo,estabelecendo um ciclo harmônico entre a empresa e o mercado.
