Code review e qualidade de código em geral.

[Kaedh]

Boa tarde pessoal,
Eu tenho uma insegurança enorme quanto a qualidade dos códigos que escrevo, acredito que até aí normal, porém eu queria ter certeza que estou escrevendo algo "bonito" e estruturado, tem alguma forma de expor as coisas que escrevo para outras pessoas analisarem, algum grupo no reddit ou facebook, sei lá.
E vocês? como lidam com essa insegurança?

[djhanlj]

Boa tarde @Kaedh, também tenho essa insegurança, acredito que chamam de 'síndrome do impostor', bem não conheço nenhum grupo ou ferramenta que façam essas análises de código, só em equipes de desenvolvimento nos Pull Requests (PR). Mas você pode ler o livro Clear Code (Código Limpo) que dizem ser a bíblia de um bom fazedor de código.

Obs: comprei o livro, mas ainda não li hehe. 8)

[wilsongomes-swe]

Eu acredito que é normal, com o tempo seu código vai melhorando, você terá mais cicatrizes e mais falhas a não serem repetidas, seu código vai ficando mais desacoplado, você vai entendendo a importância do "design for change", vai entendendo a importância dos testes, do SOLID, do DRY, DDD, KISS, vai entendo de arquitetura, de camadas, onion, ports, adapters, clean code, clean archtecture, design patterns, e muito mais...

Acredito que seja como escrever livros ou textos, você sempre poderá melhorar, é uma jornada de melhoria continua praticamente bem longa.

Lido sabendo que é normal, fazendo o máximo para que meu código seja entendível e com as melhores práticas que conheço até então, enquanto estudo e treino bastante para que conhecer práticas melhores.

[ninetails]

Certeza você nunca vai ter. E é mais fácil aceitar que tentar correr atrás do rabo.

E como nossa área, mesmo sendo exata, ela ainda é bem subjetiva.

Não importa a linguagem que vc escolher. Tirando Assembly ou talvez Cobol que a estrutura é bem dependente e inerente ao programa (e talvez outras baixo nível), você tem toda a liberdade de escrever o código da forma que quiser. E poucas são as linguagens que restringem o modo onde você escreve, como exemplo do Go que te fornece uma ferramenta para formatar teu código. Mas mesmo assim, essas ferramentas o máximo que fazem é dizer como escrever o código, não como solucionar um problema da melhor forma possível. E se for levar em conta, mesmo a melhor forma possível para um programador dado uma circunstância pode não ser a mesma para outro programador ou circunstâncias.

E ainda é algo que sofre alterações constantemente.

Aqui eu falo mais de front-end pois estamos num fórum que fala sobre frontend. Hoje o que fazemos de aplicação não é a mesma coisa que fazíamos há 10 anos. Não existiam frameworks que existem hoje. Não existia ES6. Existia HTML5 mas ainda era novidade. Mesmo se pensar em um timespan de ano, os frameworks atuais possuem pelo menos uma atualização "grande" por ano. Novas bibliotecas surgem. Novas tecnologias surgem. Até novos hardwares surgem. Há 15 anos atrás, pensar em mobile era considerado perda de tempo.

E ainda somos bombardeados por padrões de outras linguagens.

Orientação a Objeto nunca foi inerente do JavaScript. async-await veio com o envolvimento da Microsoft. map, filter, reduce veio de linguagens funcionais... PHP também não começou com Orientação a Objetos. Linguagens que não são de baixo nível recebem atualizações e melhorias frequentemente. É um pouco relacionado ao ítem anterior, mas pense que aqui são funcionalidades que mudam a forma inclusive como você escreve um código com boa legibilidade e performático.

Dado isso, o que eu digo: saber a teoria é ótimo, mas dado os fatores anteriores, a prática também é fundamental.

E para melhorar é: continuar indo atrás de conhecimento teórico, com uma infinidade de livros bem renomados, um bom senso para disso tudo tirar um "padrão teu" (pois será impossível ter um padrão juntando todos os livros, uma hora eles vão se contradizer... mas é claro que é sempre bom ver ambos os lados de tais contradições) e fazer o melhor com a tua expertise e o tempo dado, pois quem te contrata também não vai esperar vc arquitetar uma solução utópica se isso atrasar o projeto.

E acho que se vc quer se forçar a ter Code Review, se tiver culhões suficiente a melhor alternativa seria ajudar o open source. Aí teu código vai ser estressado por devs experientes e ainda recebe code review de "graça" além de ajudar a comunidade. O contra é que o projeto não é teu.

Ou se não tiver culhões, posta aqui mesmo, tiveram já alguns posts anteriormente pedindo pra revisarem o código. Afinal, comunidade tá ae pra se ajudar rs.

_{^{Aliás, sobre este assunto, já foi sugerido ter um fórum de Code Reviews mas os mods optaram por deixar rolar aqui mesmo.}}

[lddv]

@Kaedh certeza não vai ter e isso vai de acordo com o que o time define como boas práticas, e as que você aprende por experiência também.

Além do que já foi falado, penso que o primeiro code review deve ser do próprio autor, quando ele revisa todos os arquivos que ele está enviando como parte da mudança pro Pull Request. Tá cheio de gente fazendo git add -A e commita arquivo sem perceber.

Você também pode incluir seus próprios comentários no PR. Isso facilita a revisão. Ninguém gosta de ver um PR de 50+ arquivos, mas se você especificar que foi uma tarefa única estilo find & replace fica bem mais fácil pra quem tá revisando.

Espero ter ajudado, um abraço.