Design é importante?

É sim. Design (bem feito) ajuda a evitar erros na hora de programar, além de servir de guia na hora de desenvolvimento, evitando que sejam criadas coisas que fujam do propósito do software desenvolvido. Mas, convenhamos: não é todo software que precisa passar por um processo de design.

Com certeza é!

Depende da natureza da aplicação q será desenvolvida…
Acho importante definir 1º a Usabilidade do seu projeto p/depois
pensar no design…se o seu projeto irá rodar no interior de algum
servidor sem nenhuma(ou quase) interação c/o usuário acho desnece
ssário pensar em design…o q vale aí é lógica pura de programação.
mas se vc tah fazendo uma pág p/net ou um cadastro q será frequentemente acessado/manipulado/modificado é essencial q o design seja atrativo ao usuário ou q ofereça uma boa interação visual com o mesmo. Pense na comunicabilidade da sua aplicação com o usuário.

Errr, qdo se fala em design de software, fala-se no projeto dele, e não no layout de um GUI, ou qualquer coisa relacionada a HCI.

Errr, qdo se fala em design de software, fala-se no projeto dele, e não no layout de um GUI, ou qualquer coisa relacionada a HCI.

:shock: Sério???
Nossa…atirei longe… :oops:
Meu prof de Multimídia,Interface Homem-Máq é uma m…mesmo…
Isso q vc fala(projetar um soft) eu faço na modelagem …
Desculpa,e esqueçam o post acima!!!Tava falando de aspectos
físicos do sistema e da interação da View c/o usuário…
Nada ver(…) :oops:

ola pessoal,

domingo e eu aqui trabalhando de novo… e o pior é que está muito frio…

uma outra questao sobre o assunto…

se vc é o responsavel pelo desenvolvimento de um modulo do sistema e alguem vem e te entrega uma especificaçao funcional e um prazo para entrega ainda assim vcs acham que eu, papel desenvolvedor, devo tentar algum design antes de sair programando… mesmo que seja o minimo possivel ?
Vale a pena tentar isso ?

Pergunto pois estou tento muitas dificuldades de sair fazendo…

Valeu,

Spiff

Sem um design inicial, aa dificuldades no decorrer do projeto, e consequentemente a perda de tempo refazendo trabalho, serao muito maiores do que se um planejamento inicial tivesse sido feito.
Eh chato? MUITO. Mas eh muito mais chato e desistimulante voce ter que ficar quebrando a cabeca para recosntruir coisas que poderiam ser previstas em tempo de projeto.

Com um design inicial voce ja consegue ter uma nocao muito melhor das necessidades, e consegue programar bem mais focado tambem. Nao precisa fazer detalhamento de tudo, querer prever cada minimo detalhe e classe, pois simplesmente nao tem como saber de antemao tudo o que sera necessario de uma maneira final.

O importante eh voce ter dominio do problema e da tecnologia com a qual esta trabalhando, pois sem isso fica mais complicado fazer analises reais. Depois, sinta-se livre para mudar coisas no decorrer do projeto, para mudar classes ou adicionar novas, desde que de uma maneira consistente ( e ai entra a diferenca entre ter e nao ter dominio do problema ).

Se voce nunca fez algum design/analise de requerimento/diagramas e afins, faca um esforco para pegar bem esta parte, pois com certeza seus sistemas ficarao melhores!!

Nesses casos eu geralmente faco um “mapinha” de como vou desenvolver. Nada formal ou que siga regras, mas sim anotacoes sobre como penso que o processo de desenvolvimento decorrera. Com essas simples anotacoes - lembrando que nao importa se vc faz um monte de desenhos ou anotacoes que parecam sem sentido para os outros; o importante eh voce entender - voce ja consegue ter uma ideia de como programar e caminho a seguir, ao inves de sair codando “na louca”.

Rafael

Ou, quer saber a verdade?? Engenharia de software é um saco. Mas desenhar o sistema nao precisa ser.

Com um papel e um lápis vc consegue fazer um design rápido e sem frescuras (como DRD, DFD, sei lá, esqueci os nomes). Enquanto vc desenha, vc vai falando (recomenda-se fazer em voz alta): “Hum, o cosmonauta Spiff acessa essa página, e aqui vai ter um DB com a informacao que ele precisa. Vai ter x, y, z servicos, e bla bla bla…”

Se ninguém quer ver seu design, entao faz um só pra vc. Como vc nao tem que agradar ninguém além de si mesmo, vc pode fazer do jeito que te faz enxergar bem o que vc precisa ver, com o nivel de detalhes que vc precisa pra pensar.

Claro, se vc é CIO, e vai coordenar varias pessoas, vc precisa de padroes para os rabiscos, pra que um consiga entender o rabisco dos outros. Daí vc inventa nomes bonitos para os padroes para os rabiscos, compra software que faz rabiscos muito mais bonitos nos mesmos padroes, e chama isso de Engenharia. Entendeu??

gostei da definição de engenharia de software

Rafael,

Eu tambem acho importante termos uma fase de design antes da construção. Porem no projeto em que estou trabalhando isso não é a regra e sim a excessão ! Nos modulos que fiz o levantamento e a parte funcional eu montei algum design pra me guiar e que acabou sendo util pois tive que repassar esse modulos para outras pessoas. Apesar de ter feito algo sem muita rigidez acabou sendo bastante util para que pegou o ‘bonde’ andando e com certeza nos irá poupar trabalho em futuras manutenções.

O que acabou ocorrendo é que acabei sendo ‘presenteado’ com um modulo complicadíssimo do sistema onde só foi feita uma funcional, alias nao muito completa, pois a pessoa que fez é que iria codificar e tal… e agora o tempo já passou e eu tenho perdido muito tempo tentando codificar sem algo para me guiar. Ontem eu parei e resolvi fazer um design bem simples para primeiro levantar as duvidas que tenho e ir me guiando na codificacao.

sair ‘codando’ nunca tinha ouvido

Duke,

a minha ideia é fazer algo simples, sem muita formalidade, mas que seja algo que de certa forma possa me ajudar a codificar e que sirva como uma documentação para manutenções futuras…

de uma forma geral seria muito util se isso tivesse sido feito na sua devida fase e de uma forma geral em todo o projeto… mas…

valeu pelos toques pessoal,

Spiff

Spiff Is god ? Are you on !

Acho importante o design, mas tem gente que “designa”, “designa” e nada.
Tem que levar tudo em conta : os prazos, a urgencia da implementação e tal … de repente é melhor cair com a mão na massa de uma vez, você pode até encontrar coisas que nunca iria imaginar, e as vezes é bom fazer um bom planejamento.
Já deparei com ambos os casos, então, acho que o mais importante é você equacionar design e mão-na-massa de acordo com a situação.

Eu acredito que bom design vem da prática, e não tem jeito melhor de desenhar uma aplicação do que metendo a mão na massa e refatorando até ficar bom.

Esse é um dos princípios básicos do TDD (Test-Driven Development), que, apesar de eu não seguir à risca, gosto (e uso) bastante. Refatorar é sempre mais rápido, e eficiente, no fim das contas, do que passar meses na frente de um editor de UML pra depois programar. A idéia é sempre fazer o design enquanto se está programando

UML é uma besta tão gigante que ainda ta para ser criado um projeto que use todos os 999999999 diagramas.

Por isso que sou adepto do SML, a starfield modeling language.

Até agora, não inventaram linguagem de modelagem melhor que a linguagem de Napkin.

É simples:

Voce vai almocar com o cara que precisa do sistema. Ele te explica tudo, e vc tem a ideia de como fazer na hora. Aí vc pega um guardanapo, rabisca e mostra pra ele, explicando como vc entendeu.

Ele vai falar “naaaaaaaaaaao, nao é assim”. E vc desenha outra coisa, e explica de novo. Até voces chegarem num consenso.

Fim do almoco, vc senta e faz. Fim.

Isso, claro, só funciona se vc tiver features bem pequenas e divididas no seu sistema. Mas funciona que é uma maravilha

Galera, descupem a ignorancia, mas o que é refatorar?

Até mais.

Galera, descupem a ignorancia, mas o que é refatorar?

Até mais.

Acabei de descobrir que ir no google e fazer uma pesquisa não faz mal a ninguem. Encontrei a seguinte (e clara) explicação para o que é refatorar.

É o processo de mudar um software de forma que o comportamento externo do código não seja alterado mesmo que sua estrutura interna seja incrementada. É o processo de reorganizar o projeto de um sistema para torná-lo mais flexível e/ou reusável.

Até mais.

Provavelmente a expressao veio da Matemática… vc mexe nos fatores que compoem seu sistema, sem mudar o produto… : ))

[]s!!

Po eu gosto tanto de engenharia de software… Nao sei porque a galera aki no gosta…

Abraços

Pessoal,

Pela definição de Refatorar, será que é melhor alterar um software já pronto ao invés de estudar e planejar a melhor forma de implementar ?
Acho que refatoração vai acabar sendo mais custosa.

Ivan.

Ivan, refatorar até chegar num ponto onde o design seja interessante é muitas vezes mais rápido do que fazer aquele puta design logo de cara, quando vc nao tem ainda todos os requisitos levantados.

Muitas vezes, é melhor chegar logo num release pra poder mostrar pro cliente se o seu código é mesmo o que ele quer do que se preocupar com retrabalhos. Pelo menos, quando vc faz um release, o cliente pode ver o que está acontecendo

Como já diziam…

Eu discordava um pouco dessa estratégia, mas hoje já acredito nela.
Fazendo uma coisa suficientemente pensada no começo (seprando bem os conceitos) fica relativamente fácil refatorar depois.

tem muitas discussoes a respeito disso. Depende de como vc pretende desenvolver seu produto.

Ainda vejo muito desenvolverem as coisas sem pensar no usuário do outro lado. Meu software mais usavel de todos foi um que teve um prototipo em Smalltalk, desenvolvido bem fake, sem pensar em nada. Quando as telas e as funcionalidades estavam boas, a gente jogou tudo fora e foi implementar na tecnologia escolhida (que eu nao vou mencionar pq nao é educado falar palavrao na mesa).

Quando vc tem certeza de que vc vai refatorar aquilo, mesmo reaproveitando uma parte do codigo, vc nao liga de nao fazer uma obra de arte naquilo, vc larga mais o código e termina bem antes. Daí vc pode usar esse tempo (que deve estar previsto) pra aplicar padroes, reescrever partes, jogar fora aquele remendo que vc fez e trocar por um código genérico, etc. Eu ainda gostaria de estar num projeto onde, passado tudo isso, ainda desse pra fazer fine tuning do código, observando eficiencia, essas coisas. Nunca me aconteceu, pq todos os prazos estouram e o que o cliente nao ve, o coracao (dele) nao sente.

[]s!!

Mais sobre Just-In-Time Design nesse artigo na DW:

http://www-106.ibm.com/developerworks/java/library/j-xp07013.html

ola pessoal…

pelo visto o topico deu o que falar…

qdo postei a pergunta falava em um pequeno design e nao em design imenso…

minha duvida é/era vale a pena pegar uma atividade de uma semana e de repente gastar dois dias fazendo um design ao invés de ir fazendo e ficar na tentativa/erro…

meu feeling diz que sim, q um design mesmo ‘pequeno’ e em ‘papel de pao’ tem alguma valia… mas vira e mexe me questiono isso… e tento ir pro tradicional…

tem um artigo interessante no site abaixo… vale a pena uma lida

http://brazil.joelonsoftware.com/Articles/NothingSimpleSeems.html

[]’

Spiff

try this … or not …

“louds”:

UML é uma besta tão gigante que ainda ta para ser criado um projeto que use todos os 999999999 diagramas.

Por isso que sou adepto do SML, a starfield modeling language.

todos sabem que eh dificil eu e o louds concordarmos em alguma coisa. mas aqui estou 100% com ele.

UML como documentacao e para msotrar para outroa pessoa, ou apra ESBOCAR as classes, com certeza.

agora tem empresa que o manager (que ja nao programa a seculos) da o UML para o programador fazer e tem de ser daquele jeito? Isso nao existe…! Bem, existe, mas imagina a “burocracia”! Programar é arte. Nao da para chegar e falar “Ei Da Vinci, pinta essa guria aqui, ja desenhei.”

Existe o outro lado da moeda entretanto.

UML também pode trabalhar ao seu favor. O diagrama de deployment, se lembro bem, é aquele para ser feito durante toda uma segunda daquelas que voce encarna o Garfield.

UML (digo todos aqueles 9 chatíssimos e burocráticos diagramas) é mais uma daquelas coisas cujo uso que atribuiram não é o mais adequado. É específicação demais que, no final, acabando atrapalhando o programador (como o Paulo disse, "Nao da para chegar e falar “Ei Da Vinci, pinta essa guria aqui, ja desenhei.” "). Mas, como documentação final de projeto (e como guia para auxiliar nas manutenções), UML é o que há de melhor ainda.
Especificações e design devem ser feitos da maneira mais simples possível para que o programador possa conseguir traduzir a vontade do cliente com a maior liberdade possível para criar (arte).

EDITADO: que post mais acaciano!! IGNOREM ISSO, por favor

Eu acho que vocês estão sendo um pouco radicais nessa idéia de “Programar é arte”. Pode parecer absurdo falar pro Da Vinci pintar a guria já desenhada, mas não seria pedir para o cara que colore as histórias em quadrinhos.
No mercado existem todos os tipos de programadores, e com o crescimento do modelo de fábrica de software a tendência é ter o analista fazendo o design em UML e o programador implementando os detalhes no código.

Então se você está em um projeto em que todos tem o conhecimento e experiência necessárias para fazer algo decente sem um design detalhado, tudo bem, mas se é um projeto grande com pessoas mais inexperientes, a UML pode ajudar muito.

Aí é que está, Bani: essas técnicas favorecem o uso de programadores inexperientes sem habilidade criativa no desenvolvimento.

Daí acontece um dos fenomenos mais danosos para o bom cumprimento de um projeto: a perda de informacao. Existe o ótimo, que é o que o cliente precisa. Logo abaixo na escala de importancia vem o que o cliente quer. Se atendermos até aí já tá bom. O terceiro lugar fica com o malhor que o fábrica consegue produzir baseado nas informacoes recebidas. Em quarto, o que o cliente pediu. Daí pra frente, podemos chamar de “incompleto” qualquer resultado.

Pois bem, com programadores inexperientes que nao vao questionar a UML, e um analista que nao tem contato com o código, lidando com o departamento comercial do cliente, que nível vc acha que dá pra atingir? Eu acredito que vai no máximo até o quarto grau, isto é, o que ele pediu. Conforme a informacao vai passando de mao em mao, ela vai perdendo a nitidez e ganhando ruídos (necessidades imaginarias, desejos pessoais, enfim, coisas que nao fazem parte da informacao inicial).

Fora os problemas que comecam a aparecer dentro da empresa quando vc tem programadores experientes e/ou questionadores: a briguinha interna pra ver quem tem razao, o analista ou o programador. Sem um mediador, nao há consenso. Quando o analista tem mais poder, aparecem os bugs e as implementacoes fora da especificacao (já que o analista nao participa da fase de “arredondar”). Quando o programador tem mais poder, vc atrasa tudo pq o analista tem que ir sozinho arrumar a especificacao e os programadores tem que ficar esperando.

O bom mesmo é ter programadores inexperientes fazendo pequenas mudancas, ou implementando alguma coisa para a qual já existe um teste de unidade, ou trabalhando em conjunto com caras experientes que possam ensinar e utilizar o potencial produtivo dos novatos. Criar, deixe para os artistas. Isso pra mim significa um time misto, com programadores também, e se possível, alguém do “outro lado”, isto é, um representante do cliente.

Eu tive a oportunidade de desenvolver um projeto onde até os menores detalhes podiam ser perguntados para o cliente, e foi muito saudável, pq o software roda há quase um ano sem mudar uma linha sequer.

Chega, já falei demais!!
[]s!!

Bom, posso estar errado, mas poucos são suficientemente loucos para usar todos os n diagramas da UML nos seus projetos - excluindo os puristas da OO, claro. Até hoje, por exemplo, participei de dois projetinhos (pequenos mesmo) com UML em que usamos só o Caso de Uso e o Diagrama de Classes. Não vejo mal nenhum nisso, acho que depende da dimensão do sistema a ser implementado - além daqueles fatores que todo mundo já conhece, prazo, custo, disponibilidade da equipe, saco…
Mas tem uma coisa que mudou sim: é difícil convencer os analistas “estruturados” e “essenciais” de que o desenvolvimento orientado por objetos pode (e deve, dizem alguns) ser iterativo - projeta, implementa, refatora… A maioria ainda quer “analisar” e entregar o modelo ao programador que se vira para transformar um amontoado de diagramas em algo vivo. Esta eu acho a parte complicada, a mudança de cultura. Aqui onde trabalho convivo com isso todos os dias. Somos os “garotos da OO” aqui.
Lá vai uma pergunta idiota de alguém que começou a ler sobre XP agora: Como conciliar a XP com o conceito de fábrica de software? Eu sou particularmente hostil ao “ambiente” de fábrica, então a pergunta pode ser apenas preconceito meu. Queria saber a opinião de quem tem experiência nisso…

Opa! Enquanto eu escrevia o dukejeffrie disse o que eu penso tb…

Certa vez perguntaram para o Jacobson (rational) se ele conhecia xp e ele respondeu: NÃO… eu não conheço xp… respirou e respondeu novamente: É LÓGICO QUE EU CONHECO XP !!! Mas eu acho que só funciona com equipes pequenas e com programadores de alto nível…

Bom, eu vou um pouco mais longe… acho que rup não funciona.

"você já teve que fazer um diagrama de sequencia de um método getName() da vida ? "

"já desenhou o diagrama de estado do elevador ? "

"já colocou métodos toString e equals em seu diagrama de classes ? "

Cara, como é bom estar de volta

Sempre vi o trio programador/desenvolvedor/analista como uma equipe com um objetivo único: resolver um problema (de forma artística talvez, como diria o Paulo

Acompanhei a discussão aqui… e notei uma coisa… todos discutiram preferências no que diz respeito à análise, métodos, procedimentos e etc. etc. Mas um princípio fundamental no desenvolvimento de software, é a comunicação e entrosamento da equipe, se todos conhecem UML, com certeza ele será uma melhor opção, caso contrário, que usem folhas de papel, rascunhos, inventem um padrão, etc.! O importante é que todos os envolvidos no projeto ENTENDAM COM CLAREZA sua documentação. É preciso, claro, levar em consideração outros aspectos, prevendo-se que outra equipe pode vir à mexer com o mesmo sistema (em uma estrutura modular, isso é possível) pode-se utilizar um padrão conhecido (UML) ou qualquer estilo de documentação que torne as coisas claras.

Agora, quanto a pergunta: Devemos fazer um design ou projetar o software antes de começar a codificar? Bom… na minha opinião sim… no entanto, sou totalmente a favor da construção de protótipos… sempre fiz isso e isso me ajuda muito a descobrir pequenos bugs nas lógicas de negócio e/ou situações não previstas… e pra quem acha que se perde muito tempo construíndo protótipos… recentemente fiz um comparativo com o tempo de desenvolvimento que eu mesmo levava antes e depois de começar a trabalhar desta forma… e acreditem. cheguei a entregar diversos projetos antes do prazo, com folga

[]s!

Carlos H.

Olá, poderia passar mais detalhes sobre SML, a starfield modeling language.

Obrigado