Não concordo que o programador possa ser livre e usar a ferramenta de build que quiser!
Se for para trabalhar em equipe, então a equipe deve fazer uma reunião, e definir entre eles qual é a ferramenta de build mais apropriada para o projeto, e não para os indivíduos!
Um bom programador deve aceitar as decisões cedo e se adaptar o mais rápido possível! 
[quote=saoj][quote=Maurício Linhares]
Mas eu ainda acho que existem muitas coisas que devem ser acordadas, como ferramentas de build, servidores de deployment, controles de versão, padrão de documentação, não acho que isso deva ficar a cargo de cada um não.
[/quote]
Tudo isso que vc falou eu concordo que tem que padronizar. Coisas que não concordo e que já briguei com a diretoria:
:arrow: IDE (gosto muito do Jext)
:arrow: Cliente CVS (gosto muito do Tortoise)
[/quote]
Rapaz, padronizar o controle de versão é bom, mas padronizar o cliente é d+
Eles pelo menos tinham um motivo pra isso?
[quote=Fabrício Cozer Martins]Tudo pode ser feito a maneira que o programador se sinta a vontade.
Acho errado impor usar uma ferramenta para build específica sendo q o cara pode produzir o mesmo resultado com a sua própria.
[/quote]
Quando você pegar um projeto onde gente usa Maven, outro usa Ant, outro usa direto na IDE e ainda outro usa uma ferramenta que ninguém conhece, você vai entender isso.
Especialmente quando for fazer um deployment :lol:
Sem contar as estruturas de diretórios completamente diferentes, que são uma maravilha pra integrar, especialmente em projetos que tem dependências :mrgreen:
Um bom programador é capaz de produzir o que está sendo esperado, independente de ferramentas. Levando em conta os padrões de nomenclatura de classes, metodos, variaveis locais, etc … etc… por exemplo.Mas se o cara produz mais usando a ide X, pq impor ele usar a ide Y ?
Não estou falando por mim, pois em relacao a IDE, utilizava o JDev e entrei no projeto onde a maioria usava o eclipse, e a empresa estava querendo migrar. Logo, testei, comecei a usar em casa, e tals … e estou usando o eclipse sem problemas, mas existem outras pessoas no projeto q estao com o Jdev(depois q a oracle anunciou q seria free), eles continuaram com o jdev, e nao esta tendo problema algum.
Aí não … estrutura de diretório DEVE SER ÚNICA.
Mas ferramentas PARA se fazer o q foi especificado não deve ser única, seria bom que fosse, pois a equipe estaria mais integrada.
São como frameworks , uns gostam do struts, outros do ww, outros preferem criar o seu , … ja imaginou reunir essas cabecas numa equipe soh ? Não rola.
Tem coisas que deve definir, outras vc pode deixar a pessoa escolher.
Um dos benefício de se usar ferramentas de build é de certa forma vc ganhar um pouco mais de independência no seu projeto, sendo possível assim desacoplar seu projeto de uma IDE específica!
Se for para usar uma IDE por ordens superiores, fazer o que né! Mas acho interessante padronizar ao menos a ferramenta de build assim como suas operações possíveis, ai fica a critério do programador qual IDE irá usar.
A IDE se torna apenas uma ferramenta de desenvolvimento, no entanto, integrada com a ferramenta de build!
O programador até pode inventar algumas rotininhas, alguns scripts facilitadores, desde que não afete a arquitetura e estrutura do projeto que foi definido pela equipe!
Aos poucos, se algum programador tem um script não adotado no projeto e que só ele usa, e se este script for realmente interessante para a equipe, a tendência é que ele apresente esta solução para a equipe, e esta solução venha a fazer parte do projeto!
Nem sempre, as vezes se tem um ótimo programador, mas o resultado final, não bem o que o cliente esperava… :lol:
Vc já brincou de telefone sem fio qdo era pequeno ?
Pois é, as vezes a informação chega ao programador de forma incompleta, ou interpretada de n formas diferentes… mas se o programador é bom, ele deveria fazer parte de todas as fases, entendendo o que o cliente quer.
[quote=Sandro.Santos]Fala galera,
Programo desde 90, quando comecei com clipper,é já pude desenvolver diversos sistemas em diferentes áreas de atuação, o que me deu um grande flexibilidade no tocante a analise/programação.
Acredito que um programador, por melhor que seja, se não conseguir entender o negócio do cliente não vai desenvolver um bom projeto, falo por experiência, pois já errei muito. Você acaba deixando o sistema funcional, rápido, tecnologicamente avançado, mas o danado não faz o que realmente o cliente queria.
Esse é um erro cometido por uma grande parte de programadores que já conheci, pois apesar de manjarem muito da linguagem, não conseguiam entender o que o cliente queria.
Conselho: se vc já é um programador médio, tente virar um analista médio, pois se tornar um ótimo programador sem sacar de analise não da muito resultado.
[]s
[/quote]
Sou da seguinte filosofia: o profissional da informática deve conhecer as ferramentas e deve conhecer o negócio (afinal, TI é uma atividade meio).
[quote=smota][quote=tRuNkSnEt]Bom galera, o cara do artigo falou numa forma, que ele mesmo não sabe se funciona, de “ganhar dinheiro”. :lol:
Existe um ISO que é dado a empresas de qualidade. Na epoca que estava atualizado com os dados tinha nada mais nada menos que 3 empresas na america latina que detinha um nivel de qualidade 5 (ultimo) - Tinha alguma relação com PMI. Por incrivel que pareça essas empresas seguem a linha de raciocinio que eu falei. Agora não intendi onde voces querem chegar porque até agora eu so vi falar de programadores e linha de codigo sendo que a parte mais essencial de um projeto é o seu projeto :).[/quote]
Você está fora e muito fora de sintonia …
O cara do artigo é o Joel Spolsky, dono de uma empresa onde ele aplica esse conceito como está escrito no artigo (que você não deve ter lido ou entendido direito) e também está escrito que com esse modelo ele conseguiu ser rentável desde o início.
Outro ponto que você não pescou nos artigos é que não é qualquer programador, são os bons que merecem toda essa atenção e valem esse esforço. É por isso que existem programadores pobres, porque a grande maioria (também está nos artigos, leia de novo) é mediano pra baixo.
A ISO com nível 5 na verdade chama-se CMM (Capability Maturity Model) e não tem nada a ver com a ISO … é aplicável apenas em fábricas de software e afins que por definição atraem os programadores medianos que não são muito chegados em pensar e os analistas que não sabem programar. (claro que estou generalizando, mas esse modelo é um pé)
Não se engane, há várias empresas que tem esse pensamento (do artigo) e estão muito bem, obrigado![/quote]
Um programador bom, deve conhecer de engenharia de software e também do arcabouço envolvido: MPS-BR, CMMI, PMBOK, COBIT, RUP. Tudo isso facilita a vida do profissional de informática.
[quote=pcalcado][quote=tRuNkSnEt]
Eu sou analista, trabalho na area a algum tempo e por mais que o cara saiba de programação ele nunca sai com nada. Eu mesmo ja tentei fazer um programa assim do nada, o programa apresenta muito mais erros, o programador se perde completamente na hora de fazer manutenção, o programador leva muito muito mais tempo para entregar, e se algum dia outro alguem for mecher é preferível começar do zero. E incrivel como os programadores tem preguiça de ir no cliente e falar com ele.
[/quote]
Você está confundindo análise e projeto de software.
Um analista de negócios é muito importante, alguém com muito conhecimento do domínio, tanto que metodologias ágeis extrapolam e mandam você colocar o cliente na sua equipe (quem melhor que ele?).
Ética profissional não é isso.
E se alguém acha que projeto de software e programação são coisas diferentes…deve ler e programar mais.
O programador está limitado pela linguagem. O que seu analista usa, UML? Sabia que ela é uma linguagem limitada?
Desenvovler software é resolver problemas. Um analsita se preocupa com processos, técnicos se preocupam com a implementação de processos em sistemas computacionais.
Nível 3 de que, CMM?
E desde quando isso define a qualidade (ah, esquece, CMM de novo não!)?
Realmente LoC não é boa métrica para nada, o que você sugere? [/quote]
Eu sou a favor das seguintes métricas para software:
Também deve estar no pensamento diário do programador, os Padrões de Projeto… Design Patterns
Adriano Paulino Menezes tu foi o campeão em ressucitar tópicos… desde de ontem que tu vem ressucitando tópicos de 2005 com comentários sem fundamentos e inúteis… evite fazer isso.
Leia o How To -> http://www.guj.com.br/java/287476-gujnautas-how-to
Acima de tudo os seres humanos envolvidos satisfeitos, principalmente o cliente claro.
Não sei nem quem é esse palhaço,
só conheço Sputnik, desse aí nunca ouvi falar.
Empresa grande analista é de negócio, nível mais alto e corporativo. Programador e analista de SISTEMAS não éo mesmo que analista de negócio.
Vai na VIVO, telecom gigantesca vai ver se existe isso de programador e analista de sistema.
Uma vertical grande tem de ter especialista no negócio que demanda sistema, o sistema adequa-se ao negócio.
Vão procurar empresas que não são de fundo de quintal como modelo.
VIVO, PETROBRAS, VOTORANTIM, empresas desse naipe pra cima. sem falar tambem dos bancos BRADESCO, ITAÚ E HSBC.
ISSO AÍ É TUDO CONVERSA DE MENINO.
[quote=pcalcado]Isso é ilusão.
Analistas como pregados na faculdade não existem. Esse papo de entregar tudo pronto pro programadornunca foi verdade.
No papel tudo funciona. Olhando um documento de requisito de uma página ou mais, o cliente acha que está tudo bem. Quando se percebe que a implementação não pode ser feita como o “analista” ou o “arquiteto” ou o “projetista” especificou, quando o cliente v~e depois de meses que o sistema não faz o que ele quer, aí sim você entra no mundo real.
Esse carinha da palestra ou não conhece o mercado ou quis passar uma visão romântica e obsoleta.[/quote]
Falou tudo!
Pelos 5 anos de faculdade que fiz, nunca vi essa profissão sendo citada nas disciplinas. Sei que na prática é assim, mas errado são os programadores que começaram a fazer esse papel também!!!
[quote="Sparcx86 "]
Não sei nem quem é esse palhaço,
só conheço Sputnik, desse aí nunca ouvi falar.
Empresa grande analista é de negócio, nível mais alto e corporativo. Programador e analista de SISTEMAS não éo mesmo que analista de negócio.
Vai na VIVO, telecom gigantesca vai ver se existe isso de programador e analista de sistema.
Uma vertical grande tem de ter especialista no negócio que demanda sistema, o sistema adequa-se ao negócio.
Vão procurar empresas que não são de fundo de quintal como modelo.
VIVO, PETROBRAS, VOTORANTIM, empresas desse naipe pra cima. sem falar tambem dos bancos BRADESCO, ITAÚ E HSBC.
ISSO AÍ É TUDO CONVERSA DE MENINO.[/quote]
Já tive exériências em duas dessas empresas e pelo que percebi os cenários são caóticos.
Isso de acúmulo de função só faz aumentar custos.
Dá certo nessas empresas, pois se tem dinheiro para investir.
Mas os custos são elevadíssimos.
O que percebi é o grande retrabalho e alta-rotatividade que existe nessas empresas.
O separação radical das funções realmente não deve existir (programador, analista, tester), mas definir corretamente responsabilidades é coerente.
Esse coisa também de que o negócio deve estar na cabeça dos programadores é papo furado, pois cria a “armadilha” da dependencia das pessoas no processo.
E no ponto de vista da gestão isso é muito maléfico…
Um conhecimento de um sistema deve ser algo tangível, deterministico e tranparente para todos e não uma caixa preta.
Hoje, tenho o seguinte cenario aonde trabalho:
Tem um novo projeto onde existira um modulo web, um desktop e um no celular.
Vou ser o responsavel por sentar com o cliente, entender o que ele quer, o que ele precisa e em quanto tempo. Depois disso, vou documentar, analisar, reunir novamente com o cliente, ver se o que elaborei esta de acordo com as necessidades dele.
Feito isso, vou sentar na minha maquina e começar a desenvolver, entregar aos poucos e recebendo a aprovação do cliente.
Acho que “Analista Programador” se encaixa perfeitamente nesse cenario, um cenario real.
Acho engraçado essa briga entre analista e programador, tenho amigos na faculdade que odeiam analistas pelo fato de serem analistas. Essa briga vem de tempos em que muitas dessas pessoas não estavam nem em projeto de nascer. Quando o analista não sabia escrever uma linha de código, trocaram de tecnologia e ele não se preocupou em se atualizar e passou a somente fazer analise, e em função disso os programadores tinham que ficar “arrumando” os furos de analise fora que a comunicação era zero, a hierarquia era algo que incomodava e por ai vai.
Não tenho como objetivo virar O PROGRAMADOR e depois passar para O ANALISTA e parar de desenvolver e projetar.
Os dois caminham junto e acho que todos devem saber ambos os lados.