Tópicos de desenvolvimento de software sobre os quais mudei de ideia depois de 6 anos na área
(chriskiehl.com)Coisas sobre as quais mudei de ideia: coisas contra as quais eu brigava no passado, mas nas quais agora passei a acreditar
- Em equipes compostas por pessoas com diferentes níveis de experiência, linguagens tipadas são melhores
- Reuniões de stand-up são úteis para acompanhar os novatos
- Retrospectivas de sprint têm partes úteis e partes ruins (quando agile/scrum masters desperdiçam o tempo de todo mundo)
- Arquitetura de software é mais importante do que qualquer outra coisa. Uma implementação ruim de uma boa abstração não prejudica a base de código. Abstrações ruins ou camadas ausentes fazem tudo piorar
- Java não é uma linguagem tão ruim assim
- Código espirituoso normalmente não é bom código. Clareza vem antes de tudo
- É possível escrever código ruim em qualquer paradigma
- "Best practices" dependem do contexto e não se aplicam a tudo. Segui-las cegamente faz de você um tolo
- Projetar um sistema escalável sem necessidade faz de você um mau engenheiro
- Análise estática é útil
- DRY é uma forma de evitar certos problemas, não o objetivo final
- Em geral, RDBMS > NoSQL
- Programação funcional não é uma cura para tudo, é apenas mais uma ferramenta
Opiniões que fui adotando no caminho:
- YAGNI > SOLID > DRY : nessa ordem
→ You Aren't Gonna Need It : um dos princípios do XP
→ SOLID : os 5 princípios do design orientado a objetos
Single responsibility
Open-close
Liskov substitution
Interface segregation
Dependency inversion
→ DRY : Don't Repeat Yourself - Lápis e papel são a melhor ferramenta de programação pouco usada
- Em geral, trocar pureza por praticidade é uma boa escolha
- Adicionar mais tecnologia não é uma boa escolha
- Conversar diretamente com o cliente permite entender mais sobre o problema com mais precisão e em menos tempo
- A palavra "scalable" tem um poder místico e surpreendente sobre a mente dos engenheiros de software. Basta pronunciá-la de leve para lançá-los em um frenesi corrompido. Ao usar essa palavra, ações impiedosas acabam sendo justificadas
- Apesar de serem chamadas de "engenharia", a maioria das decisões é cargo cult, sem análise, dados ou números que as sustentem
→ Cargo cult: costume de esperar acreditando que alguém tecnologicamente avançado (sociedade/ancestrais) trará uma carga especial em navios ou aviões - 90%, talvez 93%, dos gerentes de projeto poderiam desaparecer amanhã sem qualquer perda em termos de eficácia ou eficiência
- Depois de fazer 100 entrevistas, cheguei à conclusão de que o formato de entrevista está completamente quebrado. Eu também não sei como melhorar isso
Opiniões antigas que não mudaram:
- Pessoas que dão muita importância a estilo de código, regras de lint e outras coisas triviais são excêntricos malucos
- Cobertura de código não tem absolutamente nada a ver com qualidade de código
- Monólitos são bem bons na maioria das situações
- Puristas de TDD são os piores. Suas mentes frágeis e pequenas não conseguem lidar com a existência de outros workflows
- Quando eu completar 10 anos de carreira, vou ver o que mais mudou ou se inverteu
9 comentários
Cada frase gera identificação. Parece que estamos mudando de um idealismo em que tudo pode ser perfeito para um pragmatismo.
Quando você entende a importância do TDD, a partir daí, como programador ...
Continua aparecendo muita opinião de que as entrevistas estão quebradas. Eu mesmo não teria confiança se me mandassem fazer um teste de programação (...).
Também encontrei este texto. Dizem que é um trecho do livro HARD CODE.
https://johngrib.github.io/wiki/better-interview/
Você percebeu essas coisas só depois de 6 anos? Hahaha, impressionante.
Em 6 anos, você alcançou a iluminação e virou um Buda!
No Hacker News, outros desenvolvedores e engenheiros com mais de 20 anos de experiência também apareceram e estão deixando comentários adicionais.
https://news.ycombinator.com/item?id=25887373
O primeiro comentário já veio pesado haha. Se for analisar um por um, provavelmente também existem situações excepcionais, mas parece perigoso transformar qualquer coisa em crença cega.
Como há bastante bugs que podem ser resolvidos só com checagem de tipos, parece ser um tema que vai continuar sendo levantado. E os métodos para lidar com tipos de forma segura também seguem evoluindo.
(Mas o TypeScript realmente é meio difícil T_T.)