[quote=Marky.Vasconcelos]Aqui também tem revisor, nao faz muita diferença eu acho.
Mas eu acho que não ia gostar de trabalhar pra revisar código dos outros.[/quote]
3
rapaz… te digo que já fiz isto… e realmente é um porre, porem até que as vezes é divertido, vc encontra cada aberração que isto chega as vezes ser engraçado…
Gente, a revisão de código é muitas vezes alocada dentro de práticas ágeis pra diminuir tempo de manutenção posteriormente… Realmente é um pé no saco fazer isso, mas eu ainda vejo como um mal necessário… Por exemplo, em meu primeiro Projeto Corporativo em Equipe com Java, com a arquitetura definida e com todos os desenvolvedores treinados na mesma, saímos para desenvolver nosso Primeiro Caso de Uso… quando todos acabaram de Desenvolver seus Primeiros Casos de Uso, o Arquiteto pegou um dos Casos de Uso e desenvolveu toda a Refatoração no mesmo, dizendo o que precisava melhorar e o que havia saído da Arquitetura… tiramos 1 semana inteira pra readequar os UCs na arquitetura e tirar o que ficou de lixo…
Cara, pensa numa semana legal… achávamos nossas próprias pérolas pra consertar… heueheuheueheuehu, acaba que no final das contas, os próximos Casos de Uso fluem de uma forma bem diferente… MUITA coisa que você faria exatamente igual a refatoração, deixa de ser feita e você vai pelo caminho certo…
Imagina você saber que alguém vai revisar teu código… não digo medo, mas com certeza mais cuidado, nem que seja um pouco mais de cuidado, você vai ter com seu código…
Se vale a pena a nível de projeto ou não eu não sei, mas para os desenvolvedores seria MUUUUUIIIITO útil…
Abs 
Adriano_si, na sua empresa vocês implementam todas as rotinas utilizando UC? E quando é necessario criar campos no banco, tem um DBA só pra isso? Como é esse tipo de organização? Na minha empresa é beem bagunçado… 
Bom, pelo menos onde trabalho é mais ou menos assim.
Toda requisição tem que ser feita pelo pessoal de requisitos que cria/altera um ou mais casos de uso, a gente sofre ao ler e implementa tentando entender o que queriam.
Coisa no banco de produção só o DBA mexe (em teoria…), discutimos alterações mo schema, etc etc etc pra chegarmos num modelo mais legal entre dev e banco,etc etc tec…
Acho legal o desenvolvimento assim, organizado.
[quote=mario.fts]Aleck eu concordo com vc em genero numero e grau. O que eu estou dizendo é que é dificil explicar isto pra pessoas não técnicas (por exemplo, diretores/gerentes/etc).
Se fosse só chegar com um relatório do Sonar ou PMD seria fácil, mas acho que isto não é uma coisa tão simples de mensurar. Como explicar que um bom design reduz o custo de manutenção? reduz em quantos %? e alias, quem garante que reduz mesmo?
Mesmo com um design ruim, mas com uma equipe acostumada com o código, as empresas conseguem atingir seus objetivos. Nós sabemos que a bomba estoura um dia, que os débitos técnicos cobram futuramente, eles é que não sabem. O que eu queria era saber como convence-los disso.
E isso me deixa MUITO puto. Veja isso e me diga se eu tenho ou não motivos pra ficar puto.[/quote]
Mostre para ele na prática, aproveite algum projeto mais light e peça o voto de confiança para implantar novas técnicas e processos na equipe, acho que nada fala mais alto que a realidade.
[quote=Felagund]Existem POG feitas as vezes sem querer sem o conhecimento prévio das regras, mas eu sempre que encontro já perco algum tempo para refazer e reestrutar quela porcaria, pra sair algo descente e mais bem feito.
[/quote]
Sim, existem muitos POGmadores, Anarquistas de sistemas e similares. OBS: POG = programação orientada a gambiarra; Mas tem várias vezes que é melhor, com pouco tempo para fazer um trabalho e aparece aquela gambiarra na cabeça, quem não faria???
[quote=mario.fts]Será que é pq as empresas geralmente estão procupadas simplesmente em resolver seus problemas, não importa quão porcamente o software que o resolva foi escrito?
Não é uma crítica, apenas algo que vejo no meu dia-a-dia.
A pergunta é: Como código simples e organizado adiciona VALOR para a empresa? Concordam que é dificil demonstrar isso na forma de R$?
[]'s[/quote]
[quote=DarthVictor][quote=Felagund]Existem POG feitas as vezes sem querer sem o conhecimento prévio das regras, mas eu sempre que encontro já perco algum tempo para refazer e reestrutar quela porcaria, pra sair algo descente e mais bem feito.
[/quote]
Sim, existem muitos POGmadores, Anarquistas de sistemas e similares. OBS: POG = programação orientada a gambiarra; Mas tem várias vezes que é melhor, com pouco tempo para fazer um trabalho e aparece aquela gambiarra na cabeça, quem não faria???
[/quote]
Mesmo neste caso, ou é inexperiência ou relaxo mesmo. Quando a pessoa adquire a preocupação de escrever código limpo ela passa a ler o próprio código para tirar essas gambiarras. E geralmente a coisa acontece do jeito que você falou mesmo, você tem um problema para resolver e faz a primeira gambiarra que vêm à cabeça para resolvê-lo, daí que vem a diferença, quem é mais caprichado tem a preocupação de reescrever a solução de uma maneira mais limpa.
[quote=rmendes08][quote=DarthVictor][quote=Felagund]Existem POG feitas as vezes sem querer sem o conhecimento prévio das regras, mas eu sempre que encontro já perco algum tempo para refazer e reestrutar quela porcaria, pra sair algo descente e mais bem feito.
[/quote]
Sim, existem muitos POGmadores, Anarquistas de sistemas e similares. OBS: POG = programação orientada a gambiarra; Mas tem várias vezes que é melhor, com pouco tempo para fazer um trabalho e aparece aquela gambiarra na cabeça, quem não faria???
[/quote]
Mesmo neste caso, ou é inexperiência ou relaxo mesmo. Quando a pessoa adquire a preocupação de escrever código limpo ela passa a ler o próprio código para tirar essas gambiarras. E geralmente a coisa acontece do jeito que você falou mesmo, você tem um problema para resolver e faz a primeira gambiarra que vêm à cabeça para resolvê-lo, daí que vem a diferença, quem é mais caprichado tem a preocupação de reescrever a solução de uma maneira mais limpa.[/quote]
Eu sei, lembro uma vez que o professor mandou a gente fazer um programa que resolve um sistema de 8 equações. Eu lembro que fiz uma gambiarra tão doida de tentativa e erro, que mesmo no meu quadricore com 4 giga de ram, levou 8,43 segundos para voltar o valor. Estava usando C(linguagem extremamente rapida), prefiro isto que ficar com 0, além do mais ele só olhou as respostas, se eu pudesse eu teria usado um método melhor e não POG, mais entre POG e nada, vai o menos pior( POG).
Bom, pelo menos onde trabalho é mais ou menos assim.
Toda requisição tem que ser feita pelo pessoal de requisitos que cria/altera um ou mais casos de uso, a gente sofre ao ler e implementa tentando entender o que queriam.
Coisa no banco de produção só o DBA mexe (em teoria…), discutimos alterações mo schema, etc etc etc pra chegarmos num modelo mais legal entre dev e banco,etc etc tec…[/quote]
É isso aí… na empresa que citei o trampo era assim mesmo… Agora trabalho na anarquia… quando precisa, manda e-mail e muita fé de que será atendido… enquanto isso parte pra outra coisa e aguarda o retorno daquela… e assim segue a vida…
Tô procurando um trampo em empresa que utilize metodologia ágil… Não porque acho que é a solução do mundo, mas porque queria conhecer e tirar minhas próprias conclusões… Não gosto de falar antes de conhecer, apesar de que, tinha uma equipe desde a época de faculdade, já utilizávamos práticas ágeis como Programação em Par, Refactoring, Desenvolvimento baseado em Testes (não igual ao que se tem hoje é claro) e até contrato de escopo variável… Tínhamos Sprints para o cliente e claro que a definição do que era importante ou não, nem sempre era o que o cliente achava importante, mas na maioria das vezes, acertávamos…
Enfim… queria testar agilidade hoje, não digo que é a solução pra tudo, mas vejo como um caminho pra reduzir as camadas burocráticas que temos hoje pra desenvolver um software…
Abs
[quote=mario.fts]Aleck eu concordo com vc em genero numero e grau. O que eu estou dizendo é que é dificil explicar isto pra pessoas não técnicas (por exemplo, diretores/gerentes/etc).
Se fosse só chegar com um relatório do Sonar ou PMD seria fácil, mas acho que isto não é uma coisa tão simples de mensurar. Como explicar que um bom design reduz o custo de manutenção? reduz em quantos %? e alias, quem garante que reduz mesmo?
Mesmo com um design ruim, mas com uma equipe acostumada com o código, as empresas conseguem atingir seus objetivos. Nós sabemos que a bomba estoura um dia, que os débitos técnicos cobram futuramente, eles é que não sabem. O que eu queria era saber como convence-los disso.
E isso me deixa MUITO puto. Veja isso e me diga se eu tenho ou não motivos pra ficar puto.[/quote]
Depende do tipo de relação estabelecida, se é de profisisonal, porque precisaria explicar não-técnicos “como” vai fazer, se é vc que vai acabar fazendo no final?
Por outro lado, se vc é funcionário está la para executar a visão de outros, e se não concorda com a visão apresentada deve tentar algo mais concreto, além de simplesmente evangelizar por “bom design no software”.
[quote=AbelBueno]Já trabalhei em lugares que o uso de recursos mais avançados da linguagem era desencorajado, para não dificultar a vida dos iniciantes.
(Mesmo que você solucionasse um problema em 5 ao invés de 100 linhas).
Se utilizasse assim mesmo, você virava o “pai” do código e era o único a dar manutenção…[/quote]
Já vi isso. Mas era por causa da pessoa “experiente” que não queria pensar ao dar manutenção posterior ao código.