Como você equilibra entre "faça o certo" e "faça o mais rápido possível" no seu trabalho diário? [fechadas]


180

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.


12
Simples: faça o que é certo e faça-o rápido
ren

158
@ren: Bem, acho que você não é um programador, você é um gerente :-)
Flot2011

44
Obrigatório. xkcd.com/844
MikeTheLiar

5
Faça o mais rápido possível. Então, se você ainda tiver tempo, faça o que é certo.
Laurent Couvidou

8
Como o tio bob diz: O caminho mais lento é o caminho mais rápido. Aproveite o tempo necessário para escrever esses testes de unidade e escreva bem seu código. Isso pode levar um pouco mais de tempo para o recurso ser implementado, mas economizará tempo a longo prazo, pois será mais fácil para outros modificarem e corrigirem erros.
martiert

Respostas:


106

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.


14
"Muitas vezes, a equipe de vendas nos coloca em apuros apenas para obter uma comissão" - em que momento você considera que as vendas devem ser responsabilizadas por vender algo que a empresa não pode entregar - supondo que exista uma? Você tem exemplos em que eles cruzaram a linha entre marketing agressivo e vendas exageradas?
Tom W

8
@ TomW: Eu tenho vários exemplos internos, detalhes que não pude postar aqui, mas quando isso acontece quase sempre acontece quando precisamos de uma conta de referência ou perto do final do trimestre. Temos alguns vendedores muito bons e outros nem tanto. Recentemente, houve uma grande mudança na limpeza da casa, uma vez que foi determinado que o desenvolvimento não era o problema e toda a estrutura de vendas mudou para melhor. As coisas estão indo maravilhosamente desde então. Eu adoraria ser mais específico, mas não posso.
precisa saber é o seguinte

9
+1 - "Não vou sacrificar a qualidade no recurso que está levando os clientes a obtê-lo o mais rápido possível, mas algo dará" ... isso foi fantástico.
Joel B

59
@TomW - Eu sempre gosto de ressaltar que o principal arquiteto naval do Titanic que alertou contra o corte de custos (Thomas Andrews) afundou com o navio, enquanto o principal vendedor de vendas / marketing que insistia em cortar custos e fazer as coisas o mais rápido possível (Bruce Ismay) escapava em um barco salva-vidas.
precisa saber é o seguinte

4
Eu adoraria ter o tempo de digitar uma resposta como esta, mas tenho um cliente que reclama com meu chefe no telefone. "Muitas vezes, a equipe de vendas nos coloca em apuros apenas para obter uma comissão". O mesmo aqui ... mas de alguma forma eles ainda recebem esses bônus!
Kenzo

62

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 .


43
Embora normalmente haja tempo para fazer um bom trabalho, normalmente não há tempo para fazê-lo perfeitamente. Há um mundo de diferença entre os dois.
Donal Fellows

2
@DonalFellows, é claro. 'Certo' é sempre "seguir as melhores práticas, usando nosso melhor entendimento do problema neste momento, da melhor maneira possível". Pessoas cometem erros. Alteração de requisitos. As melhores práticas mudam. Não corte cantos e refatorar quando as coisas acontecem.
Telastyn

3
@DonalFellows - "O inimigo da excelência é a perfeição". Um programa escrito de maneira sustentável, que atenda aos requisitos dos clientes e com desempenho aceitável, é um programa "pronto". Nada de torre de marfim sobre isso.
Keiths

1
@DonalFellows Ninguém usou a palavra perfeito, uma solução perfeita é uma solução errada, Telastyn está falando de uma solução correta. A solução certa é aquela que atende aos requisitos e é improvável que cause problemas no futuro, além de ser fácil de manusear no caso de ocorrer. Os absolutos estão sempre errados.
Jimmy Hoffa

7
+1 - Para Telastyn, embora todos os clientes queiram fazer suas coisas agora. MUITO MAIS clientes querem que suas coisas funcionem mais do que fazê-las agora. Parece que todo mundo que discorda de Telastyn afirma que perderá um cliente se isso não for feito rapidamente. Essa é de longe a exceção e não a regra. Qual é a regra, que a maioria das pessoas que discorda, é que elas estão ignorando que perderão muito mais clientes ao entregar produtos de má qualidade. A alegação de que o cliente deseja agora é a desculpa usual de pessoas que não se importam com a qualidade. Portanto, sou cético em relação ao risco reivindicado.
Dunk

21

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.

  • Comunicar Valor

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.

  • Coloque a equipe na mesma página

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.

  • Escolha as ferramentas certas

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.

  • FFS, se os engenheiros não decidirem, pelo menos, obtenha informações do engenheiro sobre a escolha das ferramentas

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.

  • Concentre-se no design e na implementação

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.

  • Registre suas preocupações

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 ".


Resposta muito agradável e aprofundada. Devo acrescentar que já experimentei um caso ruim de escolher as ferramentas certas , o que produziu uma grande perda de tempo. Poderíamos enviar o produto um mês depois, após a decisão de abandonar esse produto e usar algo que não nos bloqueia.
mhr

1
Eu me sinto bem com essa resposta, mas também acabei de encontrar meu primeiro emprego, onde biz e dev não estão constantemente na garganta um do outro e o impacto é maravilhoso. Acabamos de fazer as coisas. Nem sempre assim que queremos, mas levamos em conta o futuro e isso mostra tanto no produto quanto em nossa capacidade de modificá-lo conforme as necessidades mudam. Inevitável Big Ball of Mud é uma mentira, IMO.
precisa saber é o seguinte

19

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


12
Existe uma opção melhor: tornar a refatoração parte do seu hábito regular de codificação. Diariamente. De hora em hora. Sempre que você adiciona ou altera uma função. Portanto, você não precisa reservar um tempo extra para isso ou "convencer a gerência".
Doc Brown

Só é válido quando você não precisa lidar com o código que já está escrito. É uma tarefa comum agregar novo valor ao código-fonte antigo / herdado / herdado. Mas quando você olha para esse código, não sabe por onde começar e sente que é mais fácil escrever esse código novamente do que aprender como ele funciona. Tente justificar essas estimativas: dois dias para adicionar novo valor, seis dias para refatorar o código antigo e torná-lo sustentável. É frequente ouvir "não refatorar, basta adicionar o novo valor, descobriremos mais adiante o que fazer com esse código antigo".
Andrzej Bobak

1
@ Flot2011 Então você tem apenas uma solução. Deixe a refatoração "cotidiana" ser sua tarefa de rotina. Por exemplo, toda terça-feira, concentre-se apenas na melhoria da qualidade do código. Certifique-se de que seja respeitado pela gerência e verifique se a refatoração não é uma perda de tempo. Sem essas duas condições, mais cedo ou mais tarde, eles abandonarão a idéia de melhorar "algo que já está aqui e está funcionando".
Andrzej Bobak

1
@DocBrown Funciona quando você fala com a gerência. Se você falar com o desenvolvedor sênior e disser a ele, você adicionará dois campos ao formulário e levará 3 dias ... Bem, boa sorte :).
Andrzej Bobak

2
Ter que aumentar suas estimativas para obter tempo de manutenção é problemático por vários motivos. Às vezes, vale a pena incorrer em dívidas técnicas. O que acontece quando o biz percebe de repente que, em uma situação de emergência, foram necessários 15 minutos para colocar dois novos campos na última vez em que levou 8 dias. Na IMO, os negócios precisam estar conscientes da dívida tecnológica e do impacto a longo prazo que ela tem. O problema precisa ser entendido como você paga agora ou paga 5 vezes mais tarde quando tudo estiver pronto.
Erik Reppen

14

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/


A estratégia de Scotty funciona. Só não deixe seu chefe saber que você está fazendo isso. Muitas vezes, o tempo que leva na realidade é o dobro. É sempre melhor terminar mais cedo do que tarde.
Lucas

11

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:

  1. 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.

  2. 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.

  3. 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.


7

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.


7

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.


A menos que DRY signifique implementação confusa e ilegível de esquemas massivos de herança em cascata. Não faça isso. Desculpe, eu digo muito isso, mas eu realmente odeio isso. Além disso, +1 na solução de trabalho mínima na maioria dos casos. Às vezes, alguns recursos arquitetônicos prospectivos podem ser úteis, desde que você não exagere.
quer

1
@ErikReppen O código que é confuso, ilegível e uma implementação de esquemas maciços de herança em cascata falhariam na minha definição de DRY. Se você precisar descobrir o código toda vez que usá-lo, o design falhará claramente em DRY, mesmo que a implementação seja aprovada.
BillThor

Porém, pode envolver muita reutilização de código. A parte irritante é subir em uma árvore de 18 classes ou protótipos para encontrar a definição real de um método que está fazendo algo realmente irritante, especialmente se houver substituições.
quer

6

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.


3
Quando a gerência sabe, isso funciona. Eles aceitam o feito e não querem que você gaste nenhum outro esforço na refatoração, etc. #
Adronius 16/12/12

5

"Fazer certo" significa fazer as trocas certas para uma situação específica. Alguns deles são:

  1. Tempo e custo de desenvolvimento
  2. Facilidade de ler, depurar e atualizar o código posteriormente (tudo, desde nomes de variáveis ​​a arquitetura)
  3. Profundidade da solução (casos extremos)
  4. Velocidade de execuçã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.


1
Eu sugeriria: "Se NINGUÉM algum dia vai manter um pedaço de código ...": Escrever lixo, despejar e correr não deve ser uma opção (para quem tem consciência), mas acontece com muita frequência; empreiteiros / consultores / gerentes, certificando-se de que estão fora da porta com segurança antes de "ele" atingir o ventilador.
Phill W.

@PhillW. - concordo absolutamente. Editado de acordo.
Nathan Long

4

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.


3

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.


5
O problema é que quase nunca há tempo adequado, esse é exatamente o problema, e os erros desse tipo sempre terão a menor prioridade.
usar o seguinte texto

Eu diria que isso é verdade apenas se por "emergência" você quer dizer "algo que acontece não mais que uma vez a cada seis meses" e por "quando você tiver tempo" quer dizer "dentro de uma semana ou mais". Caso contrário, sua pergunta de acompanhamento se tornará "ajuda, o cliente precisa de algo o mais rápido possível, mas o código que preciso alterar é uma bagunça confusa e levarei semanas para resolver!"
Nathan Long

3

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.


3

Aqui está um bom plano:

  1. Faça com que o seu plano faça exatamente o mesmo tempo que faça o mais cedo possível.
  2. Otimize seu tempo para fazê-lo até que seu ambiente esteja feliz; mantenha a qualidade
  3. ???
  4. Sucesso

1

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.


1

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.


Não sei se concordo com você, mas é um ponto de vista interessante e pouco ortodoxo. +1 por pensar fora da caixa.
precisa saber é o seguinte

-1

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.