A maioria das empresas de software tem códigos complicados?

Existe. Sempre existe um estagiário, um colega não tão cuidadoso ou um sistema legado com uma tecnologia inerentemente difícil (onde será difícil também montar o ambiente para recompilar a solução, pois ele é velho, seus componentes são difíceis de encontrar, etc). Quando se trabalha em equipe, é inevitável.

Agora, já trabalhei em equipes que o pessoal, no geral, era muito bom. Aí tinhamos no geral códigos usando muitos recursos da linguagem (o que poderia complicar para um iniciante), mas muito simples de manter, pois eram muito organizados.

ViniGodoy:

Existe. Sempre existe um estagiário, um colega não tão cuidadoso ou um sistema legado com uma tecnologia inerentemente difícil (onde será difícil também montar o ambiente para recompilar a solução, pois ele é velho, seus componentes são difíceis de encontrar, etc). Quando se trabalha em equipe, é inevitável.

Agora, já trabalhei em equipes que o pessoal, no geral, era muito bom. Aí tinhamos no geral códigos usando muitos recursos da linguagem (o que poderia complicar para um iniciante), mas muito simples de manter, pois eram muito organizados.

Que história é essa? agora todo estágiario por não ter experiência é um mal programador? ele nao pode ter estudado o suficiente para entender e manter um código padrozinado ?

Concerteza!

Já vi código tipo:

for (int i = 0; i < lista.size(); i++) if (condição = true) i = 10000000; }

A parte do i = 10000000; era para sair do loop! :shock:

Existem pessoas que apenas sabem Java, mas não querem aprimorar seus conhecimentos. Uma equipe boa em Java é cara, e não é facil de se manter.
É mais fácil ter um Sênior que arquitete tudo e 2 profissionais que façam o código funcionar do que 3 pessoas que saibam OO e estejam sempre aprimorando.

Oi,

Uma maneira de diminuir (não acabar) com isso seria a utilização de técnicas/metodologia de desenvolvimento, como XP, Scrum etc…
A empresa onde trabalho utiliza a técnica XP - Extreming Programming. Existe um Implementador, Revisor e Testador.

Acredito ser um diferencial e uma boa pratica.

Tchauzin!

lina:

Oi,

Uma maneira de diminuir (não acabar) com isso seria a utilização de técnicas/metodologia de desenvolvimento, como XP, Scrum etc…
A empresa onde trabalho utiliza a técnica XP - Extreming Programming. Existe um Implementador, Revisor e Testador.

Acredito ser um diferencial e uma boa pratica.

Tchauzin!

Concordo!

moacirjava:

lina:

Oi,

Uma maneira de diminuir (não acabar) com isso seria a utilização de técnicas/metodologia de desenvolvimento, como XP, Scrum etc…
A empresa onde trabalho utiliza a técnica XP - Extreming Programming. Existe um Implementador, Revisor e Testador.

Acredito ser um diferencial e uma boa pratica.

Tchauzin!

Concordo!

Concordo! [2]

Aonde trabalho a empresa usa um gerador de código Apyon, uma palhaçada o código gerado, e no mais existem ‘‘programadores’’ marmanjos de mais de 30 anos/ alguns até formados que não tem a mínima lógica de programação.

Sim.
A experiência é fundamental fazer um bom código.
É difícil vc ter experiência suficiente para saber dividir bem classes sem ter experiência profissional.

Também é difícil você fazer bons sistemas multi-thread sem experiência, ou se preocupar em ter boas práticas de programação.

As exceções, com certeza, serão de estagiários que já tiveram experiência profissional prévia.

Tal como um médico tem que fazer residência para ser um bom médico, um estagiário tem que programar um bocado até se tornar um bom programador.

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…

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…

Puxa, no final é o projeto que tem que se adequar ao estagiário e não o contrário ?!! :shock:

Caraca, deve ser osso escrever 100 linhas só para deixar mais fácil para o estagiário…

O problema das 100 linhas é a chance que ela pode gerar de aparecer um bug, contra as 5 linhas que poderiam reduzir isto.

É, sempre tem alguem que não é muito bom escrevendo códigos.

Já peguei uns pra manutenção que me deixou incredulo com a criatividade para gambiarras que as pessoas deixam nos códigos para “apenas funcionar”, que é a visão que programadores não muito bons tem.

Mas sobre estagiario, eu sou um, mas só pelo fato de que estava fora da area e programei uns 4 anos só por diversão.

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…

Mas acredito que é dever de todo iniciante sair do nível de iniciante, é preciso conhecer a linguagem em toda a sua plenitude sob pena de produzir código verboso muitas vezes mal projetado por conta de ter que fazer muita coisa “no braço”. Acho que o código mais avançado muitas vezes é mal documentado incluindo as fontes de onde ele foi tirado, nesse caso vale a pena ao terminar de se produzir um código que utilize recursos avançados fornecer a fonte de onde aquele conhecimento foi tirado, chegando até mesmo a criar algum documento ensinando o uso do recurso, para que dessa forma os iniciantes cresçam junto com o pessoal mais “avançado”.

Eu fico revoltado de dar manutenção em códigos gambiarrados. Além de ser muuito mais difícil, parece que você vicia em escrever código do mesmo jeito. Sem contar que além de você se preocupar com as regras do negócio vc tem de se preocupar em decifrar o que aquele POG tá fazendo… “Ai… I love this job…”

lina:

Oi,

Uma maneira de diminuir (não acabar) com isso seria a utilização de técnicas/metodologia de desenvolvimento, como XP, Scrum etc…
A empresa onde trabalho utiliza a técnica XP - Extreming Programming. Existe um Implementador, Revisor e Testador.

Acredito ser um diferencial e uma boa pratica.

Tchauzin!

Revisor de código, é só que faltava.
Gambiarras em blocos de código são facilmente refatoráveis, já a arquitetura do sistema não.

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.

m4rkk:

ViniGodoy:

Existe. Sempre existe um estagiário, um colega não tão cuidadoso ou um sistema legado com uma tecnologia inerentemente difícil (onde será difícil também montar o ambiente para recompilar a solução, pois ele é velho, seus componentes são difíceis de encontrar, etc). Quando se trabalha em equipe, é inevitável.

Agora, já trabalhei em equipes que o pessoal, no geral, era muito bom. Aí tinhamos no geral códigos usando muitos recursos da linguagem (o que poderia complicar para um iniciante), mas muito simples de manter, pois eram muito organizados.

Que história é essa? agora todo estágiario por não ter experiência é um mal programador? ele nao pode ter estudado o suficiente para entender e manter um código padrozinado ?

Suponho que você seja estagiário (eu sou) e digo que já vi péssimos códigos de profissionais. Com relação ao seu comentário acho difícil (não impossível) estagiário ter estudado o suficiente para entender e manter um código padrozinado, ele está num período de aprendizado, merece suporte da equipe (na minha opinião sim) mas não deve depender da mesma para fazer sua tarefa e aprender a correr atrás para se tornar um profissional melhor.
Flw

FrancoC:

lina:

Oi,

Uma maneira de diminuir (não acabar) com isso seria a utilização de técnicas/metodologia de desenvolvimento, como XP, Scrum etc…
A empresa onde trabalho utiliza a técnica XP - Extreming Programming. Existe um Implementador, Revisor e Testador.

Acredito ser um diferencial e uma boa pratica.

Tchauzin!

Revisor de código, é só que faltava.
Gambiarras em blocos de código são facilmente refatoráveis, já a arquitetura do sistema não.

Oi,

O que tem de errado revisar o código de outro? medo?

Tchauzin!

lina:

FrancoC:

lina:

Oi,

Uma maneira de diminuir (não acabar) com isso seria a utilização de técnicas/metodologia de desenvolvimento, como XP, Scrum etc…
A empresa onde trabalho utiliza a técnica XP - Extreming Programming. Existe um Implementador, Revisor e Testador.

Acredito ser um diferencial e uma boa pratica.

Tchauzin!

Revisor de código, é só que faltava.
Gambiarras em blocos de código são facilmente refatoráveis, já a arquitetura do sistema não.

Oi,

O que tem de errado revisar o código de outro? medo?

Tchauzin!

Concordo! Aqui na empresa se tivéssemos uma pessoa para fazer esse tipo de revisão, teríamos códigos muito mais fáceis e padronizados para dar manutenção. Sem falar que é possível achar alguns bugs.

Conheço uma empresa que o códigos passam pela seguinte bateria de testes:

:arrow: Teste de funcionalidade;

:arrow: Teste de white box;

Caso seja reprovado no segundo, o código volta para o programador para que ele reescreva de forma correta e padronizada.

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.

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.

2

Felagund:

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.

2

Suponho que seja algo que poucas pessoas querem.
Dificilmente uma empresa iria pagar um profissional que ela não necessite, tendo um retorno na facilidade de manutenção do código.

Flw.

Porque desenvolver software simples é difícil?

Se o cara é estagiário e escreve código mal-feito ainda tem uma desculpa, afinal ele está na empresa para aprender. Agora se o cara é pleno/sênior e faz essas coisas, pelo amor de deus…e ao contrário do que muitos pensam existem vários deles escrevendo código mal-feito por ai no mercado, sem respeitar padrões, boas práticas nem nada, eu mesmo ja conheci alguns…
E o perigo maior é que esses caras acabam ensinando essas coisas para os estagiarios que sem saber acabam aprendendo de maneira errada.

Oi,

Acho que não seria uma profissão “Revisar o código”. Uma pessoa mais experiente ou até mesmo o Gerente do Projeto (GP) revisa sempre no final do dia os Commit’s no CVS dos programadores.

Tchauzin!

lina:

Oi,

Acho que não seria uma profissão “Revisar o código”. Uma pessoa mais experiente ou até mesmo o Gerente do Projeto (GP) revisa sempre no final do dia os Commit’s no CVS dos programadores.

Tchauzin!

ainda bem que posso fazer meus commits, uso SVN e GIT auhauhuha.

Acho que principal ponto é que um estagiario começa mal, ele está aprendendo, mas se ninguem pega o braço dele e disser não faz isso, faz desse jeito. Ele vai se tornar um senior/pleno/ninja, qualquer outra porcaria, escrevendo codigo ruim.

Outro ponto importante é o interesse, se o estagiario não tem interesse em melhorar, hoje pode não ter, mas uma hora tem que querer melhorar, ai já era também, vai ser um profissional mediocre…

GradeBook:

lina:

Oi,

Acho que não seria uma profissão “Revisar o código”. Uma pessoa mais experiente ou até mesmo o Gerente do Projeto (GP) revisa sempre no final do dia os Commit’s no CVS dos programadores.

Tchauzin!

Slide 15 peer review Ninguém dá commit no CVS sem um ok de outra pessoa.

Oi,

Isso é indiferente na minha opinião.
O controle de CVS ajuda até a depurar o código anterior do atual, ou seja, você poderá ver e rever o novo código feito pelo programador. E ainda, não custa nada commitar novamente. (Claro que existem exceções)

Tchauzin!

Também já me fiz essa pergunta…

Porque nem todos possuem bom senso.

Caras a maioria das empresas tem códigos complicados e as explicações para isso são milhares.

Agora falando sobre a qualidade de código, uma coisa que me deixa p%$# e ver um tiozinho ou tiozão (pior ainda) escrever código de qualquer maneira. Normalmente os caras vem do Cobol, PHP, Delphi, VB e C achando que trabalhar com outra linguagem, principalmente sendo uma como Java, é a mesma coisa. Se for o seu caso, pare e faça uma boa reflexão.

Por exemplo: O post do nosso amigo que falava sobre i=1000000 para sair do loop. Coisa típica de quem trabalhava com C, Pascal…se não me falha a memória isto éra feito para não deixar os “registradores carregados” forçando a saida prematura do loop extrapolando o limite máximo pevisto nos ciclos. Fala sério, o maluco começou a “mexer” com Java e não sabe do que se trata a ferramenta que opera. Assim só vai sair m#$d@ mesmo.

Detalhe, tem molecada fazendo isso também; eles normalmente vem do html, javascript e php, quando pegam uma classe java só param de digitar quando dá caimbra nos dedos. É de doer só de olhar.

R: Porque quem pede não sabe exatamente o que quer e quem executa não quer saber exatamente o que foi solicidado. Fora o fato do ser humano gostar de complicar tudo, principalmente os falantes de português e similares. Pede pro bicho fazer uma redação pra tu ver o saladão que sai.

flws

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

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

Levando-se em conta que mais da metade do custo de um projeto esta em sua manutenção, acho que é bem óbvio a importância de um código bem escrito e manutenível.

Fica difícil demonstrar para um gerente / lider de projeto / diretor que NUNCA trabalhou com desenvolvimento de software. Principalmente se não estudou, pós-graduação na àrea não vale heim! Tá cheio de gerente que passou por várias àreas da empresa e subtamente fez uma pós só para entra na àrea de tecnologia. Este tipo de cara é politico, na cabeça dele é o seguinte: funcionou naquele momento pronto acabou. Se não for um profissional que fez uma carreira seria na àrea fica difícil um monte de coisas.

flws

eu anotei essa palavra linda

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.

exatamente o que eu queria dizer.

:shock: VIXE!!! :shock:

flws

O problema não são os programadores iniciantes, estes geralmente estão interessados em aprender e seguem o que um programador experiente passou.

O problema são os programadores intermediários - que se acham os bons - que reinventam a roda para utilzar certo recurso que acabaram de ver e mostrar o quanto são bons ao invés de utilzar códigos mais simples. :?

até mais

A verdade é que se o pessoal tivesse na cabeça o principio KISS (keep it simple stupid!) se ia pensar duas vezes antes de escrever qualquer coisa.

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.

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.

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.

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.

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.

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???

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

• sim, as empresas só se preocupam em resolver os seus problemas (funcionou tá resolvido)
• o departamento de marketing é muito mais importante para a maioria das empresas do que o depto de TI o qual só gera gastos (como se enxerga hoje)
• gerentes de sw só se preocupam com prazo e custos (também generalizando)
• é sim muito, mas muito difícil apresentar valor agregado para a empresa através do sw, talvez pq ele seja muitas vezes distante da realidade do cliente (vide o famoso desenho da cadeira de balanço)
• sim eu sou revoltado com isso tudo. :?

DarthVictor:

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.

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???

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.

rmendes08:

DarthVictor:

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.

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???

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.

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…

É 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

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.

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”.

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…