Página 1 de 1

Você contrataria o Viktor Vszakats ?

Enviado: 01 Set 2019 10:26
por Vlademiro
A pergunta, obviamente, é provocativa. Quem não gostaria de ter um programador de primeira no seu time de desenvolvedores ?

Mas, e se você não soubesse que o programador era o Viktor ? Se você tivesse acesso a somente um trecho de código dele e fosse se basear somente no que os compêndios e manuais de programação prescrevem ? Será que você o contrataria ?

Na primeira empresa em que trabalhei, já tem um bom tempo, eu me deparei com rígidas regras para manter o software claro (essa palavra era muito usada por eles). Lá tinha algumas regrinhas chatas que todos deviam seguir. Por exemplo: o retorno da rotina deve vir sempre no final dela, não pode usar EXIT ou LOOP dentro de laços, as variáveis devem possuir uma nomenclatura que expresse o seu tipo de dado e escopo (lá usavem ll_ como prefixo para variável Local e Lógica, por exemplo). Essas regras chatas na verdade ajudavam a manter o código compartilhável entre os membros da equipe. Hoje, fala-se muito em Clean Code (uma rápida busca no youtube trás alguns vídeos sobre o tema), padrões de código ou styleguides.

Mas o que isso tem a ver com o Viktor ?

Calma que eu vou chegar lá.

A ideia de se manter o código limpo é boa, mas como toda boa ideia, tem os seus limites. No meu dito primeiro emprego, o programador chefe me mandou implementar uma rotina para um cliente, nem me lembro mais o que era, só me lembro de mostrar o resultado para ele. Lembro quando ele apontou erros na rotina (algo do tipo: "aquele EXIT não pode ficar ali, o código não fica claro"). No final das contas ele perdeu a paciência comigo e foi ele mesmo me ensinar como fazer. Para espanto de todos (inclusive dos outros estagiários) ele não conseguiu resolver o problema da forma que ele mesmo desejava resolver, e acabou colocando o EXIT dentro da rotina.

Sim, mas e o Viktor ?

Há sim, quase ia me esquecendo. É o seguinte: eu tive a oportunidade de mecher em um código desenvolvido pelo Viktor. Não era um fork nem era o core do harbour (não tenho conhecimento para tanto). Era um aplicativo escrito em Harbour que eu precisei adaptar para um uso pessoal. Quando comecei a olhar o código eu descobri que o Viktor havia colocado um RETURN no meio de uma rotina, aí eu pensei : "Será que ele seria contratado pela empresa onde eu trabalhei ?".

A minha resposta é: "Sim, desde que a empresa conseguisse enchergar o excelente programador que ele é." Mas antes de enchergar o excelente profissional que ele é, a empresa precisa observar, ler nas entrelinhas e abrir mão das regras que todos ficam repetindo como se fosse um mantra. Se a empresa ficar bitolada apenas na busca de padrões de codificação ela vai acabar abrindo mão de excelentes profissionais.

E vocês, o que acham ?

Você contrataria o Viktor Vszakats ?

Enviado: 01 Set 2019 13:07
por JoséQuintas
O que vejo é o seguinte:

O que deve ser evitado:

- variável PRIVATE
- MACRO
- Arquivo MEM
- RETURN desnecessário
- Abuso de Classes
- Abuso de funções
- Abuso de IFs
- Abuso até de variáveis
- Abuso de fonte mesmo

A empresa pode proibir o uso, no intuito de evitar erros do programador.
Acho que 100% dos usuários que restam no Clipper abusam dos itens acima, e muitos que foram pra Harbour/XHarbour continuam abusando.

Toda regra tem exceção, e às vezes há conflito de regras, e é necessário escolher qual das regras iremos considerar em determinado conflito.

No caso de um teste de admissão, a regra já pode eliminar candidatos viciados naquele uso errado, porque não vão conseguir fazer de outra forma, mas deve ser avaliado se aquilo não se trata de exceção.

Conclusão: existem regras e exceções, só não pode usar as exceções pra tudo.

Você contrataria o Viktor Vszakats ?

Enviado: 01 Set 2019 13:18
por JoséQuintas
Só complemento:

Houve uma época em que testei o JOINER.
Era um similar Clipper pra usar em UNIX/XENIX.
Não existia macro nesse compilador.
Aprendi muito com isso, porque comecei a não usar macro no Clipper, e ficava tudo mais rápido.

Bugs... como eles diziam, tinha bug até no Clipper, então era aceitável ter no Joiner.

Um certo dia, o SEEK não funcionava na base, apagando um registro ou adicionando um registro tudo bem.
Nessa hora, entrou o que comentei no post anterior: bug é exceção, a partir do momento que se tornaria regra, adeus Joiner.

Hoje em dia evito ao máximo usar macro, mas com certeza ainda uso, senão teria que usar muito fonte pra substituir os casos aonde ainda uso.