Lidar com gerenciamento que não vê valor em melhorias que não são imediatamente visíveis para o usuário

90

Eu posso entender a pressão do cronograma. Você quer agradar seus usuários, pois eles são a força vital da empresa. No entanto, também é verdade que algumas mudanças facilitarão tudo no futuro. Infelizmente, o gerenciamento em minha organização tem uma resistência instintiva a essas mudanças e essa resistência é tão strong que atrapalha as melhorias a longo prazo.

Por exemplo, a Apple introduziu recentemente o Automatic Reference Counting para programas iOS. Essa é uma grande melhoria em relação às chamadas manuais de retenção / liberação que anteriormente precisávamos usar. O código é mais fácil de escrever e mais fácil de manter. A mudança em si é susceptível de produzir algumas falhas. Mas uma vez que isso seja resolvido, é provável que o número de acidentes esquisitos aleatórios caia.

Mencionei recentemente ao meu chefe que queria mudar para a contagem de referência automática. Sua resposta foi que ele queria se concentrar em melhorias visíveis. É provável que essa resposta tenha sido impulsionada pela pressão que ele está recebendo de cima dele - e provavelmente do CEO.

Existem muitos exemplos semelhantes. O ponto comum é que algo precisa ser consertado, mas os custos de curto prazo da correção superam os benefícios de curto prazo, em que "curto prazo" é definido como "dentro das próximas semanas".

Como devo lidar com a situação?

EDIT: Obrigado pelas respostas. Continue vindo. Por ser relevante para a minha situação, devo deixar claro que meu gerente e o CEO são ambos programadores - embora o CEO possa até agora ter esquecido como é isso. Aparentemente, seus lados programadores foram esmagados por outras pressões.

    
por nameWithHeldToProtectTheGuilty 02.02.2012 / 02:33
fonte

19 respostas

141

Você está realmente falando sobre a dívida técnica . Talvez uma metáfora ajudaria seus gerentes. Costumo comparar o efeito da dívida técnica em software para cozinhar em uma cozinha suja. Se a pia e os balcões e o fogão estiverem cheios de louça suja e houver lixo no chão, levará mais tempo para fazer uma refeição. No entanto, a maneira mais rápida de preparar a próxima refeição é contornar a bagunça. Limpar a cozinha e mantê-la limpa atrasará a próxima refeição, mas melhorará a entrega de todas as refeições subsequentes. E assim como a pessoa com fome na sala de jantar não pode ver a cozinha bagunçada e não vai entender por que você quer limpar antes de começar a cozinhar, sua gerência não pode ver a confusão no código. Você precisa mostrar a eles a bagunça ou mostrar os problemas de qualidade e atrasos causados pela bagunça.

Talvez você também possa conversar sobre tarefas urgentes e tarefas importantes. Quando tarefas importantes não são realizadas, as tarefas urgentes demoram mais e custam mais.

    
por 03.02.2012 / 20:21
fonte
47

Você se deparou com algo que atormenta os programadores em qualquer lugar em algum ponto de suas carreiras: esse código precisa ser refatorado, há questões arquitetônicas, esse módulo está se tornando inatingível etc. da cultura atual da sua organização, no entanto, você está sendo forçado a se concentrar no trabalho que apenas produz benefícios diretamente visíveis .

É o clássico Segredo do Iceberg mais uma vez. O segredo tem a ver com o fato de que, assim como um iceberg está 90% debaixo d'água, a maioria dos qualquer projeto de desenvolvimento é: 90% do trabalho será completamente invisível para o usuário final. . Esse código terá um impacto no usuário final, mas o gerenciamento tem dificuldade em entender por que você passou seis horas refatorando as chamadas de manutenção / lançamento e de referência automática quando Não conseguem ver nenhuma diferença e tudo está Trabalhando bem.

Aqui estão alguns fatos que você pode levar com você sobre esse assunto.

  • Gerenciamento, a menos que eles próprios sejam programadores , não vão entender o segredo do Iceberg.
  • Este é um problema de ignorância, não de malícia. O CEO quer um bom produto - ele simplesmente não entende tudo que entra em um bom produto.
  • O CEO (e seu chefe direto) não é estúpido - estude e prepare alguns fatos e alguns dados concretos para por que você deve gastar tempo com isso e com outros problemas de Iceberg.

Não esqueça - você é um homem da empresa (ou mulher). Não é um homem de código. Você está desenvolvendo este produto para uma empresa que tem interesse em seu sucesso ou fracasso - seus projetos e propostas de projetos devem refletir isso. Mostre sua paixão pela empresa e pelo produto, mostre seu conhecimento e prove ao seu chefe e CEO que eles devem confiar em você quando você vier até eles e disser que o Something Needs Work funciona. Mostre-lhes como isso contribuirá para o resultado final - seja agregando valor ao produto (mais pessoas comprando cópias) ou economizando tempo (menos clientes irritados quando o produto falha).

    
por 01.02.2012 / 17:44
fonte
36

Você não faz.

Eu vejo essa pergunta e todas as perguntas como um beco sem saída. Você não pode "convencer" as pessoas de nada. Se eles já não estão cientes de coisas como esta ou investigando, as chances são de que eles não dêem a volta. E nenhuma quantidade de dados irá convencê-los do contrário. A mudança deve vir de dentro. Você pode levar um cavalo à água, mas não pode fazê-lo beber.

Eu digo as alterações desejadas em suas próximas estimativas técnicas. Seja como, ei, nós "temos que" atualizar para este novo framework que a Apple introduziu. Não deixe de usar o ARC no seu roteiro. Não há opções; migrar para o ARC é o único caminho.

    
por 01.02.2012 / 18:38
fonte
28

Eu já respondi a uma pergunta semelhante antes, então isso pode ser considerado uma duplicata. Basicamente, você não vai se desligar para fazer um "esforço de refatoração". A maneira como você faz o código mais limpo é seguir a regra do escoteiro: sempre deixe o código mais limpo quando sair do que quando você chegou.

Assim como pagar dívidas reais pode parecer uma tarefa insuperável (ou limpar uma casa bagunçada). O truque é torná-lo melhor pedaço por pedaço até que você comece a ver "ilhas de limpeza". Uma vez que você tenha um momento significativo, outros desenvolvedores da equipe começarão a perceber e, eventualmente, contribuir para a tarefa.

Sugiro ler o Clean Coder do "Uncle" Bob Martin. Escrever um bom código faz parte do seu trabalho. Você não pede permissão para fazer o seu trabalho, apenas o faz.

    
por 01.02.2012 / 20:02
fonte
7

Como com outras questões dessa natureza, você precisa fornecer números que a gerência entenderá. Números que mostram quanto tempo será economizado com a implementação dessas melhorias, quantas menos "falhas estranhas aleatórias" ocorrerão, etc. Convença-as de que as falhas são visíveis para o usuário final e que qualquer coisa feita para evitá-las é boa para os negócios. / p>

Você também pode tentar implementar essas melhorias em seu próprio ritmo (ou seja, fora do horário de trabalho) e mostrar os benefícios ao gerenciamento posteriormente. Eu só faria isso quando estiver claro que a gerência não entende o que você está tentando transmitir e / ou que eles não querem alocar tempo para você sequer tentar.

Boa sorte!

    
por 01.02.2012 / 17:34
fonte
7

Apresentar um caso de negócio

Existem muitas razões pelas quais as recomendações de engenharia costumam ser ignoradas. A melhor maneira de lidar com quase todas as razões é apresentar o caso de negócio de por que isso deve ser feito. A análise clássica de custo / benefício. Isso não só faz um argumento convincente, mas também dá aos seus patrões algo para levar aos seus superiores.

  • Qual é o custo inicial?
  • Qual é o custo contínuo?
  • Quais são as economias projetadas de dinheiro / tempo e de onde elas vêm?
  • Quanto tempo levará até vermos o ROI?

Ao fazer um business case, você deve sempre fazer o backup de seu argumento com dados.

  • Quanto tempo o desenvolvimento atualmente está gastando para lidar com problemas que isso removerá ou atenuará?
  • Quantas reclamações de usuários você recebe relacionadas aos problemas que isso removerá ou atenuará?
  • Que outros benefícios terá?

Alinhe os números e faça uma equação simples, mas simples. Vai custar X para fazer e beneficiará a empresa Y.

Observação: não se surpreenda se for proibitivamente caro implementar uma ideia academicamente boa.

    
por 01.02.2012 / 23:47
fonte
6

Esse tipo de mudança cai na categoria de refatoração. A abordagem Agile seria que você deveria incorporar o tempo de refatoração AMPLE em cada história estimada e é exatamente por isso. Além de engenheiros, ninguém vai entender por que você quer fazer isso e tudo bem, não é o seu trabalho para determinar como codificar corretamente, é seu.

Então, da próxima vez que você tiver um trabalho para fazer, certifique-se de que essas mudanças sejam parte disso. Se você estiver fornecendo estimativas, adicione 30% à sua estimativa para a refatoração, se você não estiver fornecendo estimativas, faça a refatoração como parte do seu trabalho.

Isso pode deixar você mais devagar - bem, não, essa não é a maneira de encará-lo, a maneira de encará-lo é que sua velocidade atual é uma ilusão, essencialmente uma mentira de que você está passando a corrente. deve ser um pouco mais lento por causa desse trabalho que você sabe que precisa ser feito.

Você provavelmente poderia construir casas mais rapidamente se não usasse o concreto como base - e elas ficariam tão boas para o cliente, mas - bem - Mesmo que o cliente não visse a necessidade da fundação , o construtor precisa. (Este é realmente um paralelo interessante porque os construtores nem sempre fazem o que eles sabem que devem fazer, então precisamos aprovar leis para forçá-los - não existem leis que governem o desenvolvimento de software, mesmo que enfrentemos o mesmo decisões e muitas vezes fazem os errados ...)

    
por 01.02.2012 / 19:57
fonte
5

Você menciona que tem a sorte de que seu gerente e seu CEO sejam ambos programadores. Então eles provavelmente fazem entender o que é dívida técnica.

Você deve lidar com a situação tentando resolver a situação com base em fatos, o que significa que existe uma possibilidade real de que você não acabe fazendo as melhorias técnicas desejadas (fatos podem ser irritantes) dessa maneira).

Seu trabalho é garantir que eles entendam os custos e benefícios de pagar qualquer dívida técnica específica que você incorrer. Seu trabalho é decidir se o melhor uso dos recursos está em pagá-lo ou em fazer outra coisa.

Assim como pode ser difícil para as pessoas não envolvidas com o código ver os benefícios de melhorar o material "oculto", pode ser difícil para os programadores verem os benefícios de alterações visíveis no código quando os benefícios se acumulam nas áreas do negócios um pouco "escondidos" dos desenvolvedores.

É bom que a sua gerência possa explicar-lhe porque é que os recursos visíveis valem mais o seu tempo do que pagar a dívida técnica, mas, na verdade, não é seu trabalho fazer a determinação de qualquer maneira. Então, explicar para você não faz muito pelo negócio, exceto mantê-lo feliz. E de certa forma, insistir que eles fazem isso não é confiar neles para fazer seu trabalho. Se você não gosta quando eles gerem micro você, então você deve entender.

Portanto, desde que você esteja mantendo-os cientes do status de todas as dívidas técnicas e dos custos e benefícios de ignorá-las versus pagá-las, você fez o seu trabalho. A menos que você realmente não confie em gerenciamento para fazer o deles, caso em que você tem um problema muito maior que seria uma outra pergunta a ser resolvida.

    
por 01.02.2012 / 19:36
fonte
2

Talvez isso não seja uma resposta, mas uma resposta baseada em erros que cometi. Também um desacordo com algumas das filosofias que li aqui.

  • Não se deixe enganar pela crença de que o programador sabe melhor.
  • Seja honesto. Re-factor como você vai junto, mas não mentir e pad estimativas para seus próprios propósitos.
  • Você não possui o código. Não realize trabalhos que não sejam aprovados pelo líder.
  • Você pode estar certo sobre alguma coisa; você pode estar errado ... mas você deve fazer o que você é pago para fazer.

Mas, certamente, siga o excelente conselho dado sobre como melhorar as coisas.

    
por 01.02.2012 / 20:51
fonte
2

Você obviamente trabalha para um chefe de cabelos pontudos (PHB). Ele não programa mais, se alguma vez, e se ele fez, ele provavelmente não era realmente bom (embora ele gosta de cair em frases como "const correção" e "falha de segmentação" para que os caras saibam que ele ganhou suas listras Foi assim que ele foi escolhido pela gerência.

O CEO (que praticamente tem um moicano) gosta do PHB porque o PHB oferece recursos . A cada sprint, ele orgulhosamente demonstra uma nova caixa de seleção (ligeiramente desalinhada, com um rótulo ambíguo), um ícone brilhante (ainda não funciona em qualquer ambiente, mas cor de 8 bits sobre o Citrix) e um formulário (que tem falhas aleatórias devido a condições de corrida) na variante xml feita sob medida com base em C implementado banco de dados local que ninguém no dev equipe ousa tocar porque foi escrito por uma das lendas old dev devedores 10 anos atrás e faz TUDO com macros com 5 nomes de letras, se precisavam de 5 letras ou não).

Os programadores que realmente fazem o "bit de trabalho" (você sabe que isso acontece, inconvenientemente depois de todo o trabalho real, como desenhar círculos em quadros brancos, gritar e comer miniaturas de Battenburgs) sabe que em um sane sistema o trabalho que só levou 10 caras 10 dias para laboriosamente cortar fora da selva não mantida, provavelmente seria um ou dois dias de homem, incluindo o teste. Mas para obter o sistema de onde é para sane pode levar 6 meses de trabalho genuinamente difícil, com pouca recompensa externa óbvia.

O PHB sabe que em 6 meses, por um gancho ou por um trapaceiro, ele pode obter trinta ou quarenta novos recursos no aplicativo que os vendedores (que devem ser mágicos recebem o que realmente estão vendendo) ) pode ser usado para tentar novas aquisições e upgrades.

No entanto, para dar ao PHB suas dívidas: sem as caixas de seleção e formulários, as vendas podem estagnar ou diminuir, um concorrente pode ganhar participação de mercado, e isso pode ser pior do que a alternativa.

A conclusão a que cheguei é de que a única maneira de sair do atoleiro é trabalhar em uma nova empresa, com algumas pessoas que compartilham sua visão de como o software deve ser feito e, depois, se atêm a isso. filosofia (ainda estou trabalhando para chegar lá!)

    
por 02.02.2012 / 19:59
fonte
1

Existe outro custo oculto não mencionado em outras respostas. Ou seja, que bons engenheiros tendem a sair no tipo de ambiente descrito. Eventualmente qualquer pessoa com a ambição ou capacidade de refatorar deixou a empresa, e então as coisas estarão muito ruins, provavelmente não corrigíveis. Infelizmente você não pode dizer isso ao seu gerente sem ser arrogante ("Eu sou um dos seus melhores programadores"), e um idiota agressivo ("Eu vou sair se você não fizer o que eu quero"). No entanto, lembre-se de mencioná-lo em sua entrevista de saída, para garantir que você não seja reintegrado.

    
por 01.02.2012 / 21:57
fonte
1

Você está certo e errado, é por isso que essas questões persistem por muito tempo e criam ressentimentos.

As razões pelas quais são claramente afirmadas acima: a administração pensa em dinheiro; ou ainda mais especificamente: receita. Para eles, algo que tem um custo, mas não tem visibilidade direta para o cliente, não agrega receita, por isso é um plano ruim.

Sua visão também está correta: será boa para os clientes, mas a longo prazo. Suas ações podem gerar uma receita ainda maior no futuro em comparação com os planos de curto prazo.

Você não é o gerente, você não é o responsável direto pela receita (suponho, é claro). Então você está misturando (é assim que se sente na administração) com seus problemas e você não está focando no seu trabalho: expandindo ainda mais o software.

Todas as palavras duras e claras, mas é assim que surgem a maioria dos problemas, devido a erros de comunicação. Vocês dois querem a mesma coisa, mas suas decisões de curto prazo são tomadas de forma diferente. Tudo porque o desenvolvedor tem uma visão diferente em relação ao gerente.

Como você resolve esse problema? Você se comunica e entende um ao outro muito bem em vários assuntos. Esse será o foco no envolvimento e satisfação do cliente, muito provavelmente.

Para resolver esse problema em um método estável e pronto para o futuro, concorde com algo: meça o custo da correção de bugs no código antigo. Meça o tempo que leva adicionalmente para trabalhar com o software antigo e como seria com a nova base de código.

Para provar isso, você poderia fazer, por exemplo, uma coisa bem simples: ramificar o software na sua versão. Primeiro faça o que o gerenciamento quiser, então crie esse recurso. Você faz isso, mas o acordo é que você tem tempo para mostrar o caminho diferente. Então, faça a mesma coisa no novo branch, mas primeiro corrija os problemas que você quer eliminar. Em seguida, também desenvolva a solução.

Agora você tem a mesma solução, mas totalmente desenvolvida de forma diferente. Crie um caso a partir dele, coloque as soluções lado a lado, incluindo algumas informações de gerenciamento, como estabilidade, quantidade de código necessária e o próprio código.

Agora pegue um café e comece a dar uma olhada, sem debater quem está certo, mas qual seria a influência de ambas as direções para a empresa. Isso criará uma reunião que é realmente útil e não uma discussão melhor-pior, porque isso não gerará a atmosfera que ambos precisarão. Isso não tornará seu produto melhor.

    
por 02.02.2012 / 16:32
fonte
0

Se você tiver uma revisão de código, crie um tíquete técnico informando que o código deve ser aprimorado usando o ARC e atribuindo ao gerente.

Convença-o. Explique-lhe alguns pequenos exemplos de melhorias técnicas semelhantes que você fez e seus benefícios para os projetos.

    
por 01.02.2012 / 21:01
fonte
0

Você tem que vender essas alterações da única maneira que a gerência está disposta a comprar:

Encontre um recurso para o usuário tão atraente que o gerenciamento só tenha que tê-lo, mas seria impossível fazer sem algumas melhorias de baixo nível no código.

    
por 01.02.2012 / 21:14
fonte
0

O trabalho de seu chefe é garantir que a empresa foque o desenvolvimento na entrega do que os clientes percebem como valor agregado. Existem dois fatores que podem alterar essa percepção:

  1. Quanto tempo leva para entregar uma solicitação do cliente?
  2. Você entrega quando diz que vai?

A maioria prefere dizer que vai demorar 6 semanas e entregar em 5 do que dizer que você entregará em 3, mas terá 4.

Ter uma base de código atual mais fácil de gerenciar e aprimorar permite entregar de maneira mais rápida e aumentar a previsibilidade. Se você está gastando muito tempo em correções de erros, você tem menos recursos disponíveis para adicionar novos recursos. Avalie a quantidade de recursos gastos na correção do código e o grau de precisão das promessas de recursos. Esta é uma maneira de determinar se o seu código atual (sob a filosofia do seu chefe) está custando muito.

    
por 01.02.2012 / 21:25
fonte
0

Deixe-me contar sobre uma oportunidade de US $ 2 bilhões que quase caiu por causa da inércia da gerência.

Alguns de nós ouvimos a voz do cliente, o que significa entender o que ele quer. Nem sempre é o que ele pede, mas se você estiver em posição de ter conversas com seu cliente, você eventualmente chegará a um entendimento mútuo do que ele quer. (Então ele pode explicitamente começar a perguntar por isso.)

Dito isto, é importante entender quem deve ter essa conversa com o cliente. Você geralmente tem seu pessoal de desenvolvimento de negócios junto com alguns designers principais fazendo isso. Se você tiver alguma concorrência, pode esperar que o cliente esteja tendo essa conversa com eles também.

Ao mesmo tempo, é importante que os desenvolvedores se mantenham atualizados em seus campos, porque haverá concorrência que o vencerá se você não estiver.

Na nossa situação, tínhamos um cliente existente e um produto um pouco eficaz, baseado em tecnologia antiga, e o cliente precisava de atualizações rápidas. O que eles realmente precisavam era de um produto de substituição completo, mas a mentalidade da nossa empresa era que isso nos forçaria imediatamente a uma posição competitiva, enquanto a modificação do produto existente permitia que nosso cliente continuasse conosco sem que fosse legalmente exigido para torná-lo competitivo. Nossa administração achou que eles eram donos desse mercado. O problema era que eles não conseguiam acompanhar as solicitações de upgrade, porque a estrutura do produto existente não era flexível o suficiente para atualizar.

O cliente ficou impaciente e começou a conversar com fontes concorrentes. Perdemos nossa "propriedade" desse mercado e alguns bilhões de dólares em receita. No entanto, uma vez que o mercado nos obrigou a uma posição competitiva, a administração não teve escolha senão sair do negócio ou competir. (A maioria dos que foram bloqueios de estrada eventualmente foram demitidos.) Concorremos e fomos capazes de recapturar o negócio pelo fio mais fino.

Eu disse no começo que esta oportunidade quase caiu em nossas mãos. Nós recuperamos o negócio, pela receita que mencionei. Se estivéssemos mais preparados para nos adaptar às preocupações do cliente no começo, não haveria concorrência real.

O take away que estou oferecendo é o seguinte: sempre tente ficar na ponta de suas capacidades pessoais. Sempre desenvolva um produto que seja flexível e possa ser adaptado rapidamente ao que seu cliente precisa. Se você trabalha muito tempo para uma empresa que não pensa assim, você vai murchar, e sua motivação pessoal diminuirá. Eu já vi isso acontecer.

Quando você tiver uma ideia para melhorar seu produto por qualquer motivo, faça a si mesmo estas perguntas: - É isso que eu acho que o cliente quer? Posso validar meus pensamentos sobre o desenvolvimento do produto contra a voz do cliente? Minha empresa está em condições de atender às necessidades do cliente? Se sim, como? - Você deve, então, estar em posição de apresentar argumentos persuasivos sobre suas propostas de desenvolvimento de produtos.

    
por 02.02.2012 / 04:45
fonte
0

A linguagem comum dos negócios em todos os campos e setores é dinheiro. O problema que você está descrevendo não é um problema de programação: é um problema de negócios. Se você deseja obter uma resposta adequada a uma proposta comercial, é necessário enquadrá-la no idioma dos negócios. Isso significa que você deve ser capaz de apresentar um plano de projeto alternativo, incluindo todos os custos e benefícios.

Você precisa aprender sobre coisas como custos de oportunidade, ROI (retorno do investimento) e NPV (valor presente líquido). Você não precisa de um MBA para fazer isso, mas precisa de acesso a dados que talvez não estejam disponíveis para você, como custos de mão-de-obra, custos indiretos e receita potencial. Se você puder fazer um argumento claro de que um caminho fornecerá mais valor do que outro usando números concretos, você receberá toda a atenção da gerência.

    
por 03.02.2012 / 21:56
fonte
0

Quando eu era um desenvolvedor mais novo em uma equipe muito pequena, eu fiz muito desse tipo de melhoria no meu tempo livre. Eu gostei; Eu iria fazer logon e experimentar novas técnicas interessantes enquanto estiver sentado na sala de estar com minha esposa à noite. Como cheguei a ser um desenvolvedor mais sênior e, em seguida, gerente de uma equipe maior, meu tempo livre desapareceu. Estávamos trabalhando horas extras apenas para obter os recursos e as correções críticas feitas. Tornou-se realmente difícil justificar gastar o tempo de alguém com o trabalho regular de limpeza, mesmo sabendo que era importante.

Seus chefes não precisam de uma explicação sobre o quanto é importante, manter os custos de manutenção baixos, reduzir o custo do crescimento futuro, manter uma equipe talentosa de desenvolvimento envolvida etc. Se isso acontecer, você terá grandes problemas. O que eles podem precisar, no entanto, é um plano. Porque agora eu estou supondo que eles têm todos os tipos de planos, horários, roteiros, promessas e pressão sobre o lado "adicionar funcionalidade", que estão competindo contra mera wishful thinking e solicitações abertas da equipe de desenvolvedores.

Uma coisa que você pode tentar é fazer um plano documentado. Veja se você pode vinculá-lo a liberações ou sair de critérios para nova funcionalidade. Um pedido para "passar algum tempo refazendo a contagem de referência" pode ser difícil para o seu chefe aprovar, mas agendar um período de 5 dias a partir de 4 semanas pode ser mais fácil. Basicamente, no entanto, você vê que os novos recursos são planejados e programados, tentam imitar isso ou injetam uma parte "sob o capô".

Comece pequeno, pedindo 5% de tempo alocado para esse tipo de material e, em seguida, desenvolva gradualmente suas próprias prioridades de roteiro de tecnologia, e continue corrigindo a justificativa do business case, ROI, níveis de risco, etc. em cada um deles. . Em breve, você poderá até mesmo experimentar os desafios de seus chefes, pois você encontrará rapidamente muitas outras grandes ideias do que você tem tempo para fazer.

Boa sorte!

    
por 04.02.2012 / 04:59
fonte
-1

Veja por que sua solicitação de contagem de referência automática está sendo rejeitada:

  1. Não é uma melhoria . Uma vez que você tenha algo maior que olá mundo, qualquer mudança está indo para a direção errada. Nenhuma quantidade de refatoração mudará o fato de que, se você precisa fazer mudanças, está sempre indo na direção errada. O truque é saber quando as alterações são significativas o suficiente para valer o risco de causar novos problemas. Sua gerência disse claramente que, se os usuários finais não puderem vê-lo, não vale a pena o risco.
  2. A contagem de referência é uma característica completamente louca. Você viu algumas empresas grandes e famosas implementarem algum recurso e imediatamente pensou que você precisava do mesmo recurso. Bem, é muito provável que sua base de código seja completamente diferente do que a Apple está usando. Provavelmente, a contagem de referências não vai funcionar ou é apenas perda de tempo. Você deve encontrar uma maneira diferente que não exija a propagação de primitivas de contagem de referência em todo o seu código. Provavelmente, o seu plano de recontagem requer milhares de modificações na base de código, a maioria dessas mudanças não são necessárias. Apenas desperdice tempo e dinheiro.
  3. Você está resolvendo o problema errado. O gerenciamento geralmente sabe que tipo de problemas existem no sistema. Algum problema de vazamento de memória irrelevante que a solução do refcounting esteja resolvendo não é um deles. Concentre-se em problemas reais e não em alguns problemas imaginários de como os computadores lidam com a memória.
  4. Demora muito tempo para implementá-lo A Apple é uma empresa um pouco maior do que sua equipe insignificante com poucos programadores e alguns gerentes. Eles podem fazer grandes mudanças apenas pagando o preço. Se levar alguns milhões para implementar algo, é um amendoim. Se as pequenas empresas tentarem fazer o mesmo, elas ficarão sem dinheiro rapidamente. O desenvolvimento de software já é muito caro; Adicionar custos desnecessários não ajudará nem um pouco. Um recurso irrelevante como o gerenciamento de memória abrirá as comportas: depois de aprová-lo, metade dos seus programadores querem que sua própria "melhoria" seja implementada. É uma história sem fim e a empresa poderia estar fazendo algo útil em seu lugar.

Veja alguns passos que você pode usar para lidar com o problema:

  1. Solte o recurso
  2. Descubra qual é o problema real
  3. Comece a fazer algo útil
  4. Planeje cuidadosamente como você usa seu tempo
  5. Descubra como suas melhorias estão gerando dinheiro
  6. Escolha apenas os recursos que geram a maior quantidade de dinheiro
  7. Perceba que o aspecto de programação do desenvolvimento de software é apenas uma pequena parte de todo o sistema - melhorias para ele nunca valerão o tempo
por 02.02.2012 / 19:01
fonte