Felizmente, os projetos onde eu tenho trabalhado atualmente não são problematicos como os ambientes que eu descrevi 
Eu já li bastante sobre isso, mas não ainda não saquei o seu ponto.
Então isso necessariamente é algo ruim?
Se eles usam waterfall-like, qualquer pessoa que sabe desenvolver software de verdade e já experimentou os benefícios do desenvolvimento iterativo se torna mestre para falar que eles não sabem desenvolver software. O fato do ambiente ser grande, maduro e estável não necessáriamente diz que é EFICIENTE (e geralmente não é).
Mas OK, eu tenho uma postura radical com relação a isso, e tenho pouca paciência com gestores burros que se acham os gostosões, desculpem qualquer exagero. Pode não ser muito bom para meu bolso, mas já dropei projetos por conta disso. Não é uma decisão emocional, é só um risco que não dava para aceitar (qualquer jogador de Poker ou home-broker sabe do que estou falando).
[quote=microfilo][quote=rodrigoy]
Se isso não é CMMI-like, o que é?
[/quote]
Então isso necessariamente é algo ruim?[/quote]
É bonito na teoria, mas na prática é um inferno. Especificações executáveis são a únicas que é viável verificar contra o software. O problema de ter toneladas de documentação é quando um requisito escapa de ser realizado na documentação (nenhuma equipe é perfeita). Com testes automatizados e um mínimo qualidade no processo esse tipo de coisa não resiste a primeira execução integrada do build. No caso de documentação no word nada garante isso.
Achar que softwares de rastreabilidade resolvem isso é sales pitch ou ingenuidade pois elas exigem toneladas de trabalho manual para serem usadas e no final até as equipes mais disciplinadas acabam fazendo vista grossa para grande parte do que acontece.
[quote=microfilo][quote=CMMi 1.2]
SP 1.4 Maintain Bidirectional Traceability of Requirements
Maintain bidirectional traceability among the requirements and work products.
The intent of this specific practice is to maintain the bidirectional traceability of requirements for each level of product decomposition. (See the definition of ?bidirectional traceability? in the glossary.) When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source.
[/quote]
Então isso necessariamente é algo ruim?[/quote]
Ruim? Se você ver, as idéias do CMMi não são todas ruins, a maneira como o mercado interpreta é que é um cancer. De qualquer forma:
-
A preocupação por uma matriz de rastreabilidade “cheira (ou fede) waterfall”: Dá a entender que o requisito levará meses para ser implementado. A preocupação com “será que atendemos o requisito?” demonstra também que o usuário demorará meses para ver a aplicação.
-
Essa visão é antiquada: Como falei, temos várias alternativas de demonstrar os requisitos de modo executável. Assim, o “source requirement” é o mesmo que o “lower level requirements”. Pode ter certeza que uma consultoria CMMi não vai aceitar um @Valid do hibernate validator como “source” de requisitos. Vc compreende? Se você usar os benefícios da tecnologia você não precisa de rastreabilidade bidirecional. E se você não tem essa rastreabilidade, segundo o SEI, seu processo não é maduro! Não soa estranho?
-
Matriz de rastreabilidade “cheira escopo-fechado”: É uma presunção forte que os “source requirements” são verdade lavrada em cartório. Requisitos são incertos até o sorriso do usuário aparecer. Esse “completely addressed” dá a entender que os requisitos não vão mudar.
-
Teoria da Conspiração: Passei por 2 implantações de CMMi e meu sentimento foi que era meio impossível um mortal manter uma matriz de rastreabilidade na mão. Talvez uma matriz de Sudoku 100X100 seja mais fácil. No fim, vinha aqueles vendedores de fabulosas ferramentas que “faziam isso sozinho pra você” por alguns milhares de dólares. Será que é por isso que eles pedem essa matriz?
[editado só correções ortográficas confusas]
Olá s4nchez,
como assim engolir? Na realidade não vejo muita opção. Pelo menos tenho visto mais clientes que acham que sabem mais que o a equipe de desenvolvimento do que desenvolvedores agilistas. O único lugar que vejo desenvolvedor agilista é em fórum de discussão, reuniões e eventos. Fora isso, conto nos dedos da mão direita os programadores que conheci pessoalmente que ao menos usassem TDD.
Enfim, qual é a dica para se dar ao luxo de não engolir as situações citadas pelo Rubem? :mrgreen: [/quote]
A questão é que muitas vezes os dois lados que fecham um contrato de software não sabem tanto assim sobre software, justamente porque estão mais preocupados com decisões comerciais. Neste caso cabe ao responsável interno tentar fazer valer as opiniões de quem é responsável pelo desenvolvimento em si. Pra isso é que serve ter poucos desenvolvedores ótimos do que uma cacetada de desenvolvedores medíocres, como normalmente acontece. Se a cultura de desenvolvimento da empresa não for ditada por desenvolvedores, vai ser ditada por quem?
Lógico que dá para flexibilizar algumas coisas, mas esta história de “fazemos qualquer negócio” é que mata muitas software houses hoje em dia: a cultura de desenvolvimento é ditada pelos clientes, e cada novo cliente é uma nova dor de cabeça. De que adianta fechar centenas de contratos se vai acabar como as empresas de três letrinhas?
Qual o problema de dizer que o cliente esta errado?
Mesmo que tu esteja como outsourcing dentro do cliente, dar sugestões nunca tirou os dedos de ninguem. Agora se esta como consultoria, ver um fato errado e se omitir é pedir pra mais cedo ou mais tarde ser xingado pelo cliente. Já vi isso com os proprios olhos…uma consultoria X que sabia que tava errada mas não quiz falar pro cliente, o cliente contratou a consultoria Y que avisou ele do problema…advinha o que aconteceu com a consultoria X?
Um sonoro SIM. Estamos até levando para nossos clientes muitas das práticas.
[quote=cv]
Otimos. O design das aplicacoes eh assustadoramente melhor, e todo tipo de metrica que a gente ja passou nos projetos eh melhor de maneiras significativas (e a TW lancou um whitepaper sobre essas metricas que eu nao estou conseguindo achar agora por estar razoavelmente bebado/cansado/sem saco).[/quote][/quote]
Concordo 100%.
Cv ja curou a ressaca pra passar o paper?
]['s
Pessoal,
Então recapitulando, pode se dizer que o programador que não faz testes unitários não é profissional?
Já perseveram quanto tempo vc deixou de usar em diagnostico de falhas e debugging desde que começou a usar TDD?
Abraços,
Juan.
Juan,
Essa afirmação é bem forte. Eu li isso uma vez no blog do Phillip. Eu, apesar de ser totalmente adepto não usaria uma frase como esta, pois a maioria dos que estão aqui no forum defendendo o uso de testes (inclusive eu), já programou por muito tempo sem o uso destes, e nem por isso não eramos profissionais. O ponto importante, que é o que eu acho que ele quiz dizer é que a abordagem de testes automatizados tem sido martelada faz tempo e o pessoal nem se interessa pelo assunto. Ao menos se as pessoas tentassem ver como que funciona, os ganhos, etc. Essas pessoas preferem simplesmente ignorar as coisas e usar argumentos totalmente evasivos contra a prática de testes automatizados.
Espero que essa mentalidade mude.
Essa discussão é realmente inútil, como muitos testes unitários por aí que não testam nada e são feitos por estagiários de saco cheio como o Leonardo falou!
Cara, primeiro defina PROFISSIONAL. O que é um PROFISSIONAL? Escolha abaixo:
-
É um cara que tem um emprego e ganha para programar?
-
É um cara que ganha bastante para programar, acima da média do mercado?
-
É um cara foda (ou que se acha foda) como algumas figurinhas marcadas desse forum?
-
É um cara que tem um cargo sênior de programação?
-
É um cara que tem uma carreira longa e comprovadamente de sucesso?
Falar que um programador que entrega uma linha de código sem testes UNITÁRIOS é irresponsável, é o mesmo que falar que o cara que faz um programa no notepad é irresponsável.
Agora se algumas pessoas acham que TDD, JUnit e essas coisas agilizam a implementação de um projeto então sejam felizes! So be it! Mas isso não tem nada haver com qualidade…
Só para lembrar o pessoal: existem outras formas de testar além do teste unitário, ok? Pensem nisso só um pouquinho…
Duvido muito, especialmente porque testes unitários não garatem que o sistema funciona, apenas as unidades. Existem muitos casos aonde testes unitários não valem o esforço (como em sistemas embarcados ou próximos demais ao hardware), aonde estes funtionais e de integração são muito mais eficientes e baratos.
Testes unitários tem uma importância ímpar na hora de ajudar você a definir o design dos seus objetos, mas eles não são a única solução pra testar nem garantir a qualidade de um software.
Sem falar que essa obcessão por testes unitários está levando a Herança para a fogueira da inquisição.
Herança tem sim o seu uso, é importante pra baralho e não é porque no passado você fez um extends Properties (eu também já fiz) é que você vai correr de herança como o diabo corre da cruz.
Um sistema grande e de alto nível sem herança é totalmente inviável. Se você não acredita é porque você nunca fez um sistema/framework realmente sério.
E viva o mengão!
Poderia citar alguns exemplos mais confiáveis que se encaixam em todas as fases de desenvolvimento ?
Obrigado!
Não estamos falando exclusivamente de testes unitários, ninguém defende isso. Mas um programador que não usa de testes automatizados é um irresponsável fanfarrão. É impossível construir um sistema extremamente complexo no prazo e com qualidade sem usar testes automatizados - desafio qualquer um a me mostrar um caso que prove o contrário disso. Não estou falando de sistemas grandes, mas sim de sistemas complexos.
Um micreiro que diz ser possível construir tal sistema sem automação de testes não merece ser chamado de desenvolvedor, muito menos profissional.
Não consigo entender por que raios precisa de mais argumentos que a porcaria da realidade para mostrar que testes automatizados são extremamente saudáveis a qualquer projeto. Ou você automatiza, ou você corre atrás do próprio rabo o tempo todo.
Bom, se é para dar opiniões, a minha é totalmente o contrário. Hoje em dia só uso herança quando sou obrigado (a ferramenta que eu estou usando me obriga).
Mas isso é outra discussão…
Eu acho o JForum bastante complexo e até onde eu sei ele nunca teve testes automatizados. Agora na versão 3.0 que parece que ele terá testes automatizados…
Ach que eu já descobri o que é um programador PROFISSIONAL: resposta 3)
!!! Get Real !!!
Olá
Programador profissional é aquele que faz programa para viver. Os que fazem programas ou frameworks para aprender ou para ter seu próprio modo de fazer as coisas, são diletantes.
[]s
Luca
A vida seria muito chata se isso fosse verdade. E o pior é que muitas vezes o pessoal do segundo grupo acaba ganhando mais e conseguindo mais sucesso e realização do que o pessoal do primeiro grupo. Mas não são profissionais, porque um programador profissional é …
Pois é testes unitarios sem fazer TDD, e feitos por estagiarios de saco cheio, pareceria ser unicamente um desperdiço, não são esses testes unitarios que eu pelo menos me refiro.
Agora testes unitarios no contexto do TDD fazem toda a diferença. Eu por exemplo trabalhei em projetos de software embarcados, repetidoras microondas, centrais telefônicas para suporte de serviços de chamadas massivas com cargas ultra altas, e um monte de produtos que se você não tivesse feito TDD o prejuiço seria gigantesco.
Tem que entender que Teste Unitario como estamos falando aqui de TDD na verdade nada tem a ver com testes e sim com design, nos ajudam a formalizar qual é o objetivo, eles te ajudam a pensar no teu design e te ajudam a que você possa evoluir teu design fazendo refactoring sem medo de quebrar alguma coisa, e sair da ideia de equipe que esta ganhando não se mexe, e passar para em todo momento eu mexo no codigo porque posso melhorar ele continuamente porque tenho uma rede de segurança para me indicar o que quebrei.
Nenhuma das opções acima, talvez profissional seja alguem que tem vergonha de ver quanto seus bugs atrapalham a vida de muita gente, alguem que tem orgulho daquilo que produz, alguem que esta a procura constante de excelência.
Digamos que um cirurgião que não tem um processo para contar a quantidade de gases que são usadas no paciente para quando fechar ele eles possam ter um “assert” dando a conta original, não é um teste que agrega valor depois de fechado, agrega valor durante o “procedimento”, assim como testes unitários nos permitem sair da implementação de uma feature com certeza de que estamos fazendo aquilo que imaginamos que faríamos no inicio.
O cirurgião que corre esse risco sabendo que o ideal é contar as gases, ele é mais profissional ou menos profissional daquele que toma o cuidado de conta-las?
Abraços,
Juan