fabioEM wrote:Galera é um impressão ou existe um padrão de preferências entre nós bastante comum.
1) Assistir seriados americanos um tal de Dexter (Eu, particularmente detesto, mas respeito quem goste)
2) Preferência por jogos do tipo RPG.
3) Blogs de tirinhas....
4) Passar Feriados em frente ao pc.
5) Mulher que é bom nada
6) Escrever um post como esse
E, aí o que acham?

getAdicted wrote:Bom dia,

Ontem eu tive uma conversa muito louca com uma analista de RH (psicóloga) em uma entrevista. Os dois serios, de frente um para o outro: ela me indagou: como seria trabalhar em uma pastelaria, em uma empresa cujo os prazos são apertados, etc... Eu disse: se eu soubesse onde eram guardados o "queijo" e o "presunto", tranquilo... =)

[]'s

Marcio_Nogueira wrote:Já vai tarde!

neófito wrote:

bestlinux wrote:O problema é: Ate quando você vai fazer isso ? Pular de "galho em ganho" ? Sera que isso é bem visto no mercado ?

E quem disse que eu pulo de galho em galho? E quem disse que não tenho família? Bom profissional, profissional com técnica, é valorizado. Veja bem, o tipo de empresa que faz o que está descrito neste tópico são consultorias, agências de publicidade, etc. Geralmente as empresas que desenvolvem para seu uso estão interessadas em qualidade, porque o sistema delas faz parte do próprio negócio. Se o sistema falha, há prejuízo. É tudo uma questão de decidir em qual lado você vai ficar.

neófito wrote:

htraos wrote:Boa noite.

Há um mês troquei de empresa. Saí de uma empresa pequena que tem uma preocupação grande com a qualidade (tanto de codificação quanto de "produto final" -- o que o cliente vê) e fui para uma empresa maior, mas menos preocupada com a qualidade do código.

Quanto as respostas anteriores, nunca ouvi tanta besteira assim na minha vida toda. É por isso que vejo tanto código maluco, projetos de R$800 mil afundando e toda sorte de maluquices nas empresas onde trabalho.

Você deve tentar convencer os gerentes que um código melhor resulta em manutenções mais rápidas, e que você vai embutir um tempo para refatoração em todas manutenções que você vai fazer. Se o gerente aceitar, ótimo. Caso contrário, encontre um outro emprego primeiro, depois pule fora. Dê preferencia a projetos onde você terá que desenvolver coisas novas, e não onde há apenas manutenção. Veja bem, eu disse preferência, sempre haverá manutenção. Normalmente as más empresas, geralmente consultorias e agências de publicidade, vendem o sistema com um prazo absurdo, entregam e depois contratam programadores para consertarem a cagada que fizeram.

Caso você consiga convencer seus superiores de que há necessidade de refatorar, vou dar algumas dicas. A primeira, e a mais importante: refatorar um sistema não é fácil. Pelo contrário, é bem difícil. Não é qualquer zé mané que conserta um sistema médio. É preciso técnica especializada e unidade da equipe em atingir esse objetivo.

Se o sistema for pequeno, a refatoração será mais fácil. No caso de um sistema médio, a mesma pode se tornar um pesadelo se as técnicas corretas não forem usadas. Primeiramente, você vai precisar do básico: sistema de controle de versão, um ambiente de homologação, etc. Depois, você vai precisar de técnica. Você vai precisar fazer testes unitários e de aceitação automatizados para garantir que você não quebre nada no sistema. Aconselho os livros abaixo:
Test Driven Development: By Example
The Art of Unit Testing: With Examples in .Net
Working Effectively with Legacy Code
Há outros, mas esses são fundamentais.

Os testes unitários servem para você fazer o sistema crescer saudavelmente, permitem que você refatore e tenha uma resposta rápida, mas não 100% precisa, da alteração que você realizou. Os testes de aceitação servem para você testar o sistema como um todo, uma funcionalidade do início ao fim. Geralmente eu escrevo testes de aceitação e depois testes unitários.