Estou trabalhando em um aplicativo bastante grande e com erros - e devido à maneira como ele foi escrito (pouparei os detalhes, mas viola as regras na maioria das áreas em que você pode pensar), é quase impossível desenvolvê-lo sem grandes refatorações.
Parte significativa do aplicativo foi criada por estagiários, n00bs etc .; mas também houve um programador na categoria de desenvolvedor mestre e, com toda humildade, o código que ele deixou para trás também é dúbio, de uma maneira diferente, talvez, mas ainda assim.
É verdade que seu código tende a fazer o trabalho - na maioria das vezes - mas é tipicamente enigmático, reinventando a roda (por exemplo, um grande método personalizado que realiza um backup de banco de dados SQL bastante comum) etc. Basicamente, confusão desnecessária e muita superengenharia
E isso me fez pensar que ser um programador altamente qualificado (eu deliberadamente não uso a palavra "desenvolvedor", assumindo que isso indica um conjunto mais amplo de habilidades), se não for acompanhado por outras qualidades, pode realmente ser meio venenoso.
Supondo que seja verdade, algumas das razões pelas quais pude pensar são:
- se você estiver codificando com facilidade, parece (ou realmente é, em curto prazo) apenas mais rápido para lançar suas próprias soluções no local, sem recorrer a bibliotecas, funcionalidade preexistente etc.
- se alguém é experiente o suficiente para manter facilmente uma imagem mental de um programa complexo, é menos inclinado a dividi-la em módulos, camadas etc.
Portanto, o que quero dizer é que, se um programador fluente é um desenvolvedor ruim, sua fluência não apenas compensa o último, mas na verdade causa ainda mais danos.
O que você acha daquilo? É verdade (até que ponto, se sim)?
fonte
I.ThinkOf(this).KindOfThing()Respostas:
Sim. Eu fui esse cara. E eu aprendi que é uma coisa terrível.
Está tudo muito bem para você, você não precisa aprender algo novo.
Mas e o resto da sua equipe? Eles se tornam muito dependentes de você. Eles não podem procurar no Google por "Clive's Quicky ORM" para obter ajuda no mapeador de objeto-relacional que você escreveu.
E então chega o dia em que eles precisam contratar alguém novo e não podem procurar pessoas com experiência no Quicky ORM de Clive.
E finalmente chega o dia em que você sai e alguém percebe um bug no seu ORM. E estará lá, porque você não tem uma comunidade inteira de pessoas testando e consertando seu produto.
Sim, aprender Hibernate pode levar mais tempo do que escrever algo leve. Mas o benefício de fazer isso é grande demais para ignorar, IMHO.
fonte
Hábil no idioma, mas não nas ferramentas. Isso nem é realmente um codificador forte. É apenas polir uma habilidade (conhecimento da linguagem) e permitir que outra fique enferrujada (conhecimento da biblioteca). O contrário é tão ruim, mas mais fácil de detectar.
Isso é apenas preguiça disfarçada de habilidade. Não é preciso muito esforço para manter em mente o que você está trabalhando ativamente. É preciso ter habilidade para encontrar as costuras adequadas e dividir o código ao longo delas. Os codificadores que dizem que era mais rápido ou melhor deixar tudo em um único local geralmente não conseguem ver quais itens dividir.
fonte
Apenas verifique se isso não ocorre porque ele está trabalhando em um ambiente "Se o teclado não está clicando, você não está trabalhando". Todos nós olhamos para o código e nos perguntamos o que estávamos pensando. Além disso, esta loja está na prática de refatorar seu código? Isso pode ter sido um luxo que ele não recebeu.
No entanto, precisamos nos afastar de nossa primeira ideia (a que você pode simplesmente sentar e pensar) e fazer um pouco mais de planejamento, pesquisa e pensamento. A tentação de tirar cada pequeno problema do caminho é tentadora e todo o projeto está cheio dessa prática. Ninguém quer pagar às pessoas para consertar coisas que não estão quebradas, então por que refatorar?
Edit: Vamos garantir que não punamos aqueles que sabem as respostas. Há quem seja fluente e escreva um bom código com rapidez. A chave é não abordar todos os problemas dessa maneira.
fonte
100%.
A maneira cínica de olhar para isso seria que esses tipos de codificadores estão realmente mantendo a maioria dos desenvolvedores em funcionamento, corrigindo bugs que são tão fundamentais que você pode dedicar milhares de horas de desenvolvedor sem ficar na metade do caminho para um estável, flexível e seguro , modular ou [sua propriedade de software favorita]. Esses sistemas têm tantas idiossincrasias que o próprio pensamento de migrar para outra coisa, mesmo com 95% dos recursos já existentes e uma comunidade vibrante por trás, é considerado algo entre ridículo e motivos para ser demitido.
Em resumo, codificadores fluentes podem causar mais danos do que uma horda de concorrentes, mas o preço geralmente é pago ao longo de muitos anos. E eles geralmente estavam simplesmente fazendo seu trabalho (como definido por outra pessoa).
Como saber se você é desenvolvedor ou codificador? Eu acho que isso é impossível, mas toda vez que você encontra uma maneira de simplificar seu código sem reduzir a qualidade, você dá mais um passo em direção à iluminação.
fonte
O problema que você descreveu foi basicamente o NIH ("não inventado aqui") - existem outros sintomas?
Às vezes, o NIH, principalmente se estiver isolado para uma ou duas pessoas, pode ser tratado em uma discussão em grupo ("Joe aqui tem alguma experiência em fazer backups de SQL usando bibliotecas padrão - o que você acha, Joe?"). Isso pode ser menos conflituoso do que você ir diretamente para a pessoa e dizer "Ei! Use a biblioteca padrão, manequim!" :)
fonte
Tendo estado na sua situação e tendo causado situações semelhantes, entendo sua frustração, mas acho que a resposta para sua pergunta é um "não" simples. A fluência não garante que um programador produza código sustentável. Muitas vezes, as organizações forçam os programadores a fornecer software mal projetado e implementado devido a restrições ridículas de orçamento e tempo. É possível que o programador fluente esteja cortando os cantos, apenas os programadores se preocupam em entregar algo com o qual os clientes se importam. Obviamente, isso não é bom na prática, mas infelizmente é uma realidade que a maioria dos programadores precisa lidar em algum momento de sua carreira. Há também a chance de que o programador fluente esteja apenas sendo preguiçoso ou complacente. Eu sei falar inglês perfeitamente, mas é mais fácil e divertido usar gírias.
Quanto ao uso do código de outra pessoa ou ao seu próprio argumento, acho que realmente se resume ao que faz o trabalho melhor. Às vezes, "melhor" não é responsável por coisas como estilo e manutenção, se "melhor" significa entregar um projeto de seis semanas em duas semanas. É por isso que refatoramos e refinamos. Além disso, o desenvolvedor deve estar ciente do que está disponível em termos de código de terceiros e precisa saber como usá-lo e confiar que ele funcionará e será adequadamente suportado / mantido. Dado que existem milhares de estruturas opcionais, bibliotecas e APIs para qualquer paradigma de desenvolvimento popular usando essas coisas, isso pode custar mais tempo, energia e estresse do que apenas criar o seu próprio. Além disso, encontro casos em que o código de terceiros simplesmente não faz exatamente o que eu preciso, que é quando ele '
fonte
Estou naquele barco (código legado escrito fluentemente) e fui do tipo fluente por um tempo.
O maior obstáculo para soluções "rápidas e sujas" é sempre quando você precisa adicionar mais a elas posteriormente. Quando você precisar de mais recursos. Há muito o que você pode fazer sem estrutura. Depois disso, ele quebra e é caro reorganizá-lo (ainda que satisfatório, mas não muito apreciado).
Basicamente, você precisa se proteger de QUALQUER HACK que possa se tornar uma "solução viável", pronta para ser vendida por um vendedor ansioso. É o velho "Não está pronto! - Mas funciona, não?" dilema.
fonte