Discussão sobre como se situar no projeto

não vi po post do philip ainda, mas se houve tempo verei os 2. Na verdade acredito que o certo mesmo, é haver algumas palestras mesmo q relâmpago para situar o cara no projeto. Trabalho para uma grande seguradora, com módulos de aceitação de seguro e risco e em ramos como esse, pouco adianta o cara querer saber alguma coisa sem conhecer ao menos um pouco do negócio…

Sempre temos que conhecer o negócio.
Um sistema só faz sentido se estiver alinhado com o negócio da empresa.
Acho mais prático olhar os código, diagramas ajudam, mas desde que estejam atualizados, ou seja, dificilmente.

Bom, passou pela minha cabeça que as respostas fornecessem uma maneira de medir o grau de difusão da prática de Domain-Driven Design e Test-Driven Development entre os desenvolvedores que freqüentam o GUJ. Penso isso porque, se o sistema foi modelado segundo princípios de DDD, há de fato uma parte do código separada do resto do sistema que expressa o modelo do domínio ( e testes unitários associados correspondentes através dos quais é possível entender as funcionalidades do software ). Dessa forma, olhar para o código é entender o sistema. Mas se a maioria das pessoas achar mais confortável verificar os diagramas UML, poderia ser um sintoma de que as responsabilidades de negócio não estão bem separadas.

O que acham?

Primeiro eu deveria saber o que o sistema se propõe a fazer pelos integrantes do meu time.
Depois tentaria descobrir qual a visão do cliente sobre o sistema: como vai utiliza-lo, quais as necessidades, vocabulario, o que virá pela frente, etc.

(Garanto que alguma diferença eu vou notar nessas 2 conversas…)

Antes de ver o código preciso saber quais linguagens, frameworks e a arquitetura adotada, assim como preciso saber o que existe de testes, documentação, etc.

Tendo essas ideias, posso me aventurar no código SE o mesmo tiver sido projetado para ser legível e facil de manter, caso contrario preciso me dedicar a trazer essas características ao codigo sob pena de sofrer muito e perder o interesse no projeto em decorrencia desse sofrimento.

E se a engenharia civil começasse a seguir os passos da engenharia de software ?

http://www.aia.org/nwsltr_db.cfm?pagename=db_a_20070222_sports

1. Programação em Pares. Se o time não era composto de apenas 1 desenvolvedor eu começaria tentando trabalhando com alguém que conheça o código. Posso até bater um papo com os analistas para entender o negócio, mas só vou poder colaborar depois que me situar com o código.

2. Testes. Quando não desse pra programar em par eu leria os testes para entender como o sistema funciona. Se eles foram bem escritos dá pra ter uma boa idéia de como são as funcionalidades (testes de aceitação/integração) e como elas foram implementadas (testes de unidade). Se eles não forem já sei um bom lugar onde posso colaborar

3. Se não desse para fazer programação em par e o sistema não tivesse testes, eu consideraria seriamente pedir as contas. Se no começo foi assim já dá pra imaginar como vai ser o trabalho dali alguns meses…