Sou mto ruim ou é normal!?

A documentação do sistema está ai para te ajudar nisso…

por exemplo, que tal dar uma olhada no diagrama de classes para ver como as classes estão interagindo ?!

Eae Marck,

Eu acho isso normal, pois vc entender o que outra pessoa fez as vezes é muito mais complicado do que fazer do zero! isso tbm é questão de lógica, o jeito é procurar um livrinho de lógica… para acustumar sua cabeça!

“Bons programadores escrevem códigos para pessoas entenderem e nao para o computador!”

Mas é Normal isso ae…

Boa sorte! =D

heuhua…

Nosso sistema não tem documentação, comentário…NADA…heueh…
Tem algumas coisas esquisitas que “vc” demora a encontrar.

O problema não é lógica. Todo código que escrevo, tento me colocar no lugar de alguém que estará trabalhando com ele.
Imagine, programação estruturada, alguns calculos que são feitos no init de um relatório, e dependendo de uma condição que está sendo verificada DENTRO DE UM CAMPO, ele mostra o valor. Então vc fica algum tempo seguindo o código e acompanhando os calculos que da um valor e na exibição mostra outro totalmente diferente. O problema é q isso poderia ser feito de uma maneira TÃO mais fácil.

isso é de mata!!!

Dependendo do código nem deus imagina o que se passava na cabeça do programador…

conhece quem fez?
então, mete bronca meu caro…hahahhhahaa…brincadeira heim…

hahheau

Agente passa o dia todo zuando aqui…rss

Costumamos dizer q temos um Sistema de Desinformação. heeu

acho que programar é igual a letra de cada um uauha tipo… se o cara programa bem pensando na legibilidade… entao isso facilita a compreensao… agora se o cara programa para entendimento dele… e talz ai complica… se nao tiver a a documentacao… é complicado e as vezes ja peguei uns com documentacao e tava ao contrario do que estava no codigo imagine ai? hehe

E a letra de uma pessoa é a mesma coisa, eu qdo escrevo para minha compreensao é dificil terceiros entender, porem qdo vou escrever algo que vai ser transferivel ai tenho que escrever bonitinho para depois o cara nao me encher o saco ligando perguntando o que está escrito na parte X.

em um ambiente de desenvolvimento esse fato de nao entendimento é anormal, o normal é que vc entenda… mais vai ai da politica da empresa de como cobra isso dos gerentes e os gerentes dos desenvolvedores. Ja empresa cobrar isso, como tarefa do desenvolvedor mesmo. Principalmente aquelas que ja sofreram com isso qdo o cara saiu…

hehe!

depende do animal q fez o codigo
depende da sua capacidade
dependa da arquitetura
depende da documentacao bem detalhada

Entenda a merda feita

/** O metodo faz um monte de coisas para o usuario quando o programador precisa
     * @param w
     */
    public void metedoFaz(Object w) {  
       
    	Alun x = new Alun(); 
    	Clace y = new Clace(); 
    	Prof z = new Prof(); 
    	
    	x.setNom("Macelo"); 
    	y.setNum(145); 
    	z.setNom("Marcelo");
    	
    	z.setAlun(x);
    	y.setProf(z);
    	    	
    }

entenda a merda “documenta”

/** O metodo faz o encapsulamento do Alun (Aluno) e Prof (Professor) na objeto Clace (Classe).
     * @param w - Object
     */
    public void metedoFaz(Object w) {  
       
    	Alun x = new Alun(); // A e o tipo de Aluno
    	Clace y = new Clace(); // Clace é a Classe do aluno
    	Prof z = new Prof(); // Classe professor
    	
    	x.setNom("Macelo"); // Nome do Aluno
    	y.setNum(206); // Numero da classe
    	z.setNom("Marcelo"); // Nome do professor
    	
    	z.setAlun(x);
    	y.setProf(z);
    	    	
    }

Documentar o codigo não significa sempre criar um monte de comentários e java doc.
Muitas vezes a correta nomeação das vareáveis, métodos e classes já torna o codigo muito mais
legivel. Pegando o exemplo do jjose veja a diferença:

public void criaClasseParaAluno(String nomeDoAluno) {  
       
    	Aluno aluno = new Aluno(); 
    	Classe classe = new Classe (); 
    	Professor professor = new Professor(); 
    	
    	aluno.setNome(nomeDoAluno);
    	classe.setNumero(206); 
    	professor.setNome("Marcelo"); 
    	
    	classe.addAluno(aluno);
    	classe.setProfessor(professor);
    	    	
       
    }

sergiotaborda:

Documentar o codigo não significa sempre criar um monte de comentários e java doc.
Muitas vezes a correta nomeação das vareáveis, métodos e classes já torna o codigo muito mais
legivel. Pegando o exemplo do jjose veja a diferença:

public void criaClasseParaAluno(String nomeDoAluno) {  
       
    	Aluno aluno = new Aluno(); 
    	Classe classe = new Classe (); 
    	Professor professor = new Professor(); 
    	
    	aluno.setNome(nomeDoAluno);
    	classe.setNumero(206); 
    	professor.setNome("Marcelo"); 
    	
    	classe.addAluno(aluno);
    	classe.setProfessor(professor);
    	    	
       
    }

eu tentei da um exemplo de um codigo ruim com documentacao e o mesmo sem
mostrar como o comentario pode salva ou ajudar no entendimento
se tem varios programadores “programando”
vai saber o nome que o lazarento vai por no metodo
todo metodo faz alguma coisa entao pq colocar o nome metodoFaz
a documentacao feita no primeiro naum ajuda em nada
nomes errados e sem padrao da sun

programador satan - o programador veio do inferno para condenar o projeto

o código deve ser bem escrito, de forma que qq programador possa entendê-lo…

se for para encher de comentários no codigo é melhor dar uma estudada em refatoração, pois está no momento de refatorar o código e deixá-lo legível…

O ponto principal é a perda de tempo tentando entender tais códigos.
Aqui na empresa, temos um erp que ao longo dos anos foi alterado unicamente por freelancers…

Então, o cara chegava, fazia do jeito que queria e ia embora…Não houve cobrança para documentação nem nada do tipo.
O complicado é q vc vê mta coisa errada e sabe que quem faz tbm sabia q estava errado, mas por falta de comprometimento deixou daquele jeito.

É complicado mesmo.

Eu penso que o código deve ter 2 requisitos importantes, além de funcionar (óbeveo): nomes de variáveis auto-explicativas e javadoc.

dedejava:

É complicado mesmo.

Eu penso que o código deve ter 2 requisitos importantes, além de funcionar (óbeveo): nomes de variáveis auto-explicativas e javadoc.

Eu troco o javadoc por testes. Se o programador realmente escreveu bem o seu código, este não só será legível como existirão testes pra demonstrar na prática onde o programador queria chegar quando escreveu aquilo.

Em todos os meus últimos projetos a facilidade de entender o código era diretamente proporcional a quantidade e qualidade dos testes existentes…

s4nchez:

Eu troco o javadoc por testes. Se o programador realmente escreveu bem o seu código, este não só será legível como existirão testes pra demonstrar na prática onde o programador queria chegar quando escreveu aquilo.

Em todos os meus últimos projetos a facilidade de entender o código era diretamente proporcional a quantidade e qualidade dos testes existentes…

valeuz…

O que eu disse não quer dizer que ele somente terá aquilo. Mas é uma coisa básica que, na minha opinião, o código deve ter.

Eu discordo, imaginem se o pessoal da sun seguisse esta linha de raciocínio… acho que documentação com javadoc é extremamente importante, porém o que ocorre é que tem gente que escreve uma monografia sobre o método.

A documentação do Método deve ser simples e rápida.

Metodos devem ser simples de se entender, o mesmo deve acontecer com a documentação…

Eu discordo, imaginem se o pessoal da sun seguisse esta linha de raciocínio… acho que documentação com javadoc é extremamente importante, porém o que ocorre é que tem gente que escreve uma monografia sobre o método.

A documentação do Método deve ser simples e rápida.

Javadoc é extremamente importante para API Java, onde quem a usa tem que saber o que o método faz, sem necessariamente entender o código dele.

Agora, num projeto onde os desenvolvedores têm que saber como cada método está implementado, o cenário é outro. E neste caso me desculpe mas eu continuo preferindo testes.

Na minha opinião, para uma pessoa entender um código existente, as melhores práticas são (em ordem de eficiência):

1. Sentar com quem fez e programar em dupla
2. Executar os testes e ver como o código está sendo utilizado
3. Ler qualquer documentação em texto (javadoc, diagramas etc)

coisas deste tipo são os spaguetti code ou as gambiarras nervozas… realmente e dificil mesmo entender codigos que são feitos assim e ainda não se tem comentarios… programador bom faz codigo pra ser entendido e com javadocs e comentarios para que outro entenda… e não faz spaguetis quem faz spaguete deveria e ser cozinheiro e não progrmador… bem mas isto e mais normal que vc possa imaginar… mas se olhar atentamente para um codigo e ver que eles esta descentralizado todo emaranhado cheio de gambiarra e que vc não consegue entender bulhufaz não se preucupe não e vc que e ruim e sim o “cozinheiro” ou o “magaiver(mestre das gambis)” que fez o codigo…

Não é sempre sobre somar, mas escrever e manter tralha desnecessária. Eu fico extremamente feliz quando posso deletar código ao invés de escrever mais. Se o seu código é claro o suficiente, faz sentido escrever documentação que precisa ser atualizada quando houver mudanças? No fim das contas ainda se trata de bom senso, ou você documenta gets/sets?

valeuz…

Complicado qd vc vê no meio do código uma chamada para um metodo q é executado no banco de dados…rs…500 linguagens em um bloco de código…rsss
Bom, tomara q eu não seja “tão ruim assim”…rs…

Sobre o problema q falei, as vezes encontro código com 100 linhas para fazer algo muito simples e outros q fazer coisas super complexas com 10 linhas…
Outra coisa q me incomoda é qd o cara faz uma alteração e o código antigo ele deixa comentado…fica uma tralha gigante…dá pra encontrar coisa de 5 anos atrás…rs
e os comentáros: “alterei pq o usuario X pediu…” ehehe

[edit]
Sobre javadoc não tenho q falar pois nossa linguagem é totalmente ultrapassada, mas a documentação é independente de linguagem…
[\edit]

Marck:

Pessoal,

Vcs pegam códigos que te faz passar horas e horas tentando entender o q está sendo feito?
Valores que vc nem imagina de onde estão vindo?

Eu sou mto ruim ou isso é normal?

Abraço!

Tem uma boa solução (ao menos a melhor que encontrei) para isso, refatorar…
de faz entender o código mais rapidamente… além de deixar a apossibilidade de dar mais flexibilidade ao atual sistema.

refatora um pouquinho testa, refatora um pouquinho e testa.

dreampeppers99:

Marck:

Pessoal,

Vcs pegam códigos que te faz passar horas e horas tentando entender o q está sendo feito?
Valores que vc nem imagina de onde estão vindo?

Eu sou mto ruim ou isso é normal?

Abraço!

Tem uma boa solução (ao menos a melhor que encontrei) para isso, refatorar…
de faz entender o código mais rapidamente… além de deixar a apossibilidade de dar mais flexibilidade ao atual sistema.

refatora um pouquinho testa, refatora um pouquinho e testa.

citei em um dos posts acima sobre refatoracao…

mas para usar refatoracao nao eh assim tao trivial nao…é bastante aconselhavel q se tenha um conjunto de testes automatizados…nao é simplesmente "refatora um pokim, testa, refatora outro pokim e testa " …é mais do que isso…

abraços

pardal_nb:

citei em um dos posts acima sobre refatoracao…

mas para usar refatoracao nao eh assim tao trivial nao…é bastante aconselhavel q se tenha um conjunto de testes automatizados…nao é simplesmente "refatora um pokim, testa, refatora outro pokim e testa " …é mais do que isso…
abraços

Bem eu acredito que essa “trivialidade” se dá para quem conhece o processo de refatoração…
Quando disse:
“Refatora um pouquinho, testa, refatora …” estava resumindo (muito mesmo) o processo, ora quem quiser saber que leia.

Pior que eu? Ah, duvido!

Marck:

O ponto principal é a perda de tempo tentando entender tais códigos.
Aqui na empresa, temos um erp que ao longo dos anos foi alterado unicamente por freelancers…

Então, o cara chegava, fazia do jeito que queria e ia embora…Não houve cobrança para documentação nem nada do tipo.
O complicado é q vc vê mta coisa errada e sabe que quem faz tbm sabia q estava errado, mas por falta de comprometimento deixou daquele jeito.

Se a empresa não mantém um padrão de desenvolvedores da nisso mesmo, o negocio dele é ganhar e se mandar

[color=red] Segundo pensamento POG [/color] Do meu jeito é mais fácil e rápido!

Preciso de um programador, quem cobra menos???

[]'s

jack_-_ganzha:

s4nchez:

Eu troco o javadoc por testes. Se o programador realmente escreveu bem o seu código, este não só será legível como existirão testes pra demonstrar na prática onde o programador queria chegar quando escreveu aquilo.

Em todos os meus últimos projetos a facilidade de entender o código era diretamente proporcional a quantidade e qualidade dos testes existentes…

Totalmente de acordo. E acho que lendo documentação vc não aprende exatamente a ler código. Ler e escrever código é que ensinam a… erhm… ler e escrever código.

valeuz…

Como funciona, vocês perguntam “O que você prefere, documentado ou bem escrito?” ?

Não pode existir os dois?
Eu sempre vejo as pessoas trocarem uma qualidade pela outra nessa forum ao invez de somar

Marck, o problema pode não ser você, já viu os programadores MacGyver que tentam programar em 500 linguagens/scripts e detonam tudo?

Não é sempre sobre somar, mas escrever e manter tralha desnecessária. Eu fico extremamente feliz quando posso deletar código ao invés de escrever mais. Se o seu código é claro o suficiente, faz sentido escrever documentação que precisa ser atualizada quando houver mudanças? No fim das contas ainda se trata de bom senso, ou você documenta gets/sets?

valeuz…

Se houver alguma validação eu coloco no javadoc sim… Se um outro programador precisar usar, nem precisa olhar meu código pois vai estar detalhado.
Quando alguém pergunta dos meus códigos eu respondo “Olhe pelo nome da classe,o método e javadoc que é isso que vai ser feito!”.

/** Este método persiste uma Venda. Lazy para ItemVenda e Produto.
	 * @param venda VendaVO
	 * @return boolean
	 * @throws Exception
	 */
	public boolean insertInLazy(VendaVO venda) throws Exception{

• Isso atrapalha no que?