Dissidência entre o líder do programa e eu, o que devo fazer? [duplicado]

4

Sou programador de MMORPG há dois anos. Eu tenho algumas experiências em plataformas limitadas, como telefones celulares, então tenho uma strong percepção da otimização de memória. Mas os programas da minha empresa atual consomem muita memória, nem os parceiros do lado do servidor nem os do lado do cliente não se importam com esse assunto, talvez estragados pelo crescimento da indústria de memória. Relatei essa questão ao nosso líder de programa, mas ele não fez nada além de minhas idéias, e ele me disse que deveríamos fazer a otimização da memória do cliente quando o projeto estivesse quase liberando, e a ocupação da memória do lado do servidor não é um problema. todos, chips de memória são baratos, portanto, poderíamos ligar mais, se não for suficiente. Estou muito angustiada com essa linguagem. Podemos desperdiçar memória em todos os lugares se o líder não defender essa otimização. Este problema é um problema de fato em nosso projeto liberado que causou baixa FPS de servidor e atraso de cliente. Meu projeto é ainda em desenvolvimento. O que devo fazer? Qualquer sugestão é apreciada.

    
por paladin 27.04.2011 / 05:27
fonte

8 respostas

9

prove o valor

ou aceite que não é uma prioridade para eles agora

possivelmente ambos

    
por 27.04.2011 / 07:07
fonte
6

Você e o líder do seu programa estão parcialmente certos .

Um programa que vaza memória é de fato um problema em potencial se levar a um processo (além de suporte essencial ao sistema operacional) ocupar mais memória do que sua máquina host está fisicamente disponível. Em teoria, você pode viver com isso se a memória desperdiçada estiver sendo lentamente paginada, mas com muita frequência isso não funciona assim na prática. Uma vez que muita memória é embaralhada para e do disco, o desempenho é destruído . Além disso, pode levar muito tempo para caçar vazamentos de memória (a instrumentação de memória é bastante cara), por isso não é uma boa ideia deixá-la antes do lançamento, pois isso aumenta muito o risco do cronograma do projeto.

Por outro lado, não faz sentido colocar um esforço estúpido na busca por vazamentos de memória, uma vez que as coisas estão abaixo do ponto em que não são mais um problema no hardware disponível e no tempo gasto na execução. A disponibilidade média de memória está definitivamente aumentando, e no lado do servidor é certamente possível calcular quanto hardware deve ser lançado no código.

Portanto, não há motivo para conflito. Você acabou de ter perspectivas diferentes.

Mas isso não é um plano de ação! O que você deveria fazer? Eu sugiro não ter uma discussão sobre isso (afinal de contas, ambos estão parcialmente certos) e, em vez disso, focar em tentar garantir que o código que você escreve não tenha vazamentos de memória. Afinal, é sempre tão raro que um vazamento de memória seja uma coisa boa! É muito melhor acertar da primeira vez. Tenha um cuidado especial ao trabalhar com o código do cliente, pois é muito mais provável que ele precise ser executado em pequenas quantidades de memória e vazamentos de memória, o que causará um impacto maior na qualidade percebida pelo cliente do sistema como um todo. No lado do servidor, concentre-se particularmente em vazamentos no caminho crítico do serviço, pois eles prejudicarão imensamente a implantação. No outro extremo da escala, não vale a pena procurar um vazamento único (por exemplo, ao analisar o arquivo de configuração do servidor). E não perca vazamentos de caça no código produzido por outros membros de sua equipe ainda; você precisa do acordo do seu líder de programa para isso e ele tem que equilibrar essa tarefa contra todos os outros importantes que precisam ser feitos.

    
por 27.04.2011 / 08:00
fonte
5

Você deve ouvir o seu líder de programação. Otimizar apenas quando necessário, quando o programa funciona. E a memória é barata. Se você conseguir 4GB por cem dólares e o problema for resolvido, não vale a pena considerar apenas uma hora de trabalho na otimização do uso da memória.

    
por 27.04.2011 / 11:03
fonte
2

Seu lead pode estar certo em priorizar o comportamento correto antes de tentar melhorar a utilização da memória. Pessoalmente, eu me concentro no comportamento antes de me concentrar na otimização, já que nem sempre fica claro onde os gargalos estão no começo ou até no meio do ciclo de vida do produto.

No entanto, não há nada que o impeça de levantar suas preocupações supostamente bem fundamentadas sobre o estado atual do código, escrevendo uma análise do estado das coisas como elas são. Se você puder fornecer uma avaliação da pressão da memória, talvez respaldada por testes de desempenho, análise de perfil, análise estática ou instrumentação de código projetada para detectar vazamentos de memória, você pode criar um argumento de que há motivações técnicas e comerciais para investir nessa área. / p>

Cada membro da equipe geralmente traz uma perspectiva diferente sobre a importância geral de uma preocupação específica no sistema. Mas você sempre tem que pesar as trocas entre obter algo de remessa e colocar a coisa toda "certa", por alguma definição de "certo".

Há séculos atrás em outra vida, lembro-me de passar horas tentando convencer nossos desenvolvedores a corrigir um bug que causava uma falha de aplicativo toda vez que alguém tentava imprimir uma página da Web que tinha um applet Java nela, apenas no Leste Asiático. versões do Windows 95. Era de alta severidade, mas no grande esquema das coisas, era uma questão de baixa prioridade para o objetivo maior de obter o navegador para fora da porta. Meus esforços não pararam o lançamento, mas acabou sendo um negócio grande o suficiente para que fosse consertado (trabalhado, na verdade) no próximo lançamento.

Aumentar as preocupações com evidências adequadas, sem soar indevidamente alarmista, resultará em investimento na correção do problema ou em uma declaração clara da administração de que o problema é um risco que eles estão dispostos a assumir. Qualquer um desses resultados é bom. Você deve estar focado em trabalhar com os problemas do seu sistema; não se apegue muito a resultados específicos.

    
por 27.04.2011 / 08:17
fonte
2

+1 para se concentrar em algo que a maioria dos desenvolvedores nem pensa. Como Steven Lowe disse que você precisa provar o valor da otimização de memória. Somente quando o custo justificar, seu gerente concordará. Se você está usando apenas 10 KB de memória para um aplicativo e desperdiçando mais 10 KB, ele não é muito (mesmo que seja 100% de desperdício) porque 10KB não importam para um PC moderno com 2-3gigs de RAM. Por outro lado, se o seu aplicativo ocupar 1 GB de memória, até mesmo 10% de desperdício será crítico.

Eu discordo totalmente do seu gerente que as otimizações podem esperar até o lançamento. Apressado, otimizações de última hora podem acabar soprando na sua cara. Se você acha que o problema vai ser sério, você terá que se defender.

    
por 27.04.2011 / 08:30
fonte
1

Iterações do ciclo de desenvolvimento:

  1. Trabalhando corretamente sem bugs (o que significa que não há vazamentos de memória)
  2. Estabilidade (re-fatorar qualquer coisa que possa causar problemas de manutenção no futuro)
  3. Desempenho (somente após a criação de perfil, inclui a otimização do uso de memória)
  4. Ir para 1

O desempenho é o último porque causa risco e comprometimento para os dois primeiros. Ajustes de desempenho podem quebrar coisas que estão funcionando e podem fazer com que as coisas fiquem inapagáveis.

Ajustes de desempenho só devem ser implementados quando o perfil demonstrar um valor ao realizar o trabalho e eliminar o risco envolvido na modificação do código estável de trabalho.

O comportamento incorreto rápido do software não é um sucesso.

O software rápido não estável não é um sucesso.

Em poucas palavras, seu gerente está correto.

    
por 05.05.2011 / 01:07
fonte
0

O sistema funcionará bem durante o desenvolvimento, mesmo que a memória não seja gerenciada muito bem. Aguarde até que centenas de usuários simultâneos acessem o aplicativo ao mesmo tempo. Então vai desmoronar.

O resultado é este e sempre será assim, a menos que você trabalhe para o governo. Sales Drives Everything. Se este projeto estiver em modo de desenvolvimento com apenas clientes em potencial do que uma prova de conceito. O objetivo neste momento pode ser simplesmente um modelo funcional para mostrar aos clientes em potencial. Você não vai gastar toneladas de horas homem para fazer um protótipo perfeito.

O problema se torna isso ... quando você mostra o gerenciamento que você tem modelo de trabalho, todos eles aqui é a palavra trabalhando . Eles não têm ideia de que é apenas uma prova de conceito. Eles começam a vendê-lo e agora, você tem que lutar porque todos os problemas de memória que você criou começam a aparecer e o servidor fica travando.

    
por 05.05.2011 / 00:19
fonte
0

Tudo o que você pode fazer é expressar suas preocupações. Na minha experiência, nada de bom virá de empurrar a questão. Deixe ele se enforcar ...

    
por 05.05.2011 / 02:37
fonte