| Autor |
Mensagem |
|
|
Ouçam o conference... please
Senhores, quanta especulação.
|
 |
|
|
brunohansen wrote:
Isso não é controverso?
sergiotaborda wrote:
Isso é uma falácia.
Nem falácia nem controverso!
Não se pode confundir um objeto de invenção pura, com o Data Transfer Objects.
Um objeto não deve persistir a si mesmo; isso viola o principio de Separação de Interesses.
O padrão Separação de Interesses tem prioridade sobre o Especialista na Informação.
Existe uma prioridade nos padrões; Primeiro Grasp (básicos) depois GoF, e todo padrão tem contra-indicação...
|
|
|
|
Moderadores, não sei se esse tipo de tópico é permitido. Então, fiquem à vontade para excluir, sendo o caso.
Pessoal,
Tenho base de conhecimento para desenvolver em Hibernate, JPA, JSF, Struts, JSP/Servlet, SQL Server T/SQL, Oracle 8i, HTML, CSS, Java Script, Dojo Ajax Toolkit. Alguns Design Patterns dentro de Grasp e GoF. Conhecimento de algumas metodologias de A/POO.
Tenho experiência em 1 projeto Web com Java utilizando MVC, Dojo Toolkit, JavaScript, HTML, CSS.
Já passei pelas tecnologias: ASP e VB.
Tenho boa experiência com desenvolvimento (4 anos) e web (3 anos).
Entre minhas referências de estudo estão: Martin Fowler, Craig Larman, Edson Gonçalves, Documentação da IBM, Documentação da Sun.
Se alguma empresa tiver interesse. Estou desalocado.
Sds
|
|
|
|
|
Pessoal, para abrir a empresa, na nossa profissão é necessário o Alvará?
|
|
|
|
Acrescentando: Teste a priori. Em Desenvolvimento Dirigido por Testes, apoiado pelo PU, os testes são escritos primeiro.
Desenvolvimento Iterativo não é atuação Cawboy do programador. Desculpe-me a franquesa.
Não vejo como a UML não seja utilizada Em uma decente A/POO a UML é muito importante, embora, não seja um bala de prata.
A UML é vasta, muito ampla, e se você quiser ir a fundo com especificações do tipo: abra o arquivo, feche o arquivo, dá pra fazer sim. Mas no modelo Iterativo são deixadas as partes especulativas de um sistema.
|
|
|
|
|
boas dicas.
|
|
|
|
Bruno Laturner wrote:
Pergunta: O que você fará com este UML? Ou melhor, de que forma ele está te ajudando a desenvolver?
Acho que já coloquei isso antes:
Acrescentando: UML especializa subconjuntos da notação para áreas de assunto comum.
O UML representa o sistema em diferentes atuações. E é uma linguagem Visual. Visualização é um termo chave.
UML pode representar todo seu sistema para os Analistas, para você mesmo, para os Designers; UML documenta o sistema, a arquitetura de pacotes, a lógica, o dominio...
Na prática, essa visualização, fará grande diferença, quando em um quadro, quem diagrama, percebe o quanto sua visão do projeto estava mal elaborada e refaz ela talvez uma dezenas de vezes até chegar a um bom modelo.
Sabendo que em um projeto, são em maior número os que codificam. Faça um cálculo parecido com isso: N modificações modelo x qtd programadores x qtd de implementações = qtd de re-trabalho.
Para um exército de um homem só, pense em deixar um testamento UML para o proxímo. 
IMHO
|
|
|
|
celso.martins wrote:
F?io Henrique wrote:
Engenharia avante, reversa e de ida e volta.
Engenharia avante significa a geração de código a partir de digramas;
 engenharia reversa significa a geração de diagramas a partir do código; (você PODE ter alterado código, sem sincronizar os diagramas UML)
e a engenharia de ida e volta fecha o ciclo.
Engenharia reversa eu sei o que é, não entendi a parte da refatoração partir a engenharia reversa.
F?io Henrique wrote:
Concordo, pois das refactorings, é feita a engenharia reversa, disponibilizando a UML.
F?io Henrique wrote:
.....
Creio que no modelo Iterativo a figura do Analista se faz ainda mais presente.
IMHO
Respeito a sua opnião, mas discordo dela. Se você está, constantemente, analisando, implementando e testando, acredito que o desenvolvedor deva ter estas 3 habilidades.
Imagino que você esteja pensando que estou associando (de forma dependente) refatoração com engenharia reversa UML.
Na verdade, estou usando o implicito.
Está implicito que se você faz uma refatoração, logo, seu código esta diferente e o UML pode não estar sincronizado com esse novo código. Do produto da refatoração (novo código) , é feita a engenharia reversa para atualizar o UML.
Na prática, sempre que são feitas alterações relevantes, significativas e que alteram o diagrama representacional UML, em vez de alterar o UML diretamente, pode ser feita a engenharia reversa atualizando os diagramas UML.
Tanto os Desenvolvedores que desempenham o papel dos Analistas e Analistas que códificam, por papel são Analistas.
Então se um Desenvolvedor desempenha funções antes, atendidas pelos Analistas, logo o mesmo é Analista. Diferente da figura de Desenvolvedor que pode nem ter noções de Arquitetura e/ou Metodologias. No meu ponto de vista, uma unificação, mas prevalecerá a definição Analista.
Então, acho que fui breve demais nos posts anteriores.
Vlw
IMHO
|
|
|
|
celso.martins wrote:
F?io Henrique wrote:
Concordo, pois das refactorings, é feita a engenharia reversa, disponibilizando a UML.
Não entendi esse conceito. Pode me explicar melhor, por favor?
Não entendi a relação entre refatoração e engenharia reversa.
Obrigado! =)
Abraços!
Engenharia avante, reversa e de ida e volta.
Engenharia avante significa a geração de código a partir de digramas;
engenharia reversa significa a geração de diagramas a partir do código; (você PODE ter alterado código, sem sincronizar os diagramas UML)
e a engenharia de ida e volta fecha o ciclo.
Antes de ir para o quadro novamente para uma nova iteração, use uma ferramenta UML para fazer engenharia reversa do código para produzir diagramas UML de classe, pacote e de iNteração, imprima em papel de plotter, grande, mande os desenvolvedores rascunharem a nova iteração.
http://www.objectsbydesign.com/tools/umltools_byCompany.html
Isso para mim, são apenas conceitos não experimentados por mim na prática. Mas tenho me esforçado no sentido.
Uma vez me foi dito, em um cenário pessoal, que aquilo que eu mais odiava ou achava chato de fazer, seria justamente, o que me faria crescer. Quando um Analista descobre as capacidades relativas a UML, sua visão de implementação é objetiva e clara. UML não foi uma projeção qualquer.
Creio que no modelo Iterativo a figura do Analista se faz ainda mais presente.
IMHO
|
|
|
|
Mauricio Linhares wrote:
F?io Henrique wrote:Não vejo como isso possa subjulgar o desenvolvedor. Pelo contrário, é um meio comum para garantir a comunicação (entendimento), e explorar possiblidades em um projeto.
A maneira mais eficiente de se "explorar" coisas em um sistema é com testes e refactorings, porque eles vão lhe mostrar os resultados ali, na hora, UML é só imagem. Como já dizia aquela propaganda da Spite, "imagem não é nada, sede é tudo" 
Me refiro a uma Iteração inicial, onde o produto PODE não existir.
Concordo, pois das refactorings, é feita a engenharia reversa, disponibilizando a UML. Me corrijam se estiver errado, pois tenho aprendido assim. E nesse ponto de vista, achar que o desenvolvedor NÃO é capaz, é jogar essas possibilidades fora. Mas antes de uma refactoring, podem vir rescunhos UML dando um visão, mas não são candidatos a documentação, como são os resultados da engenharia reversa das refactorings.
|
|
|
|
Dentro do modelo Iterativo, tenha a UML:
* Como rascunho.
* Como planta de software.
* Como linguagem de programação (determina uma especificação executavel, ainda em desenvolvimento)..
* Como documentação.
Visual é a palavra chave aqui.
Não vejo como isso possa subjulgar o desenvolvedor. Pelo contrário, é um meio comum para garantir a comunicação (entendimento), e explorar possiblidades em um projeto.
Esses são alguns pontos fortes, no modelo Iterativo.
No projeto Iterativo, o cliente está envolvido nas reuniões, visto como responsável pelo projeto também, e os programadores participam e não recebem recados dos analistas. Muitas perspectivas, definem um Projeto Unificado.
O Projeto em Cascata ainda é muito utilizado, pois requer uma mudança em um nível mais alto: financeiro.
IMHO
|
|
|
|
1 - Use o membro privado diretamente quando não há lógica na atribuição
2 - Use os métodos gets e setters quando há lógica dentro desses métodos
A priori, use sempre privado... acesso é (imperceptivelmente) mais rápido, e menos tedioso para debug...
Simples assim...
|
|
|
|
ViniGodoy wrote:Aqui aplicamos prova + entrevista.
Tô careca de ver Certificado que não sabe nada sobre Arquitetura de Sistemas... Persistência... tratamento de interface Web...
Não ajuda muito fica esmiuçando se o cara lembra o comando tal ou sintaxe tal..
Para resolver problemas... o candidato tem que ter discernimento, inteligência..
Por exemplo: esse problema com o Enum.. alguns gostam de utilizar o padrão: Polimorfismo:
Justamente para não encher o programa de ifs (procedural)...
Como tratar condicionais com base no tipo: Polimorfismo... dai o cara pode nem usar enum exaustamente... mesmo sendo um profissional que poderia acrescentar a equipe... não vai passar no teste...
De um aspecto comum, não há apenas uma forma de resolver o problema...
Acho que uma boa conversa, indo em detalhes, ajuda.
O problema ai, é que tem gente que não gosta de "argumentar", principamente com um candidato.
|
|
|
|
juliobrrj wrote:
Nossa profissão é raciocínio+conhecimento+criatividade, e não produção em escala.
Ninguem disse que isso não é altamente estimado.
Acontece, que todos pensam que têm: conhecimento, criatividade, raciocínio. Mas quando você vira para o colega e diz, não faz assim não, ele surta e perde todos esses atributos e ai o projeto, vai pro saco... um bom profissional, deve ter também um orelhão. Igual ao meu hihihi... só não me jogue água que o bicho pega.. In my humble opinion
|
|
|
|
peczenyj wrote:É mas não mata. Perfeito para descobrir se o cara vai surtar no primeiro probleminha que ele encontrar pela frente.
Isso testa o conhecimento também.
O que ele esta dizendo é para perceber certos aspectos de comportamento do candidato.. já fizeram isso comigo... fizeram varias perguntas seguidas e relacionadas, antes que eu responder uma pergunta, outro, já fazia uma nova... no final o entrevistador me achou um cara calmo... mas eu não tinha conhecimento suficiente para preencher a vaga. Entre esses métodos: atacar diretamente o currículo do candidato e dizer alguma besteira para ver se o candidato corrigirá de forma adequada o entrevistador.
Mas acho que só passa ai, quem já sacou esse tipo de abordagem, pois qualquer ficará intimidado. Durante essa entrevista, eu esqueci uma pancada de coisas; tive que dizer que não sabia explicar.
Mas acho que o método não é ruim, porque a equipe sofre quando encontra um membro que quer ser o sabichão e perde as estribeiras em uma discussão; do contrário: se o cara passar, terá todas as condições de evoluir com/a equipe.
Isso é diferente das sacanagens que citei, pois ali, estou abordando o feedback falso do cliente para o RH.
Mas uma coisa: o entrevistado pode ficar em evidência quanto a equipe, se a equipe não concordar com alguma coisa, não quer dizer que ele esteja errado.
|
|
|
|
|
|