Encontro-me ponderando sobre esta questão de tempos em tempos, uma e outra vez. Quero fazer as coisas da maneira certa: escrever código limpo, compreensível e correto, fácil de manter. No entanto, o que acabo fazendo é escrever um patch em um patch; só porque não há tempo, os clientes estão esperando, um bug deve ser corrigido durante a noite, a empresa está perdendo dinheiro com esse problema, um gerente está pressionando muito, etc., etc.
Sei perfeitamente bem que, a longo prazo, estou perdendo mais tempo com esses patches, mas como esse período se estende por meses de trabalho, ninguém se importa. Além disso, como costumava dizer um de meus gerentes: "não sabemos se haverá um longo prazo se não o corrigirmos agora".
Tenho certeza de que não sou o único preso nesses infinitos ciclos de escolha real / ideal. Então, como vocês, meus colegas programadores, lidam com isso?
ATUALIZAÇÃO: Obrigado a todos por esta discussão interessante. É triste que muitas pessoas tenham que escolher diariamente entre uma quantidade e uma qualidade de seu código. Ainda assim, surpreendentemente muitas pessoas pensam que é possível vencer esta batalha, então obrigado a todos por esse incentivo.
Respostas:
Na verdade, essa é uma pergunta muito difícil, porque não há uma resposta absolutamente certa. Em nossa organização, estamos implantando melhores processos para produzir código melhor. Atualizamos nossos padrões de codificação para refletir como escrevemos código em grupo e instituímos um loop muito forte de teste / refator / design / código. Entregamos continuamente ou pelo menos tentamos. No mínimo, temos algo para mostrar às partes interessadas a cada duas semanas. Sentimos que somos artesãos de software e o moral é alto. Mas, apesar de todos esses freios e contrapesos, sofremos do mesmo problema que você.
No final do dia, estamos entregando um produto a um cliente pagador. Esse cliente tem necessidades e expectativas, realistas ou não. Muitas vezes, a equipe de vendas nos coloca em apuros apenas para obter uma comissão. Às vezes, o cliente tem expectativas de ir ao ar que não são realistas ou exigem mudanças, mesmo que tenhamos um contrato em vigor. Os cronogramas acontecem. A TDF e os dias perdidos durante um sprint podem acontecer. Todos os tipos de pequenas coisas podem culminar em uma situação em que somos forçados a enfrentar o dilema de "fazer o certo" ou "fazê-lo o mais rápido possível". Quase sempre, somos forçados a "fazê-lo o mais rápido possível".
Como engenheiros de software, desenvolvedores, programadores, pessoas que codificam para um trabalho - é nossa tendência natural "fazer o que é certo". "Faça o mais rápido possível" é o que acontece quando trabalhamos para sobreviver, como a maioria de nós. A balança é difícil.
Sempre começo abordando a gerência executiva (sou diretora de desenvolvimento de software e desenvolvedora ativa nesse grupo) para defender o cronograma, a equipe e o trabalho que está sendo realizado. Normalmente, nesse ponto, me dizem que o cliente precisa dele agora e tem que funcionar. Quando sei que não há espaço para negociação ou doação, volto e trabalho com a equipe para ver quais cantos podem ser cortados. Não sacrificarei a qualidade no recurso que está direcionando a necessidade do cliente para obtê-lo o mais rápido possível, mas algo irá e será empurrado para outro sprint. Isso quase sempre está OK.
Quando você não consegue entregar porque há muitos bugs, a qualidade do código está ruim e piora, e as linhas de tempo estão ficando mais curtas, então você está em uma situação diferente da que eu descrevo. Nesse caso, má administração atual ou passada, más práticas de desenvolvimento que levaram à baixa qualidade do código ou outros fatores podem levar você a uma marcha da morte.
Minha opinião aqui é fazer o possível para defender bons códigos e práticas recomendadas para começar a tirar sua empresa das trincheiras. Se não houver um único colega disposto a ouvir ou lutar contra o grupo contra a gerência, talvez seja hora de começar a procurar um novo emprego.
No final, a vida real supera tudo. Se você estiver trabalhando para uma empresa que precisa vender o que está desenvolvendo, encontrará esse compromisso diariamente. Somente lutando para alcançar bons princípios de desenvolvimento desde o início, consegui me manter à frente da curva de qualidade do código.
A pressão entre desenvolvedores e vendedores me lembra uma piada. "Qual é a diferença entre um vendedor de carros usados e um vendedor de software? Pelo menos o vendedor de carros usados sabe que está mentindo." Mantenha o queixo erguido e tente "fazer a coisa certa" à medida que avança.
fonte
Uma coisa que percebi em minha carreira é que sempre há tempo para fazer o que é certo. Sim, seu gerente pode estar pressionando. O cliente pode estar chateado. Mas eles não sabem quanto tempo as coisas levam para fazer. Se você (sua equipe de desenvolvimento) não faz isso, não está sendo feito; você mantém toda a alavancagem.
Porque você sabe o que realmente fará seu gerente levar você ou seu cliente a ficar chateado? Má qualidade .
fonte
Isso se resume ao que eu comecei a pensar como "O Conflito Eterno" (entre negócios e engenharia). Não tenho a solução, pois é um problema que nunca desaparece, mas você pode fazer coisas para ajudar a mitigar.
O que as pessoas geralmente não percebem é que, como engenheiros, estamos apenas assumindo que o problema de "negócios de sucesso" é sempre um dado. Queremos que nosso código seja agradável, limpo e de fácil manutenção, para que possamos adicionar novos recursos e ajustar os existentes rapidamente e com um mínimo de clientes fazendo o controle de qualidade, descobrindo casos bizarros que poderiam ser prejudicados por um código melhor. Manter os clientes e manter uma vantagem competitiva com recursos e requinte que ninguém mais pode produzir com rapidez suficiente são as duas vitórias nos negócios em que um bom código contribui diretamente e informa muito sobre a razão pela qual queremos um código melhor em primeiro lugar.
Então soletre. "Queremos fazer o X em nossa base de código porque, se não o fizermos, impactará negativamente os negócios devido a Y" ou "... porque aumentará nossa capacidade de permanecermos competitivos, melhorando nossa capacidade de ativar novos aprimoramentos e recursos mais rapidamente . "
E faça o seu melhor para tentar obter evidências tangíveis de que as melhorias estão funcionando. Se a melhoria de algum subconjunto de um aplicativo resultou em um recurso / aprimoramento mais rápido, verifique qualquer ferramenta de lista de pendências que você esteja usando para obter evidências disso e aponte-o nas reuniões apropriadas.
Os egos costumam ser um problema. Uma coisa que as equipes de engenharia precisam muito é estabelecer o valor de ter algum tipo de abordagem consistente e acordada para resolver certos tipos de problemas em relação a todos que fazem seu próprio copo de Kool Aid d'jour porque sabem melhor. Não há problema em acreditar que a preferência do outro cara é pior que a sua, mas valoriza a consistência em ser mais correto se a abordagem dele for viável e for um argumento que você não pode vencer. O compromisso por uma questão de consistência é fundamental. Quando as coisas são consistentes, é mais difícil fazê-las erradas, pois a maneira consistente estabelecida geralmente também será a maneira mais rápida.
Existem duas escolas de estruturas / conjuntos de ferramentas / bibliotecas / o que for. "Defina 99% disso para mim, então eu tenho que saber / fazer muito pouco" vs. "ficar fora do meu caminho quando não quero você lá, mas me ajude a fazer bricolage de maneira muito rápida e consistente com as coisas que eu realmente quero para usar na cenoura, em vez de usar o princípio da vara. " Favorecer o segundo. A flexibilidade e o controle granular nunca devem ser sacrificados no altar da recuperação rápida, porque, para começar, "não podemos fazer isso porque nossas próprias ferramentas não nos permitem" nunca é uma resposta aceitável e a pergunta sempre será feita por não- engenharia de produto trivial / descartável. Na minha experiência, ferramentas inflexíveis quase sempre são abertas ou trabalhadas de maneira deselegante e fazem uma grande bagunça gigante e inatingível. Mais frequentemente do que não, as soluções flexíveis / mais fáceis de modificar são tão ou quase tão rápidas quanto no curto prazo, independentemente. Rápido, flexível e sustentável são possíveis com as ferramentas certas.
Tenho a sensação de que essa é uma pergunta da perspectiva do desenvolvedor, mas já estive em muitas situações em que as decisões de tecnologia foram tomadas com zero entrada de engenheiro. Que diabo é isso? Sim, alguém precisa finalmente fazer a chamada final, mas obtenha algumas opiniões qualificadas se você for um gerente não técnico, não o que algum vendedor ou site de demonstração diz sobre seus próprios produtos. Qualquer coisa prometendo poupar dinheiro porque as pessoas não precisam ser tão inteligentes ou porque protege os desenvolvedores de si mesmas é uma mentira suja e suja. Contrate talentos nos quais possa confiar. Diga a eles o que você quer de uma pilha ou de outra solução tecnológica e leve a sério as informações antes de decidir em qual onda da tecnologia usar.
As ferramentas são para implementação e, como tal, podem ajudá-lo, mas a primeira prioridade deve ser a arquitetura, independentemente do conjunto de brinquedos que você tiver para construir essa arquitetura. No final do dia, o KISS e o DRY e todas as excelentes filosofias que se estendem a partir delas importam mais do que em .NET ou Java ou talvez em algo que é gratuito e não é ruim.
Quando o lado da empresa insistir para que você faça isso da maneira errada, salve esse email, especialmente a parte em que você disse por que isso custaria. Quando todas as suas previsões se tornam realidade e surgem sérios problemas que prejudicam os negócios, é aí que você tem uma grande pilha de argumentos para levar as preocupações dos engenheiros mais a sério. Mas tempo as coisas com cuidado. No meio do inferno ardente, é um momento ruim para um "eu te disse" seguindo o código de incêndio. Apague o fogo e leve sua lista de preocupações anteriormente ignoradas para uma reunião / conversa retrospectiva e tente manter o foco nas preocupações de engenharia expressas e ignoradas e o raciocínio que você entendeu por que elas estavam sendo ignoradas, não os nomes das pessoas reais tomando a decisão de ignorar. Você é engenheiro. Fique nos problemas, não nas pessoas. " Expressamos preocupação com o X porque temíamos que isso levasse a problemas em Y. Foi-nos dito que Z e adiamos lidar com isso ".
fonte
Existe apenas uma solução. Reserve de 10 a 20% do tempo do projeto / trabalho para refatoração. Se for difícil convencer o gerenciamento de que é uma tarefa justificável, forneça o único argumento real: sem refatorar, o custo da manutenção do código aumentará exponencialmente ao longo do tempo. É bom ter algumas métricas / artigos / resultados de pesquisa para fazer backup desta tese durante a reunião com o gerente :)
Edit: existem alguns bons recursos sobre "refatoração versus aumento dos custos de manutenção" mencionados neste white paper: http://www.omnext.net/downloads/Whitepaper_Omnext.pdf
fonte
Sempre que tiver tempo para fazer algo certo, use-o - escreva o melhor código possível e melhore-o constantemente. Não torne seu trabalho mais difícil, sendo desleixado e introduzindo dívidas técnicas quando não houver necessidade.
As chamadas de emergência para a correção de um bug grave não são coisas que você pode controlar sozinho; quando elas ocorrem, é preciso reagir o mais rápido possível, a vida é assim. Obviamente, se você tiver a impressão de que todo o seu trabalho consiste em chamadas de emergência e nunca tiver tempo suficiente para fazer as coisas corretamente, estará em um caminho para se esgotar e deve conversar com seu chefe.
Se isso não ajudar, ainda existe a "estratégia de Scotty" para obter tempo suficiente para fazer as coisas corretamente: multiplique todas as suas estimativas por um fator de 4:
http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/
fonte
Eu vejo meu trabalho como fornecendo o melhor software de qualidade possível dentro dos prazos permitidos para o projeto. Se estou preocupado que o nível de qualidade seja baixo, contratarei o proprietário do projeto. Descrevo minhas preocupações e discuto os riscos potenciais da implantação do software nesse estado. Uma das três coisas acontecerá neste momento:
O proprietário do projeto não vai querer aceitar os riscos e voltará o cronograma para nos permitir dedicar mais tempo à qualidade do software.
O proprietário do projeto não deseja aceitar os riscos, mas não pode mudar o cronograma. Se isso acontecer, precisamos negociar quais recursos / funcionalidades remover do escopo do projeto, a fim de dedicar mais tempo à qualidade do software para as principais partes do aplicativo.
O proprietário do projeto aceitará os riscos e o software de baixa qualidade sairá dentro do prazo. Às vezes, o risco comercial de não implantar nada (ou implantação tardia) é muito maior do que o risco comercial de implantar software de baixa qualidade, e somente o proprietário do projeto pode tomar essa decisão.
Escrever software é como pintar um retrato. É impossível dizer que um retrato é feito "certo" ou "perfeito". Perfeito é o inimigo do feito. Você poderia literalmente passar 1 mês trabalhando em um único método e ainda não ser considerado "perfeito" por alguns. Meu trabalho é pintar um retrato que o cliente esteja satisfeito.
fonte
Isso não funcionará em todos os casos, mas tive alguma sorte usando esta estratégia se o problema for um problema de produção quebrado que deve ser corrigido com urgência. Estime o tempo para fazer uma correção rápida para iniciar a produção e o tempo para fazer a correção da qualidade no futuro. Apresente as estimativas ao seu chefe / cliente e aprove o tempo aprovado para ambos. Em seguida, você faz a correção rápida para obter a execução da produção e uma correção a longo prazo imediatamente depois que a pressão de tempo urgente está desligada. Acho que, se eu o apresentar conforme preciso desse tempo para fazer o trabalho corretamente, mas posso colocar uma correção temporária até que eu possa fazer isso, para que meus clientes pareçam gostar dessa abordagem. Faz com que o prod funcione novamente e atenda às necessidades de longo prazo.
fonte
O equilíbrio ideal pode ser gastar tanto tempo extra fazendo da maneira correta quanto você gastaria corrigindo os bugs eliminados fazendo a coisa certa. Evite dourar a solução. Na maioria dos casos, a solução Volkswagen corretamente é tão boa quanto a solução Cadillac. Geralmente, você pode atualizar mais tarde quando for comprovado que você precisa do Cadillac.
A correção do código que não segue as práticas recomendadas geralmente leva muito mais tempo. Tentar descobrir de onde vem o nulo quando a chamada se parece com abcde () pode demorar muito tempo.
A aplicação de DRY e a reutilização do código existente geralmente são muito mais rápidas que a codificação e o teste de outra solução. Também facilita a aplicação de alterações quando elas ocorrem. Você só precisa alterar e testar um conjunto de códigos, não dois, três ou vinte.
Procure um código básico sólido. Pode-se perder muito tempo tentando torná-lo perfeito. Existem práticas recomendadas que levam ao código que é rápido, mas não necessariamente o mais rápido possível. Além disso, tentar antecipar gargalos e otimizar o código à medida que ele é criado pode ser desperdiçado tempo. Pior ainda, a otimização pode desacelerar o código.
Sempre que possível, forneça a solução de trabalho mínima. Vi semanas desperdiçando soluções de revestimento de ouro. Seja extremamente cuidadoso com o escopo.
Passei algum tempo trabalhando em um projeto que deveria levar seis meses. Quando entrei, estava em andamento há um ano e meio. O líder do projeto fez ao gerente de projeto uma pergunta no início: "Você quer que eu faça o que é certo ou responda?" Em uma semana, um recurso foi implementado segunda, quarta e sexta-feira; Terça e quinta-feira, o recurso foi removido.
EDIT: Quando o código é feito para um nível satisfatório, deixe-o. Não volte para corrigi-lo se você encontrar uma maneira melhor de fazê-lo. Se você deve fazer uma anotação. Se forem necessárias alterações, revise sua ideia e implemente-a se ainda faz sentido.
Se houver lugares onde você implementaria extensões para os próximos recursos, não implemente as extensões. Você pode deixar um comentário no marcador para lembrá-lo de onde fazer as alterações.
fonte
Faça o trabalho, em seguida, faça-o perfeito
Posso dar um pouco de folga para isso - mas se o tempo é essencial, sua principal prioridade deve ser fazê-lo funcionar, simples assim. Comente amplamente sobre as deficiências do seu código e anote o que você fez em qualquer software de gerenciamento de projetos / tempo que esteja usando.
Espero que isso lhe dê mais tempo para retornar a esses problemas e torná-los perfeitos.
Obviamente, não existe uma resposta correta absoluta para isso, mas é uma resposta que tento seguir. Você pode não achar adequado para o seu estilo de trabalho atual. O que me leva à alternativa ...
Basta encontrar um método que funcione para você ; e depois fique com ele. Todo mundo tem sua própria maneira de lidar com projetos e não existe uma abordagem "tamanho único". Encontre uma abordagem e torne-a sua.
fonte
"Fazer certo" significa fazer as trocas certas para uma situação específica. Alguns deles são:
Obviamente, se um pedaço de código for usado uma vez e jogado fora, o número 2 poderá ser sacrificado por qualquer um dos outros. (Mas cuidado: você pode pensar que vai jogá-lo fora e descobrir que precisa continuar usando-o e mantendo-o; nesse momento, será mais difícil convencer as pessoas a dar tempo para melhorar algo que "funciona".)
Se você e / ou sua equipe continuarão usando e atualizando algum código, usar atalhos agora significa apenas diminuir a velocidade mais tarde.
Se você está atualmente entregando código de buggy (fraco no 4) e demorando muito tempo para fazê-lo (fraco no 1), e é porque você está tentando atualizar o código fraco no 2, bem, você obteve um argumento sólido e pragmático para mudar suas práticas.
fonte
Se for um bug, faça o mais rápido possível, se for um novo recurso, não se apresse.
E se você trabalha para uma empresa que não respeita o trabalho do desenvolvedor, pode não ter escolha, mas fazê-lo rapidamente e sacrificar a qualidade.
Já trabalhei para várias empresas que iriam de um projeto para outro e faziam tudo rápido. Por fim, eles tiveram pouco sucesso em todos os projetos porque a implementação (não apenas a programação) foi apressada.
As melhores empresas do mercado entendem que um bom software leva tempo e habilidade.
fonte
Em caso de emergência, crie a solução de correção. Crie um novo bug no rastreamento de erros mencionando isso. Faça tudo certo sempre que tiver tempo.
fonte
Acho que faço o que todo mundo que está preso trabalhando nessa indústria faz. Eu faço o mais rápido possível e, se tiver que deixar de fora algumas das coisas legais que ajudariam a evitar problemas no futuro ou a facilitar a resolução de problemas no futuro, eu faço. Não é uma situação ideal, mas quando você está preso a prazos com base em estimativas baseadas em estimativas, com base em muitas variáveis desconhecidas, é praticamente o melhor que você pode fazer.
fonte
Aqui está um bom plano:
fonte
Faço a maioria das coisas da maneira rotineira, a primeira que me vem à mente. Isso é rápido e eu gosto de pensar que sou um programador decente e que faço quase tudo razoavelmente bem na primeira tentativa.
De vez em quando (eu gostaria de dizer duas vezes por dia, mas duas vezes por semana é mais realista), especialmente quando acho algo extremamente chato de fazer na rotina, penso "qual seria uma maneira IMPRESSIONANTE de fazer isso" ? " e passo o tempo extra para encontrar ou inventar uma maneira melhor de fazê-lo.
Se eu continuar fazendo isso com bastante frequência, minha codificação de rotina continuará melhorando, eu acho.
fonte
Software é uma coisa estranha e o processo de desenvolvimento de software é mais estranho.
Ao contrário da maioria das coisas na vida real, mas como a maioria das coisas relacionadas aos computadores
Mais rápido é mais confiável
Isso vai contra todas as intuições que a sua vida até agora lhe ensinou, carros altamente afinados quebram com mais frequência do que os carros comuns, casas construídas rapidamente desmoronam mais rapidamente, o dever de casa feito na parte de trás do ônibus escolar não recebe notas altas.
Mas procedimentos metódicos lentos não produzem software melhor. Pessoas que passam semanas produzindo documentos de requisitos e dias nos diagramas de aula antes de escrever o código não produzem software melhor. O cara que obtém o requisito básico, esclarece alguns problemas, rabisca um diagrama de classes no quadro branco e obtém a codificação de sua equipe quase sempre produz software mais confiável e melhor, e o faz em dias e não em meses.
fonte
O trabalho não é adequado para você.
Código de baixa qualidade escrito "porque não há tempo, os clientes estão esperando, um bug deve ser corrigido da noite para o dia, a empresa está perdendo dinheiro com esse problema, um gerente está pressionando bastante" é um sintoma de uma empresa mal gerenciada.
Se você deseja se orgulhar de seu trabalho e escrever um código de alta qualidade, a melhor coisa a fazer é encontrar um empregador que entenda isso e pagará para você fazer isso.
fonte