Qual é a sua opinião de programação mais controversa?

Isso é definitivamente subjetivo, mas eu gostaria de tentar evitar que isso se torne argumentativo. Eu acho que poderia ser uma pergunta interessante se as pessoas a tratarem adequadamente.

A idéia para esta pergunta veio do tópico de comentários da minha resposta ao "Quais são as cinco coisas que você odeia no seu idioma favorito?" pergunta . Argumentei que as classes em C # deveriam ser seladas por padrão - não colocarei meu raciocínio na pergunta, mas posso escrever uma explicação mais completa como resposta a essa pergunta. Fiquei surpreso com o calor da discussão nos comentários (25 comentários atualmente).

Então, que opiniões controversas você tem? Prefiro evitar o tipo de coisa que acaba sendo bastante religiosa, com relativamente pouca base (por exemplo, colocação de chaves), mas os exemplos podem incluir coisas como "teste de unidade não é realmente muito útil" ou "campos públicos são realmente bons". O importante (para mim, pelo menos) é que você tem razões por trás de suas opiniões.

Por favor, apresente sua opinião e seu raciocínio - eu incentivaria as pessoas a votarem em opiniões bem fundamentadas e interessantes, independentemente de você concordar ou não com elas.

Os programadores que não codificam em seu tempo livre por diversão nunca serão tão bons quanto aqueles que o fazem.

Acho que mesmo as pessoas mais inteligentes e talentosas nunca se tornarão realmente bons programadores, a menos que tratem isso como mais do que um trabalho. Isso significa que eles fazem pequenos projetos paralelos ou simplesmente mexem com muitos idiomas e idéias diferentes em seu tempo livre.

(Nota: não estou dizendo que bons programadores fazem nada além de programar, mas fazem mais que programar das 9 às 5)

A única "melhor prática" que você deve usar o tempo todo é "Use Your Brain".

Muitas pessoas pulam em muitos bandwagons e tentam forçar métodos, padrões, estruturas etc. em coisas que não lhes são justificadas. Só porque algo é novo, ou porque alguém respeitado tem uma opinião, não significa que serve para todos :)

EDIT: Apenas para esclarecer - não acho que as pessoas devam ignorar as melhores práticas, opiniões valiosas etc. Só que as pessoas não devem pular cegamente em algo sem pensar em POR QUE essa "coisa" é tão boa? É aplicável ao que eu estou fazendo, e quais benefícios / desvantagens isso traz?

"Pesquisando" está tudo bem!

Sim, eu sei que ofende algumas pessoas por aí que seus anos de intensa memorização e / ou pilhas gloriosas de livros de programação estão começando a cair no caminho de um recurso que qualquer pessoa pode acessar em segundos, mas você não deve defender isso contra pessoas que o usam.

Muitas vezes, ouço respostas do Google a problemas como resultado de críticas, e isso realmente não faz sentido. Antes de tudo, deve-se admitir que todos precisam de materiais para referência. Você não sabe tudo e precisará procurar as coisas. Concedendo isso, realmente importa onde você conseguiu as informações? Importa se você procurou em um livro, no Google ou ouviu de um sapo falante que você alucinou? Não. Uma resposta certa é uma resposta certa.

O importante é que você entenda o material, use-o como um meio para atingir uma solução de programação bem-sucedida e o cliente / seu empregador esteja satisfeito com os resultados.

(embora, se você estiver obtendo respostas de sapos falantes de alucinações, provavelmente receba ajuda da mesma forma)

A maioria dos comentários no código é, de fato, uma forma perniciosa de duplicação de código.

Passamos a maior parte do tempo mantendo o código escrito por outras pessoas (ou por nós mesmos) e comentários ruins, incorretos, desatualizados e enganosos devem estar próximos ao topo da lista dos artefatos mais irritantes do código.

Eu acho que, eventualmente, muitas pessoas simplesmente as apagam, especialmente aquelas monstruosidades de caixas de flores.

Muito melhor se concentrar em tornar o código legível, refatorar conforme necessário e minimizar expressões idiomáticas e peculiaridades.

Por outro lado, muitos cursos ensinam que os comentários são muito mais importantes que o próprio código, o que leva à próxima linha que acrescenta um ao estilo de comentário invoiceTotal .

XML é altamente sobrestimado

Eu acho que muitos saltam para a onda de XML antes de usar o cérebro ... XML para coisas da Web é ótimo, pois foi projetado para isso. Caso contrário, acho que algumas definições de problemas e idéias de design devem impedir qualquer decisão de usá-lo.

Meus 5 centavos

Nem todos os programadores são criados iguais

Muitas vezes, os gerentes pensam que DeveloperA == DeveloperB simplesmente porque têm o mesmo nível de experiência e assim por diante. De fato, o desempenho de um desenvolvedor pode ser 10x ou até 100x o de outro.

É politicamente arriscado falar sobre isso, mas às vezes sinto que, embora vários membros da equipe pareçam ter a mesma habilidade, nem sempre é o caso. Eu já vi casos em que os desenvolvedores líderes estavam 'além da esperança' e os desenvolvedores juniores faziam todo o trabalho real - mas garanti que eles recebessem o crédito. :)

Não entendo por que as pessoas pensam que Java é absolutamente a melhor "primeira" linguagem de programação a ser ensinada nas universidades.

Por um lado, acredito que a primeira linguagem de programação deve ser tal que destaque a necessidade de aprender o fluxo e as variáveis ​​de controle, não os objetos e a sintaxe

Por outro lado, acredito que as pessoas que não tiveram experiência em depurar vazamentos de memória no C / C ++ não podem apreciar completamente o que o Java traz para a mesa.

Além disso, a progressão natural deve ser de "como posso fazer isso" para "como posso encontrar a biblioteca que faz isso" e não o contrário.

Se você conhece apenas um idioma, não importa quão bem o conheça, você não é um grande programador.

Parece haver uma atitude que diz que quando você é realmente bom em C # ou Java ou qualquer outra linguagem que você começou a aprender, é tudo o que você precisa. Eu não acredito nisso - toda linguagem que eu já aprendi me ensinou algo novo sobre programação que pude trazer de volta ao meu trabalho com todas as outras. Eu acho que quem se restringe a um idioma nunca será tão bom quanto poderia ser.

Também indica para mim uma certa falta de questionamento e vontade de experimentar que não necessariamente coincide com as qualidades que eu esperaria encontrar em um bom programador.

Desempenho faz importa.

Instruções de impressão são uma maneira válida de depurar código

Eu acredito que é perfeitamente bom depurar seu código, colocando-o em lixo System.out.println(ou qualquer declaração de impressão que funcione no seu idioma). Geralmente, isso pode ser mais rápido que a depuração e você pode comparar as saídas impressas com outras execuções do aplicativo.

Apenas certifique-se de remover as instruções de impressão quando for à produção (ou melhor, transformá-las em instruções de registro)

Seu trabalho é sair do trabalho.

Quando você está escrevendo um software para o seu empregador, qualquer software que você criar deve ser escrito de forma que possa ser adquirido por qualquer desenvolvedor e entendido com um esforço mínimo. Ele é bem projetado, escrito de forma clara e consistente, formatado de forma limpa, documentado onde precisa estar, compilado diariamente conforme o esperado, verificado no repositório e com a versão apropriada.

Se você for atropelado por um ônibus, demitido, demitido ou sair do emprego, seu empregador poderá substituí-lo a qualquer momento, e o próximo funcionário poderá assumir seu papel, pegar seu código e ser correndo dentro de uma semana no máximo. Se ele ou ela não puder fazer isso, você falhou miseravelmente.

Curiosamente, descobri que esse objetivo me tornou mais valioso para meus empregadores. Quanto mais eu me esforço para ser descartável, mais valioso me torno para eles.

1) A farsa de aplicativos de negócios :

Eu acho que a coisa toda sobre estruturas "Enterprise" é fumaça e espelhos. J2EE, .NET, a maioria das estruturas Apache e a maioria das abstrações para gerenciar essas coisas criam muito mais complexidade do que resolvem.

Pegue qualquer ORM Java ou .NET regular ou qualquer estrutura MVC supostamente moderna para qualquer um que faça "mágica" para resolver tarefas simples e tediosas. Você acaba escrevendo grandes quantidades de clichês XML feios, difíceis de validar e gravar rapidamente. Você tem APIs massivas, nas quais metade delas serve apenas para integrar o trabalho de outras APIs, interfaces impossíveis de reciclar e classes abstratas necessárias apenas para superar a inflexibilidade de Java e C #. Simplesmente não precisamos da maior parte disso.

Que tal todos os diferentes servidores de aplicativos com sua própria sintaxe de descritor, o banco de dados excessivamente complexo e os produtos de groupware?

O ponto disso não é a complexidade == ruim, é a complexidade desnecessária == ruim. Eu trabalhei em instalações corporativas massivas onde algumas delas eram necessárias, mas mesmo na maioria dos casos, alguns scripts criados em casa e um front-end simples da web são necessários para resolver a maioria dos casos de uso.

Eu tentaria substituir todos esses aplicativos corporativos por estruturas da Web simples, bancos de dados de código aberto e construções de programação triviais.

2) O número de anos de experiência exigido:

A menos que você precise de um consultor ou técnico para lidar com um problema específico relacionado a um aplicativo, API ou estrutura, então você realmente não precisa de alguém com 5 anos de experiência nesse aplicativo. O que você precisa é de um desenvolvedor / administrador que possa ler a documentação, que tenha conhecimento de domínio no que quer que esteja fazendo e que possa aprender rapidamente. Se você precisar desenvolver algum tipo de linguagem, um desenvolvedor decente irá buscá-lo em menos de 2 meses. Se você precisar de um administrador para o servidor da Web X, em dois dias ele deve ter lido as páginas de manual e os grupos de notícias e estar atualizado. Qualquer coisa menos e essa pessoa não vale o que é paga.

3) O currículo comum de graduação em "ciência da computação":

A maioria dos diplomas de ciência da computação e engenharia de software é tola. Se sua primeira linguagem de programação é Java ou C #, você está fazendo algo errado. Se você não faz vários cursos completos de álgebra e matemática, está errado. Se você não se aprofundar na programação funcional, ela estará incompleta. Se você não pode aplicar invariantes de loop a um loop for trivial, não vale a pena ser um suposto cientista da computação. Se você tiver experiência nas linguagens xey e na orientação a objetos, está cheio de merda. Um cientista da computação real vê uma linguagem em termos dos conceitos e sintaxes que usa, e vê as metodologias de programação como uma dentre muitas, e tem um entendimento tão bom das filosofias subjacentes de ambas que escolher novas linguagens, métodos de design ou linguagens de especificação seja trivial.

Getters e Setters são altamente utilizados

Eu já vi milhões de pessoas alegando que os campos públicos são maus, então eles os tornam privados e fornecem getters e setters para todos eles. Acredito que isso é quase idêntico a tornar os campos públicos, talvez um pouco diferente se você estiver usando threads (mas geralmente não é o caso) ou se seus acessadores tiverem lógica de negócios / apresentação (pelo menos algo 'estranho').

Eu não sou a favor de campos públicos, mas contra fazer um getter / setter (ou Propriedade) para todos eles, e depois afirmar que fazer isso é encapsulamento ou ocultação de informações ... ha!

ATUALIZAR:

Esta resposta levantou alguma controvérsia em seus comentários, então tentarei esclarecer um pouco (deixarei o original intocado, pois é isso que muitas pessoas votaram).

Primeiro de tudo: quem usa campos públicos merece pena de prisão

Agora, criar campos privados e usar o IDE para gerar automaticamente getters e setters para cada um deles é quase tão ruim quanto usar campos públicos.

Muitas pessoas pensam:

private fields + public accessors == encapsulation

Eu digo que a geração (automática ou não) de pares getter / setter para seus campos efetivamente vai contra o chamado encapsulamento que você está tentando obter.

Por fim, deixe-me citar o tio Bob neste tópico (retirado do capítulo 6 do "Código Limpo"):

Há uma razão para mantermos nossas variáveis ​​privadas. Não queremos que mais ninguém dependa deles. Queremos a liberdade de mudar seu tipo ou implementação por capricho ou impulso. Por que, então, tantos programadores adicionam automaticamente getters e setters a seus objetos, expondo seus campos particulares como se fossem públicos?

Os diagramas UML são superestimados

É claro que existem diagramas úteis, por exemplo, diagrama de classes para o Padrão Composto , mas muitos diagramas UML não têm absolutamente nenhum valor.

Opinião: SQL é código. Trate-o como tal

Ou seja, assim como seu C #, Java ou outra linguagem de objeto / procedimento favorita, desenvolva um estilo de formatação legível e de manutenção.

Eu odeio quando vejo código SQL de formato livre desleixado. Se você grita quando vê os dois estilos de chaves em uma página, por que ou por que não grita quando vê SQL ou SQL formatado livre que oculta ou ofusca a condição JOIN?

A legibilidade é o aspecto mais importante do seu código.

Ainda mais que correção. Se é legível, é fácil de corrigir. Também é fácil otimizar, alterar e entender. E espero que outros desenvolvedores também aprendam algo com isso.

Se você é um desenvolvedor, deve poder escrever código

Fiz várias entrevistas no ano passado e, para minha parte da entrevista, eu deveria testar a maneira como as pessoas pensavam e como elas implementavam algoritmos simples a moderados em um quadro branco. Inicialmente, comecei com perguntas como:

Dado que Pi pode ser estimado usando a função 4 * (1 - 1/3 + 1/5 - 1/7 + ...) com mais termos dando maior precisão, escreva uma função que calcule Pi com uma precisão de 5 casas decimais .

É um problema que deve fazer você pensar, mas não deve estar fora do alcance de um desenvolvedor experiente (pode ser respondido em cerca de 10 linhas de C #). No entanto, muitos de nossos candidatos (supostamente pré-selecionados pela agência) nem sequer começaram a responder, ou mesmo explicaram como poderiam responder. Então, depois de um tempo, comecei a fazer perguntas mais simples, como:

Dado que a área de um círculo é dada por Pi vezes o raio ao quadrado, escreva uma função para calcular a área de um círculo.

Surpreendentemente, mais da metade dos candidatos não conseguiu escrever essa função em nenhum idioma (eu posso ler os idiomas mais populares, então deixo que eles usem qualquer idioma de sua escolha, incluindo o pseudo-código). Tivemos "desenvolvedores de C #" que não puderam escrever essa função em C #.

Fiquei surpreso com isso. Eu sempre pensei que os desenvolvedores deveriam ser capazes de escrever código. Parece que hoje em dia essa é uma opinião controversa. Certamente está entre os candidatos à entrevista!

Editar:

Há muita discussão nos comentários sobre se a primeira pergunta é boa ou ruim e se você deve fazer perguntas tão complexas quanto esta em uma entrevista. Não vou me aprofundar nisso aqui (isso é uma pergunta totalmente nova), além de dizer que você está perdendo o objetivo do post .

Sim, eu disse que as pessoas não poderiam avançar com isso, mas a segunda pergunta é trivial e muitas pessoas também não conseguiram avançar com isso! Qualquer pessoa que se autodenomina desenvolvedor deve ser capaz de escrever a resposta para a segunda em alguns segundos sem nem pensar. E muitos não podem.

O uso da notação húngara deve ser punido com a morte.

Isso deve ser bastante controverso;)

Os padrões de design estão prejudicando mais o bom design do que o ajudando.

O design de software da IMO, especialmente o bom design de software, é muito variado para ser capturado de maneira significativa nos padrões, especialmente no pequeno número de padrões que as pessoas conseguem lembrar - e são abstratos demais para que as pessoas realmente lembrem mais do que um punhado. Então eles não estão ajudando muito.

Por outro lado, muitas pessoas ficam apaixonadas pelo conceito e tentam aplicar padrões em todos os lugares - normalmente, no código resultante, não é possível encontrar o design real entre todos os Singletons e Fábricas Abstratas (completamente sem sentido).

Menos código é melhor que mais!

Se os usuários dizem "é isso?", E seu trabalho permanece invisível, é feito da maneira certa. Glória pode ser encontrada em outro lugar.

PHP é uma merda ;-)

A prova está no pudim.

O teste de unidade não ajuda a escrever um bom código

O único motivo para realizar testes de unidade é garantir que o código que já funciona não seja quebrado. Escrever testes primeiro ou escrever código nos testes é ridículo. Se você escrever nos testes antes do código, nem saberá quais são os casos extremos. Você pode ter um código que passe nos testes, mas ainda falhe em circunstâncias imprevistas.

Além disso, bons desenvolvedores manterão a coesão baixa, o que tornará improvável a adição de novo código para causar problemas com as coisas existentes.

De fato, vou generalizar isso ainda mais,

A maioria das "Boas Práticas" em Engenharia de Software existe para impedir que programadores ruins causem muitos danos .

Eles estão lá para segurar os desenvolvedores ruins e impedi-los de cometer erros idiotas. Obviamente, como a maioria dos desenvolvedores é ruim, isso é uma coisa boa, mas bons desenvolvedores devem obter aprovação.

Escreva métodos pequenos. Parece que os programadores adoram escrever métodos muito longos, onde fazem várias coisas diferentes.

Eu acho que um método deve ser criado sempre que você pode nomear um.

Não há problema em escrever código de lixo de vez em quando

Às vezes, uma parte rápida e suja do código do lixo é tudo o que é necessário para executar uma tarefa específica. Padrões, ORMs, SRP, qualquer que seja ... Crie um console ou aplicativo da Web, escreva algum sql embutido (é bom) e elimine o requisito.

Código == Design

Não sou fã de diagramas sofisticados de UML e documentação interminável de códigos. Em um idioma de alto nível, seu código deve ser legível e compreensível como está. Documentação e diagramas complexos não são mais fáceis de usar.

Aqui está um artigo sobre o tópico Código como design .

Desenvolvimento de software é apenas um trabalho

Não me interpretem mal, eu gosto muito de desenvolvimento de software. Eu escrevi um blog nos últimos anos sobre o assunto. Passei tempo suficiente aqui para ter> 5000 pontos de reputação. E eu trabalho em uma start-up, fazendo tipicamente 60 horas por semana por muito menos dinheiro do que eu poderia conseguir como empreiteiro, porque a equipe é fantástica e o trabalho é interessante.

Mas no grande esquema das coisas, é apenas um trabalho.

Sua importância está abaixo de muitas coisas, como família, minha namorada, amigos, felicidade, etc., e abaixo de outras coisas que eu preferiria fazer se tivesse um suprimento ilimitado de dinheiro, como andar de moto, veleiro ou snowboard.

Às vezes, acho que muitos desenvolvedores esquecem que o desenvolvimento é apenas algo que nos permite ter as coisas mais importantes da vida (e tê-las fazendo algo que gostamos), em vez de ser o objetivo final em si.

Também acho que não há nada de errado em ter binários no controle de origem . Se houver uma boa razão para isso. Se eu tenho um assembly para o qual não tenho a fonte e talvez não esteja necessariamente no mesmo lugar em cada máquina de desenvolvedores, normalmente o colocarei em um diretório "binários" e o referencio em um projeto usando um caminho relativo .

Muitas pessoas parecem pensar que eu deveria estar queimada em jogo por mencionar "controle de fonte" e "binário" na mesma frase. Eu até sei de lugares que têm regras rígidas dizendo que você não pode adicioná-los.

Todo desenvolvedor deve estar familiarizado com a arquitetura básica dos computadores modernos. Isso também se aplica aos desenvolvedores que têm como alvo uma máquina virtual (talvez ainda mais porque foram informados várias vezes que não precisam se preocupar com o gerenciamento de memória etc.)

Arquitetos / designers de software são superestimados

Como desenvolvedor, odeio a idéia de arquitetos de software. Eles são basicamente pessoas que não codificam mais em período integral, leem revistas e artigos e depois explicam como criar software. Somente pessoas que realmente escrevem software em tempo integral para viver devem fazer isso. Não me importo se você era o melhor codificador do mundo há 5 anos antes de se tornar um arquiteto, sua opinião é inútil para mim.

Como isso é controverso?

Editar (para esclarecer): Eu acho que a maioria dos arquitetos de software faz ótimos analistas de negócios (conversando com clientes, requisitos de gravação, testes etc.), simplesmente acho que eles não têm espaço para projetar software, de alto nível ou de outra forma.

Não existe uma abordagem única para o desenvolvimento

Estou surpreso que essa seja uma opinião controversa, porque me parece senso comum. No entanto, existem muitas entradas em blogs populares que promovem a abordagem do desenvolvimento "tamanho único", então acho que posso ser minoria.

Coisas que eu vi sendo apontadas como a abordagem correta para qualquer projeto - antes que qualquer informação seja conhecida - são coisas como o uso de Test Driven Development (TDD), Domain Driven Design (DDD), Mapeamento Objeto-Relacional (ORM) , Agile (capital A), Orientação a objetos (OO), etc., abrangendo desde metodologias a arquiteturas e componentes. Tudo com boas siglas comercializáveis, é claro.

As pessoas até parecem colocar crachás em seus blogs, como "Eu sou orientado para o teste" ou similar, como se sua estrita adesão a uma única abordagem, independentemente dos detalhes do projeto, fosse realmente uma coisa boa .

Não é.

Escolher as metodologias, arquiteturas e componentes corretos, etc., é algo que deve ser feito por projeto e depende não apenas do tipo de projeto em que você está trabalhando e dos requisitos exclusivos, mas também do tamanho e da capacidade da equipe com a qual você está trabalhando.