Combater a dívida técnica como o “desenvolvedor mais baixo”?


20

Digamos que você trabalhe para uma empresa e o que você faz é desenvolver software para elas. Você não tem idéia do quadro geral ou talvez leve. O que você tem são tarefas atribuídas a você por meio do sistema de rastreamento de problemas. Você recebe tarefas, as faz funcionar da maneira que a tarefa as descreve, as envia de volta. Como adicionar 2 números inteiros:

function add(a,b){return a + b;}

Porém, mais tarde, à medida que o projeto avança, você percebe que, à medida que addse torna mais complexo, percebe que ele deveria ter necessitado de alguma forma de arquitetura, mais do que apenas uma função que adiciona parâmetros e retorna um valor. No entanto, você não sabia disso. Em primeiro lugar, tudo o que eles precisavam era simples assim add. Você não esperava que o add se tornasse tão complexo.

O projeto avança com mais recursos, que você não esperava ter em primeiro lugar. E, no final, você continua acumulando hacks e camadas e mais camadas de funções para evitar a quebra / reescrita do código existente.

Como você lida com essas situações? Como você luta contra a dívida técnica como "o desenvolvedor mais baixo"?

Esclarecimento:

  • Você é o "implementador", o mais baixo da hierarquia.

  • Você vê o problema, mas não tem voz a dizer sobre o assunto.

  • Não estou quantificando dívidas técnicas ou procurando ferramentas.

  • Em relação ao terceiro "duplicado"

    • Refatoração e reescrita - Você está bloqueado para suas tarefas. Você não é pago para fazer extra.
    • Visão geral da arquitetura - Você conhece o sistema geral, mas não faz ideia da arquitetura.
    • Code Freeze - Não é sua ligação. Você não é gerente.
    • Modularização - Não faço ideia de arquitetura. Módulos mudam conforme os requisitos mudam.
    • Testes automatizados - Não existe.


3
@gnat, acho que as perguntas estão relacionadas (especialmente a última), mas não duplicadas. Vejo essa pergunta como "Como o arquiteto de um sistema não é o implementador e os implementadores não têm uma visão de alto nível do sistema, como pode ter certeza de que as implementações são suficientemente flexíveis ou escaláveis?"
MetaFight 04/04

1
Você está perguntando como combater a dívida técnica em geral, ou está perguntando como combater a dívida técnica quando está no papel de um codificador sem responsabilidade atribuída por melhorar a arquitetura?
Doc Brown

2
@JosephtheDreamer Sim, há muitas coisas que podem ser feitas para melhorar o código-fonte, mas você afirmou em sua pergunta que o problema é a falta de autoridade para agir sobre quaisquer alterações. Eu poderia lhe contar todas as melhores práticas, mas se você não tem permissão para investir uma quantidade enorme de tempo para implementá-las, então qual é o objetivo? ;)
Reactgular

2
" Mas as tarefas vêm das pessoas mais altas " - o que impede você de se dar algumas tarefas, além de " não sou pago por isso " hoje? Se você agir como uma abelha operária receptora de comando, será tratado como um.
JensG

Respostas:


22

Sempre que perceber algo assim, insira um novo ticket no seu sistema de rastreamento de problemas.

Crie o hábito de usar o rastreador de problemas como uma ferramenta primária para comunicar coisas desse tipo, porque a partir daí será fácil escolher, avaliar e priorizar seus colegas seniores / líder / gerente / quem for responsável por rastrear os problemas em seu projeto .

Use a ferramenta certa para o trabalho. Eu sempre faço isso e recomendo fortemente que você faça o mesmo.

Como exemplo, aqui está um ticket que criei cerca de um mês atrás. Após a conclusão de um recurso específico, descobri que o código se tornou substancialmente mais complicado do que era antes, mas não posso corrigi-lo no prazo estabelecido para a implementação do recurso.

(Os nomes dos recursos, tickets e código usados ​​no rastreador real são obscurecidos, mas o texto é copiado como está).

Resumo: simplifique o design envolvendoParticularPieceOfCode

Descrição:
No curso da implementação, de acordo com o TICKET-12345, o código que envolve o uso ParticularPieceOfCodeacumulou um pouco de complicação e tornou-se bastante difícil de ler, entender e manter (veja o exemplo de trecho de código abaixo).

Encontre uma maneira de simplificá-lo.

Um exemplo de código que seria desejável reprojetar pode ser encontrado em ClassName#methodName:

<a piece of code like one behind the right door here:>
http://i.stack.imgur.com/ARBSs.jpg


FWIW, meu conselho se aplica independentemente do "nível" que você é.

Eu tenho usado no seu nível atual ("mais baixo") e estou usando agora que meu nível está muito longe de "mais baixo" e tenho um "dizer" satisfatório, como você chama, e eu vou usá-lo sempre não importa o quê.

Pense nisso, sem nível, não importa quanta autoridade você tenha, simplesmente não pode haver melhor maneira.

Se você "disser" ei, temos um problema , é apenas um ruído de ar. E mesmo se seu chefe / líder concordar e disser que você está certo, temos um problema , isso não muda nada - é apenas um ruído de ar novamente, e não pode ser mais nada.

  • Você pode pensar que ter a sua opinião por escrito (por exemplo, por e-mail) seria melhor, mas se você pensar nisso, realmente não é. Se o seu projeto tiver atividades substanciais de correio, o que foi escrito será perdido e esquecido um mês depois.

Use a ferramenta certa para o trabalho. Para o trabalho que você descreve, o rastreador de problemas é exatamente a ferramenta certa.

Você percebe o problema, entra no sistema projetado para rastrear esses dados e cuida do resto, da melhor maneira possível - simplesmente porque foi projetado para isso :

pacote de software de computador que gerencia e mantém listas de problemas , conforme necessário por uma organização ... comumente usado ... para criar, atualizar e resolver problemas relatados de clientes, ou mesmo problemas relatados por outros funcionários dessa organização ... O sistema é semelhante a um " rastreador de erros " e, freqüentemente, uma empresa de software venderá os dois, e alguns rastreadores podem ser usados ​​como um sistema de rastreamento de problemas e vice-versa. O uso consistente de um problema ou sistema de rastreamento de bugs é considerado uma das "características de uma boa equipe de software" 1 ...

Quaisquer outros meios que você queira escolher para se comunicar, ter um ticket no rastreador apenas facilitará as coisas para você.

Mesmo se você preferir mexer no ar , dizer "Eu gostaria de discutir o TICKET-54321 ..." é um ponto de partida mais sólido do que "Ouça, eu gostaria de falar sobre algum código com o qual lidei há um tempo atrás. ... "E você pode passar com segurança as referências ao ticket pelo correio: mesmo se o correio for perdido, o problema ainda estará presente no rastreador, com todos os detalhes que você deseja informar.


7
+1 Um bom conselho, mas o rastreamento de problemas em um ambiente que não abraça o processo se torna um buraco negro. Que bom é um rastreador de problemas de uma pessoa. Na melhor das hipóteses, uma lista sofisticada de tarefas a fazer.
Reactgular

@MathewFoscarini antes da postagem, esclarei isso com o OP nos comentários (vinculado em "seu sistema de rastreamento de problemas" na minha resposta) - 'Sim, portanto, as "tarefas" (problemas, tickets, o que você quiser chamá-las) ...' Eu também não seria tão pessimista em relação a casos de "buraco negro", a longo prazo as coisas tendem a mudar, especialmente se os desenvolvedores de "nível mais baixo" tomarem uma iniciativa e investirem esforços para manter o rastreador e promover o uso deles (eles já fizeram isso )
gnat

Além disso, vi pessoas sendo acusadas de poluir o sistema de tickets (= abrir "muitos") tickets. Se a cultura não se encaixar, nenhum sistema de tickets ajudará. Infelizmente, tecnicamente, as pessoas tendem a procurar uma ferramenta técnica em vez de uma solução, e outras pessoas pensam nisso como um bom conselho, porque se encaixa em seu processo de pensamento.
JensG

1
@JensG "pessoas acusadas de poluir o sistema de ingressos" - este é um fenômeno conhecido, provavelmente merecedor de uma pergunta dedicada (ou talvez já tenha sido feita e respondida, eu não procurei). Se a cultura não se encaixar, são necessários esforços específicos adicionais necessários para que o sistema de tickets se torne útil (como escrevi em comentários anteriores, já fiz isso antes).
mosquito

8

O que me faz sentir mal com o seu cenário é exatamente o que você escreveu no título e várias vezes no texto da pergunta:

Você é o desenvolvedor mais baixo da cadeia

Por que esse ponto é tão importante? Bem, primeiro de tudo, e de um ponto de vista puramente tecnológico, você certamente está certo. Você é contratado como o que chama de "implementador" das coisas, uma abelha operária que age de acordo com os comandos dados.

Mas mesmo se você for o desenvolvedor mais baixo em relação à classificação, isso ainda não está certo. A chave aqui é perceber que você está apenas se percebendo como sendo o desenvolvedor mais baixo. Você já tentou superar essa autopercepção e realmente assumir a responsabilidade por alguma coisa ?

Toma! Não espere, até que alguém o torne responsável.

  • Você vê o problema, mas não tem voz a dizer sobre o assunto.
  • Não estou quantificando dívidas técnicas ou procurando ferramentas.
  • Você está bloqueado para suas tarefas. Você não é pago para fazer extra.
  • Não é sua ligação. Você não é gerente.

Normalmente, é o contrário: você recebe mais e sua opinião é respeitada mais, depois de mostrar que vale a pena . É "faça antes de ter", e não o contrário.

O que espero das pessoas da minha equipe é exatamente isso: Um senso de responsabilidade pelo projeto ou produto que estamos tentando criar e por todos os processos relacionados a esse esforço. Sempre que alguém da minha equipe me impressiona assumindo a responsabilidade, por exemplo, propondo melhorias ou ainda melhor começa a melhorar as coisas por conta própria, essas são as pessoas que serão promovidas.

Em outras palavras: ninguém promove as abelhas operárias, as pessoas aguardam passivamente as tarefas que lhes são atribuídas, sem o menor piscar de iniciativa " porque elas não são pagas por isso ", finalmente choramingando que nunca tiveram chance.

Obviamente, tudo isso depende da cultura da sua empresa, com a qual Joel se refere nas "Duas histórias" vinculadas por Arthur. Se os gerentes da empresa são realmente tão estúpidos para impedir seu próprio pessoal de progredir, então a taxa de flutuação provavelmente já é muito alta e pode ser hora de tirar conclusões disso. Mas, se esse não for o caso, o verdadeiro problema pode estar dentro de você.


8

Você é um profissional. Seu empregador contratou você para ser profissional. Assim, tratar suas preocupações da mesma forma que você gostaria profissionais que você contratar para tratar seus profissionais opiniões . Em particular, você espera que outros profissionais façam as otimizações e correções necessárias ao longo do caminho, desde que essas otimizações não aumentem inesperadamente o custo.

Por exemplo, suponha que você leve seu carro a um mecânico para substituir uma lâmpada. O mecânico percebe quatro coisas:

  1. O fio que leva à lâmpada está desgastado e perigoso. Mas, pode ser aparado sem aumentar notavelmente o custo. Você esperaria que ele levasse alguns minutos para cortar o fio, possivelmente sem nem perceber.
  2. Um parafuso está solto. É totalmente independente, ele acabou de vê-lo. São 20 segundos para pegar o motorista necessário e apertá-lo; então, você esperaria que ele fizesse isso.
  3. O chassi da lâmpada está rachado, o que fará com que a lâmpada chacoalhe. É caro substituir. E não é essencial. Então, ele chama você para perguntar sobre isso - se você diz "não", ele coloca uma recomendação por escrito no resumo da sua visita.
  4. Há uma boa quantidade de fluido de freio embaixo do carro. Ele deve, e pode até ser exigido como profissional, impedir que você use o carro até permitir que alguém conserte o vazamento.

Cada um desses cenários, e tenho certeza que outros, têm paralelos no desenvolvimento de software - especialmente se você se considera um profissional de qualquer nível . Como profissional, com muito poucas exceções, seu trabalho é atingir o objetivo final de melhorar o produto de uma maneira específica, de acordo com sua compreensão profissional .

  1. Se a correção for trivial, independente ou não, faça a correção.
  2. Se a correção não for trivial e desnecessária, faça uma recomendação formal usando o mecanismo formal de comunicação / rastreamento de problemas com o qual você concordou.
  3. Se for possível concluir que a correção é necessária para realizar a tarefa principal, mas aumentará inesperadamente o custo, comunique a alteração do escopo.
  4. Se o problema identificado representar uma séria ameaça ao sucesso do projeto, deixe isso claro. Formalmente. Se houver preocupações éticas em permitir que o problema não seja corrigido (como nos sistemas de saúde, emergência ou transporte), insista em abordar o problema antes que o produto seja enviado (notifique a mídia ou as autoridades, se for necessário eticamente).

Essa resposta é exatamente o que eu faria. Não coloco tarefas mesquinhas de refatoração no rastreador de problemas. Eu apenas refatoro. Colocar cada pedacinho de dívida técnica no backlog de problemas apenas cria uma enorme lista de problemas, o que dificulta a obtenção de visibilidade e, quando alguém trabalha nessa tarefa, o problema pode desaparecer, mudar de forma , piorou, mudou-se ou quem sabe o quê. Se demorar 5 minutos, conserte-o!
Brandon

5

Você faz isso da mesma maneira que um funcionário de um escritório de advocacia luta contra comportamentos antiéticos, um funcionário de fast-food luta contra comportamentos insalubres ou um policial de estacionamento combate a corrupção policial.

  1. Seja um bom exemplo. Na medida do possível, produza um código limpo e sensível. Quando tiver uma escolha, escolha aquela que atenda às suas necessidades com menos desvantagens. (Esteja ciente de que a dívida técnica não é diferente da dívida hipotecária - apenas tê-la não é necessariamente uma coisa ruim.)
  2. Comunique suas preocupações . Você deve ter alguém, um líder de equipe ou cliente ou arquiteto, que tenha a responsabilidade real de gerenciar a dívida técnica e alocar os recursos da sua empresa. Quando vir algo que considera ruim, comunique sua preocupação a eles. Escreva por escrito (por exemplo, um e-mail) se não tiver certeza de que eles entenderão, responderão e darão crédito por sua contribuição.
  3. Não se estresse. A dívida técnica raramente causa a falha no término do emprego de uma empresa. Desde que você comunique suas preocupações e faça seu trabalho, problemas de arquitetura, como dívida técnica, literalmente não são problema seu. Sim, eles podem afetá-lo, mas não são mais sua preocupação do que a reeleição de um xerife é a preocupação de um policial mais novo.

No exemplo que você forneceu, com uma addfunção que sofreu uma fluência completa no recurso, reserve alguns minutos e rascunhe o esboço do que o melhoraria. Envie isso para quem você precisar de aprovação para implementá-lo e siga em frente.

Supondo que sua empresa foi gerenciada por pessoas extremamente competentes e estruturada corretamente, sua preocupação seria encaminhada para o projetista de sistema certo para uma decisão ou você teria uma margem de manobra para implementar sua sugestão. Como desenvolvedor júnior, eu me preocuparia mais em aprender como sua empresa funciona do que em dívida técnica - e, se você conhece o primeiro, como lidar com o último deve ser óbvio.


2
"Dívidas técnicas raramente causam o fracasso no término do emprego de uma empresa". Eu não teria tanta certeza. A razão por trás da falha de muitos projetos de software é uma dívida técnica.
eufórico

2
Um projeto não é uma empresa, @Euphoric. O Mozilla não está extinto apenas porque o Sunbird nunca decolou. Se o seu projeto falhar, você passa a um novo projeto com o mesmo empregador. Se sua empresa falhar, você precisará encontrar um novo emprego.
DougM

Esta resposta está muito errada. Vi dívida técnica destruir um produto da empresa. E quanto a "tecnicamente a dívida literalmente não é problema seu", cuja responsabilidade é essa, se não os desenvolvedores de software?
Brandon

2

Nunca ouvi falar de uma organização que não quisesse que seus funcionários participassem. Você diz que você é pago apenas para executar as tarefas. Sinceramente, duvido que você tenha as tarefas certas em mente. Porque você é pago para escrever um bom software.

Assuma essa responsabilidade. Diga não à adição de recursos se você não puder suportar a base. Aconselhe o cliente com sua experiência. Pise no freio agora, antes que seja tarde demais e você tenha que jogar fora todo o projeto, porque ele não será mais sustentável.


4
Essa é apenas a sua opinião ou você pode apoiá-la de alguma forma? No nível OP ("mais baixo"), "pisar no freio, dizer não" na minha experiência, raramente acabava bem. Nem por projeto, nem por carreira. Olhando para trás, lembro-me claramente de casos em que perdi uma coisa ou duas ao "dizer não" contra a visão dos colegas seniores / líder / gerente #
396

Em termos de recursos humanos, colocar as pessoas atrás de multas de trabalho sem lidar com as preocupações com o valor do trabalho provavelmente acabará em um desastre. Trabalhadores felizes trabalham mais por menos, há provas econômicas disso. Pisar nos freios é uma oportunidade de aprendizado para os jovens e para a gerência. Pisar nos freios é como as startups podem ser tão competentes em tão pouco tempo, não temos ingressos friggin. Pode surgir conflito, mas o conflito faz parte da maldita vida. Preocupar-se com a qualidade deve ser ouvido e reforçado, por isso estou no passo do lado dos freios.
Arthur Havlicek

2
Eu recomendo essa leitura que tratam sobre devs baixo nível capacitar joelonsoftware.com/articles/TwoStories.html
Arthur Havlicek
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.