Projetos bem feitos:Fabula ou Realidade

lucifeler:

Bom, gostaria de saber se alguem realmente ja trabalhou em projetos bem feitos utilizando uma arquitetura bem definida respeitando os principios da POO e utilizando Patterns corretamente.
Pergunto isso pois durante o meu trajeto de desenvolvedor (em torno de 3 anos) trabalhei em somente um projeto descente, mesmo assim o projeto ja tinha sido mexido por outras pessoas que alteraram o codigo criando gambiarras :?.
Só para dar uma ideia, estamos em 2008 e atualmente eu trabalho em um projeto que não utiliza nenhum tipo de framework e abusa demais dos malditos scriplets, e o projeto é enorme, agora imagina dar manutenção num treco desses.

Arrume um emprego melhor. Projetos bem executados existem sim.

Pior que nos ultimos tres empregos que eu trabalhei os projetos eram pessimos alguns tinham umas perolas de doer os olhos, e o pior não é isso nos dois ultimos tive que fazer prova para entrar com perguntas de certificação SCJP e algumas de padrões de projeto e quando vou ver o sistema que estão desenvolvendo nada que foi exigido é utilizado, ai é dureza.

louds:

Projetos bem executados existem sim.

A realidade deve ser: vc está nesse projeto pq isso dá lucro pra alguem.

Alguem está lucrando com programas feitos da pior forma possivel nem q seja com contrato de manutenção.

Se vc encontrar uma empresa que lucra com projetos bem feitos, então vc está no lugar certo.

Pergunta: vcs tem Testes Unitários ou Automatizados? Se não tem… pense em injetar esses conceitos.

Se não conseguir mude de emprego, o que mais tem é empresa contratando por ai.

Eles não possuem Testes unitarios, eu ja pensei nisso, alias eu ate ja tinha começado a criar test Cases para algumas funcionalidades que eu tive que modificar. Mas não acredito que eles vão aceitar pois como de costume os prazos de entrega são apertados. E o interesse geral para melhorar o projeto é zero

Se o teu interesse não for esse, como o louds te aconselhou, mude de emprego!

Em 1 ano e meio de experiência, trabalhei em uma empresa onde podiamos desenvolver projetos com arquitetura de alta qualidade, porém era uma empresa pequena onde o dono não entendi muito bem de informatica e tinhamos cliente pequenos, logo nos podiamos usar Java 6, Generics, Abstração e muita orientação à objetos no limite pois não tinhamos que fazer um sistema de 6 meses em 2.

Em contra-partida, na empresa só haviam desenvolvedores, logo não existiam processos(CMMI) e nem documentação. Trabalhavamos em uma especie de extreme programming e por isso acabei mudando de empresa para conhecer mais essa area de processo de desenvolvimento de Software. Acabei descobrindo as maravilhas de utilizar a arquitetura imposta pelo cliente (WebSphere 6, WSAD 5.2, EJB 2, Ireport 0.4, JDK 1.3 e por ai vai) e até cheguei a pegar um projeto com JDBC e sem “muita utilização de Frameworks”.

Rubem Azenha:

louds:

Projetos bem executados existem sim.

Onde? Projetos bem executados são ficticios :twisted:

Isso acontece com mais freqüência em empresas que acham que um bando de ferramentas gerências bestas substitui comunicação e o uma visão mais humana do processo de produção de software. Empresas que tem seus Piloto de Microsoft Project estão fadas a terem projetos mal executados pela alienação que causam no time.

Projetos ágeis produzem melhores resultados, qualquer um que passou pelos dois lado sabe como é.

Esse amontuado de consultorias de “3 letrinhas” e as famigeradas “fábricas de software” são os lugares onde se tem os piores projetos da galáxia.

Siga o conselho de todos, se esta num lugar ruim, que não lhe da abertura nenhuma de melhoria, seu crescimento profissional será zero, MUDE de emprego!

eu tinha visto uma frase em um livro que dizia bem assim:
“bons programadores não são aqueles que fazem um bom projeto. Os melhores são aqueles que tornam um projeto ruim em um projeto bom”
(tá era com outras palavras huioeahua)

veja cada projeto “fudido” como chance de fazer algo melhor: talvez algum refactoring ou fazer com que cada classe que tu gere seja da melhor forma possível. Analisar código já feito para melhorias, sugerir outras arquiteturas ou bibliotecas muitas vezes fazem muitos projetos sairem do buraco para algo agradável de se trabalhar =)

Pelo menos o que vejo de relato de amigos (e meu mesmo), na maioria esmagadora das vezes a empresa (e quase sempre a equipe) naõ tem interesse nenhum nisso, por isso que os projetos chegam a estados lamentáveis como se ve facilmente no mercado.

Concordo plenamente, não adianta eu querer mudar o projeto sendo que o arquiteto e os desenvolvedores que estão a mais tempo não querem ou não dão a minima, sendo que se ao começar a alterar um sistema por conta propria, entenda-se sem o aval de seu superior é bem provavel que o mesmo reclame ou ponha a culpa de algum problema do sistema nos refactoring feitos

Sim, então, por que os caras da tua equipe não querem melhorar o projeto você deve fazer o mesmo?

Você fez um tópico de reclamação dos projetos que só existem nos livros do Martin Fowler e não existem no mundo real. Daí você se vê diante de um projeto que você pode fazer coisas melhores e não faz por causa da cultura da equipe?

Sei lá, pra mim isso se chama hipocrisia =/ Esperar que as coisas mudem e você não fazer nada pra melhorar ou pra ajudar, é a mesma coisa que você reclamar da sujeira das ruas e mesmo assim jogar lixo no chão: “ah, quando todos pararem de jogar lixo eu vou parar também…”

além disso, muitas vezes todos esquecem os contextos que projetos foram criados: Muitas vezes por causa de um piloto de ms project o projeto foi feito as pressas e boa sorte; outras vezes o conhecimento da equipe era baixo e era feito o que era possíbel; e assim por diante

Não foi isso que o amigo disse e nem eu…

Para chegar a um ponto de se sabe e tem a visão de que nem a empresa, nem a equipe, se interessam por melhorar, é porque essas melhorias foram propostas, expostas, concorda comigo?

Sem isso não se tem como chegar a uma visão de que a coisa não vai mudar mesmo.

É esse o meu pensamento, entendi o lado salvado da pátria que vc falou, temos sim que tentar mudar o mundo, fazer as coisas funcionarem corretamente, mas deve-se ter um ponto de limite, fiacr dando soco em ponta de faca não vai adiantar em nada, ai a melhor escolha é realmente partir pra outra.

Ter prazo apertado não é desculpa pra não ter teste.

Pelo contrario, ajuda a entregar as coisas.

Entregar com bug é o mesmo que não entregar.

hehehe Luiz, o que eu disse não era direcionado a você (e eu concordo também com o que você diz)

na verdade é por causa disso

Fazer uma classe bem feita precisa que outros desenvolvedores o façam também? O arquiteto precisa te autorizar a fazer algo bom?

não precisa alterar o sistema por completo, mas o que estiver a seu alcance pode ser da melhor maneira possível

peczenyj:

Ter prazo apertado não é desculpa pra não ter teste.

Pelo contrario, ajuda a entregar as coisas.

Entregar com bug é o mesmo que não entregar.

Depende muito de onde você trabalha :lol:

Em muitos desses lugares onde se “desenvolve software” o negócio é entregar, seja lá o que for.

É ai que a porca torce o rabo…

Na verdade era pra porca simplesmente levantar o rabo, mas como não teve teste nenhum ela esta torcendo o rabo rsrsrs

Leozin :

Sei lá, pra mim isso se chama hipocrisia =/ Esperar que as coisas mudem e você não fazer nada pra melhorar ou pra ajudar, é a mesma coisa que você reclamar da sujeira das ruas e mesmo assim jogar lixo no chão: “ah, quando todos pararem de jogar lixo eu vou parar também…”

Bom em nenhum momento disse que ficaria parado mas do mesmo jeito não posso sair mudando o codigo ja existente porque eu acho melhor, temos que ver que pessoas ja trabalham com isso bem mais tempo, eu sou novo na empresa, e por essa mesma razão alterar coisas pode causar um certo desconforto na equipe, antes de começar a refatorar o projeto é necessario ganhar o respeito da equipe. So para ilustrar, se eu estivesse em uma empresa e participasse de um projeto desde o inicio, ajudando na arquitetura , nas tecnologias usadas entre outras coisas e apos uns dois anos fosse contratado um novo desenvolvedor e o mesmo começasse a refatorar o codigo por conta propria eu ficaria muito preocupado e daria um corte nele pois ainda nao o conheço e nao sei se ele tem a maturidade para refatorar um codigo tendo pouco conhecimento do sistema, não sei se ele vai cagar tudo.

Eu ja tomei bronca de um chefe porque estava “perdendo tempo fazendo testes cases” e que aquilo não importava O.o
Ah era uma dessas que nao importa a qualidade o que importa é se foi entrege na data estipulada.

Velho, será que é tão dificil de entender que patterns e profissionais podem custar um pouco mais mas no final das contas saem mto mais barato???

lucifeler:

Eu ja tomei bronca de um chefe porque estava “perdendo tempo fazendo testes cases” e que aquilo não importava O.o
Ah era uma dessas que nao importa a qualidade o que importa é se foi entrege na data estipulada.

Qual parte do arrumar um emprego que presta vc não entendeu?

Resposta deles: “Patterns, já ouvi falar. É de comer?”

Bem, não tenho ilusões quanto a trabalhar numa empresa que não vê além do cronograma. Elas são a maioria. Apesar disso é fácil encontrar empresas que seguem a boa palavra, elas simplesmente estão mais acima na pirâmide social.

Quer melhorar o teu projeto semi-falido? O alto escalão não ajuda? Ninguém ao redor se importa? Refatore sozinho e o suficiente para completar o pedaço de refatoração até te mandarem p/ outro projeto. Ninguém vai reconhecer o teu trabalho, mas você estará estudando p/ ser um desenvolvedor melhor, e levar este conhecimento para alguém que se importe.

leandro.anjos:

Em contra-partida, na empresa só haviam desenvolvedores, logo não existiam processos(CMMI) e nem documentação. Trabalhavamos em uma especie de extreme programming e por isso acabei mudando de empresa para conhecer mais essa area de processo de desenvolvimento de Software.

Cuidado com conceitos. O que você falou não tem anda de Extreme Programming e nem CMMI é in6onimo de processo (menos ainda de processo eficiente).

Falou tudo. Tem hora que não tem jeio mesmo, já se tentou de tudo mas a empresa doente continua agonizando sem dar sinais que vai reavivar.