Sou apenas um desenvolvedor júnior, mas meu trabalho me obriga a trabalhar com código PHP realmente péssimo (pense no pior código PHP que você já viu; depois, pense no código duas vezes mais). Eu costumo tentar corrigir bugs e lutar com a base de código para adicionar novos recursos. Às vezes, tenho ordens para fazer as coisas funcionarem o mais rápido possível, o que geralmente envolve hacks sujos.
O produto era anteriormente de código aberto e eu estou preocupado que ele possa ser de código aberto no futuro. Eu ficaria envergonhado se alguém (especialmente empregadores em potencial) pudesse encontrar meu nome ao lado de alguns dos changesets. O que posso fazer para proteger meu bom nome?
Não tenho certeza se isso é relevante, mas acrescentarei que nem meu chefe nem meus colegas querem admitir que o código é ruim, mas não tenho certeza se posso culpá-los por isso - para muitos deles este é o primeiro emprego deles.
Roma não foi construída em um dia, mas você pode ser um bom 'escoteiro'. Toda vez que você tocar no código, deixe-o melhor do que antes. Não é preciso um tempo extraordinário para usar nomes de função sensatos, bons padrões de codificação e colocar comentários decentes quando você trabalha.
Eu acho que o perigo é pensar que é tudo ou nada. Só porque você não pode gastar o tempo que você quer escrever código elegante, não significa que você tem que desistir totalmente e escrever lixo.
Mas, se você seguisse seu caminho e tentasse escrever códigos perfeitos desde o começo, provavelmente teria gasto muito tempo e feito quase nada.
Então ... escreva código ruim, ... muito disso ... código que mal funciona, e depois ITERATE. Cada iteração é um pouquinho melhor!
Ninguém escreveu a solução perfeita na primeira vez.
* isto, se fosse mais curto, teria sido um comentário.
Os comentários do código são seus amigos aqui.
Sempre que você sentir que precisa escrever um hack barato por causa da pressão, diga algo como: "Esse código faz X por causa de restrições de tempo. Idealmente, eu faria Y em vez disso. - Ashamed One, 5 de julho de 2011"
Então, se os potenciais empregadores perceberem, eles perceberão que você prefere escrever um bom código, mas também está disposto a ajustar seu estilo de codificação às necessidades de negócios. A maioria dos empregadores verá ambos como coisas boas.
Depende de como eles forçam você.
Na minha experiência, existem duas possibilidades:
Você se sente forçado por um cronograma apertado, código legado, etc.
Nesse caso, como a maioria das outras respostas já diz, cabe a você "otimizar o coolness". Você pode não ter tempo para reescrever a base de código para MVC, mas como primeiro passo, por exemplo, você pode parar de colar seu SQL manualmente e em vez disso escrever um execute_sql($query, $params) , que cria a base para abstrações como fetch_customer($filter_params) , etc. Lembre-se, todas as melhores práticas são, em última análise, que seu chefe recebe um produto mais cedo, então só há um conflito em quanto tempo investir no futuro contra o agora.
Quando você define o contexto certo ('dentro de 6 meses, sem tempo extra, eu refatorei o código monolítico para MVC') você deve deixar seu nome no código, e tentar se orgulhar como um terapeuta, que ensina um vítima de derrame para dizer palavras únicas novamente.
Você está explicitamente determinado a implementá-lo de uma forma que julgue imprópria
A tentativa de separar a visão do modelo não sobrevive à revisão, porque "é muito complicado, por que você não faz apenas consultas SQL?". Seu execute_sql fica enlatado porque 'um codificador com disciplina não precisa disso'.
Este caso é ruim. Na minha experiência, geralmente vem com microgerenciamento e líderes de equipe que foram promovidos lá por razões políticas, não por seus sucessos. O problema real é que você é encarregado de algo (o código) que você não pode controlar (você tem que fazer do jeito deles). A melhor solução seria resolver a causa raiz (ou seja, você é tratado como um grunhido). A segunda melhor (e na minha experiência, a usual) solução é desistir.
A vantagem é que, nesse cenário, seu nome provavelmente não será publicado, porque o líder da equipe leva o crédito por todo o sucesso.
Estou bastante confiante de que seu chefe exige que você entregue algo rápido, mas não que você faça um esforço extra para torná-lo deliberadamente ruim. O que significa que sempre que você tiver uma escolha entre um código realmente ruim e um código um pouco menos ruim, e ambas as opções levariam o mesmo tempo para serem implementadas, você escolheria a opção um pouco menos ruim. Essa é a solução de curto prazo e não requer nenhum esforço.
A longo prazo, converse com seu chefe. Explique como investir 15 minutos aqui pode economizar horas lá. Certifique-se de ter exemplos convincentes - não do tipo "se eu fiz isso e aquilo aqui, minha esperança é que eu seja capaz de fazer outra coisa no próximo ano", mas sim, "olha, aqui fiz essa coisa, e porque disso, levei três horas para encontrar o problema lá; se eu tivesse feito isso e aquilo, o bug teria aparecido imediatamente ". Um aviso aqui: enquanto o código elegante e de manutenção se sente muito melhor e mais eficiente, às vezes não é. Há situações em que uma correção rápida desleixada é perfeitamente justificada: às vezes você está escrevendo um código de uso único, às vezes você está mantendo um trecho desatualizado de lixo vivo, aguardando a coisa real; às vezes, o benefício de uma solução adequada não justifica o esforço (em termos de dinheiro, no qual todo seu chefe está interessado).
Se tudo mais falhar, procure outro emprego.
Ninguém força você a escrever códigos ruins. Você pode mudar essa situação e torná-la positiva. Mudança pioneira para políticas e procedimentos. E você também não pode ser o "sim" homem / mulher. Se eles disserem que precisam da funcionalidade x antes do final do dia, diga-lhes que isso não é viável, mas dê justificativas porque de fato não é. Onde houver um problema, ofereça soluções. Não apenas um olho cego, ou pior ... acrescentando a ele.
Sua loja virtual não é a primeira a ter prazos rigorosos, embora ainda tenha o desejo de manter um código bem projetado.
Qualquer empresa precisa encontrar um equilíbrio entre escrever códigos brilhantes, com documentação extensa e testes de unidade e colocar produtos no mercado com orçamento e espaço de tempo razoáveis.
O melhor código do mundo não importa se é obsoleto antes de ser lançado.
Ser pragmático é tentar encontrar esse equilíbrio. Obter recursos corrigidos rapidamente pode ser comercialmente essencial no momento, isso não significa que sempre será.
É preciso muita experiência (mais do que a maioria dos programadores já fez) para obter esse equilíbrio. É muito fácil ir para qualquer um dos extremos. Encontrar um meio termo é mais difícil.
Eu não estou dizendo que seu chefe está certo. Como codificador, existe a tentação de tentar criar constantemente um código bonito que não seja comercialmente viável. Estar atento a essa tentação pode ajudá-lo a perceber que alguns desses hacks não são tão ruins.
A maior parte do código, após um período de tempo suficiente, conterá hacks para situações específicas que eram caras demais para refatorar em uma estrutura geral.
Eu gostaria de acrescentar que você não deve continuar como está fazendo agora, não dizendo nada e apenas hackeando e hackeando.
Você precisa se levantar e apontar para o código concreto e dizer-lhes o que é ruim. Seja específico e use métricas de código para fazer backup de suas reivindicações. Nada é mais embaraçoso do que afirmar que um código é ruim quando na verdade não é, você simplesmente não entendeu o que estava sendo feito.
Tenho certeza de que existem muitas ferramentas disponíveis gratuitamente para análise de código php link
Além disso, é claro que isso link
Leia, some o que você pode encontrar em sua aplicação e, claro, liste alternativas . Sua má prática é apenas ficar de pé e gritar "Eu não gosto de como isso é feito" sem apresentar uma alternativa (de preferência) melhor maneira de fazê-lo.
Hackers rápidos custam dinheiro. E não o veja como totalmente negativo - Você pode aprender muito com este trabalho agora e pode lucrar com as experiências que você agora faz em seu próximo.
hth
Antes de mais nada, você usa o controle de origem de algum tipo, certo? Se não, comece a partir daí. Ele ajudará você primeiro e será adotado pelo restante da equipe rapidamente.
Se você tem controle de origem, você não deve colocar seu nome no código, basta colocar o nome da sua empresa. É comum em um código incorreto colocar um histórico de revisão nos comentários no topo dos arquivos, isso é melhor delegado ao controle de origem.
Agora, em relação à qualidade do código, você não poderá alterá-lo como uma abordagem big bang. Lentamente, um por um, adicione novas abordagens para diferentes questões. Se você fizer certo, você economizará algum tempo e você o usará para melhorar a qualidade geral.
Para dar um exemplo meu, uma vez cheguei no meio de um projeto com um aplicativo Perl / CGI onde todo o HTML estava no código. O aplicativo inteiro estava em um único arquivo sem estrutura clara. Nada foi versionado. Comecei configurando um repositório de CVS (sem SVN disponível na época), coloquei uma interface web para o cliente. No início, eu estava cuidando dos commits dos meus colegas. Então, eu divido todos os métodos em diferentes módulos (arquivos). Nesse ponto, os colegas começaram a adotar o CVS. Então, mudei o HTML do código. Então, toda vez que eu tive que fazer uma mudança em alguma parte do código, eu levei um pouco de tempo para refatorar algumas delas. No final, a velocidade de desenvolvimento aumentou tanto que o cliente ficou extremamente feliz. Eles solicitariam uma mudança estética e, em vez de dizerem a eles que "levaria 2 dias", eu mudei o código no ambiente de desenvolvimento.
No entanto, essa abordagem só funcionará se você dominar o código geral bem o suficiente. Se você não entender o quadro geral, se algumas partes do aplicativo permanecerem ininteligíveis, isso tornará seu trabalho realmente difícil.
Uma última coisa, uma reescrita completa às vezes é a única solução, mas geralmente é muito difícil justificar seu custo para o gerenciamento.
Desde que você é um desenvolvedor júnior, isso é realmente uma coisa boa. Ser jogado no meio de um grande e velho código vai te ensinar muito mais sobre o que não fazer do que apenas trabalhar com código perfeitamente 'limpo'. Tire proveito da situação e aprenda como refatorar o código ruim e convertê-lo lentamente em algo mais gerenciável. E não reclamar sobre isso ter que ser o mais rápido possível. Esse é o ponto - aprender a refatorar e limpar o código enquanto faz as coisas sob um prazo apertado. Afinal, qualquer um pode escrever um código perfeito se tiver tempo infinito disponível.