Para mim, débito técnico não é abrir mão da qualidade do código ou da
estrutura. Débito técnico é algo que com certeza soa como não ideal, mas
não compromete a entrega e, portanto, pode ser revisto mais tarde.
Meus débitos técnicos são questões de modelagem, algo que poderia estar em
outro lugar mas que, no momento, não está claro pra mim onde deveria estar.
Por exemplo, posso abstrair caching usando uma abordagem AOP... mas o
output cache do asp.net faz o trabalho bem feito (numa situação
hipotética). Isso não torna o código feio, ilegível. Isso não compromete a
qualidade da entrega. Mas a dívida existe.
Quanto aos meus critérios serem inegociáveis, se eu abrir mão de critérios
de qualidade para atender à expectativa do stakeholder, já estou deixando
de atender a expectativa dele, já que parte do que pra mim faz parte do
compromisso da entrega está deixando de ser entregue. Mais importante
ainda: Para o próprio Stakeholder, na grande maioria das vezes, se ele for
bem contextualizado, sempre por dentro do andamento das coisas, o prazo
quase sempre é menos importante do que a qualidade da entrega.
É como falar de credores e devedores. Tudo o que o credor quer é receber.
Ele coloca prazos, estipula juros, pressiona o devedor... mas no fundo, ele
só quer receber. Por isso que, normalmente, quando o devedor está disposto
a negociar, o credor também está. Para ele, o importante não é que o
devedor pague no prazo, mas que ele pague.
Assim é a expectativa dos stakeholders (lá vem os encrenqueiros insinuarem
que estou dizendo que você pode enrolar o cliente pelo tempo que
precisar...). É claro que quanto antes você entregar, melhor pra ele, pois
ele vai tirar o benefício estratégico desejado mais cedo. Mas o que eu
estou tentando dizer é que não adianta nada entregar no prazo e causar só
dor de cabeça pro cliente depois com uma série de lacks.
No melhor cenário, você deveria conseguir os dois... o que seria uma
entrega for the win... Mas o que está sendo entregue com certeza conta
muito mais do que "quando" será entregue, quando um dos dois precisa ser
posto de lado... não adianta entregar a sopa, sem a colher em tempo hábil.
> Concordo que a equipe de desenvolvimento tem de entregar qualidade... No
> entanto, creio que devamos estar alinhados com a estratégia da empresa, a
> para isso podemos considerar criarmos um débito técnico para entregar o
> projeto na data estimada.
> E quando você fala que seus critérios de qualidade são inegociáveis, você
> está esquecendo que entregar valor é atender a expectativa do stakeholder
> (não confundam com defesa ao pmbok), e embora qualidade seja sempre uma
> delas, não podemos deixar de analisar os outros quesitos do projeto.
> Abs.,
> João Bateloche
> Em 21 de junho de 2012 19:11, Daniel Moreira Yokoyama <
> moreira.yokoy...@gmail.com> escreveu:
> Eu vivo no mundo corporativo e não abro mão de um bom trabalho. O prazo
>> que eu tenho é o prazo que eu dei. Se houver razões para atrasar devido a
>> algo inesperado, vai atrasar. Se isso for algum problema, não é problema
>> meu. Meu trabalho é entregar com qualidade o que me compete entregar. Os
>> meus critérios de qualidade são inegociáveis. Se tiver problema com isso,
>> me diga e eu saio sem problemas. Do contrário, é o meu trabalho garantir a
>> entrega. Me deixe fazer o trabalho que me pagam pois que seja feito.
>> Em 21/06/2012 17:12, "Thiago C. Santos" <thiago.csantos...@gmail.com>
>> escreveu:
>>> Quem vive no mundo corporativo sabe que existem aqueles momentos que
>>> algo "feio" necessita ser feito, isso por que no mundo corporativo existem
>>> custos, prazos e não somente o código que agente quer que fique animal.
>>> Att,
>>> Thiago C. Santos
>>> 2012/6/20 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>>>> osse seu último dia de vida, você faria o que está prestes a fazer?
>>>> Você está feliz fazendo isso?
>>> --
>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>> hospedado no Google Groups.
>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>>> Para sair do grupo envie uma mensagem para
>>> dotnetarchitects+unsubscribe@googlegroups.com
>>> Para mais opções visite o grupo em
>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>> --
>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>> hospedado no Google Groups.
>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>> Para sair do grupo envie uma mensagem para
>> dotnetarchitects+unsubscribe@googlegroups.com
>> Para mais opções visite o grupo em
>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitects+unsubscribe@googlegroups.com
> Para mais opções visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br
Trabalho em uma instituição financeira, setor que é altamente regulamentado
e com demandas legais surgindo a todo momento, e um time to marketing
agressivo já que nossos produtos são altamente customizados para atender a
demanda dos clientes.
Vejoa todo momento esse pensamento que atender ao cliente é entregar de
qualquer jeito sem a qualidade citada pelo Daniel, e sabe o que no fim das
contas acontece?
a) O cliente não é atendido porque recebe um produto de baixa qualidade
que demanda uma certa quantidade de “manobras de contorno” devido aos erros
que apresenta;
b) É quase que impossível se darestimativas e se cumprir os prazos das
manutenções já que junto com o que está sendo solicitado há coisasque são
detectadas em tempo de execução por culpa do péssimo código gerado na
demanda anterior;
Isto quer dizer que, com ou sem qualidade, o prazo nunca será cumprido.
A diferença é que se o código tivesse qualidade esse tempo se pagaria nas
próximas demandas.
Grato,
Alexandre
De: dotnetarchitects@googlegroups.com
[mailto:dotnetarchitects@googlegroups.com] Em nome de João Bateloche
Enviada em: quinta-feira, 21 de junho de 2012 22:08
Para: dotnetarchitects@googlegroups.com
Assunto: Re: [dotnetarchitects] Re: Como parei de escrever códigos
incríveis!
Daniel,
Concordo que a equipe de desenvolvimento tem de entregar qualidade... No
entanto, creio que devamos estar alinhados com a estratégia da empresa, a
para isso podemos considerar criarmos um débito técnico para entregar o
projeto na data estimada.
E quando você fala que seus critérios de qualidade são inegociáveis, você
está esquecendo que entregar valor é atender a expectativa do stakeholder
(não confundam com defesa ao pmbok), e embora qualidade seja sempre uma
delas, não podemos deixar de analisar os outros quesitos do projeto.
Abs.,
João Bateloche
Em 21 de junho de 2012 19:11, Daniel Moreira Yokoyama
<moreira.yokoy...@gmail.com> escreveu:
Eu vivo no mundo corporativo e não abro mão de um bom trabalho. O prazo que
eu tenho é o prazo que eu dei. Se houver razões para atrasar devido a algo
inesperado, vai atrasar. Se isso for algum problema, não é problema meu. Meu
trabalho é entregar com qualidade o que me compete entregar. Os meus
critérios de qualidade são inegociáveis. Se tiver problema com isso, me diga
e eu saio sem problemas. Do contrário, é o meu trabalho garantir a entrega.
Me deixe fazer o trabalho que me pagam pois que seja feito.
Em 21/06/2012 17:12, "Thiago C. Santos" <thiago.csantos...@gmail.com>
escreveu:
Quem vive no mundo corporativo sabe que existem aqueles momentos que algo
"feio" necessita ser feito, isso por que no mundo corporativo existem
custos, prazos e não somente o código que agente quer que fique animal.
Att,
Thiago C. Santos
2012/6/20 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
osse seu último dia de vida, você faria o que está prestes a fazer? Você
está feliz fazendo isso?
-- Você recebeu esta mensagem porque faz parte do grupo .Net Architects
hospedado no Google Groups.
Para postar envie uma mensagem para dotnetarchitects@googlegroups.com Para sair do grupo envie uma mensagem para
dotnetarchitects+unsubscribe@googlegroups.com
<mailto:dotnetarchitects%2Bunsubscribe@googlegroups.com> Para mais opções visite o grupo em
http://groups.google.com/group/dotnetarchitects?hl=pt-br
-- Você recebeu esta mensagem porque faz parte do grupo .Net Architects
hospedado no Google Groups.
Para postar envie uma mensagem para dotnetarchitects@googlegroups.com Para sair do grupo envie uma mensagem para
dotnetarchitects+unsubscribe@googlegroups.com
<mailto:dotnetarchitects%2Bunsubscribe@googlegroups.com> Para mais opções visite o grupo em
http://groups.google.com/group/dotnetarchitects?hl=pt-br
-- Você recebeu esta mensagem porque faz parte do grupo .Net Architects
hospedado no Google Groups.
Para postar envie uma mensagem para dotnetarchitects@googlegroups.com Para sair do grupo envie uma mensagem para
dotnetarchitects+unsubscribe@googlegroups.com
Para mais opções visite o grupo em
http://groups.google.com/group/dotnetarchitects?hl=pt-br
Além do que, da mesma forma que o devedor e credor que você citou, se você
entregar antes, e com qualidade, quem ganha também é você que poderá
iniciar um novo pojeto com um cliente que ficou muito satisfeito com o seu
trabalho.
Concordo plenamente que quando as coisas ficam claras, como diz um certo
politico, fica bom para ambas as partes.
Atenciosamente,
Alexandre
De: dotnetarchitects@googlegroups.com
[mailto:dotnetarchitects@googlegroups.com] Em nome de Daniel Moreira
Yokoyama
Enviada em: quinta-feira, 21 de junho de 2012 22:27
Para: dotnetarchitects@googlegroups.com
Assunto: Re: [dotnetarchitects] Re: Como parei de escrever códigos
incríveis!
João,
Para mim, débito técnico não é abrir mão da qualidade do código ou da
estrutura. Débito técnico é algo que com certeza soa como não ideal, mas não
compromete a entrega e, portanto, pode ser revisto mais tarde.
Meus débitos técnicos são questões de modelagem, algo que poderia estar em
outro lugar mas que, no momento, não está claro pra mim onde deveria estar.
Por exemplo, posso abstrair caching usando uma abordagem AOP... mas o output
cache do asp.net faz o trabalho bem feito (numa situação hipotética). Isso
não torna o código feio, ilegível. Isso não compromete a qualidade da
entrega. Mas a dívida existe.
Quanto aos meus critérios serem inegociáveis, se eu abrir mão de critérios
de qualidade para atender à expectativa do stakeholder, já estou deixando de
atender a expectativa dele, já que parte do que pra mim faz parte do
compromisso da entrega está deixando de ser entregue. Mais importante ainda:
Para o próprio Stakeholder, na grande maioria das vezes, se ele for bem
contextualizado, sempre por dentro do andamento das coisas, o prazo quase
sempre é menos importante do que a qualidade da entrega.
É como falar de credores e devedores. Tudo o que o credor quer é receber.
Ele coloca prazos, estipula juros, pressiona o devedor... mas no fundo, ele
só quer receber. Por isso que, normalmente, quando o devedor está disposto a
negociar, o credor também está. Para ele, o importante não é que o devedor
pague no prazo, mas que ele pague.
Assim é a expectativa dos stakeholders (lá vem os encrenqueiros insinuarem
que estou dizendo que você pode enrolar o cliente pelo tempo que
precisar...). É claro que quanto antes você entregar, melhor pra ele, pois
ele vai tirar o benefício estratégico desejado mais cedo. Mas o que eu estou
tentando dizer é que não adianta nada entregar no prazo e causar só dor de
cabeça pro cliente depois com uma série de lacks.
No melhor cenário, você deveria conseguir os dois... o que seria uma entrega
for the win... Mas o que está sendo entregue com certeza conta muito mais do
que "quando" será entregue, quando um dos dois precisa ser posto de lado...
não adianta entregar a sopa, sem a colher em tempo hábil.
Em 21 de junho de 2012 22:07, João Bateloche <jbatelo...@gmail.com>
escreveu:
Daniel,
Concordo que a equipe de desenvolvimento tem de entregar qualidade... No
entanto, creio que devamos estar alinhados com a estratégia da empresa, a
para isso podemos considerar criarmos um débito técnico para entregar o
projeto na data estimada.
E quando você fala que seus critérios de qualidade são inegociáveis, você
está esquecendo que entregar valor é atender a expectativa do stakeholder
(não confundam com defesa ao pmbok), e embora qualidade seja sempre uma
delas, não podemos deixar de analisar os outros quesitos do projeto.
Abs.,
João Bateloche
Em 21 de junho de 2012 19:11, Daniel Moreira Yokoyama
<moreira.yokoy...@gmail.com> escreveu:
Eu vivo no mundo corporativo e não abro mão de um bom trabalho. O prazo que
eu tenho é o prazo que eu dei. Se houver razões para atrasar devido a algo
inesperado, vai atrasar. Se isso for algum problema, não é problema meu. Meu
trabalho é entregar com qualidade o que me compete entregar. Os meus
critérios de qualidade são inegociáveis. Se tiver problema com isso, me diga
e eu saio sem problemas. Do contrário, é o meu trabalho garantir a entrega.
Me deixe fazer o trabalho que me pagam pois que seja feito.
Em 21/06/2012 17:12, "Thiago C. Santos" <thiago.csantos...@gmail.com>
escreveu:
Quem vive no mundo corporativo sabe que existem aqueles momentos que algo
"feio" necessita ser feito, isso por que no mundo corporativo existem
custos, prazos e não somente o código que agente quer que fique animal.
Att,
Thiago C. Santos
2012/6/20 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
osse seu último dia de vida, você faria o que está prestes a fazer? Você
está feliz fazendo isso?
-- Você recebeu esta mensagem porque faz parte do grupo .Net Architects
hospedado no Google Groups.
Para postar envie uma mensagem para dotnetarchitects@googlegroups.com Para sair do grupo envie uma mensagem para
dotnetarchitects+unsubscribe@googlegroups.com
<mailto:dotnetarchitects%2Bunsubscribe@googlegroups.com> Para mais opções visite o grupo em
http://groups.google.com/group/dotnetarchitects?hl=pt-br
-- Você recebeu esta mensagem porque faz parte do grupo .Net Architects
hospedado no Google Groups.
Para postar envie uma mensagem para dotnetarchitects@googlegroups.com Para sair do grupo envie uma mensagem para
dotnetarchitects+unsubscribe@googlegroups.com
<mailto:dotnetarchitects%2Bunsubscribe@googlegroups.com> Para mais opções visite o grupo em
http://groups.google.com/group/dotnetarchitects?hl=pt-br
-- Você recebeu esta mensagem porque faz parte do grupo .Net Architects
hospedado no Google Groups.
Para postar envie uma mensagem para dotnetarchitects@googlegroups.com Para sair do grupo envie uma mensagem para
dotnetarchitects+unsubscribe@googlegroups.com
<mailto:dotnetarchitects%2Bunsubscribe@googlegroups.com> Para mais opções visite o grupo em
http://groups.google.com/group/dotnetarchitects?hl=pt-br
-- Você recebeu esta mensagem porque faz parte do grupo .Net Architects
hospedado no Google Groups.
Para postar envie uma mensagem para dotnetarchitects@googlegroups.com Para sair do grupo envie uma mensagem para
dotnetarchitects+unsubscribe@googlegroups.com
Para mais opções visite o grupo em
http://groups.google.com/group/dotnetarchitects?hl=pt-br
0) Software sem bugs.
1) Código com baixa barreira de entrada para novos desenvolvedores, isto é,
código legível que siga os padrões mais conhecidos de mercado.
2) Código com facilidade de manter e evoluir.
...
200) Beleza estética do código (nomes, organização, etc...)
> Galera, o que é "qualidade" pra vocês? Eu acho que é possível fazer código
> muito bem feito sem qualidade (leia-se: código bonito), e eu acho que é o
> que mais acontece nos melhores produtos. Parece vivermos uma época
> parnasiana da programação, do código pelo código e da estética e eu não sei
> bem se concordo com isso.
> Em 21 de junho de 2012 21:40, Robson Castilho <robsoncasti...@yahoo.com.br
> > escreveu:
> Daniel:
>> Mais uma vez corretíssimo. Eu fico 100x mais incomodado com a
>> qualidade da entrega do que com prazo (isto não quer dizer que eu
>> despreze o último)...
>> Gerson:
>> Nem todas. Aqui a empresa se preocupa com qualidade sim, porque eles
>> sabem que estão perdendo e já perderam muito dinheiro com manutenção
>> de software porco...Temos que ir mostrando que dói no bolso, que
>> vários devs poderiam estar liberados para projetos e funcionalidades
>> novas (mais $$$) ao invés de ficarem a maior parte do tempo apagando
>> incêndio...
>> E para todos:
>> Vejo muitos devs argumentando muito em cima de prazo, prazo, prazo e
>> pouco em favor de qualidade, qualidade, qualidade...
>> Onde fica a qualidade no meio disso tudo?
>> De onde vem esse bicho chamado prazo? Quem o definiu? Por que? Com
>> qual propósito? De onde tiraram aquela data? Essas respostas tem que
>> estar claras (não vale resposta de um gerente dizendo que quer o bônus
>> dele até aquela data pra ele trocar de carro). Havendo uma real
>> necessidade de se entregar naquela data, os devs vão poder elaborar
>> melhor uma solução, quem sabe mexer no escopo para entregar naquela
>> data mantendo qualidade. Transparência ajuda bastante nesses casos...
>> []s a todos.
>> On Jun 21, 6:36 pm, Daniel Moreira Yokoyama
>> <moreira.yokoy...@gmail.com> wrote:
>> > Só para que conste, quando eu digo que não é problema meu se houver
>> algum
>> > problema com atrasos, eu não quero dizer que sou inflexível com o
>> cliente,
>> > o que eu quero dizer é que as pessoas que se incomodam mais com o
>> > cumprimento do prazo do que com a qualidade da entrega não vai ver esta
>> > postura em mim.
>> > Uma coisa é ser lean para dar ao cliente uma vantagem estratégica no que
>> > diz respeito a time to market... outra coisa é cumprir o prazo
>> colocando em
>> > risco o verdadeiro valor da entrega, que diz respeito inclusive no
>> custo da
>> > manutenção que o cliente vai ter no futuro.
>> > Para garantir o melhor disso, eu não abro a mão de testes automatizados,
>> > que são a melhor maneira de medir no futuro o que foi ou não afetado por
>> > manutenções futuras. Isto é critério meu, do qual eu não abro mão, a
>> menos
>> > que seja algo pontual, para ser usado uma única vez e nunca mais.
>> > Para garantir que estes testes realmente garantam o funcionamento do que
>> > estou implementando, eu uso TDD, ou seja, não faço uma linha de código
>> sem
>> > que haja um teste para aquilo antes. E preciso ver o teste quebrar pra
>> ter
>> > certeza de que ele faz o que eu espero que faça: valide a funcionalidade
>> > que nem sequer foi implementada ainda.
>> > São só meros exemplos, mas são critérios meus. Ninguém precisa cobrar
>> isso
>> > de mim, mas ninguém jamais vai me impedir de entregar as coisas desta
>> > forma. São meus valores, que definem aquilo que me compete entregar.
>> > Em 21 de junho de 2012 19:11, Daniel Moreira Yokoyama <
>> > moreira.yokoy...@gmail.com> escreveu:
>> > > Eu vivo no mundo corporativo e não abro mão de um bom trabalho. O
>> prazo
>> > > que eu tenho é o prazo que eu dei. Se houver razões para atrasar
>> devido a
>> > > algo inesperado, vai atrasar. Se isso for algum problema, não é
>> problema
>> > > meu. Meu trabalho é entregar com qualidade o que me compete entregar.
>> Os
>> > > meus critérios de qualidade são inegociáveis. Se tiver problema com
>> isso,
>> > > me diga e eu saio sem problemas. Do contrário, é o meu trabalho
>> garantir a
>> > > entrega. Me deixe fazer o trabalho que me pagam pois que seja feito.
>> > > Em 21/06/2012 17:12, "Thiago C. Santos" <thiago.csantos...@gmail.com>
>> > > escreveu:
>> > >> Quem vive no mundo corporativo sabe que existem aqueles momentos que
>> algo
>> > >> "feio" necessita ser feito, isso por que no mundo corporativo existem
>> > >> custos, prazos e não somente o código que agente quer que fique
>> animal.
>> > >> Att,
>> > >> Thiago C. Santos
>> > >> 2012/6/20 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>> > >>> osse seu último dia de vida, você faria o que está prestes a fazer?
>> Você
>> > >>> está feliz fazendo isso?
>> > >> --
>> > >> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>> > >> hospedado no Google Groups.
>> > >> Para postar envie uma mensagem para
>> dotnetarchitects@googlegroups.com
>> > >> Para sair do grupo envie uma mensagem para
>> > >> dotnetarchitects+unsubscribe@googlegroups.com
>> > >> Para mais opções visite o grupo em
>> > >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>> --
>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>> hospedado no Google Groups.
>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>> Para sair do grupo envie uma mensagem para
>> dotnetarchitects+unsubscribe@googlegroups.com
>> Para mais opções visite o grupo em
>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitects+unsubscribe@googlegroups.com
> Para mais opções visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br
Eu acho que os três primeiros que o Mário colocou são ótimos.
Adicionaria a simplicidade (que talvez esteja no segundo item). Acho que em nome de 'boas práticas’ frequentemente vemos uma engenharia exagerada nos códigos. E acho que código bom não precisa ser complexo, não precisa usar X ou Y só porque aquilo está quente na comunidade. Basta que o software atenda aos requisitos, seja fácil de manter e tenha um mínimo de bugs ou nenhum.
[]s
From: Mário Meyrelles Sent: Friday, June 22, 2012 8:30 AM
To: dotnetarchitects@googlegroups.com Subject: Re: [dotnetarchitects] Re: Como parei de escrever códigos incríveis!
Para mim, qualidade é:
0) Software sem bugs.
1) Código com baixa barreira de entrada para novos desenvolvedores, isto é, código legível que siga os padrões mais conhecidos de mercado.
2) Código com facilidade de manter e evoluir.
...
200) Beleza estética do código (nomes, organização, etc...)
Galera, o que é "qualidade" pra vocês? Eu acho que é possível fazer código muito bem feito sem qualidade (leia-se: código bonito), e eu acho que é o que mais acontece nos melhores produtos. Parece vivermos uma época parnasiana da programação, do código pelo código e da estética e eu não sei bem se concordo com isso.
Em 21 de junho de 2012 21:40, Robson Castilho <robsoncasti...@yahoo.com.br> escreveu:
Daniel:
Mais uma vez corretíssimo. Eu fico 100x mais incomodado com a
qualidade da entrega do que com prazo (isto não quer dizer que eu
despreze o último)...
Gerson:
Nem todas. Aqui a empresa se preocupa com qualidade sim, porque eles
sabem que estão perdendo e já perderam muito dinheiro com manutenção
de software porco...Temos que ir mostrando que dói no bolso, que
vários devs poderiam estar liberados para projetos e funcionalidades
novas (mais $$$) ao invés de ficarem a maior parte do tempo apagando
incêndio...
E para todos:
Vejo muitos devs argumentando muito em cima de prazo, prazo, prazo e
pouco em favor de qualidade, qualidade, qualidade...
Onde fica a qualidade no meio disso tudo?
De onde vem esse bicho chamado prazo? Quem o definiu? Por que? Com
qual propósito? De onde tiraram aquela data? Essas respostas tem que
estar claras (não vale resposta de um gerente dizendo que quer o bônus
dele até aquela data pra ele trocar de carro). Havendo uma real
necessidade de se entregar naquela data, os devs vão poder elaborar
melhor uma solução, quem sabe mexer no escopo para entregar naquela
data mantendo qualidade. Transparência ajuda bastante nesses casos...
[]s a todos.
On Jun 21, 6:36 pm, Daniel Moreira Yokoyama
<moreira.yokoy...@gmail.com> wrote:
> Só para que conste, quando eu digo que não é problema meu se houver algum
> problema com atrasos, eu não quero dizer que sou inflexível com o cliente,
> o que eu quero dizer é que as pessoas que se incomodam mais com o
> cumprimento do prazo do que com a qualidade da entrega não vai ver esta
> postura em mim.
>
> Uma coisa é ser lean para dar ao cliente uma vantagem estratégica no que
> diz respeito a time to market... outra coisa é cumprir o prazo colocando em
> risco o verdadeiro valor da entrega, que diz respeito inclusive no custo da
> manutenção que o cliente vai ter no futuro.
>
> Para garantir o melhor disso, eu não abro a mão de testes automatizados,
> que são a melhor maneira de medir no futuro o que foi ou não afetado por
> manutenções futuras. Isto é critério meu, do qual eu não abro mão, a menos
> que seja algo pontual, para ser usado uma única vez e nunca mais.
>
> Para garantir que estes testes realmente garantam o funcionamento do que
> estou implementando, eu uso TDD, ou seja, não faço uma linha de código sem
> que haja um teste para aquilo antes. E preciso ver o teste quebrar pra ter
> certeza de que ele faz o que eu espero que faça: valide a funcionalidade
> que nem sequer foi implementada ainda.
>
> São só meros exemplos, mas são critérios meus. Ninguém precisa cobrar isso
> de mim, mas ninguém jamais vai me impedir de entregar as coisas desta
> forma. São meus valores, que definem aquilo que me compete entregar.
>
> Atenciosamente,
>
> Daniel Moreira Yokoyama.
>
>
>
>
>
>
>
> > Eu vivo no mundo corporativo e não abro mão de um bom trabalho. O prazo
> > que eu tenho é o prazo que eu dei. Se houver razões para atrasar devido a
> > algo inesperado, vai atrasar. Se isso for algum problema, não é problema
> > meu. Meu trabalho é entregar com qualidade o que me compete entregar. Os
> > meus critérios de qualidade são inegociáveis. Se tiver problema com isso,
> > me diga e eu saio sem problemas. Do contrário, é o meu trabalho garantir a
> > entrega. Me deixe fazer o trabalho que me pagam pois que seja feito.
> > Em 21/06/2012 17:12, "Thiago C. Santos" <thiago.csantos...@gmail.com>
> > escreveu:
>
> >> Quem vive no mundo corporativo sabe que existem aqueles momentos que algo
> >> "feio" necessita ser feito, isso por que no mundo corporativo existem
> >> custos, prazos e não somente o código que agente quer que fique animal.
>
> >> Att,
>
> >> Thiago C. Santos
>
> >> 2012/6/20 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>
> >>> osse seu último dia de vida, você faria o que está prestes a fazer? Você
> >>> está feliz fazendo isso?
>
> >> --
> >> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >> hospedado no Google Groups.
> >> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
> >> Para sair do grupo envie uma mensagem para
> >> mailto:dotnetarchitects%2Bunsubscribe@googlegroups.com
> >> Para mais opções visite o grupo em
> >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
Para sair do grupo envie uma mensagem para mailto:dotnetarchitects%2Bunsubscribe@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
-- Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetarchitects@googlegroups.com Para sair do grupo envie uma mensagem para mailto:dotnetarchitects%2Bunsubscribe@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
-- Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetarchitects@googlegroups.com Para sair do grupo envie uma mensagem para dotnetarchitects+unsubscribe@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
> 0) Software sem bugs.
> 1) C�digo com baixa barreira de entrada para novos desenvolvedores, > isto �, c�digo leg�vel que siga os padr�es mais conhecidos de mercado.
> 2) C�digo com facilidade de manter e evoluir.
> ...
> 200) Beleza est�tica do c�digo (nomes, organiza��o, etc...)
> Galera, o que � "qualidade" pra voc�s? Eu acho que � poss�vel
> fazer c�digo muito bem feito sem qualidade (leia-se: c�digo
> bonito), e eu acho que � o que mais acontece nos melhores
> produtos. Parece vivermos uma �poca parnasiana da programa��o, do
> c�digo pelo c�digo e da est�tica e eu n�o sei bem se concordo com
> isso.
> Em 21 de junho de 2012 21:40, Robson Castilho
> <robsoncasti...@yahoo.com.br <mailto:robsoncasti...@yahoo.com.br>>
> escreveu:
> Daniel:
> Mais uma vez corret�ssimo. Eu fico 100x mais incomodado com a
> qualidade da entrega do que com prazo (isto n�o quer dizer que eu
> despreze o �ltimo)...
> Gerson:
> Nem todas. Aqui a empresa se preocupa com qualidade sim,
> porque eles
> sabem que est�o perdendo e j� perderam muito dinheiro com
> manuten��o
> de software porco...Temos que ir mostrando que d�i no bolso, que
> v�rios devs poderiam estar liberados para projetos e
> funcionalidades
> novas (mais $$$) ao inv�s de ficarem a maior parte do tempo
> apagando
> inc�ndio...
> E para todos:
> Vejo muitos devs argumentando muito em cima de prazo, prazo,
> prazo e
> pouco em favor de qualidade, qualidade, qualidade...
> Onde fica a qualidade no meio disso tudo?
> De onde vem esse bicho chamado prazo? Quem o definiu? Por que? Com
> qual prop�sito? De onde tiraram aquela data? Essas respostas
> tem que
> estar claras (n�o vale resposta de um gerente dizendo que quer
> o b�nus
> dele at� aquela data pra ele trocar de carro). Havendo uma real
> necessidade de se entregar naquela data, os devs v�o poder
> elaborar
> melhor uma solu��o, quem sabe mexer no escopo para entregar
> naquela
> data mantendo qualidade. Transpar�ncia ajuda bastante nesses
> casos...
> []s a todos.
> On Jun 21, 6:36 pm, Daniel Moreira Yokoyama
> <moreira.yokoy...@gmail.com
> <mailto:moreira.yokoy...@gmail.com>> wrote:
> > S� para que conste, quando eu digo que n�o � problema meu se
> houver algum
> > problema com atrasos, eu n�o quero dizer que sou inflex�vel
> com o cliente,
> > o que eu quero dizer � que as pessoas que se incomodam mais
> com o
> > cumprimento do prazo do que com a qualidade da entrega n�o
> vai ver esta
> > postura em mim.
> > Uma coisa � ser lean para dar ao cliente uma vantagem
> estrat�gica no que
> > diz respeito a time to market... outra coisa � cumprir o
> prazo colocando em
> > risco o verdadeiro valor da entrega, que diz respeito
> inclusive no custo da
> > manuten��o que o cliente vai ter no futuro.
> > Para garantir o melhor disso, eu n�o abro a m�o de testes
> automatizados,
> > que s�o a melhor maneira de medir no futuro o que foi ou n�o
> afetado por
> > manuten��es futuras. Isto � crit�rio meu, do qual eu n�o
> abro m�o, a menos
> > que seja algo pontual, para ser usado uma �nica vez e nunca
> mais.
> > Para garantir que estes testes realmente garantam o
> funcionamento do que
> > estou implementando, eu uso TDD, ou seja, n�o fa�o uma linha
> de c�digo sem
> > que haja um teste para aquilo antes. E preciso ver o teste
> quebrar pra ter
> > certeza de que ele faz o que eu espero que fa�a: valide a
> funcionalidade
> > que nem sequer foi implementada ainda.
> > S�o s� meros exemplos, mas s�o crit�rios meus. Ningu�m
> precisa cobrar isso
> > de mim, mas ningu�m jamais vai me impedir de entregar as
> coisas desta
> > forma. S�o meus valores, que definem aquilo que me compete
> entregar.
> > Em 21 de junho de 2012 19:11, Daniel Moreira Yokoyama <
> > moreira.yokoy...@gmail.com
> <mailto:moreira.yokoy...@gmail.com>> escreveu:
> > > Eu vivo no mundo corporativo e n�o abro m�o de um bom
> trabalho. O prazo
> > > que eu tenho � o prazo que eu dei. Se houver raz�es para
> atrasar devido a
> > > algo inesperado, vai atrasar. Se isso for algum problema,
> n�o � problema
> > > meu. Meu trabalho � entregar com qualidade o que me
> compete entregar. Os
> > > meus crit�rios de qualidade s�o inegoci�veis. Se tiver
> problema com isso,
> > > me diga e eu saio sem problemas. Do contr�rio, � o meu
> trabalho garantir a
> > > entrega. Me deixe fazer o trabalho que me pagam pois que
> seja feito.
> > > Em 21/06/2012 17:12, "Thiago C. Santos"
> <thiago.csantos...@gmail.com <mailto:thiago.csantos...@gmail.com>>
> > > escreveu:
> > >> Quem vive no mundo corporativo sabe que existem aqueles
> momentos que algo
> > >> "feio" necessita ser feito, isso por que no mundo
> corporativo existem
> > >> custos, prazos e n�o somente o c�digo que agente quer que
> fique animal.
> > >> Att,
> > >> Thiago C. Santos
> > >> 2012/6/20 Daniel Moreira Yokoyama
> <moreira.yokoy...@gmail.com <mailto:moreira.yokoy...@gmail.com>>
> > >>> osse seu �ltimo dia de vida, voc� faria o que est�
> prestes a fazer? Voc�
> > >>> est� feliz fazendo isso?
> > >> --
> > >> Voc� recebeu esta mensagem porque faz parte do grupo .Net
> Architects
> > >> hospedado no Google Groups.
> > >> Para postar envie uma mensagem para
> dotnetarchitects@googlegroups.com
> <mailto:dotnetarchitects@googlegroups.com>
> > >> Para sair do grupo envie uma mensagem para
> > >> dotnetarchitects+unsubscribe@googlegroups.com
> <mailto:dotnetarchitects%2Bunsubscribe@googlegroups.com>
> > >> Para mais op��es visite o grupo em
> > >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
> --
> Voc� recebeu esta mensagem porque faz parte do grupo .Net
> Architects hospedado no Google Groups.
> Para postar envie uma mensagem para
> dotnetarchitects@googlegroups.com
> <mailto:dotnetarchitects@googlegroups.com>
> Para sair do grupo envie uma mensagem para
> dotnetarchitects+unsubscribe@googlegroups.com
> <mailto:dotnetarchitects%2Bunsubscribe@googlegroups.com>
> Para mais op��es visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br
> -- > Voc� recebeu esta mensagem porque faz parte do grupo .Net
> Architects hospedado no Google Groups.
> Para postar envie uma mensagem para
> dotnetarchitects@googlegroups.com
> <mailto:dotnetarchitects@googlegroups.com>
> Para sair do grupo envie uma mensagem para
> dotnetarchitects+unsubscribe@googlegroups.com
> <mailto:dotnetarchitects%2Bunsubscribe@googlegroups.com>
> Para mais op��es visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br
> -- > Voc� recebeu esta mensagem porque faz parte do grupo .Net Architects > hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
> Para sair do grupo envie uma mensagem para
Daniel, como você diz que ta preocupado com a qualidade e você prefere não
cumprir o prazo para fazer algo do jeito que você acha que deve ser feito?
Sendo que podia entregar no prazo so que não seria algo tão "bom"mas que
poderia arrumar depois.
Você fala de qualidade so visando o código, você esta falando da visão de
um desenvolvedor, mas para o cliente se você compromete o prazo não esta
executando o projeto com qualidade.
Alias, a maioria aqui esta falando de qualidade so visando o código...
PRAZO
Tem muita coisa mais importante para o cliente do que o código em si, ele
pode esperar o projeto em tal dia e ele realmente precisa do projeto tal
dia, então você não vai entregar por que você acha que tem que florear
ainda mais o projeto?
CUSTO
Se você vai levar mais tempo para executar as tarefar do projeto isso vai
demandar custo, e ai quem vai pagar? A empresa desenvolvedora ou o cliente?
Seja o que for a qualidade do PROJETO esta comprometida.
obs: Acho que as necessidades do cliente como CUSTO e PRAZO são mais
interessantes para definir a qualidade do projeto do que o código em si,
não estou dizendo que o código pode ficar ruim desde que se cumpra isso...
> Eu acho que os três primeiros que o Mário colocou são ótimos.
> Adicionaria a simplicidade (que talvez esteja no segundo item). Acho que
> em nome de 'boas práticas’ frequentemente vemos uma engenharia exagerada
> nos códigos. E acho que código bom não precisa ser complexo, não precisa
> usar X ou Y só porque aquilo está quente na comunidade. Basta que o
> software atenda aos requisitos, seja fácil de manter e tenha um mínimo de
> bugs ou nenhum.
> []s
> *From:* Mário Meyrelles <mariomeyrel...@gmail.com>
> *Sent:* Friday, June 22, 2012 8:30 AM
> *To:* dotnetarchitects@googlegroups.com
> *Subject:* Re: [dotnetarchitects] Re: Como parei de escrever códigos
> incríveis!
> Para mim, qualidade é:
> 0) Software sem bugs.
> 1) Código com baixa barreira de entrada para novos desenvolvedores, isto
> é, código legível que siga os padrões mais conhecidos de mercado.
> 2) Código com facilidade de manter e evoluir.
> ...
> 200) Beleza estética do código (nomes, organização, etc...)
>> Galera, o que é "qualidade" pra vocês? Eu acho que é possível fazer
>> código muito bem feito sem qualidade (leia-se: código bonito), e eu acho
>> que é o que mais acontece nos melhores produtos. Parece vivermos uma época
>> parnasiana da programação, do código pelo código e da estética e eu não sei
>> bem se concordo com isso.
>> Em 21 de junho de 2012 21:40, Robson Castilho <
>> robsoncasti...@yahoo.com.br> escreveu:
>> Daniel:
>>> Mais uma vez corretíssimo. Eu fico 100x mais incomodado com a
>>> qualidade da entrega do que com prazo (isto não quer dizer que eu
>>> despreze o último)...
>>> Gerson:
>>> Nem todas. Aqui a empresa se preocupa com qualidade sim, porque eles
>>> sabem que estão perdendo e já perderam muito dinheiro com manutenção
>>> de software porco...Temos que ir mostrando que dói no bolso, que
>>> vários devs poderiam estar liberados para projetos e funcionalidades
>>> novas (mais $$$) ao invés de ficarem a maior parte do tempo apagando
>>> incêndio...
>>> E para todos:
>>> Vejo muitos devs argumentando muito em cima de prazo, prazo, prazo e
>>> pouco em favor de qualidade, qualidade, qualidade...
>>> Onde fica a qualidade no meio disso tudo?
>>> De onde vem esse bicho chamado prazo? Quem o definiu? Por que? Com
>>> qual propósito? De onde tiraram aquela data? Essas respostas tem que
>>> estar claras (não vale resposta de um gerente dizendo que quer o bônus
>>> dele até aquela data pra ele trocar de carro). Havendo uma real
>>> necessidade de se entregar naquela data, os devs vão poder elaborar
>>> melhor uma solução, quem sabe mexer no escopo para entregar naquela
>>> data mantendo qualidade. Transparência ajuda bastante nesses casos...
>>> []s a todos.
>>> On Jun 21, 6:36 pm, Daniel Moreira Yokoyama
>>> <moreira.yokoy...@gmail.com> wrote:
>>> > Só para que conste, quando eu digo que não é problema meu se houver
>>> algum
>>> > problema com atrasos, eu não quero dizer que sou inflexível com o
>>> cliente,
>>> > o que eu quero dizer é que as pessoas que se incomodam mais com o
>>> > cumprimento do prazo do que com a qualidade da entrega não vai ver esta
>>> > postura em mim.
>>> > Uma coisa é ser lean para dar ao cliente uma vantagem estratégica no
>>> que
>>> > diz respeito a time to market... outra coisa é cumprir o prazo
>>> colocando em
>>> > risco o verdadeiro valor da entrega, que diz respeito inclusive no
>>> custo da
>>> > manutenção que o cliente vai ter no futuro.
>>> > Para garantir o melhor disso, eu não abro a mão de testes
>>> automatizados,
>>> > que são a melhor maneira de medir no futuro o que foi ou não afetado
>>> por
>>> > manutenções futuras. Isto é critério meu, do qual eu não abro mão, a
>>> menos
>>> > que seja algo pontual, para ser usado uma única vez e nunca mais.
>>> > Para garantir que estes testes realmente garantam o funcionamento do
>>> que
>>> > estou implementando, eu uso TDD, ou seja, não faço uma linha de código
>>> sem
>>> > que haja um teste para aquilo antes. E preciso ver o teste quebrar pra
>>> ter
>>> > certeza de que ele faz o que eu espero que faça: valide a
>>> funcionalidade
>>> > que nem sequer foi implementada ainda.
>>> > São só meros exemplos, mas são critérios meus. Ninguém precisa cobrar
>>> isso
>>> > de mim, mas ninguém jamais vai me impedir de entregar as coisas desta
>>> > forma. São meus valores, que definem aquilo que me compete entregar.
>>> > Em 21 de junho de 2012 19:11, Daniel Moreira Yokoyama <
>>> > moreira.yokoy...@gmail.com> escreveu:
>>> > > Eu vivo no mundo corporativo e não abro mão de um bom trabalho. O
>>> prazo
>>> > > que eu tenho é o prazo que eu dei. Se houver razões para atrasar
>>> devido a
>>> > > algo inesperado, vai atrasar. Se isso for algum problema, não é
>>> problema
>>> > > meu. Meu trabalho é entregar com qualidade o que me compete
>>> entregar. Os
>>> > > meus critérios de qualidade são inegociáveis. Se tiver problema com
>>> isso,
>>> > > me diga e eu saio sem problemas. Do contrário, é o meu trabalho
>>> garantir a
>>> > > entrega. Me deixe fazer o trabalho que me pagam pois que seja feito.
>>> > > Em 21/06/2012 17:12, "Thiago C. Santos" <thiago.csantos...@gmail.com
>>> > > escreveu:
>>> > >> Quem vive no mundo corporativo sabe que existem aqueles momentos
>>> que algo
>>> > >> "feio" necessita ser feito, isso por que no mundo corporativo
>>> existem
>>> > >> custos, prazos e não somente o código que agente quer que fique
>>> animal.
>>> > >> Att,
>>> > >> Thiago C. Santos
>>> > >> 2012/6/20 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>>> > >>> osse seu último dia de vida, você faria o que está prestes a
>>> fazer? Você
>>> > >>> está feliz fazendo isso?
>>> > >> --
>>> > >> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>> > >> hospedado no Google Groups.
>>> > >> Para postar envie uma mensagem para
>>> dotnetarchitects@googlegroups.com
>>> > >> Para sair do grupo envie uma mensagem para
>>> > >> mailto:dotnetarchitects%2Bunsubscribe@googlegroups.com<dotnetarchitects%2Bu nsubscribe@googlegroups.com>
>>> --
>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>> hospedado no Google Groups.
>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>>> Para sair do grupo envie uma mensagem para
>>> mailto:dotnetarchitects%2Bunsubscribe@googlegroups.com<dotnetarchitects%2Bu nsubscribe@googlegroups.com>
>> --
>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>> hospedado no Google Groups.
>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>> Para sair do grupo envie uma mensagem para
>> mailto:dotnetarchitects%2Bunsubscribe@googlegroups.com<dotnetarchitects%2Bu nsubscribe@googlegroups.com>
> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitects+unsubscribe@googlegroups.com
> Para mais opções visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br
> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> hospedado no Google Groups.
> Para postar envie
As pessoas tratam "Beleza e estética do código" como algum tipo de
ornamentação. Para mim, um código bonito é um código que garante o item 2.
Afinal, para que o código facilite a entrada de outros membros, ele precisa
ter propriedades de difícil medição, como nomes bem definidos, instruções
expressivas que transmitam conhecimento do modelo, etc.
> 0) Software sem bugs.
> 1) Código com baixa barreira de entrada para novos desenvolvedores, isto
> é, código legível que siga os padrões mais conhecidos de mercado.
> 2) Código com facilidade de manter e evoluir.
> ...
> 200) Beleza estética do código (nomes, organização, etc...)
>> Galera, o que é "qualidade" pra vocês? Eu acho que é possível fazer
>> código muito bem feito sem qualidade (leia-se: código bonito), e eu acho
>> que é o que mais acontece nos melhores produtos. Parece vivermos uma época
>> parnasiana da programação, do código pelo código e da estética e eu não sei
>> bem se concordo com isso.
>> Em 21 de junho de 2012 21:40, Robson Castilho <
>> robsoncasti...@yahoo.com.br> escreveu:
>> Daniel:
>>> Mais uma vez corretíssimo. Eu fico 100x mais incomodado com a
>>> qualidade da entrega do que com prazo (isto não quer dizer que eu
>>> despreze o último)...
>>> Gerson:
>>> Nem todas. Aqui a empresa se preocupa com qualidade sim, porque eles
>>> sabem que estão perdendo e já perderam muito dinheiro com manutenção
>>> de software porco...Temos que ir mostrando que dói no bolso, que
>>> vários devs poderiam estar liberados para projetos e funcionalidades
>>> novas (mais $$$) ao invés de ficarem a maior parte do tempo apagando
>>> incêndio...
>>> E para todos:
>>> Vejo muitos devs argumentando muito em cima de prazo, prazo, prazo e
>>> pouco em favor de qualidade, qualidade, qualidade...
>>> Onde fica a qualidade no meio disso tudo?
>>> De onde vem esse bicho chamado prazo? Quem o definiu? Por que? Com
>>> qual propósito? De onde tiraram aquela data? Essas respostas tem que
>>> estar claras (não vale resposta de um gerente dizendo que quer o bônus
>>> dele até aquela data pra ele trocar de carro). Havendo uma real
>>> necessidade de se entregar naquela data, os devs vão poder elaborar
>>> melhor uma solução, quem sabe mexer no escopo para entregar naquela
>>> data mantendo qualidade. Transparência ajuda bastante nesses casos...
>>> []s a todos.
>>> On Jun 21, 6:36 pm, Daniel Moreira Yokoyama
>>> <moreira.yokoy...@gmail.com> wrote:
>>> > Só para que conste, quando eu digo que não é problema meu se houver
>>> algum
>>> > problema com atrasos, eu não quero dizer que sou inflexível com o
>>> cliente,
>>> > o que eu quero dizer é que as pessoas que se incomodam mais com o
>>> > cumprimento do prazo do que com a qualidade da entrega não vai ver esta
>>> > postura em mim.
>>> > Uma coisa é ser lean para dar ao cliente uma vantagem estratégica no
>>> que
>>> > diz respeito a time to market... outra coisa é cumprir o prazo
>>> colocando em
>>> > risco o verdadeiro valor da entrega, que diz respeito inclusive no
>>> custo da
>>> > manutenção que o cliente vai ter no futuro.
>>> > Para garantir o melhor disso, eu não abro a mão de testes
>>> automatizados,
>>> > que são a melhor maneira de medir no futuro o que foi ou não afetado
>>> por
>>> > manutenções futuras. Isto é critério meu, do qual eu não abro mão, a
>>> menos
>>> > que seja algo pontual, para ser usado uma única vez e nunca mais.
>>> > Para garantir que estes testes realmente garantam o funcionamento do
>>> que
>>> > estou implementando, eu uso TDD, ou seja, não faço uma linha de código
>>> sem
>>> > que haja um teste para aquilo antes. E preciso ver o teste quebrar pra
>>> ter
>>> > certeza de que ele faz o que eu espero que faça: valide a
>>> funcionalidade
>>> > que nem sequer foi implementada ainda.
>>> > São só meros exemplos, mas são critérios meus. Ninguém precisa cobrar
>>> isso
>>> > de mim, mas ninguém jamais vai me impedir de entregar as coisas desta
>>> > forma. São meus valores, que definem aquilo que me compete entregar.
>>> > Em 21 de junho de 2012 19:11, Daniel Moreira Yokoyama <
>>> > moreira.yokoy...@gmail.com> escreveu:
>>> > > Eu vivo no mundo corporativo e não abro mão de um bom trabalho. O
>>> prazo
>>> > > que eu tenho é o prazo que eu dei. Se houver razões para atrasar
>>> devido a
>>> > > algo inesperado, vai atrasar. Se isso for algum problema, não é
>>> problema
>>> > > meu. Meu trabalho é entregar com qualidade o que me compete
>>> entregar. Os
>>> > > meus critérios de qualidade são inegociáveis. Se tiver problema com
>>> isso,
>>> > > me diga e eu saio sem problemas. Do contrário, é o meu trabalho
>>> garantir a
>>> > > entrega. Me deixe fazer o trabalho que me pagam pois que seja feito.
>>> > > Em 21/06/2012 17:12, "Thiago C. Santos" <
>>> thiago.csantos...@gmail.com>
>>> > > escreveu:
>>> > >> Quem vive no mundo corporativo sabe que existem aqueles momentos
>>> que algo
>>> > >> "feio" necessita ser feito, isso por que no mundo corporativo
>>> existem
>>> > >> custos, prazos e não somente o código que agente quer que fique
>>> animal.
>>> > >> Att,
>>> > >> Thiago C. Santos
>>> > >> 2012/6/20 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>>> > >>> osse seu último dia de vida, você faria o que está prestes a
>>> fazer? Você
>>> > >>> está feliz fazendo isso?
>>> > >> --
>>> > >> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>> > >> hospedado no Google Groups.
>>> > >> Para postar envie uma mensagem para
>>> dotnetarchitects@googlegroups.com
>>> > >> Para sair do grupo envie uma mensagem para
>>> > >> dotnetarchitects+unsubscribe@googlegroups.com
>>> > >> Para mais opções visite o grupo em
>>> > >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>> --
>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>> hospedado no Google Groups.
>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>>> Para sair do grupo envie uma mensagem para
>>> dotnetarchitects+unsubscribe@googlegroups.com
>>> Para mais opções visite o grupo em
>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>> --
>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>> hospedado no Google Groups.
>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>> Para sair do grupo envie uma mensagem para
>> dotnetarchitects+unsubscribe@googlegroups.com
>> Para mais opções visite o grupo em
>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitects+unsubscribe@googlegroups.com
> Para mais opções visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br
> **
> Participe en la XVI Convención Científica de Ingeniería y Arquitectura del
> 26 al 30 de noviembre de 2012. La Habana, Cuba: http://ccia.cujae.edu.cu > Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitects+unsubscribe@googlegroups.com
> Para mais opções visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br
Acaz, acredito ter a mesma visão que você, nos desenvolvemos para o PROJETO
sair, não o projeto surgiu para nos ficarmos programando... O código por
código esta errado o código deve ser feito para atender ao projeto!
Att,
Thiago C. Santos
2012/6/22 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
> As pessoas tratam "Beleza e estética do código" como algum tipo de
> ornamentação. Para mim, um código bonito é um código que garante o item 2.
> Afinal, para que o código facilite a entrada de outros membros, ele precisa
> ter propriedades de difícil medição, como nomes bem definidos, instruções
> expressivas que transmitam conhecimento do modelo, etc.
>> El 22-Jun-12 8:30 AM, Mário Meyrelles escribió:
>> Para mim, qualidade é:
>> 0) Software sem bugs.
>> 1) Código com baixa barreira de entrada para novos desenvolvedores, isto
>> é, código legível que siga os padrões mais conhecidos de mercado.
>> 2) Código com facilidade de manter e evoluir.
>> ...
>> 200) Beleza estética do código (nomes, organização, etc...)
>>> Galera, o que é "qualidade" pra vocês? Eu acho que é possível fazer
>>> código muito bem feito sem qualidade (leia-se: código bonito), e eu acho
>>> que é o que mais acontece nos melhores produtos. Parece vivermos uma época
>>> parnasiana da programação, do código pelo código e da estética e eu não sei
>>> bem se concordo com isso.
>>> Em 21 de junho de 2012 21:40, Robson Castilho <
>>> robsoncasti...@yahoo.com.br> escreveu:
>>> Daniel:
>>>> Mais uma vez corretíssimo. Eu fico 100x mais incomodado com a
>>>> qualidade da entrega do que com prazo (isto não quer dizer que eu
>>>> despreze o último)...
>>>> Gerson:
>>>> Nem todas. Aqui a empresa se preocupa com qualidade sim, porque eles
>>>> sabem que estão perdendo e já perderam muito dinheiro com manutenção
>>>> de software porco...Temos que ir mostrando que dói no bolso, que
>>>> vários devs poderiam estar liberados para projetos e funcionalidades
>>>> novas (mais $$$) ao invés de ficarem a maior parte do tempo apagando
>>>> incêndio...
>>>> E para todos:
>>>> Vejo muitos devs argumentando muito em cima de prazo, prazo, prazo e
>>>> pouco em favor de qualidade, qualidade, qualidade...
>>>> Onde fica a qualidade no meio disso tudo?
>>>> De onde vem esse bicho chamado prazo? Quem o definiu? Por que? Com
>>>> qual propósito? De onde tiraram aquela data? Essas respostas tem que
>>>> estar claras (não vale resposta de um gerente dizendo que quer o bônus
>>>> dele até aquela data pra ele trocar de carro). Havendo uma real
>>>> necessidade de se entregar naquela data, os devs vão poder elaborar
>>>> melhor uma solução, quem sabe mexer no escopo para entregar naquela
>>>> data mantendo qualidade. Transparência ajuda bastante nesses casos...
>>>> []s a todos.
>>>> On Jun 21, 6:36 pm, Daniel Moreira Yokoyama
>>>> <moreira.yokoy...@gmail.com> wrote:
>>>> > Só para que conste, quando eu digo que não é problema meu se houver
>>>> algum
>>>> > problema com atrasos, eu não quero dizer que sou inflexível com o
>>>> cliente,
>>>> > o que eu quero dizer é que as pessoas que se incomodam mais com o
>>>> > cumprimento do prazo do que com a qualidade da entrega não vai ver
>>>> esta
>>>> > postura em mim.
>>>> > Uma coisa é ser lean para dar ao cliente uma vantagem estratégica no
>>>> que
>>>> > diz respeito a time to market... outra coisa é cumprir o prazo
>>>> colocando em
>>>> > risco o verdadeiro valor da entrega, que diz respeito inclusive no
>>>> custo da
>>>> > manutenção que o cliente vai ter no futuro.
>>>> > Para garantir o melhor disso, eu não abro a mão de testes
>>>> automatizados,
>>>> > que são a melhor maneira de medir no futuro o que foi ou não afetado
>>>> por
>>>> > manutenções futuras. Isto é critério meu, do qual eu não abro mão, a
>>>> menos
>>>> > que seja algo pontual, para ser usado uma única vez e nunca mais.
>>>> > Para garantir que estes testes realmente garantam o funcionamento do
>>>> que
>>>> > estou implementando, eu uso TDD, ou seja, não faço uma linha de
>>>> código sem
>>>> > que haja um teste para aquilo antes. E preciso ver o teste quebrar
>>>> pra ter
>>>> > certeza de que ele faz o que eu espero que faça: valide a
>>>> funcionalidade
>>>> > que nem sequer foi implementada ainda.
>>>> > São só meros exemplos, mas são critérios meus. Ninguém precisa cobrar
>>>> isso
>>>> > de mim, mas ninguém jamais vai me impedir de entregar as coisas desta
>>>> > forma. São meus valores, que definem aquilo que me compete entregar.
>>>> > Em 21 de junho de 2012 19:11, Daniel Moreira Yokoyama <
>>>> > moreira.yokoy...@gmail.com> escreveu:
>>>> > > Eu vivo no mundo corporativo e não abro mão de um bom trabalho. O
>>>> prazo
>>>> > > que eu tenho é o prazo que eu dei. Se houver razões para atrasar
>>>> devido a
>>>> > > algo inesperado, vai atrasar. Se isso for algum problema, não é
>>>> problema
>>>> > > meu. Meu trabalho é entregar com qualidade o que me compete
>>>> entregar. Os
>>>> > > meus critérios de qualidade são inegociáveis. Se tiver problema com
>>>> isso,
>>>> > > me diga e eu saio sem problemas. Do contrário, é o meu trabalho
>>>> garantir a
>>>> > > entrega. Me deixe fazer o trabalho que me pagam pois que seja feito.
>>>> > > Em 21/06/2012 17:12, "Thiago C. Santos" <
>>>> thiago.csantos...@gmail.com>
>>>> > > escreveu:
>>>> > >> Quem vive no mundo corporativo sabe que existem aqueles momentos
>>>> que algo
>>>> > >> "feio" necessita ser feito, isso por que no mundo corporativo
>>>> existem
>>>> > >> custos, prazos e não somente o código que agente quer que fique
>>>> animal.
>>>> > >> Att,
>>>> > >> Thiago C. Santos
>>>> > >> 2012/6/20 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>>>> > >>> osse seu último dia de vida, você faria o que está prestes a
>>>> fazer? Você
>>>> > >>> está feliz fazendo isso?
>>>> > >> --
>>>> > >> Você recebeu esta mensagem porque faz parte do grupo .Net
>>>> Architects
>>>> > >> hospedado no Google Groups.
>>>> > >> Para postar envie uma mensagem para
>>>> dotnetarchitects@googlegroups.com
>>>> > >> Para sair do grupo envie uma mensagem para
>>>> > >> dotnetarchitects+unsubscribe@googlegroups.com
>>>> > >> Para mais opções visite o grupo em
>>>> > >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>>> --
>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>>> hospedado no Google Groups.
>>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>>>> Para sair do grupo envie uma mensagem para
>>>> dotnetarchitects+unsubscribe@googlegroups.com
>>>> Para mais opções visite o grupo em
>>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>> --
>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>> hospedado no Google Groups.
>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>>> Para sair do grupo envie uma mensagem para
>>> dotnetarchitects+unsubscribe@googlegroups.com
>>> Para mais opções visite o grupo em
>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>> --
>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>> hospedado no Google Groups.
>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>> Para sair do grupo envie uma mensagem para
>> dotnetarchitects+unsubscribe@googlegroups.com
>> Para mais opções visite o grupo em
>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>> **
>> Participe en la XVI Convención Científica de Ingeniería y Arquitectura
>> del 26 al 30 de noviembre de 2012. La Habana, Cuba:
>> http://ccia.cujae.edu.cu >> Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
>> --
>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>> hospedado no Google Groups.
>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>> Para sair do grupo envie uma mensagem para
>> dotnetarchitects+unsubscribe@googlegroups.com
>> Para mais opções visite o grupo em
>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
> --
> Você recebeu esta mensagem porque faz parte
Acho que nada é regra. Tudo é um DEPENDE bem grande com prós e contras.
Destacando o item de *manutenção *onde possibilita a entrada de novos
códigos e modificação dos antigos c/ o menor esforço possível deixa o
código ainda maior e mais difícil de entender.
Em 22 de junho de 2012 09:28, Thiago C. Santos
<thiago.csantos...@gmail.com>escreveu:
> Acaz, acredito ter a mesma visão que você, nos desenvolvemos para o
> PROJETO sair, não o projeto surgiu para nos ficarmos programando... O
> código por código esta errado o código deve ser feito para atender ao
> projeto!
> Att,
> Thiago C. Santos
> 2012/6/22 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>> Concordo Lemol.
>> As pessoas tratam "Beleza e estética do código" como algum tipo de
>> ornamentação. Para mim, um código bonito é um código que garante o item 2.
>> Afinal, para que o código facilite a entrada de outros membros, ele precisa
>> ter propriedades de difícil medição, como nomes bem definidos, instruções
>> expressivas que transmitam conhecimento do modelo, etc.
>>> El 22-Jun-12 8:30 AM, Mário Meyrelles escribió:
>>> Para mim, qualidade é:
>>> 0) Software sem bugs.
>>> 1) Código com baixa barreira de entrada para novos desenvolvedores, isto
>>> é, código legível que siga os padrões mais conhecidos de mercado.
>>> 2) Código com facilidade de manter e evoluir.
>>> ...
>>> 200) Beleza estética do código (nomes, organização, etc...)
>>>> Galera, o que é "qualidade" pra vocês? Eu acho que é possível fazer
>>>> código muito bem feito sem qualidade (leia-se: código bonito), e eu acho
>>>> que é o que mais acontece nos melhores produtos. Parece vivermos uma época
>>>> parnasiana da programação, do código pelo código e da estética e eu não sei
>>>> bem se concordo com isso.
>>>> Em 21 de junho de 2012 21:40, Robson Castilho <
>>>> robsoncasti...@yahoo.com.br> escreveu:
>>>> Daniel:
>>>>> Mais uma vez corretíssimo. Eu fico 100x mais incomodado com a
>>>>> qualidade da entrega do que com prazo (isto não quer dizer que eu
>>>>> despreze o último)...
>>>>> Gerson:
>>>>> Nem todas. Aqui a empresa se preocupa com qualidade sim, porque eles
>>>>> sabem que estão perdendo e já perderam muito dinheiro com manutenção
>>>>> de software porco...Temos que ir mostrando que dói no bolso, que
>>>>> vários devs poderiam estar liberados para projetos e funcionalidades
>>>>> novas (mais $$$) ao invés de ficarem a maior parte do tempo apagando
>>>>> incêndio...
>>>>> E para todos:
>>>>> Vejo muitos devs argumentando muito em cima de prazo, prazo, prazo e
>>>>> pouco em favor de qualidade, qualidade, qualidade...
>>>>> Onde fica a qualidade no meio disso tudo?
>>>>> De onde vem esse bicho chamado prazo? Quem o definiu? Por que? Com
>>>>> qual propósito? De onde tiraram aquela data? Essas respostas tem que
>>>>> estar claras (não vale resposta de um gerente dizendo que quer o bônus
>>>>> dele até aquela data pra ele trocar de carro). Havendo uma real
>>>>> necessidade de se entregar naquela data, os devs vão poder elaborar
>>>>> melhor uma solução, quem sabe mexer no escopo para entregar naquela
>>>>> data mantendo qualidade. Transparência ajuda bastante nesses casos...
>>>>> []s a todos.
>>>>> On Jun 21, 6:36 pm, Daniel Moreira Yokoyama
>>>>> <moreira.yokoy...@gmail.com> wrote:
>>>>> > Só para que conste, quando eu digo que não é problema meu se houver
>>>>> algum
>>>>> > problema com atrasos, eu não quero dizer que sou inflexível com o
>>>>> cliente,
>>>>> > o que eu quero dizer é que as pessoas que se incomodam mais com o
>>>>> > cumprimento do prazo do que com a qualidade da entrega não vai ver
>>>>> esta
>>>>> > postura em mim.
>>>>> > Uma coisa é ser lean para dar ao cliente uma vantagem estratégica no
>>>>> que
>>>>> > diz respeito a time to market... outra coisa é cumprir o prazo
>>>>> colocando em
>>>>> > risco o verdadeiro valor da entrega, que diz respeito inclusive no
>>>>> custo da
>>>>> > manutenção que o cliente vai ter no futuro.
>>>>> > Para garantir o melhor disso, eu não abro a mão de testes
>>>>> automatizados,
>>>>> > que são a melhor maneira de medir no futuro o que foi ou não afetado
>>>>> por
>>>>> > manutenções futuras. Isto é critério meu, do qual eu não abro mão, a
>>>>> menos
>>>>> > que seja algo pontual, para ser usado uma única vez e nunca mais.
>>>>> > Para garantir que estes testes realmente garantam o funcionamento do
>>>>> que
>>>>> > estou implementando, eu uso TDD, ou seja, não faço uma linha de
>>>>> código sem
>>>>> > que haja um teste para aquilo antes. E preciso ver o teste quebrar
>>>>> pra ter
>>>>> > certeza de que ele faz o que eu espero que faça: valide a
>>>>> funcionalidade
>>>>> > que nem sequer foi implementada ainda.
>>>>> > São só meros exemplos, mas são critérios meus. Ninguém precisa
>>>>> cobrar isso
>>>>> > de mim, mas ninguém jamais vai me impedir de entregar as coisas desta
>>>>> > forma. São meus valores, que definem aquilo que me compete entregar.
>>>>> > Em 21 de junho de 2012 19:11, Daniel Moreira Yokoyama <
>>>>> > moreira.yokoy...@gmail.com> escreveu:
>>>>> > > Eu vivo no mundo corporativo e não abro mão de um bom trabalho. O
>>>>> prazo
>>>>> > > que eu tenho é o prazo que eu dei. Se houver razões para atrasar
>>>>> devido a
>>>>> > > algo inesperado, vai atrasar. Se isso for algum problema, não é
>>>>> problema
>>>>> > > meu. Meu trabalho é entregar com qualidade o que me compete
>>>>> entregar. Os
>>>>> > > meus critérios de qualidade são inegociáveis. Se tiver problema
>>>>> com isso,
>>>>> > > me diga e eu saio sem problemas. Do contrário, é o meu trabalho
>>>>> garantir a
>>>>> > > entrega. Me deixe fazer o trabalho que me pagam pois que seja
>>>>> feito.
>>>>> > > Em 21/06/2012 17:12, "Thiago C. Santos" <
>>>>> thiago.csantos...@gmail.com>
>>>>> > > escreveu:
>>>>> > >> Quem vive no mundo corporativo sabe que existem aqueles momentos
>>>>> que algo
>>>>> > >> "feio" necessita ser feito, isso por que no mundo corporativo
>>>>> existem
>>>>> > >> custos, prazos e não somente o código que agente quer que fique
>>>>> animal.
>>>>> > >> Att,
>>>>> > >> Thiago C. Santos
>>>>> > >> 2012/6/20 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>>>>> > >>> osse seu último dia de vida, você faria o que está prestes a
>>>>> fazer? Você
>>>>> > >>> está feliz fazendo isso?
>>>>> > >> --
>>>>> > >> Você recebeu esta mensagem porque faz parte do grupo .Net
>>>>> Architects
>>>>> > >> hospedado no Google Groups.
>>>>> > >> Para postar envie uma mensagem para
>>>>> dotnetarchitects@googlegroups.com
>>>>> > >> Para sair do grupo envie uma mensagem para
>>>>> > >> dotnetarchitects+unsubscribe@googlegroups.com
>>>>> > >> Para mais opções visite o grupo em
>>>>> > >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>>>> --
>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>>>> hospedado no Google Groups.
>>>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>>>>> Para sair do grupo envie uma mensagem para
>>>>> dotnetarchitects+unsubscribe@googlegroups.com
>>>>> Para mais opções visite o grupo em
>>>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>>> --
>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>>> hospedado no Google Groups.
>>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>>>> Para sair do grupo envie uma mensagem para
>>>> dotnetarchitects+unsubscribe@googlegroups.com
>>>> Para mais opções visite o grupo em
>>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>> --
>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>> hospedado no Google Groups.
>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>>> Para sair do grupo envie uma mensagem para
>>> dotnetarchitects+unsubscribe@googlegroups.com
>>> Para mais opções visite o grupo em
>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
> Acho que nada é regra. Tudo é um DEPENDE bem grande com prós e contras.
> Destacando o item de *manutenção *onde possibilita a entrada de novos
> códigos e modificação dos antigos c/ o menor esforço possível deixa o
> código ainda maior e mais difícil de entender.
> Em 22 de junho de 2012 09:28, Thiago C. Santos <
> thiago.csantos...@gmail.com> escreveu:
>> Acaz, acredito ter a mesma visão que você, nos desenvolvemos para o
>> PROJETO sair, não o projeto surgiu para nos ficarmos programando... O
>> código por código esta errado o código deve ser feito para atender ao
>> projeto!
>> Att,
>> Thiago C. Santos
>> 2012/6/22 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>>> Concordo Lemol.
>>> As pessoas tratam "Beleza e estética do código" como algum tipo de
>>> ornamentação. Para mim, um código bonito é um código que garante o item 2.
>>> Afinal, para que o código facilite a entrada de outros membros, ele precisa
>>> ter propriedades de difícil medição, como nomes bem definidos, instruções
>>> expressivas que transmitam conhecimento do modelo, etc.
>>>> El 22-Jun-12 8:30 AM, Mário Meyrelles escribió:
>>>> Para mim, qualidade é:
>>>> 0) Software sem bugs.
>>>> 1) Código com baixa barreira de entrada para novos desenvolvedores,
>>>> isto é, código legível que siga os padrões mais conhecidos de mercado.
>>>> 2) Código com facilidade de manter e evoluir.
>>>> ...
>>>> 200) Beleza estética do código (nomes, organização, etc...)
>>>>> Galera, o que é "qualidade" pra vocês? Eu acho que é possível fazer
>>>>> código muito bem feito sem qualidade (leia-se: código bonito), e eu acho
>>>>> que é o que mais acontece nos melhores produtos. Parece vivermos uma época
>>>>> parnasiana da programação, do código pelo código e da estética e eu não sei
>>>>> bem se concordo com isso.
>>>>> Em 21 de junho de 2012 21:40, Robson Castilho <
>>>>> robsoncasti...@yahoo.com.br> escreveu:
>>>>> Daniel:
>>>>>> Mais uma vez corretíssimo. Eu fico 100x mais incomodado com a
>>>>>> qualidade da entrega do que com prazo (isto não quer dizer que eu
>>>>>> despreze o último)...
>>>>>> Gerson:
>>>>>> Nem todas. Aqui a empresa se preocupa com qualidade sim, porque eles
>>>>>> sabem que estão perdendo e já perderam muito dinheiro com manutenção
>>>>>> de software porco...Temos que ir mostrando que dói no bolso, que
>>>>>> vários devs poderiam estar liberados para projetos e funcionalidades
>>>>>> novas (mais $$$) ao invés de ficarem a maior parte do tempo apagando
>>>>>> incêndio...
>>>>>> E para todos:
>>>>>> Vejo muitos devs argumentando muito em cima de prazo, prazo, prazo e
>>>>>> pouco em favor de qualidade, qualidade, qualidade...
>>>>>> Onde fica a qualidade no meio disso tudo?
>>>>>> De onde vem esse bicho chamado prazo? Quem o definiu? Por que? Com
>>>>>> qual propósito? De onde tiraram aquela data? Essas respostas tem que
>>>>>> estar claras (não vale resposta de um gerente dizendo que quer o bônus
>>>>>> dele até aquela data pra ele trocar de carro). Havendo uma real
>>>>>> necessidade de se entregar naquela data, os devs vão poder elaborar
>>>>>> melhor uma solução, quem sabe mexer no escopo para entregar naquela
>>>>>> data mantendo qualidade. Transparência ajuda bastante nesses casos...
>>>>>> []s a todos.
>>>>>> On Jun 21, 6:36 pm, Daniel Moreira Yokoyama
>>>>>> <moreira.yokoy...@gmail.com> wrote:
>>>>>> > Só para que conste, quando eu digo que não é problema meu se houver
>>>>>> algum
>>>>>> > problema com atrasos, eu não quero dizer que sou inflexível com o
>>>>>> cliente,
>>>>>> > o que eu quero dizer é que as pessoas que se incomodam mais com o
>>>>>> > cumprimento do prazo do que com a qualidade da entrega não vai ver
>>>>>> esta
>>>>>> > postura em mim.
>>>>>> > Uma coisa é ser lean para dar ao cliente uma vantagem estratégica
>>>>>> no que
>>>>>> > diz respeito a time to market... outra coisa é cumprir o prazo
>>>>>> colocando em
>>>>>> > risco o verdadeiro valor da entrega, que diz respeito inclusive no
>>>>>> custo da
>>>>>> > manutenção que o cliente vai ter no futuro.
>>>>>> > Para garantir o melhor disso, eu não abro a mão de testes
>>>>>> automatizados,
>>>>>> > que são a melhor maneira de medir no futuro o que foi ou não
>>>>>> afetado por
>>>>>> > manutenções futuras. Isto é critério meu, do qual eu não abro mão,
>>>>>> a menos
>>>>>> > que seja algo pontual, para ser usado uma única vez e nunca mais.
>>>>>> > Para garantir que estes testes realmente garantam o funcionamento
>>>>>> do que
>>>>>> > estou implementando, eu uso TDD, ou seja, não faço uma linha de
>>>>>> código sem
>>>>>> > que haja um teste para aquilo antes. E preciso ver o teste quebrar
>>>>>> pra ter
>>>>>> > certeza de que ele faz o que eu espero que faça: valide a
>>>>>> funcionalidade
>>>>>> > que nem sequer foi implementada ainda.
>>>>>> > São só meros exemplos, mas são critérios meus. Ninguém precisa
>>>>>> cobrar isso
>>>>>> > de mim, mas ninguém jamais vai me impedir de entregar as coisas
>>>>>> desta
>>>>>> > forma. São meus valores, que definem aquilo que me compete entregar.
>>>>>> > Em 21 de junho de 2012 19:11, Daniel Moreira Yokoyama <
>>>>>> > moreira.yokoy...@gmail.com> escreveu:
>>>>>> > > Eu vivo no mundo corporativo e não abro mão de um bom trabalho. O
>>>>>> prazo
>>>>>> > > que eu tenho é o prazo que eu dei. Se houver razões para atrasar
>>>>>> devido a
>>>>>> > > algo inesperado, vai atrasar. Se isso for algum problema, não é
>>>>>> problema
>>>>>> > > meu. Meu trabalho é entregar com qualidade o que me compete
>>>>>> entregar. Os
>>>>>> > > meus critérios de qualidade são inegociáveis. Se tiver problema
>>>>>> com isso,
>>>>>> > > me diga e eu saio sem problemas. Do contrário, é o meu trabalho
>>>>>> garantir a
>>>>>> > > entrega. Me deixe fazer o trabalho que me pagam pois que seja
>>>>>> feito.
>>>>>> > > Em 21/06/2012 17:12, "Thiago C. Santos" <
>>>>>> thiago.csantos...@gmail.com>
>>>>>> > > escreveu:
>>>>>> > >> Quem vive no mundo corporativo sabe que existem aqueles momentos
>>>>>> que algo
>>>>>> > >> "feio" necessita ser feito, isso por que no mundo corporativo
>>>>>> existem
>>>>>> > >> custos, prazos e não somente o código que agente quer que fique
>>>>>> animal.
>>>>>> > >> Att,
>>>>>> > >> Thiago C. Santos
>>>>>> > >> 2012/6/20 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>>>>>> > >>> osse seu último dia de vida, você faria o que está prestes a
>>>>>> fazer? Você
>>>>>> > >>> está feliz fazendo isso?
>>>>>> > >> --
>>>>>> > >> Você recebeu esta mensagem porque faz parte do grupo .Net
>>>>>> Architects
>>>>>> > >> hospedado no Google Groups.
>>>>>> > >> Para postar envie uma mensagem para
>>>>>> dotnetarchitects@googlegroups.com
>>>>>> > >> Para sair do grupo envie uma mensagem para
>>>>>> > >> dotnetarchitects+unsubscribe@googlegroups.com
>>>>>> > >> Para mais opções visite o grupo em
>>>>>> > >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>>>>> --
>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>>>>> hospedado no Google Groups.
>>>>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>>>>>> Para sair do grupo envie uma mensagem para
>>>>>> dotnetarchitects+unsubscribe@googlegroups.com
>>>>>> Para mais opções visite o grupo em
>>>>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>>>> --
>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>>>> hospedado no Google Groups.
>>>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>>>>> Para sair do grupo envie uma mensagem para
>>>>> dotnetarchitects+unsubscribe@googlegroups.com
>>>>> Para mais opções visite o grupo em
O prazo não é tão importante para o cliente, se o que será entregue não
funciona.
Que vantagem haverá nisso? Me mostre em que cenário o cliente prefere
receber no prazo algo que simplesmente não atenda suas necessidades, não
funcione como esperado.
Agora, de que forma você pode garantir que o que está sendo feito funciona
de verdade sem uma boa cobertura de testes. Nem estou falando
necessariamente de TDD... ele é um meio de especificar o sistema através de
testes, e de quebra vc ganha um monte de testes automatizados pra rodar
sempre que quiser validar o funcionamento da coisa.
Isso pra mim é um valor inegociável de qualidade por que simplesmente me
garante que o que está sendo feito, funciona. Eu nem gosto do termo "livre
de bugs", por que sempre tem alguns equívocos. Mas estes também estão ali,
presentes nos testes. Os testes lhe dirão o que o sistema faz.
Se o cliente perguntar "Por que tal coisa está acontecendo sempre que eu
clico neste botão", você terá provavelmente terá um teste que deixará claro
o que acontece e o cliente poderá lhe dizer: "Ah, mas isto não deveria
acontecer."
E aí você sabe exatamente que teste deve mudar, como deve mudar, e ele vai
quebrar quando você fizer as alterações, até que você corrija o código.
Veja quanta coisa você consegue ter em mãos simplesmente por que se
preocupou com a qualidade.
Mas tem mais uma parte... Custo: O cliente na grande maioria das vezes não
precisa pagar mais do que o que foi combinado para ter valor de negócio.
Esta é a proposta do lean. Isto não compromete a qualidade. Só abre mão de
coisas que, talvez, não fossem tão necessárias assim. Ou, ainda que sejam
necessárias (por exemplo, ferramentas de monitoramento do produto,
métricas, etc) não vão deixar o cliente sem usufruir do benefício
estratégico que o produto lhe dará.
Eu volto a dizer: prometer pro cliente que algo vai ficar pronto antes de
ficar de fato, não vai deixá-lo mais satisfeito por que entregou antes algo
que não estava pronto entregando o mínimo de valor suficiente para que ele
tire real benefício daquilo. Não adianta entregar a sopa, se você não
entregar uma colher.
É necessário ressaltar, normalmente, o meu cliente sempre está ciente dos
atrasos, o que os causou e este tipo de transparência o coloca a par das
coisas a ponto de não haver insatisfação com os atrasos. Ele sabe o que
quer, e está vendo ali que o que quer não funciona como queria, esta é a
forma mais assertiva de fazer com que atrasos sejam aceitáveis, não é de
hoje que sabemos disto: leve o cliente junto com você. Deixe-o saber o que
acontece no projeto.
Atrasos não acontecem da noite para o dia. Eles são consequência de
situações inesperadas. Deixe-as claras para o cliente. Isto funciona muito
melhor do que simplesmente falhar na entrega do sprint. Ninguém que chega
no sprint sem ter todas as estórias que se comprometeu a entregar descobriu
isso no dia anterior.
Eu não consigo lembrar de nenhum atraso em entregas nos meus projetos
recentes que tenham estressado o cliente. Sempre na hora da apresentação
ele já estava previamente ciente das dificuldades e isso sempre fez com que
ele não ficasse surpreso ao saber que tal coisa não pôde ser entregue. É
muito importante isto. Deixar o cliente por dentro do que acontece no
projeto faz com que os atrasos não prejudiquem sua expectativa. Melhor
ainda, dá ao cliente a possibilidade de se armar estrategicamente.
> Daniel, como você diz que ta preocupado com a qualidade e você prefere não
> cumprir o prazo para fazer algo do jeito que você acha que deve ser feito?
> Sendo que podia entregar no prazo so que não seria algo tão "bom"mas que
> poderia arrumar depois.
> Você fala de qualidade so visando o código, você esta falando da visão de
> um desenvolvedor, mas para o cliente se você compromete o prazo não esta
> executando o projeto com qualidade.
> Alias, a maioria aqui esta falando de qualidade so visando o código...
> PRAZO
> Tem muita coisa mais importante para o cliente do que o código em si, ele
> pode esperar o projeto em tal dia e ele realmente precisa do projeto tal
> dia, então você não vai entregar por que você acha que tem que florear
> ainda mais o projeto?
> CUSTO
> Se você vai levar mais tempo para executar as tarefar do projeto isso vai
> demandar custo, e ai quem vai pagar? A empresa desenvolvedora ou o cliente?
> Seja o que for a qualidade do PROJETO esta comprometida.
> obs: Acho que as necessidades do cliente como CUSTO e PRAZO são mais
> interessantes para definir a qualidade do projeto do que o código em si,
> não estou dizendo que o código pode ficar ruim desde que se cumpra isso...
>> Eu acho que os três primeiros que o Mário colocou são ótimos.
>> Adicionaria a simplicidade (que talvez esteja no segundo item). Acho que
>> em nome de 'boas práticas’ frequentemente vemos uma engenharia exagerada
>> nos códigos. E acho que código bom não precisa ser complexo, não precisa
>> usar X ou Y só porque aquilo está quente na comunidade. Basta que o
>> software atenda aos requisitos, seja fácil de manter e tenha um mínimo de
>> bugs ou nenhum.
>> []s
>> *From:* Mário Meyrelles <mariomeyrel...@gmail.com>
>> *Sent:* Friday, June 22, 2012 8:30 AM
>> *To:* dotnetarchitects@googlegroups.com
>> *Subject:* Re: [dotnetarchitects] Re: Como parei de escrever códigos
>> incríveis!
>> Para mim, qualidade é:
>> 0) Software sem bugs.
>> 1) Código com baixa barreira de entrada para novos desenvolvedores, isto
>> é, código legível que siga os padrões mais conhecidos de mercado.
>> 2) Código com facilidade de manter e evoluir.
>> ...
>> 200) Beleza estética do código (nomes, organização, etc...)
>>> Galera, o que é "qualidade" pra vocês? Eu acho que é possível fazer
>>> código muito bem feito sem qualidade (leia-se: código bonito), e eu acho
>>> que é o que mais acontece nos melhores produtos. Parece vivermos uma época
>>> parnasiana da programação, do código pelo código e da estética e eu não sei
>>> bem se concordo com isso.
>>> Em 21 de junho de 2012 21:40, Robson Castilho <
>>> robsoncasti...@yahoo.com.br> escreveu:
>>> Daniel:
>>>> Mais uma vez corretíssimo. Eu fico 100x mais incomodado com a
>>>> qualidade da entrega do que com prazo (isto não quer dizer que eu
>>>> despreze o último)...
>>>> Gerson:
>>>> Nem todas. Aqui a empresa se preocupa com qualidade sim, porque eles
>>>> sabem que estão perdendo e já perderam muito dinheiro com manutenção
>>>> de software porco...Temos que ir mostrando que dói no bolso, que
>>>> vários devs poderiam estar liberados para projetos e funcionalidades
>>>> novas (mais $$$) ao invés de ficarem a maior parte do tempo apagando
>>>> incêndio...
>>>> E para todos:
>>>> Vejo muitos devs argumentando muito em cima de prazo, prazo, prazo e
>>>> pouco em favor de qualidade, qualidade, qualidade...
>>>> Onde fica a qualidade no meio disso tudo?
>>>> De onde vem esse bicho chamado prazo? Quem o definiu? Por que? Com
>>>> qual propósito? De onde tiraram aquela data? Essas respostas tem que
>>>> estar claras (não vale resposta de um gerente dizendo que quer o bônus
>>>> dele até aquela data pra ele trocar de carro). Havendo uma real
>>>> necessidade de se entregar naquela data, os devs vão poder elaborar
>>>> melhor uma solução, quem sabe mexer no escopo para entregar naquela
>>>> data mantendo qualidade. Transparência ajuda bastante nesses casos...
>>>> []s a todos.
>>>> On Jun 21, 6:36 pm, Daniel Moreira Yokoyama
>>>> <moreira.yokoy...@gmail.com> wrote:
>>>> > Só para que conste, quando eu digo que não é problema meu se houver
>>>> algum
>>>> > problema com atrasos, eu não quero dizer que sou inflexível com o
>>>> cliente,
>>>> > o que eu quero dizer é que as pessoas que se incomodam mais com o
>>>> > cumprimento do prazo do que com a qualidade da entrega não vai ver
>>>> esta
>>>> > postura em mim.
>>>> > Uma coisa é ser lean para dar ao cliente uma vantagem estratégica no
>>>> que
>>>> > diz respeito a time to market... outra coisa é cumprir o prazo
>>>> colocando em
>>>> > risco o verdadeiro valor da entrega, que diz respeito inclusive no
>>>> custo da
>>>> > manutenção que o cliente vai ter no futuro.
>>>> > Para garantir o melhor disso, eu não abro a mão de testes
>>>> automatizados,
>>>> > que são a melhor maneira de medir no futuro o que foi ou não afetado
>>>> por
>>>> > manutenções futuras. Isto é critério meu, do qual eu não abro mão, a
>>>> menos
>>>> > que seja algo pontual, para ser usado uma única vez e nunca mais.
>>>> > Para garantir que estes testes realmente garantam o funcionamento do
>>>> que
>>>> > estou implementando, eu uso TDD, ou seja, não faço uma linha de
>>>> código sem
>>>> > que haja um teste para aquilo antes. E preciso ver o teste quebrar
>>>> pra ter
>>>> > certeza de que ele faz o que eu espero que faça: valide a
Existem contextos onde uma ferramenta só será usada uma única vez e pronto.
Como um sistema de inscrições para um evento excepcional, pra citar UM
exemplo.
Este tipo de cenário não requer manutenibilidade. É basicamente um crud. Se
você vive de projetos deste tipo, você dificilmente vai concordar com
qualquer coisa que eu diga. Para mim é raro ter que desenvolver algo desse
tipo.
>> Acho que nada é regra. Tudo é um DEPENDE bem grande com prós e contras.
>> Destacando o item de *manutenção *onde possibilita a entrada de novos
>> códigos e modificação dos antigos c/ o menor esforço possível deixa o
>> código ainda maior e mais difícil de entender.
>> Em 22 de junho de 2012 09:28, Thiago C. Santos <
>> thiago.csantos...@gmail.com> escreveu:
>>> Acaz, acredito ter a mesma visão que você, nos desenvolvemos para o
>>> PROJETO sair, não o projeto surgiu para nos ficarmos programando... O
>>> código por código esta errado o código deve ser feito para atender ao
>>> projeto!
>>> Att,
>>> Thiago C. Santos
>>> 2012/6/22 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>>>> Concordo Lemol.
>>>> As pessoas tratam "Beleza e estética do código" como algum tipo de
>>>> ornamentação. Para mim, um código bonito é um código que garante o item 2.
>>>> Afinal, para que o código facilite a entrada de outros membros, ele precisa
>>>> ter propriedades de difícil medição, como nomes bem definidos, instruções
>>>> expressivas que transmitam conhecimento do modelo, etc.
>>>>> El 22-Jun-12 8:30 AM, Mário Meyrelles escribió:
>>>>> Para mim, qualidade é:
>>>>> 0) Software sem bugs.
>>>>> 1) Código com baixa barreira de entrada para novos desenvolvedores,
>>>>> isto é, código legível que siga os padrões mais conhecidos de mercado.
>>>>> 2) Código com facilidade de manter e evoluir.
>>>>> ...
>>>>> 200) Beleza estética do código (nomes, organização, etc...)
>>>>>> Galera, o que é "qualidade" pra vocês? Eu acho que é possível fazer
>>>>>> código muito bem feito sem qualidade (leia-se: código bonito), e eu acho
>>>>>> que é o que mais acontece nos melhores produtos. Parece vivermos uma época
>>>>>> parnasiana da programação, do código pelo código e da estética e eu não sei
>>>>>> bem se concordo com isso.
>>>>>> Em 21 de junho de 2012 21:40, Robson Castilho <
>>>>>> robsoncasti...@yahoo.com.br> escreveu:
>>>>>> Daniel:
>>>>>>> Mais uma vez corretíssimo. Eu fico 100x mais incomodado com a
>>>>>>> qualidade da entrega do que com prazo (isto não quer dizer que eu
>>>>>>> despreze o último)...
>>>>>>> Gerson:
>>>>>>> Nem todas. Aqui a empresa se preocupa com qualidade sim, porque eles
>>>>>>> sabem que estão perdendo e já perderam muito dinheiro com manutenção
>>>>>>> de software porco...Temos que ir mostrando que dói no bolso, que
>>>>>>> vários devs poderiam estar liberados para projetos e funcionalidades
>>>>>>> novas (mais $$$) ao invés de ficarem a maior parte do tempo apagando
>>>>>>> incêndio...
>>>>>>> E para todos:
>>>>>>> Vejo muitos devs argumentando muito em cima de prazo, prazo, prazo e
>>>>>>> pouco em favor de qualidade, qualidade, qualidade...
>>>>>>> Onde fica a qualidade no meio disso tudo?
>>>>>>> De onde vem esse bicho chamado prazo? Quem o definiu? Por que? Com
>>>>>>> qual propósito? De onde tiraram aquela data? Essas respostas tem que
>>>>>>> estar claras (não vale resposta de um gerente dizendo que quer o
>>>>>>> bônus
>>>>>>> dele até aquela data pra ele trocar de carro). Havendo uma real
>>>>>>> necessidade de se entregar naquela data, os devs vão poder elaborar
>>>>>>> melhor uma solução, quem sabe mexer no escopo para entregar naquela
>>>>>>> data mantendo qualidade. Transparência ajuda bastante nesses casos...
>>>>>>> []s a todos.
>>>>>>> On Jun 21, 6:36 pm, Daniel Moreira Yokoyama
>>>>>>> <moreira.yokoy...@gmail.com> wrote:
>>>>>>> > Só para que conste, quando eu digo que não é problema meu se
>>>>>>> houver algum
>>>>>>> > problema com atrasos, eu não quero dizer que sou inflexível com o
>>>>>>> cliente,
>>>>>>> > o que eu quero dizer é que as pessoas que se incomodam mais com o
>>>>>>> > cumprimento do prazo do que com a qualidade da entrega não vai ver
>>>>>>> esta
>>>>>>> > postura em mim.
>>>>>>> > Uma coisa é ser lean para dar ao cliente uma vantagem estratégica
>>>>>>> no que
>>>>>>> > diz respeito a time to market... outra coisa é cumprir o prazo
>>>>>>> colocando em
>>>>>>> > risco o verdadeiro valor da entrega, que diz respeito inclusive no
>>>>>>> custo da
>>>>>>> > manutenção que o cliente vai ter no futuro.
>>>>>>> > Para garantir o melhor disso, eu não abro a mão de testes
>>>>>>> automatizados,
>>>>>>> > que são a melhor maneira de medir no futuro o que foi ou não
>>>>>>> afetado por
>>>>>>> > manutenções futuras. Isto é critério meu, do qual eu não abro mão,
>>>>>>> a menos
>>>>>>> > que seja algo pontual, para ser usado uma única vez e nunca mais.
>>>>>>> > Para garantir que estes testes realmente garantam o funcionamento
>>>>>>> do que
>>>>>>> > estou implementando, eu uso TDD, ou seja, não faço uma linha de
>>>>>>> código sem
>>>>>>> > que haja um teste para aquilo antes. E preciso ver o teste quebrar
>>>>>>> pra ter
>>>>>>> > certeza de que ele faz o que eu espero que faça: valide a
>>>>>>> funcionalidade
>>>>>>> > que nem sequer foi implementada ainda.
>>>>>>> > São só meros exemplos, mas são critérios meus. Ninguém precisa
>>>>>>> cobrar isso
>>>>>>> > de mim, mas ninguém jamais vai me impedir de entregar as coisas
>>>>>>> desta
>>>>>>> > forma. São meus valores, que definem aquilo que me compete
>>>>>>> entregar.
>>>>>>> > Em 21 de junho de 2012 19:11, Daniel Moreira Yokoyama <
>>>>>>> > moreira.yokoy...@gmail.com> escreveu:
>>>>>>> > > Eu vivo no mundo corporativo e não abro mão de um bom trabalho.
>>>>>>> O prazo
>>>>>>> > > que eu tenho é o prazo que eu dei. Se houver razões para atrasar
>>>>>>> devido a
>>>>>>> > > algo inesperado, vai atrasar. Se isso for algum problema, não é
>>>>>>> problema
>>>>>>> > > meu. Meu trabalho é entregar com qualidade o que me compete
>>>>>>> entregar. Os
>>>>>>> > > meus critérios de qualidade são inegociáveis. Se tiver problema
>>>>>>> com isso,
>>>>>>> > > me diga e eu saio sem problemas. Do contrário, é o meu trabalho
>>>>>>> garantir a
>>>>>>> > > entrega. Me deixe fazer o trabalho que me pagam pois que seja
>>>>>>> feito.
>>>>>>> > > Em 21/06/2012 17:12, "Thiago C. Santos" <
>>>>>>> thiago.csantos...@gmail.com>
>>>>>>> > > escreveu:
>>>>>>> > >> Quem vive no mundo corporativo sabe que existem aqueles
>>>>>>> momentos que algo
>>>>>>> > >> "feio" necessita ser feito, isso por que no mundo corporativo
>>>>>>> existem
>>>>>>> > >> custos, prazos e não somente o código que agente quer que fique
>>>>>>> animal.
>>>>>>> > >> Att,
>>>>>>> > >> Thiago C. Santos
>>>>>>> > >> 2012/6/20 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>>>>>>> > >>> osse seu último dia de vida, você faria o que está prestes a
>>>>>>> fazer? Você
>>>>>>> > >>> está feliz fazendo isso?
>>>>>>> > >> --
>>>>>>> > >> Você recebeu esta mensagem porque faz parte do grupo .Net
>>>>>>> Architects
>>>>>>> > >> hospedado no Google Groups.
>>>>>>> > >> Para postar envie uma mensagem para
>>>>>>> dotnetarchitects@googlegroups.com
>>>>>>> > >> Para sair do grupo envie uma mensagem para
>>>>>>> > >> dotnetarchitects+unsubscribe@googlegroups.com
>>>>>>> > >> Para mais opções visite o grupo em
> Que vantagem haverá nisso? Me mostre em que cenário o cliente prefere
> receber no prazo algo que simplesmente não atenda suas necessidades, não
> funcione como esperado.
> Agora, de que forma você pode garantir que o que está sendo feito funciona
> de verdade sem uma boa cobertura de testes. Nem estou falando
> necessariamente de TDD... ele é um meio de especificar o sistema através de
> testes, e de quebra vc ganha um monte de testes automatizados pra rodar
> sempre que quiser validar o funcionamento da coisa.
> Daniel, me diz quando eu disse que você deve entregar algo que não
> funcione, sem ter feito testes e cheio de bugs?
> Falei que você pode entregar algo sem florear tanto (Quando o código já
> esta funcional porem poderia estar melhor) e atender ao prazo.
> Att,
> Thiago C. Santos
> 2012/6/22 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>> Que vantagem haverá nisso? Me mostre em que cenário o cliente prefere
>> receber no prazo algo que simplesmente não atenda suas necessidades, não
>> funcione como esperado.
>> Agora, de que forma você pode garantir que o que está sendo feito
>> funciona de verdade sem uma boa cobertura de testes. Nem estou falando
>> necessariamente de TDD... ele é um meio de especificar o sistema através de
>> testes, e de quebra vc ganha um monte de testes automatizados pra rodar
>> sempre que quiser validar o funcionamento da coisa.
> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitects+unsubscribe@googlegroups.com
> Para mais opções visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br
Daniel, se você acha que só existem 2 ou 3 tipos de contexto e que todo boa
pratica deve ser aplicada em todo projeto, realmente não podemos
prosseguir...
Se você não conseguiu compreender oque eu escrevi vou deixar mais claro,
quando digo que algo deve ser feito por que o contexto exige é que o
desenvolvedor não deve por imaturidade inserir toda e qualquer tipo de boa
pratica no projeto sendo que o projeto não exige isso. Somente isso, não
citei nada de projetos que seram usado somente uma vez...
Att,
Thiago C. Santos
2012/6/22 Thiago C. Santos <thiago.csantos...@gmail.com>
> Daniel, me diz quando eu disse que você deve entregar algo que não
> funcione, sem ter feito testes e cheio de bugs?
> Falei que você pode entregar algo sem florear tanto (Quando o código já
> esta funcional porem poderia estar melhor) e atender ao prazo.
> Att,
> Thiago C. Santos
> 2012/6/22 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>> Que vantagem haverá nisso? Me mostre em que cenário o cliente prefere
>> receber no prazo algo que simplesmente não atenda suas necessidades, não
>> funcione como esperado.
>> Agora, de que forma você pode garantir que o que está sendo feito
>> funciona de verdade sem uma boa cobertura de testes. Nem estou falando
>> necessariamente de TDD... ele é um meio de especificar o sistema através de
>> testes, e de quebra vc ganha um monte de testes automatizados pra rodar
>> sempre que quiser validar o funcionamento da coisa.
- Abstrações desnecessárias
- Defender-se de um futuro que ninguém sabe como vai ser (big design upfront)
- Interfaces e injeção de dependência a dar com pau, sem necessidade
- Cobertura de testes de unidade excessivamente alta
Abraços,
From: Daniel Moreira Yokoyama Sent: Friday, June 22, 2012 10:21 AM
To: dotnetarchitects@googlegroups.com Subject: Re: [dotnetarchitects] Re: Como parei de escrever códigos incríveis!
Me esclareça por favor, o que é florear o código. Colocar corações como pingos nos i's?
Em 22 de junho de 2012 10:16, Thiago C. Santos <thiago.csantos...@gmail.com> escreveu:
Daniel, me diz quando eu disse que você deve entregar algo que não funcione, sem ter feito testes e cheio de bugs?
Falei que você pode entregar algo sem florear tanto (Quando o código já esta funcional porem poderia estar melhor) e atender ao prazo.
Att,
Thiago C. Santos
2012/6/22 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
Que vantagem haverá nisso? Me mostre em que cenário o cliente prefere receber no prazo algo que simplesmente não atenda suas necessidades, não funcione como esperado.
Agora, de que forma você pode garantir que o que está sendo feito funciona de verdade sem uma boa cobertura de testes. Nem estou falando necessariamente de TDD... ele é um meio de especificar o sistema através de testes, e de quebra vc ganha um monte de testes automatizados pra rodar sempre que quiser validar o funcionamento da coisa.
-- Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetarchitects@googlegroups.com Para sair do grupo envie uma mensagem para mailto:dotnetarchitects%2Bunsubscribe@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
-- Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetarchitects@googlegroups.com Para sair do grupo envie uma mensagem para dotnetarchitects+unsubscribe@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
O Leo, respondeu por mim... alem do desenvolvedor ficar refatorando,
refatorando, refatorando, refatorando, refatorando, refatorando o que já
esta muito bom!
> Daniel, penso eu:
> - Abstrações desnecessárias
> - Defender-se de um futuro que ninguém sabe como vai ser (big design
> upfront)
> - Interfaces e injeção de dependência a dar com pau, sem necessidade
> - Cobertura de testes de unidade excessivamente alta
> Abraços,
> *From:* Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
> *Sent:* Friday, June 22, 2012 10:21 AM
> *To:* dotnetarchitects@googlegroups.com
> *Subject:* Re: [dotnetarchitects] Re: Como parei de escrever códigos
> incríveis!
> Me esclareça por favor, o que é florear o código. Colocar corações como
> pingos nos i's?
> Em 22 de junho de 2012 10:16, Thiago C. Santos <
> thiago.csantos...@gmail.com> escreveu:
>> Daniel, me diz quando eu disse que você deve entregar algo que não
>> funcione, sem ter feito testes e cheio de bugs?
>> Falei que você pode entregar algo sem florear tanto (Quando o código já
>> esta funcional porem poderia estar melhor) e atender ao prazo.
>> Att,
>> Thiago C. Santos
>> 2012/6/22 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>>> Que vantagem haverá nisso? Me mostre em que cenário o cliente prefere
>>> receber no prazo algo que simplesmente não atenda suas necessidades, não
>>> funcione como esperado.
>>> Agora, de que forma você pode garantir que o que está sendo feito
>>> funciona de verdade sem uma boa cobertura de testes. Nem estou falando
>>> necessariamente de TDD... ele é um meio de especificar o sistema através de
>>> testes, e de quebra vc ganha um monte de testes automatizados pra rodar
>>> sempre que quiser validar o funcionamento da coisa.
>> --
>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>> hospedado no Google Groups.
>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>> Para sair do grupo envie uma mensagem para
>> mailto:dotnetarchitects%2Bunsubscribe@googlegroups.com<dotnetarchitects%2Bu nsubscribe@googlegroups.com>
> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitects+unsubscribe@googlegroups.com
> Para mais opções visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br
> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitects+unsubscribe@googlegroups.com
> Para mais opções visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br
Em desenvolvimento de interface web rica, usei apenas jQuery e strings HTML, fazendo manipulação dos elementos do DOM. Ficou super legal e simples de entender, compatível com todos os navegadores, etc.
Então chegou um outro dev do time, insistindo que eu deveria rescrever aquilo usando o framework Knockout (um framework de templating e MVVM para javascript e HTML). Que todos deveriam usar o Knockout, que aquilo era o certo. Bom, eu não gosto desse tipo de coisa, quando um dev vende a preferência PESSOAL dele como “best practice”. Não é best practice nada. É apenas preferência pessoal. Eu não usando a biblioteca inclusive defendo o meu código do fato da biblioteca não ser mais mantida no futuro (como aconteceu com o JQuery templates).
Abraços
From: Leo D Sent: Friday, June 22, 2012 10:23 AM
To: dotnetarchitects@googlegroups.com Subject: Re: [dotnetarchitects] Re: Como parei de escrever códigos incríveis!
Daniel, penso eu:
- Abstrações desnecessárias
- Defender-se de um futuro que ninguém sabe como vai ser (big design upfront)
- Interfaces e injeção de dependência a dar com pau, sem necessidade
- Cobertura de testes de unidade excessivamente alta
Abraços,
From: Daniel Moreira Yokoyama Sent: Friday, June 22, 2012 10:21 AM
To: dotnetarchitects@googlegroups.com Subject: Re: [dotnetarchitects] Re: Como parei de escrever códigos incríveis!
Me esclareça por favor, o que é florear o código. Colocar corações como pingos nos i's?
Em 22 de junho de 2012 10:16, Thiago C. Santos <thiago.csantos...@gmail.com> escreveu:
Daniel, me diz quando eu disse que você deve entregar algo que não funcione, sem ter feito testes e cheio de bugs?
Falei que você pode entregar algo sem florear tanto (Quando o código já esta funcional porem poderia estar melhor) e atender ao prazo.
Att,
Thiago C. Santos
2012/6/22 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
Que vantagem haverá nisso? Me mostre em que cenário o cliente prefere receber no prazo algo que simplesmente não atenda suas necessidades, não funcione como esperado.
Agora, de que forma você pode garantir que o que está sendo feito funciona de verdade sem uma boa cobertura de testes. Nem estou falando necessariamente de TDD... ele é um meio de especificar o sistema através de testes, e de quebra vc ganha um monte de testes automatizados pra rodar sempre que quiser validar o funcionamento da coisa.
-- Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetarchitects@googlegroups.com Para sair do grupo envie uma mensagem para mailto:dotnetarchitects%2Bunsubscribe@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
-- Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetarchitects@googlegroups.com Para sair do grupo envie uma mensagem para dotnetarchitects+unsubscribe@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
Vou ter que fazer uma citação do Elemar: Boas práticas são aquelas que
diminuem o TCO... ou seja, ou reduzem o custo do desenvolvimento, ou da
manutenção.
> Daniel, se você acha que só existem 2 ou 3 tipos de contexto e que todo
> boa pratica deve ser aplicada em todo projeto, realmente não podemos
> prosseguir...
> Se você não conseguiu compreender oque eu escrevi vou deixar mais claro,
> quando digo que algo deve ser feito por que o contexto exige é que o
> desenvolvedor não deve por imaturidade inserir toda e qualquer tipo de boa
> pratica no projeto sendo que o projeto não exige isso. Somente isso, não
> citei nada de projetos que seram usado somente uma vez...
> Att,
> Thiago C. Santos
> 2012/6/22 Thiago C. Santos <thiago.csantos...@gmail.com>
>> Daniel, me diz quando eu disse que você deve entregar algo que não
>> funcione, sem ter feito testes e cheio de bugs?
>> Falei que você pode entregar algo sem florear tanto (Quando o código já
>> esta funcional porem poderia estar melhor) e atender ao prazo.
>> Att,
>> Thiago C. Santos
>> 2012/6/22 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>>> Que vantagem haverá nisso? Me mostre em que cenário o cliente prefere
>>> receber no prazo algo que simplesmente não atenda suas necessidades, não
>>> funcione como esperado.
>>> Agora, de que forma você pode garantir que o que está sendo feito
>>> funciona de verdade sem uma boa cobertura de testes. Nem estou falando
>>> necessariamente de TDD... ele é um meio de especificar o sistema através de
>>> testes, e de quebra vc ganha um monte de testes automatizados pra rodar
>>> sempre que quiser validar o funcionamento da coisa.
> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitects+unsubscribe@googlegroups.com
> Para mais opções visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br
Mas o mundo não é tão preto-no-branco assim. Há vários clientes que
precisam que o sistema esteja implantado seja como for, até o fim do
semestre pois este milestone alcançado serve como alicerce da avaliação de
performance e por conseguinte, serve para calcular a PLR. E mais. Muitas
empresas preferem entregar o sistema mesmo falho para poder emitir a nota e
pagar o 13o. salário da galera, seja a primeira parcela, seja a segunda.
E mais: muitas consultorias adoram fazer coisas com problemas que
necessitem de bastante manutenção - elas tentam entrar no core business do
cliente, de forma que ele dependa do fornecedor para sempre para fazer a
manutenção do código.
Isso é tudo muito, muito triste. Mas é um cenário muito comum. Infelizmente.
2012/6/22 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
> O prazo não é tão importante para o cliente, se o que será entregue não
> funciona.
> Que vantagem haverá nisso? Me mostre em que cenário o cliente prefere
> receber no prazo algo que simplesmente não atenda suas necessidades, não
> funcione como esperado.
> Agora, de que forma você pode garantir que o que está sendo feito funciona
> de verdade sem uma boa cobertura de testes. Nem estou falando
> necessariamente de TDD... ele é um meio de especificar o sistema através de
> testes, e de quebra vc ganha um monte de testes automatizados pra rodar
> sempre que quiser validar o funcionamento da coisa.
> Isso pra mim é um valor inegociável de qualidade por que simplesmente me
> garante que o que está sendo feito, funciona. Eu nem gosto do termo "livre
> de bugs", por que sempre tem alguns equívocos. Mas estes também estão ali,
> presentes nos testes. Os testes lhe dirão o que o sistema faz.
> Se o cliente perguntar "Por que tal coisa está acontecendo sempre que eu
> clico neste botão", você terá provavelmente terá um teste que deixará claro
> o que acontece e o cliente poderá lhe dizer: "Ah, mas isto não deveria
> acontecer."
> E aí você sabe exatamente que teste deve mudar, como deve mudar, e ele vai
> quebrar quando você fizer as alterações, até que você corrija o código.
> Veja quanta coisa você consegue ter em mãos simplesmente por que se
> preocupou com a qualidade.
> Mas tem mais uma parte... Custo: O cliente na grande maioria das vezes não
> precisa pagar mais do que o que foi combinado para ter valor de negócio.
> Esta é a proposta do lean. Isto não compromete a qualidade. Só abre mão de
> coisas que, talvez, não fossem tão necessárias assim. Ou, ainda que sejam
> necessárias (por exemplo, ferramentas de monitoramento do produto,
> métricas, etc) não vão deixar o cliente sem usufruir do benefício
> estratégico que o produto lhe dará.
> Eu volto a dizer: prometer pro cliente que algo vai ficar pronto antes de
> ficar de fato, não vai deixá-lo mais satisfeito por que entregou antes algo
> que não estava pronto entregando o mínimo de valor suficiente para que ele
> tire real benefício daquilo. Não adianta entregar a sopa, se você não
> entregar uma colher.
> É necessário ressaltar, normalmente, o meu cliente sempre está ciente dos
> atrasos, o que os causou e este tipo de transparência o coloca a par das
> coisas a ponto de não haver insatisfação com os atrasos. Ele sabe o que
> quer, e está vendo ali que o que quer não funciona como queria, esta é a
> forma mais assertiva de fazer com que atrasos sejam aceitáveis, não é de
> hoje que sabemos disto: leve o cliente junto com você. Deixe-o saber o que
> acontece no projeto.
> Atrasos não acontecem da noite para o dia. Eles são consequência de
> situações inesperadas. Deixe-as claras para o cliente. Isto funciona muito
> melhor do que simplesmente falhar na entrega do sprint. Ninguém que chega
> no sprint sem ter todas as estórias que se comprometeu a entregar descobriu
> isso no dia anterior.
> Eu não consigo lembrar de nenhum atraso em entregas nos meus projetos
> recentes que tenham estressado o cliente. Sempre na hora da apresentação
> ele já estava previamente ciente das dificuldades e isso sempre fez com que
> ele não ficasse surpreso ao saber que tal coisa não pôde ser entregue. É
> muito importante isto. Deixar o cliente por dentro do que acontece no
> projeto faz com que os atrasos não prejudiquem sua expectativa. Melhor
> ainda, dá ao cliente a possibilidade de se armar estrategicamente.
> Em 22 de junho de 2012 09:07, Thiago C. Santos <
> thiago.csantos...@gmail.com> escreveu:
>> Daniel, como você diz que ta preocupado com a qualidade e você prefere
>> não cumprir o prazo para fazer algo do jeito que você acha que deve ser
>> feito? Sendo que podia entregar no prazo so que não seria algo tão "bom"mas
>> que poderia arrumar depois.
>> Você fala de qualidade so visando o código, você esta falando da visão de
>> um desenvolvedor, mas para o cliente se você compromete o prazo não esta
>> executando o projeto com qualidade.
>> Alias, a maioria aqui esta falando de qualidade so visando o código...
>> PRAZO
>> Tem muita coisa mais importante para o cliente do que o código em si, ele
>> pode esperar o projeto em tal dia e ele realmente precisa do projeto tal
>> dia, então você não vai entregar por que você acha que tem que florear
>> ainda mais o projeto?
>> CUSTO
>> Se você vai levar mais tempo para executar as tarefar do projeto isso vai
>> demandar custo, e ai quem vai pagar? A empresa desenvolvedora ou o cliente?
>> Seja o que for a qualidade do PROJETO esta comprometida.
>> obs: Acho que as necessidades do cliente como CUSTO e PRAZO são mais
>> interessantes para definir a qualidade do projeto do que o código em si,
>> não estou dizendo que o código pode ficar ruim desde que se cumpra isso...
>>> Eu acho que os três primeiros que o Mário colocou são ótimos.
>>> Adicionaria a simplicidade (que talvez esteja no segundo item). Acho que
>>> em nome de 'boas práticas’ frequentemente vemos uma engenharia exagerada
>>> nos códigos. E acho que código bom não precisa ser complexo, não precisa
>>> usar X ou Y só porque aquilo está quente na comunidade. Basta que o
>>> software atenda aos requisitos, seja fácil de manter e tenha um mínimo de
>>> bugs ou nenhum.
>>> []s
>>> *From:* Mário Meyrelles <mariomeyrel...@gmail.com>
>>> *Sent:* Friday, June 22, 2012 8:30 AM
>>> *To:* dotnetarchitects@googlegroups.com
>>> *Subject:* Re: [dotnetarchitects] Re: Como parei de escrever códigos
>>> incríveis!
>>> Para mim, qualidade é:
>>> 0) Software sem bugs.
>>> 1) Código com baixa barreira de entrada para novos desenvolvedores, isto
>>> é, código legível que siga os padrões mais conhecidos de mercado.
>>> 2) Código com facilidade de manter e evoluir.
>>> ...
>>> 200) Beleza estética do código (nomes, organização, etc...)
>>>> Galera, o que é "qualidade" pra vocês? Eu acho que é possível fazer
>>>> código muito bem feito sem qualidade (leia-se: código bonito), e eu acho
>>>> que é o que mais acontece nos melhores produtos. Parece vivermos uma época
>>>> parnasiana da programação, do código pelo código e da estética e eu não sei
>>>> bem se concordo com isso.
>>>> Em 21 de junho de 2012 21:40, Robson Castilho <
>>>> robsoncasti...@yahoo.com.br> escreveu:
>>>> Daniel:
>>>>> Mais uma vez corretíssimo. Eu fico 100x mais incomodado com a
>>>>> qualidade da entrega do que com prazo (isto não quer dizer que eu
>>>>> despreze o último)...
>>>>> Gerson:
>>>>> Nem todas. Aqui a empresa se preocupa com qualidade sim, porque eles
>>>>> sabem que estão perdendo e já perderam muito dinheiro com manutenção
>>>>> de software porco...Temos que ir mostrando que dói no bolso, que
>>>>> vários devs poderiam estar liberados para projetos e funcionalidades
>>>>> novas (mais $$$) ao invés de ficarem a maior parte do tempo apagando
>>>>> incêndio...
>>>>> E para todos:
>>>>> Vejo muitos devs argumentando muito em cima de prazo, prazo, prazo e
>>>>> pouco em favor de qualidade, qualidade, qualidade...
>>>>> Onde fica a qualidade no meio disso tudo?
>>>>> De onde vem esse bicho chamado prazo? Quem o definiu? Por que? Com
>>>>> qual propósito? De onde tiraram aquela data? Essas respostas tem que
>>>>> estar claras (não vale resposta de um gerente dizendo que quer o bônus
>>>>> dele até aquela data pra ele trocar de carro). Havendo uma real
>>>>> necessidade de se entregar naquela data, os devs vão poder elaborar
>>>>> melhor uma solução, quem sabe mexer no escopo para entregar naquela
>>>>> data mantendo qualidade. Transparência ajuda bastante nesses casos...
>>>>> []s a todos.
>>>>> On Jun 21, 6:36 pm, Daniel Moreira Yokoyama
>>>>> <moreira.yokoy...@gmail.com> wrote:
>>>>> > Só para que conste, quando eu digo que não é problema meu se houver
>>>>> algum
>>>>> > problema com atrasos, eu não quero dizer que sou inflexível com o
>>>>> cliente,
>>>>> > o que eu quero dizer é que as pessoas que se
> O Leo, respondeu por mim... alem do desenvolvedor ficar refatorando,
> refatorando, refatorando, refatorando, refatorando, refatorando o que já
> esta muito bom!
>> Daniel, penso eu:
>> - Abstrações desnecessárias
>> - Defender-se de um futuro que ninguém sabe como vai ser (big design
>> upfront)
>> - Interfaces e injeção de dependência a dar com pau, sem necessidade
>> - Cobertura de testes de unidade excessivamente alta
>> Abraços,
>> *From:* Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>> *Sent:* Friday, June 22, 2012 10:21 AM
>> *To:* dotnetarchitects@googlegroups.com
>> *Subject:* Re: [dotnetarchitects] Re: Como parei de escrever códigos
>> incríveis!
>> Me esclareça por favor, o que é florear o código. Colocar corações como
>> pingos nos i's?
>> Em 22 de junho de 2012 10:16, Thiago C. Santos <
>> thiago.csantos...@gmail.com> escreveu:
>>> Daniel, me diz quando eu disse que você deve entregar algo que não
>>> funcione, sem ter feito testes e cheio de bugs?
>>> Falei que você pode entregar algo sem florear tanto (Quando o código já
>>> esta funcional porem poderia estar melhor) e atender ao prazo.
>>> Att,
>>> Thiago C. Santos
>>> 2012/6/22 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>>>> Que vantagem haverá nisso? Me mostre em que cenário o cliente prefere
>>>> receber no prazo algo que simplesmente não atenda suas necessidades, não
>>>> funcione como esperado.
>>>> Agora, de que forma você pode garantir que o que está sendo feito
>>>> funciona de verdade sem uma boa cobertura de testes. Nem estou falando
>>>> necessariamente de TDD... ele é um meio de especificar o sistema através de
>>>> testes, e de quebra vc ganha um monte de testes automatizados pra rodar
>>>> sempre que quiser validar o funcionamento da coisa.
>>> --
>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>> hospedado no Google Groups.
>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>>> Para sair do grupo envie uma mensagem para
>>> mailto:dotnetarchitects%2Bunsubscribe@googlegroups.com<dotnetarchitects%2Bu nsubscribe@googlegroups.com>
>> --
>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>> hospedado no Google Groups.
>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>> Para sair do grupo envie uma mensagem para
>> dotnetarchitects+unsubscribe@googlegroups.com
>> Para mais opções visite o grupo em
>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>> --
>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>> hospedado no Google Groups.
>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>> Para sair do grupo envie uma mensagem para
>> dotnetarchitects+unsubscribe@googlegroups.com
>> Para mais opções visite o grupo em
>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitects+unsubscribe@googlegroups.com
> Para mais opções visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br
Só tem uma coisa a ser dita pra quem vive esse tipo de realidade: get out!
Ninguém é obrigado a ficar em empresas assim. Os que vivem nesse mundo só
estão lá por que querem. E quando deixarem de querer vão descobrir o
maravilhoso recurso de desligamento.
> Mas o mundo não é tão preto-no-branco assim. Há vários clientes que
> precisam que o sistema esteja implantado seja como for, até o fim do
> semestre pois este milestone alcançado serve como alicerce da avaliação de
> performance e por conseguinte, serve para calcular a PLR. E mais. Muitas
> empresas preferem entregar o sistema mesmo falho para poder emitir a nota e
> pagar o 13o. salário da galera, seja a primeira parcela, seja a segunda.
> E mais: muitas consultorias adoram fazer coisas com problemas que
> necessitem de bastante manutenção - elas tentam entrar no core business do
> cliente, de forma que ele dependa do fornecedor para sempre para fazer a
> manutenção do código.
> Isso é tudo muito, muito triste. Mas é um cenário muito comum.
> Infelizmente.
> 2012/6/22 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>> Poxa, Thiago. Eu odeio parecer repetitivo.
>> O prazo não é tão importante para o cliente, se o que será entregue não
>> funciona.
>> Que vantagem haverá nisso? Me mostre em que cenário o cliente prefere
>> receber no prazo algo que simplesmente não atenda suas necessidades, não
>> funcione como esperado.
>> Agora, de que forma você pode garantir que o que está sendo feito
>> funciona de verdade sem uma boa cobertura de testes. Nem estou falando
>> necessariamente de TDD... ele é um meio de especificar o sistema através de
>> testes, e de quebra vc ganha um monte de testes automatizados pra rodar
>> sempre que quiser validar o funcionamento da coisa.
>> Isso pra mim é um valor inegociável de qualidade por que simplesmente me
>> garante que o que está sendo feito, funciona. Eu nem gosto do termo "livre
>> de bugs", por que sempre tem alguns equívocos. Mas estes também estão ali,
>> presentes nos testes. Os testes lhe dirão o que o sistema faz.
>> Se o cliente perguntar "Por que tal coisa está acontecendo sempre que eu
>> clico neste botão", você terá provavelmente terá um teste que deixará claro
>> o que acontece e o cliente poderá lhe dizer: "Ah, mas isto não deveria
>> acontecer."
>> E aí você sabe exatamente que teste deve mudar, como deve mudar, e ele
>> vai quebrar quando você fizer as alterações, até que você corrija o código.
>> Veja quanta coisa você consegue ter em mãos simplesmente por que se
>> preocupou com a qualidade.
>> Mas tem mais uma parte... Custo: O cliente na grande maioria das vezes
>> não precisa pagar mais do que o que foi combinado para ter valor de
>> negócio. Esta é a proposta do lean. Isto não compromete a qualidade. Só
>> abre mão de coisas que, talvez, não fossem tão necessárias assim. Ou, ainda
>> que sejam necessárias (por exemplo, ferramentas de monitoramento do
>> produto, métricas, etc) não vão deixar o cliente sem usufruir do benefício
>> estratégico que o produto lhe dará.
>> Eu volto a dizer: prometer pro cliente que algo vai ficar pronto antes de
>> ficar de fato, não vai deixá-lo mais satisfeito por que entregou antes algo
>> que não estava pronto entregando o mínimo de valor suficiente para que ele
>> tire real benefício daquilo. Não adianta entregar a sopa, se você não
>> entregar uma colher.
>> É necessário ressaltar, normalmente, o meu cliente sempre está ciente dos
>> atrasos, o que os causou e este tipo de transparência o coloca a par das
>> coisas a ponto de não haver insatisfação com os atrasos. Ele sabe o que
>> quer, e está vendo ali que o que quer não funciona como queria, esta é a
>> forma mais assertiva de fazer com que atrasos sejam aceitáveis, não é de
>> hoje que sabemos disto: leve o cliente junto com você. Deixe-o saber o que
>> acontece no projeto.
>> Atrasos não acontecem da noite para o dia. Eles são consequência de
>> situações inesperadas. Deixe-as claras para o cliente. Isto funciona muito
>> melhor do que simplesmente falhar na entrega do sprint. Ninguém que chega
>> no sprint sem ter todas as estórias que se comprometeu a entregar descobriu
>> isso no dia anterior.
>> Eu não consigo lembrar de nenhum atraso em entregas nos meus projetos
>> recentes que tenham estressado o cliente. Sempre na hora da apresentação
>> ele já estava previamente ciente das dificuldades e isso sempre fez com que
>> ele não ficasse surpreso ao saber que tal coisa não pôde ser entregue. É
>> muito importante isto. Deixar o cliente por dentro do que acontece no
>> projeto faz com que os atrasos não prejudiquem sua expectativa. Melhor
>> ainda, dá ao cliente a possibilidade de se armar estrategicamente.
>> Em 22 de junho de 2012 09:07, Thiago C. Santos <
>> thiago.csantos...@gmail.com> escreveu:
>>> Daniel, como você diz que ta preocupado com a qualidade e você prefere
>>> não cumprir o prazo para fazer algo do jeito que você acha que deve ser
>>> feito? Sendo que podia entregar no prazo so que não seria algo tão "bom"mas
>>> que poderia arrumar depois.
>>> Você fala de qualidade so visando o código, você esta falando da visão
>>> de um desenvolvedor, mas para o cliente se você compromete o prazo não esta
>>> executando o projeto com qualidade.
>>> Alias, a maioria aqui esta falando de qualidade so visando o código...
>>> PRAZO
>>> Tem muita coisa mais importante para o cliente do que o código em si,
>>> ele pode esperar o projeto em tal dia e ele realmente precisa do projeto
>>> tal dia, então você não vai entregar por que você acha que tem que florear
>>> ainda mais o projeto?
>>> CUSTO
>>> Se você vai levar mais tempo para executar as tarefar do projeto isso
>>> vai demandar custo, e ai quem vai pagar? A empresa desenvolvedora ou o
>>> cliente? Seja o que for a qualidade do PROJETO esta comprometida.
>>> obs: Acho que as necessidades do cliente como CUSTO e PRAZO são mais
>>> interessantes para definir a qualidade do projeto do que o código em si,
>>> não estou dizendo que o código pode ficar ruim desde que se cumpra isso...
>>>> Eu acho que os três primeiros que o Mário colocou são ótimos.
>>>> Adicionaria a simplicidade (que talvez esteja no segundo item). Acho
>>>> que em nome de 'boas práticas’ frequentemente vemos uma engenharia
>>>> exagerada nos códigos. E acho que código bom não precisa ser complexo, não
>>>> precisa usar X ou Y só porque aquilo está quente na comunidade. Basta que o
>>>> software atenda aos requisitos, seja fácil de manter e tenha um mínimo de
>>>> bugs ou nenhum.
>>>> []s
>>>> *From:* Mário Meyrelles <mariomeyrel...@gmail.com>
>>>> *Sent:* Friday, June 22, 2012 8:30 AM
>>>> *To:* dotnetarchitects@googlegroups.com
>>>> *Subject:* Re: [dotnetarchitects] Re: Como parei de escrever códigos
>>>> incríveis!
>>>> Para mim, qualidade é:
>>>> 0) Software sem bugs.
>>>> 1) Código com baixa barreira de entrada para novos desenvolvedores,
>>>> isto é, código legível que siga os padrões mais conhecidos de mercado.
>>>> 2) Código com facilidade de manter e evoluir.
>>>> ...
>>>> 200) Beleza estética do código (nomes, organização, etc...)
>>>>> Galera, o que é "qualidade" pra vocês? Eu acho que é possível fazer
>>>>> código muito bem feito sem qualidade (leia-se: código bonito), e eu acho
>>>>> que é o que mais acontece nos melhores produtos. Parece vivermos uma época
>>>>> parnasiana da programação, do código pelo código e da estética e eu não sei
>>>>> bem se concordo com isso.
>>>>> Em 21 de junho de 2012 21:40, Robson Castilho <
>>>>> robsoncasti...@yahoo.com.br> escreveu:
>>>>> Daniel:
>>>>>> Mais uma vez corretíssimo. Eu fico 100x mais incomodado com a
>>>>>> qualidade da entrega do que com prazo (isto não quer dizer que eu
>>>>>> despreze o último)...
>>>>>> Gerson:
>>>>>> Nem todas. Aqui a empresa se preocupa com qualidade sim, porque eles
>>>>>> sabem que estão perdendo e já perderam muito dinheiro com manutenção
>>>>>> de software porco...Temos que ir mostrando que dói no bolso, que
>>>>>> vários devs poderiam estar liberados para projetos e funcionalidades
>>>>>> novas (mais $$$) ao invés de ficarem a maior parte do tempo apagando
>>>>>> incêndio...
>>>>>> E para todos:
>>>>>> Vejo muitos devs argumentando muito em cima de prazo, prazo, prazo e
>>>>>> pouco em favor de qualidade, qualidade, qualidade...
>>>>>> Onde fica a qualidade no meio disso
É o que o Mário Meyrelles falou, tem cliente aberto a negociar prazo e tem
cliente que aplica multa se você não cumprir... Este é um otimo exemplo de
contexto diferentes em projetos...
Att,
Thiago C. Santos
2012/6/22 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
> Em 22 de junho de 2012 10:27, Thiago C. Santos <
> thiago.csantos...@gmail.com> escreveu:
>> O Leo, respondeu por mim... alem do desenvolvedor ficar refatorando,
>> refatorando, refatorando, refatorando, refatorando, refatorando o que já
>> esta muito bom!
>>> Daniel, penso eu:
>>> - Abstrações desnecessárias
>>> - Defender-se de um futuro que ninguém sabe como vai ser (big design
>>> upfront)
>>> - Interfaces e injeção de dependência a dar com pau, sem necessidade
>>> - Cobertura de testes de unidade excessivamente alta
>>> Abraços,
>>> *From:* Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>>> *Sent:* Friday, June 22, 2012 10:21 AM
>>> *To:* dotnetarchitects@googlegroups.com
>>> *Subject:* Re: [dotnetarchitects] Re: Como parei de escrever códigos
>>> incríveis!
>>> Me esclareça por favor, o que é florear o código. Colocar corações como
>>> pingos nos i's?
>>> Em 22 de junho de 2012 10:16, Thiago C. Santos <
>>> thiago.csantos...@gmail.com> escreveu:
>>>> Daniel, me diz quando eu disse que você deve entregar algo que não
>>>> funcione, sem ter feito testes e cheio de bugs?
>>>> Falei que você pode entregar algo sem florear tanto (Quando o código já
>>>> esta funcional porem poderia estar melhor) e atender ao prazo.
>>>> Att,
>>>> Thiago C. Santos
>>>> 2012/6/22 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>>>>> Que vantagem haverá nisso? Me mostre em que cenário o cliente prefere
>>>>> receber no prazo algo que simplesmente não atenda suas necessidades, não
>>>>> funcione como esperado.
>>>>> Agora, de que forma você pode garantir que o que está sendo feito
>>>>> funciona de verdade sem uma boa cobertura de testes. Nem estou falando
>>>>> necessariamente de TDD... ele é um meio de especificar o sistema através de
>>>>> testes, e de quebra vc ganha um monte de testes automatizados pra rodar
>>>>> sempre que quiser validar o funcionamento da coisa.
>>>> --
>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>>> hospedado no Google Groups.
>>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>>>> Para sair do grupo envie uma mensagem para
>>>> mailto:dotnetarchitects%2Bunsubscribe@googlegroups.com<dotnetarchitects%2Bu nsubscribe@googlegroups.com>
>>> --
>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>> hospedado no Google Groups.
>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>>> Para sair do grupo envie uma mensagem para
>>> dotnetarchitects+unsubscribe@googlegroups.com
>>> Para mais opções visite o grupo em
>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>> --
>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>> hospedado no Google Groups.
>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>>> Para sair do grupo envie uma mensagem para
>>> dotnetarchitects+unsubscribe@googlegroups.com
>>> Para mais opções visite o grupo em
>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>> --
>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>> hospedado no Google Groups.
>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>> Para sair do grupo envie uma mensagem para
>> dotnetarchitects+unsubscribe@googlegroups.com
>> Para mais opções visite o grupo em
>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitects+unsubscribe@googlegroups.com
> Para mais opções visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br
Aí volta na discussão antiga e recorrente de uma outra thread recente daqui.
Se você souber de empresas que tenham:
1) Projetos legais
2) Ambiente legal / condições de trabalho ideais / pessoas competentes
3) Continuidade (ist est, posso pensar em ficar na empresa por anos e anos
e sei que não vou ser mandado embora por falta de projetos)
4) Salário bom
Peço gentilmente que me indique rs. Aliás, nem precisa me indicar - só
coloca aqui o nome das empresas!
Sds
Mário
2012/6/22 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
> Só tem uma coisa a ser dita pra quem vive esse tipo de realidade: get out!
> Ninguém é obrigado a ficar em empresas assim. Os que vivem nesse mundo só
> estão lá por que querem. E quando deixarem de querer vão descobrir o
> maravilhoso recurso de desligamento.
> Em 22 de junho de 2012 10:28, Mário Meyrelles <mariomeyrel...@gmail.com>escreveu:
> Idealmente eu concordo com você Daniel.
>> Mas o mundo não é tão preto-no-branco assim. Há vários clientes que
>> precisam que o sistema esteja implantado seja como for, até o fim do
>> semestre pois este milestone alcançado serve como alicerce da avaliação de
>> performance e por conseguinte, serve para calcular a PLR. E mais. Muitas
>> empresas preferem entregar o sistema mesmo falho para poder emitir a nota e
>> pagar o 13o. salário da galera, seja a primeira parcela, seja a segunda.
>> E mais: muitas consultorias adoram fazer coisas com problemas que
>> necessitem de bastante manutenção - elas tentam entrar no core business do
>> cliente, de forma que ele dependa do fornecedor para sempre para fazer a
>> manutenção do código.
>> Isso é tudo muito, muito triste. Mas é um cenário muito comum.
>> Infelizmente.
>> 2012/6/22 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
>>> Poxa, Thiago. Eu odeio parecer repetitivo.
>>> O prazo não é tão importante para o cliente, se o que será entregue não
>>> funciona.
>>> Que vantagem haverá nisso? Me mostre em que cenário o cliente prefere
>>> receber no prazo algo que simplesmente não atenda suas necessidades, não
>>> funcione como esperado.
>>> Agora, de que forma você pode garantir que o que está sendo feito
>>> funciona de verdade sem uma boa cobertura de testes. Nem estou falando
>>> necessariamente de TDD... ele é um meio de especificar o sistema através de
>>> testes, e de quebra vc ganha um monte de testes automatizados pra rodar
>>> sempre que quiser validar o funcionamento da coisa.
>>> Isso pra mim é um valor inegociável de qualidade por que simplesmente me
>>> garante que o que está sendo feito, funciona. Eu nem gosto do termo "livre
>>> de bugs", por que sempre tem alguns equívocos. Mas estes também estão ali,
>>> presentes nos testes. Os testes lhe dirão o que o sistema faz.
>>> Se o cliente perguntar "Por que tal coisa está acontecendo sempre que eu
>>> clico neste botão", você terá provavelmente terá um teste que deixará claro
>>> o que acontece e o cliente poderá lhe dizer: "Ah, mas isto não deveria
>>> acontecer."
>>> E aí você sabe exatamente que teste deve mudar, como deve mudar, e ele
>>> vai quebrar quando você fizer as alterações, até que você corrija o código.
>>> Veja quanta coisa você consegue ter em mãos simplesmente por que se
>>> preocupou com a qualidade.
>>> Mas tem mais uma parte... Custo: O cliente na grande maioria das vezes
>>> não precisa pagar mais do que o que foi combinado para ter valor de
>>> negócio. Esta é a proposta do lean. Isto não compromete a qualidade. Só
>>> abre mão de coisas que, talvez, não fossem tão necessárias assim. Ou, ainda
>>> que sejam necessárias (por exemplo, ferramentas de monitoramento do
>>> produto, métricas, etc) não vão deixar o cliente sem usufruir do benefício
>>> estratégico que o produto lhe dará.
>>> Eu volto a dizer: prometer pro cliente que algo vai ficar pronto antes
>>> de ficar de fato, não vai deixá-lo mais satisfeito por que entregou antes
>>> algo que não estava pronto entregando o mínimo de valor suficiente para que
>>> ele tire real benefício daquilo. Não adianta entregar a sopa, se você não
>>> entregar uma colher.
>>> É necessário ressaltar, normalmente, o meu cliente sempre está ciente
>>> dos atrasos, o que os causou e este tipo de transparência o coloca a par
>>> das coisas a ponto de não haver insatisfação com os atrasos. Ele sabe o que
>>> quer, e está vendo ali que o que quer não funciona como queria, esta é a
>>> forma mais assertiva de fazer com que atrasos sejam aceitáveis, não é de
>>> hoje que sabemos disto: leve o cliente junto com você. Deixe-o saber o que
>>> acontece no projeto.
>>> Atrasos não acontecem da noite para o dia. Eles são consequência de
>>> situações inesperadas. Deixe-as claras para o cliente. Isto funciona muito
>>> melhor do que simplesmente falhar na entrega do sprint. Ninguém que chega
>>> no sprint sem ter todas as estórias que se comprometeu a entregar descobriu
>>> isso no dia anterior.
>>> Eu não consigo lembrar de nenhum atraso em entregas nos meus projetos
>>> recentes que tenham estressado o cliente. Sempre na hora da apresentação
>>> ele já estava previamente ciente das dificuldades e isso sempre fez com que
>>> ele não ficasse surpreso ao saber que tal coisa não pôde ser entregue. É
>>> muito importante isto. Deixar o cliente por dentro do que acontece no
>>> projeto faz com que os atrasos não prejudiquem sua expectativa. Melhor
>>> ainda, dá ao cliente a possibilidade de se armar estrategicamente.
>>> Em 22 de junho de 2012 09:07, Thiago C. Santos <
>>> thiago.csantos...@gmail.com> escreveu:
>>>> Daniel, como você diz que ta preocupado com a qualidade e você prefere
>>>> não cumprir o prazo para fazer algo do jeito que você acha que deve ser
>>>> feito? Sendo que podia entregar no prazo so que não seria algo tão "bom"mas
>>>> que poderia arrumar depois.
>>>> Você fala de qualidade so visando o código, você esta falando da visão
>>>> de um desenvolvedor, mas para o cliente se você compromete o prazo não esta
>>>> executando o projeto com qualidade.
>>>> Alias, a maioria aqui esta falando de qualidade so visando o código...
>>>> PRAZO
>>>> Tem muita coisa mais importante para o cliente do que o código em si,
>>>> ele pode esperar o projeto em tal dia e ele realmente precisa do projeto
>>>> tal dia, então você não vai entregar por que você acha que tem que florear
>>>> ainda mais o projeto?
>>>> CUSTO
>>>> Se você vai levar mais tempo para executar as tarefar do projeto isso
>>>> vai demandar custo, e ai quem vai pagar? A empresa desenvolvedora ou o
>>>> cliente? Seja o que for a qualidade do PROJETO esta comprometida.
>>>> obs: Acho que as necessidades do cliente como CUSTO e PRAZO são mais
>>>> interessantes para definir a qualidade do projeto do que o código em si,
>>>> não estou dizendo que o código pode ficar ruim desde que se cumpra isso...
>>>>> Eu acho que os três primeiros que o Mário colocou são ótimos.
>>>>> Adicionaria a simplicidade (que talvez esteja no segundo item). Acho
>>>>> que em nome de 'boas práticas’ frequentemente vemos uma engenharia
>>>>> exagerada nos códigos. E acho que código bom não precisa ser complexo, não
>>>>> precisa usar X ou Y só porque aquilo está quente na comunidade. Basta que o
>>>>> software atenda aos requisitos, seja fácil de manter e tenha um mínimo de
>>>>> bugs ou nenhum.
>>>>> []s
>>>>> *From:* Mário Meyrelles <mariomeyrel...@gmail.com>
>>>>> *Sent:* Friday, June 22, 2012 8:30 AM
>>>>> *To:* dotnetarchitects@googlegroups.com
>>>>> *Subject:* Re: [dotnetarchitects] Re: Como parei de escrever códigos
>>>>> incríveis!
>>>>> Para mim, qualidade é:
>>>>> 0) Software sem bugs.
>>>>> 1) Código com baixa barreira de entrada para novos desenvolvedores,
>>>>> isto é, código legível que siga os padrões mais conhecidos de mercado.
>>>>> 2) Código com facilidade de manter e evoluir.
>>>>> ...
>>>>> 200) Beleza estética do código (nomes, organização, etc...)
>>>>>> Galera, o que é "qualidade" pra vocês? Eu acho que é possível fazer
>>>>>> código muito bem feito sem qualidade (leia-se: código bonito), e eu acho
>>>>>> que é o que mais acontece nos melhores produtos. Parece vivermos uma época
>>>>>> parnasiana da programação, do código pelo código e da estética e eu não sei
>>>>>> bem se concordo com isso.
>>>>>> Em 21 de junho de 2012 21:40, Robson Castilho <
>>>>>> robsoncasti...@yahoo.com.br> escreveu:
