[Notes2-team] *como vamos funfar?*

[Anderson R. B. <and...@po...>]

Bom,

um tempo atr=E1s lancei uma pergunta na lista que era a seguinte:
*como vamos funcionar?*

Poucas respostas (uma?) apareceram na lista. Ent=E3o, acho que como=20
capit=E3o do barco
=E9 minha fun=E7=E3o propor algo. =C9 s=F3 uma proposta a ser=20
discutida-modificada-refeita-critica-etc.
Ent=E3o nada de votos (ainda). quero apenas vossas opini=F5es e id=E9ias.=
 Vamo l=E1:
-
Penso que no momento a equipe n=E3o aguentaria um per=EDodo de 2-3 meses =
em=20
que fossemos fazer o design de todo o c=F3digo e que os usu=E1rios est=E3=
o=20
esperando ver algo funcionado logo,logo. Al=E9m disso, n=E3o tenho certez=
a=20
se vale realmente a pena fazer um design de TODO o c=F3digo, j=E1 que por=
=20
mais que tentemos nos ater aos planos, iremos modific=E1-los por v=E1rios=
=20
motivos: por que novas (e melhores) id=E9ias podem surgir a qualquer=20
momento; por que novas pessoas entrar=E3o na equipe e v=E3o querer coisas=
=20
que n=E3o estavam planejadas inicialmente; por que algumas das coisas=20
planejadas podem ser mais dif=EDceis de serem feitas do que esper=E1vamos=
;=20
etc. Tamb=E9m n=E3o acho que temos uma equipe suficientemente grande para=
=20
quebrar o c=F3digo em m=F3dulos que cada grupo de programadores=20
implementaria em separado - tamb=E9m por que n=E3o =E9 vantajoso que as=20
pessoas s=F3 conhe=E7am uma parte do c=F3digo... Acho que o mais indicado=
=20
seria funcionarmos da maneira que um programador solit=E1rio funcionaria:=
=20
ele primeiro implementaria o componente de edi=E7=E3o de textos, verifica=
ria=20
se ele funciona perfeitamente, jogaria ele num form e faria o primeiro=20
release (um pr=E9-pr=E9-alpha). Claro que neste caso n=E3o ser=EDamos um=20
programador, mas ser=EDamos sim um s=F3 grupo. O design de cada m=F3dulo=20
importante do c=F3digo (por exemplo, o componente de edi=E7=E3o) seria fe=
ito=20
imediatamente antes de come=E7ar a desenvolv=EA-lo. Modifica=E7=F5es pode=
riam=20
ser feitas no design se id=E9ias melhores fossem surgindo durante o=20
desenvolvimento. Ou seja, a minha id=E9ia =E9 de fazermos os m=F3dulos em=
=20
s=E9rie (um depois do outro, escritos pelo grupo) e n=E3o em paralelo (to=
dos=20
ao mesmo tempo, cada um escrito por parte do grupo).

Cada m=F3dulo seria a implementa=E7=E3o de uma nova feature. Poderiam ser=
=20
m=F3dulos o componente de edi=E7=E3o; o gerenciador de temas (que altera =
cores=20
e =EDcones da interface); o suporte a extens=F5es; a constru=E7=E3o da GU=
I=20
atrav=E9s de arquivos de configura=E7=E3o (toolbars e menus criados atrav=
=E9s de=20
arquivos XML); etc. Cada vez que um m=F3dulo estiver "pronto" ele=20
adicionado ao Notes e =E9 lan=E7ado ao p=FAblico. Assim v=E1rios e v=E1ri=
os=20
pr=E9-alphas seriam lan=E7ados, permitindo tanto que os usu=E1rios=20
verificassem que estamos trabalhando, que eles reportassem os bugs que=20
fossem encontrando nos m=F3dulos j=E1 "acabados" e que fossem dando suas=20
sugest=F5s para melhorias durante o desenvolvimento. Quem acompanha o=20
desenvolvimento de softwares livres sabe que =E9 mais ou menos assim que=20
as coisas funcionam - os desenvolvedores v=E3o adicionando features e=20
fazendo releases. Nada de genial at=E9 aqui ent=E3o. Al=E9m disso, propon=
ho=20
que cada um desses m=F3dulos (que na realidade ser=E3o conjuntos de class=
es=20
e componentes) possa funcionar sem muito c=F3digo extra. Por exemplo, o=20
componente de edi=E7=E3o deve poder descobrir sozinho onde ficam os arqui=
vos=20
de configura=E7=E3o que ele precisa e carregar as suas informa=E7=F5es de=
 l=E1,=20
sem interven=E7=E3o de algum c=F3digo no form principal. Ou seja, os m=F3=
dulos=20
devem ser o mais independente poss=EDveis, devem funcionar sozinhos -=20
basta voc=EA criar um deles que o resto ele sabe fazer. Eu acho que o=20
quanto mais objeto orientado for o c=F3digo, mais f=E1cil ser=E1 mantermo=
s e=20
melhorarmos o Notes 2 no futuro.

Como seriam feitos os m=F3dulos? Eu sugeriria quebrarmos a constru=E7=E3o=
 dos=20
m=F3dulos em micro-tarefas que ficariam sob responsabilidade sempre de=20
apenas uma pessoa. Digamos que temos que limpar o SynEdit de todo o=20
c=F3digo dele que faz a colora=E7=E3o de syntaxe (realmente teremos que f=
azer=20
isto). Dividimos as Units (que s=E3o muitas) do SynEdit entre os=20
desenvolvedores e cada um teria que limpar as Units pelas quais ficou=20
respons=E1vel em 1 ou 2 semanas. Ou seja, rapidamente ter=EDamos todo o=20
SynEdit pronto para mexermos nele. E, no meio deste processo, todos=20
acabariam j=E1 tendo uma familiariza=E7=E3o com ele - o que j=E1 ajudar=E1=
 na=20
realiza=E7=E3o das pr=F3ximas tarefas! Assim, a cada 1,2 ou 3 semanas nos=
=20
encontrar=EDamos (chat, irc, icq, e-mail, etc.) e distribuir=EDamos as=20
micro-tarefas entre os programadores. O importante =E9 que todas as=20
micro-tarefas sejam curtas o suficiente para serem feitas pelo=20
programador respons=E1vel dentro do prazo. De quelaquer forma, seria=20
importante que no min=EDmo uma vez por semana o desenvolvedor atualizasse=
=20
o CVS com as mudan=E7as que ele fez e baixasse as modifica=E7=F5es feitas=
 por=20
outros (poder=EDamos combinar um dia da semana em que todos teriam que=20
atualizar o CVS, se n=E3o o tiverem feito ainda).

Cada programador deveria testar o seu c=F3digo e ter certeza de que ele=20
funciona conforme a tarefa exige - e conforme o nosso planejamento. Cada=20
c=F3digo deve ser testado para ver se funciona perfeitamente em todas as=20
situa=E7=F5es. Por exemplo, um m=E9todo que serve para passar o conte=FAd=
o de um=20
arquivo para uma string deve ser testado com v=E1rios arquivos, de todos=20
os tamanhos, bin=E1rios e de texto, com arquivos localizados na rede e at=
=E9=20
com arquivos que n=E3o existem. O programador teria liberdade aqui para=20
implementar o que lhe foi pedido do modo que achar melhor - afinal este=20
=E9 um software livre, temos que nos divertir um pouco ao desenvolvermos=20
ele, n=E9?! Cada programador teria completa autonomia para modificar=20
c=F3digos que outros fizeram para que o c=F3digo novo e o c=F3digo antigo=
 se=20
integrem perfeitamente. Todos os programadores teriam a responsabilidade=20
em tornar o c=F3digo do programa mais flex=EDvel e reus=E1vel, eliminar (=
ou=20
comentar) funcionalidades que n=E3o est=E3o sendo utilizadas e melhorar=20
designs obsoletos (obviamente a equipe dever=E1 ser consultada antes de=20
modifia=E7=F5es enormes). O desenvolvedor teria tamb=E9m a responsabilida=
de de=20
documentar cada tarefa que implementa (assim a documenta=E7=E3o do source=
 do=20
notes estar=E1 sempre atualizada e novatos na equipe poder=E3o se integra=
r=20
mais rapidamente) e de, ao t=E9rmino da tarefa, enviar para a lista um=20
micro-relat=F3rio sobre o que ele implementou e que testes fez para=20
verificar se o c=F3digo funciona como deveria. (Quem sabe possamos usar=20
componentes de testagens como o DUnit ou o QTeste para automatizar as=20
nossas testagens...) Estes micro-relat=F3rios dever=E3o ser arquivados, p=
ois=20
provavelmente ser=E3o extremamente =FAteis ao encotrarmos bugs :)

N=E3o sei se voc=EAs conseguem imaginar isto ocorrendo. Conseguem? Eu=20
consigo. A id=E9ia =E9 basicamente que todos sempre saibam de tudo o que=20
est=E1 ocorrendo; que cada um sempre saiba o que tem que fazer e qual =E9=
 o=20
prazo que deve observar; que existam coisas conclu=EDdas no programa (2=20
m=F3dulos prontos ao inv=E9s de todos os m=F3dulos rec=E9m iniciados) par=
a que=20
possam ir a p=FAblico - como deveria ser feito em qualquer software livre=
;=20
que as coisas sejam flex=EDveis o suficiente para podermos implementar as=
=20
id=E9ias que aparecem e jogar fora as que se mostrarem ruins; e que tudo=20
isto esteja documentando sempre, para facilitar a vida dos=20
rec=E9m-chegados e possibilitar que eles possam come=E7ar a contribuir=20
conosco o mais rapidamente poss=EDvel. =C9 um m=E9todo que mant=E9m todo =
mundo=20
sempre funcionando - sem precisar que eu fique chamando a aten=E7=E3o de=20
algu=E9m por n=E3o estar contibuindo (eu odeio ter que chamar a aten=E7=E3=
o de=20
qualquer um!). Al=E9m disso, a qualidade do software est=E1 sempre sendo=20
"medida" tanto atrav=E9s dos testes feitos por cada desenvolvedor quanto=20
pelos testes feitos pelos usu=E1rios nos pr=E9-releases.

*RESUMO:*

M=F3dulo 1
    -=3DDesign do M=F3dulo 1=3D-
    # Parte A
        > Desenvolvedor 1: micro-tarefa 1;
        > Desenvolvedor 2: micro-tarefa 2;
        > Desenvolvedor 3: micro-tarefa 3;
        > Desenvolvedor 4: micro-tarefa 4; etc.
    # Parte B
        > Desenvolvedor 1: micro-tarefa 5;
        > Desenvolvedor 2: micro-tarefa 6;
        > Desenvolvedor 3: micro-tarefa 7;
        > Desenvolvedor 4: micro-tarefa 8; etc.
    # Parte X, etc.
    ----------> Notes 2 Pr=E9-Alpha 1
M=F3dulo 2
    -=3DDesign do M=F3dulo 2=3D-
    # Parte A
        > Desenvolvedor 1: micro-tarefa 9;
        > Desenvolvedor 2: micro-tarefa 10;
        > Desenvolvedor 3: micro-tarefa 11;
        > Desenvolvedor 4: micro-tarefa 12; etc.
    # Parte X, etc.
    ----------> Notes 2 Pr=E9-Alpha 2
M=F3dulo 3
    -=3DDesign do M=F3dulo 3=3D-
    # Parte X, etc...

--
Ab.
Anderson