Fotografia de capa por Niranjan, tirada por uma Canon, EOS 90D
É muito comum pra novos desenvolvedores achar que uma aplicação ideal é uma aplicação com código cheio de padrões e testes, uma aplicação que do início até a fase final é levado em conta tópicos como clean code e clean architecture, porém quem esta no mercado há um tempo sabe que não é assim que as coisas são...
A ilusão de mundo perfeito de código se vai quando você é cobrado pra entregar sua primeira feature em um produto que já existe e fica apavorado com a quantidade de coisas erradas sendo feitas ao redor daquela parte do código que você tá mexendo, e um comportamento normal em devs novos é achar que tudo da teoria se aplica a prática, um de vários exemplos que posso citar é do livro clean code:
“Duplication is the primary enemy of a well-designed system. It represents additional work, additional risk, and additional unnecessary complexity.”
― Robert C. Martin
Essa citação quando você lê faz total sentido, dado que duplicação de código é problemático principalmente em sistemas mais complexos e maiores por conta de você não ter certeza se fez um fix em todos os lugares que precisava, mas algo bem pior que a duplicação é uma abstração errada. Justamente pois uma duplicação outro dev consegue entender, e a abstração é alguma lógica que tava na cabeça do dev anterior, que pode ter pego a regra de negócio do produto incompleta, e isso, consequentemente gera complexidade desnecessária.
Então com o tempo você vai entendendo a melhor hora de duplicar código e a melhor hora de abstrair ele, nisso é envolvido tanto a sua experiência quanto o momento do produto.
Entenda que eu não estou dizendo que padrões e testes não são necessários, o que quero dizer é que as mudanças no código precisam ser feitas com base no produto que afeta o usuário final.
Um exemplo disso é:
- Pra que escrever testes? pra evitar que o usuário seja exposto a bugs inesperados.
- Pra que criar uma abstração em cima de tal design pattern? pra facilitar criar features novas para o usuário.
Escrever código é uma forma de otimizar processos, mas é sempre um aditivo pois produto existe sem código, resolver problemas primariamente sem código vai ser sempre mais barato e menos trabalhoso.
Código legado é ruim quando precisamos dar manutenção nele, quando não precisamos, ele não é!
Então quando digo resolva problemas e não goste de código, eu quero dizer que o melhor perfil de desenvolvedor na minha opinião é o que usa código pra construir produto e não usa o produto pra poder construir código, ou seja, código é uma ferramenta que você pode ou não usar pra entregar melhor valor as pessoas.
Se hoje você não é orientado a produto e quer ser, deixo aqui 3 passos:
- Procure entender o negócio e como aquele produto gera valor para a empresa.
- Dê opiniões e ideias sobre o produto.
- Comunique-se bem não só com devs e entenda o fluxo inteiro (marketing, vendas, design...)
A sua ownership sobre produto vai ser inevitavelmente maior!