Obsoleto significa algo que não está mais em uso.
[quote=JoseIgnacio][quote=ViniGodoy]
Aqui esse número certamente é bem mais baixo do que 90%.
[/quote]
Obsoleto significa algo que não está mais em uso.[/quote]
Não, tem 3 significados:
[quote=“Dicionário Aurélio”]
- Que caiu em desuso; arcaico:
?fez que ressurgisse uma lei obsoleta, de há quatro séculos.? (Euclides da Cunha, Contrastes e Confrontos, p. 29). - V. antiquado.
- Mal desenvolvido; atrofiado, rudimentar.[/quote]
O que eu disse se enquadrava nos sinônimos 2 e 3.
E detalhe que “cair em desuso” não significa “não ser usado em lugar nenhum”. A língua dificilmente é matemática assim.
Significa que não é mais usado atualmente, e que geralmente, haverá coisa melhor.
E você chegou a essa conclusão baseado em que?
[quote=YvGa]
Pois é, e se voce for avaliar bem, vai reparar ainda que dos outros 50% que não são lucro, pelo menos metade é desperdício. Analistas que não sabem programar, hierarquia enorme de gerentes, sub-gerentes, semi-gerentes e coordenadores que mais atrapalham que ajudam e não contribuem em nada para o produto em si. Consultorias e pessoal contratado específicamente para implantar CMMI, MPS BR, ISO e afins. E nada disso é capaz de fazer software de qualidade, mas o cliente paga a conta disso tudo. [/quote]
Se modelos de gestão ágil são mais produtivos porque não possuem margens de lucro maiores?
Acho que nem com modelo de gestão diferente porque os clientes ainda vão preferir lidar com analistas que entendam do negócio, do que com programadores diretamente…
Em qualquer livro moderno de metodologia?
Por exemplo, “Utilizando UML e Padrões”, do Craig Larman (que nem é tão moderno assim, e nem fala de uma metodologia tão ágil assim), onde ele aponta que a fase de análise do Processo Unificado agora é uma fase curta do desenvolvimento, e que é geralmente desempenhada pelos próprios programadores da solução?
Ou qualquer livro de metodologia ágil?
Talvez você também queira procurar por alguma pesquisa sobre a adoção de metodologias ágeis na indústria.
Agora, gostaria que você citasse a referência de que:
a) “a maioria” das consultorias ainda usa Waterfall;
e de que:
b) Não existe tendência de substituição por processos ágeis.
[quote=ViniGodoy]
Agora, gostaria que você citasse a referência de que:
a) “a maioria” das consultorias ainda usa Waterfall;[/quote]
Não lembro de ter falado em Waterfall, mas empresas em que o papel de analista não é desempenhado por programadores.
[quote=ViniGodoy]
e de que:
b) Não existe tendência de substituição por processos ágeis.[/quote]
Nunca vi consultoria sem separação entre analista e programadores. Como posso ter referência de algo que nunca vi? rs
Ok, desculpe, realmente me confundi. Mas serviriam referências (assim como vc pediu para mim) sobre isso também.
Creio que a sua evasividade já comprova meu argumento. Se você está baseando suas afirmações categóricas no que “você vê”, e “você acha”, então, ok, pense o que quiser…
[quote=JoseIgnacio]
Nunca vi consultoria sem separação entre analista e programadores. Como posso ter referência de algo que nunca vi? rs[/quote]
Livros?
É como o Viny disse: não dá pra se basear só no que vemos pra tomar como verdade. Apesar de eu já ter visto muito os dois casos.
Mas imagine então uma empresa que trabalha da forma que voce diz. Vai um analista até o cliente, levanta todos os requisitos, bem certinho, tudo bem documentado. Aí ele volta para a empresa, faz a modelagem, escreve uma especificação e passa para um programador. O programador vai lá e implementa…
Nesse cenario ideal essa especificação contem tudo que o cliente pediu para a funcionalidade, descrito de forma bem detalhada, com todos os poréns e todas as exceções. Tudo muito bem descrito para que o programador possa desenvolver exatamente de acordo com aquilo que foi solicitado.
Isso pode parecer muito lógico e sensato a princípio, bastante intuitivo, mas vamos analisar mais de perto.
Digamos que o analista, mesmo ele não sendo um especialista no negócio (por mais conhecimento que tenha ele não é um especialista, coisa que só um profissional da área pode se dizer), consiga compreender exatamente o que é preciso, inclusive o que ficou nas entrelinhas, mesmo aquilo que o cliente esqueceu de dizer porque na cabeça dele está implícito.
Ao elaborar a tal especificação nada do que ele ouviu do cliente e entendeu perfeitamente pode ficar de fora do documento, porque o programador não estava na fase de levantamento de requisitos, logo não faz a menor ideia do que foi discutido, para ele o que vale é a especificação. Por tanto ali estarão além de prints de tela, previamente idealizadas pelo analista, exemplos do modelo de dados, descrevendo exatamente qual informação da tela vai para tal campo e etc e etc e etc.
E além disso, ele vai ter que descrever exatamente, e com riqueza de detalhes todo o processo a ser implementado, todos os possíveis caminhos, o principal, todos os alternativos, o que deve ou não gerar exceção, o que deve abortar a operação, o que deve somente alertar o usuário. Quais botões estarão habilitados e quando. E assim por diante.
Repare que o programador só entra na história na hora de traduzir para a máquina aquilo que o analista já projetou.
Mas pera aí? Não é para isso que serve uma linguagem de programação? Não é justamente para traduzir para a máquina aquilo que projetamos? Então por que diabos o analista ao invés de fazer prints de tela (no paint como já vi muitas vezes), já não faz em html (ou alguma ferramenta visual) a tela de verdade? Porque ele não escreve em Java, C#, php, C++ etc… aqueles processos todos que ele vai escrever no Word? Se todos os detalhes tem que estar lá, todos os caminhos, todas as exceções, a diferença de tempo que vai levar para fazer em um ou outro é pequena. Com a vantagem de que se for feito numa linguagem de programação, ao terminar já estará pronto para ser entregue.
Então eu pergunto: Qual a lógica? Sob que argumento é adicionada mais uma camada ao processo? O programador/digitador?
“Ah, o analista não tem domínio da linguagem de programação.” Então que se cuide, porque existem no mercado inúmeros analistas que tem esse domínio. Gente que sabe programar, e bem, e é capaz de levantar requisitos, entender o negócio e até - pasmem- conversar com o cliente.
Eu vejo a diferença entre analista e programador como perfil.
Tem o cara que gosta de transformar regra de negócio em software funcionando, gosta de entender um problema e achar soluções pra ele. Esse é o analista. Esse é o meu caso.
Tem o cara que gosta de escovar bit, fazer a máquina falar, virar um framework de ponta cabeça só pra saber como é feito, inventar algoritmos do nada. Esse é o programador. E para desmentir o que muitos pensam, os melhores programadores ganham muitas vezes mais que os melhores analistas.
Mas saber programar é requisito básico tanto pra um quanto pra outro. Analista que não programa está com os dias contados.
Vai me dizer que você nunca ouviu alguém dizer a seguinte frase sobre um analista? “Esse se for demitido não arruma emprego em lugar nenhum”.
Por que será?
Não tenho grande vivencia em Java, mas já fiz cursos e trabalhei num projeto usando Struts 2, o que atuo de fato é .NET, usando ASP.NET MVC, também baseado em action como o Struts 2.
Na parte de programar nas Views achei o .NET um pouco mais produtivo, Razor é muito mais legal de escrever do que Taglib (eu só aprendi dessa forma na época, não sei tem outra).
Na parte de controllers nao lembro muito no Java, mas lembro de ter muitos annotations e um XML no struts2 e no .NET é mais programático e uso de convenções mais fortes. Parte de filter por exemplo você programa de forma simples ao invés de configurar em XML, pelo menos foi o que usavam na época…
Na parte de model, realmente a questão dos gets e sets implícitos do C# deixam o código mais limpo e agradável.
Na parte de ORM, o Entity Framework da Microsoft fica anos luz atrás do Hibernate. Mas graças a comunidade existe o NHibernate para .NET, sei que é uma versão magra, mas para o que sempre precisei achei muito melhor que o Hibernate do Java, com mapeamento programático, sem XML ou amarração de annotations, e linguagem de consulta em objetos melhorada (QueryOver, que usa criteria por baixo dos panos).
Lembrando que todas essas vantagens que notei do .NET e ASP.NET MVC são frutos de cópias melhoradas do Java e Struts2.
Não trabalho com .NET desde a versão 2.0, então não conheço bem o Razor, MVC, nem as novidades da plataforma. Mas isso que você falou, se eu entendi bem, existe sim em Java, são os scriptlets. Mas são considerados má prática porque dificultam a manutenção do código (ele se espalha pra todo lado) e quebram o princípio básico da separação de responsabilidades.
[quote=YvGa][quote=javaflex]
Na parte de programar nas Views achei o .NET um pouco mais produtivo, Razor é muito mais legal de escrever do que Taglib (eu só aprendi dessa forma, não sei tem como usar diretamente sintaxe Java como acontece no .NET, onde o Razor permite trabalhar diretamente com linguagem C# nas Views).
[/quote]
Não trabalho com .NET desde a versão 2.0, então não conheço bem o Razor, MVC, nem as novidades da plataforma. Mas isso que você falou, se eu entendi bem, existe sim em Java, são os scriptlets. Mas são considerados má prática porque dificultam a manutenção do código (ele se espalha pra todo lado) e quebram o princípio básico da separação de responsabilidades.[/quote]
Deve ser equivalente a isso mesmo, só que sem os delimitadores chatos <% %>, usa só um arroba @ no inicio. Só quebra a responsabilidade se a equipe quiser, para esses casos existe o WebMatrix, esse sim é para equipe que quer trabalhar dessa forma, seria como o JSP clássico. As equipes de boas empresas que trabalham com ASP.NET MVC geralmente seguem padrões e não precisam ter algo engessado para que não quebrem boas práticas, e ao mesmo tempo usufruem de uma programação mais natural na view e não somos crucificados por usar essa forma. Você só define qual classe model vai ser usada na view e partir daí navega em cima do objeto (requisitado por uma action). No ASP.NET WebForms confesso que na média era produtividade orientada a “bagunça” mesmo.
YvGa, eu sempre me pergunto:
"Alguém aí já brincou de telefone sem-fio e a mensagem chegou exatamente igual ao final da conversa?"
Então porque você acha que isso vai dar certo no processo de desenvolvimento do sistema?
Cliente->Analista->Documentação->Engenheiro->Documentação->Programador->Software.
O que acha que vai sair no software?
O Razor serve exatamente para evitar trabalhar com C# nas Views.
De qualquer forma, é um erro também usar isso na forma de scriptlets. O correto é estruturar corretamente o Controller, faze-lo criar classes para simplificar ao máximo o trabalho da View.
[quote=ViniGodoy]YvGa, eu sempre me pergunto:
"Alguém aí já brincou de telefone sem-fio e a mensagem chegou exatamente igual ao final da conversa?"
Então porque você acha que isso vai dar certo no processo de desenvolvimento do sistema?
Analista->Documentação->Engenheiro->Documentação->Programador->Software.
O que acha que vai sair no software?
O Razor serve exatamente para evitar trabalhar com C# nas Views.
De qualquer forma, é um erro também usar isso na forma de scriptlets. O correto é estruturar corretamente o Controller, faze-lo criar classes para simplificar ao máximo o trabalho da View.[/quote]
Razor é só uma engine para nos permitir processamento de informações dentro do html usando a própria linguagem que já usamos normalmente, C# no caso.
Abaixo exemplo de View no ASP.NET MVC.
A primeira linha define qual tipo de objeto a view vai receber.
O foreach abaixo por exemplo é linguagem C# de verdade, não é outro tipo de coisa como taglib.
“Model” por convenção é o objeto estruturado para a view, que a action da controller retornará do tipo definido acima.
O “@” é da sintaxe do motor Razor, para saber onde começa a instrução da linguagem C# no meio do html. E não precisamos definir onde termina, o Razor se encarrega de saber onde termina pelo contexto da instrução.
Sim, o curioso é que, embora ele seja usado para você dar o comando C# nas Views, a recomendação é justamente que você evite ao máximo isso. 
Quer dizer, você use o Razor para dar comandos simples, geralmente de uma só linha, e geralmente usando classes helper de alguma camada de fachada do servidor (como essa Html.ActionLink).
A recomendação existe para que não se faça em MS MVC o que se fazia em ASP padrão.
[2]
Ainda adiciono mais: Se você fizer direitinho, o Designer continua conseguindo editar as telinhas de view.
Acho um pouco simplista a idéia de que só pq a tag é “HTML like” vai ser mais fácil para o designer.
[2]
Ainda adiciono mais: Se você fizer direitinho, o Designer continua conseguindo editar as telinhas de view.
Acho um pouco simplista a idéia de que só pq a tag é “HTML like” vai ser mais fácil para o designer.[/quote]
Exatamente, eu trabalho com designers que em pouco tempo já se familiarizaram com a sintaxe “não-tag” nos pontos que eles sabem muito bem que são partes dinâmicas. A coloração do editor de código na parte de linguagem servidor já ajuda melhor do que se fossem “tags”. O importante é o código ficar limpo e legível e sem muita lógica, ou seja o model já vir mastigado para atender a view. Para eles designers inferno era trabalhar com frameworks baseados em componentes como ASP.NET WebForms ou JSF, que é difícil ter o controle apurado do resultado.
[quote=ViniGodoy]YvGa, eu sempre me pergunto:
"Alguém aí já brincou de telefone sem-fio e a mensagem chegou exatamente igual ao final da conversa?"
Então porque você acha que isso vai dar certo no processo de desenvolvimento do sistema?
Cliente->Analista->Documentação->Engenheiro->Documentação->Programador->Software.
O que acha que vai sair no software?
[/quote]
Concordo plenamente, eu só quis no meu post exemplificar que, ainda que fosse possível, essa cadeia de transmissão de informação é desnecessária. Por isso nem comentei sobre o efeito "telefone sem fio".
Se for usar como nesse seu exemplo, tudo bem. Realmente não há muita diferença entre um foreach e um <c:forEach. O problema é quando o pessoal começa a colocar regra de negócio diretamente ali.>
JoseIgnacio, o ViniGodoy está certo. O modelo em que se separa programador e analista está extremamente obsoleto. Existem aí diversos artigos que colocam que nesse modelo as chances de fracasso, horas e gastos extras são muito grandes. Mas apesar disso, devo concordar com você que mesmo aqui em SÃO PAULO muitas empresas grandes ainda adotam esse modelo ultrapassado. Não sei se são 90% como você disse mas são muitas mesmo. Eu trabalhei em um grande banco em que usava esse modelo. Empresas grandes de TI também como a Accenture também utilizam esse modelo. Apesar de ficar infeliz com esse fato, acho que ainda vai demorar muito para grandes empresas e multinacionais mudarem o modelo de desenvolvimento de software por aqui. Algumas até tentam, mas fazem um “MIX” de Waterfall com Ágil. Li alguns casos de sucesso, mas geralmente disso aí não deve sair muita coisa boa. A agilidade não está no processo, mas sim em conceito. Cada empresa deve adaptar o conceito ágil de acordo com a sua realidade e de acordo com cada projeto. Não é um modelo pronto.
Inúmeros? Talvez.
Infelizmente o programador típico não se interessa por ir além da interface do software e só quer saber de como ele é implementado.