Um pode andar sobre as águas e o outro pode correr. Compare seus currículos veja que a lista de habilidades são praticamente iguais: J2EE, Struts, Spring, Hibernate, etc.
A diferença é então a maneira como eles codificam? Ou nos anos de experiência? Enquanto em alguns momentos andar sobre a água seja uma tarefa mais fácil de ser atingida do que muitas das tarefas que encaramos em Java, a diferença entre um arquiteto e um desenvolvedor é a amplitude de conhecimento versus a profundidade do conhecimento.
Por exemplo, uma empresa, como havia anunciado, procurava por um arquiteto, mas na verdade, perdeu muito tempo até perceber que realmente precisava de um desenvolvedor disciplinado que seguisse as boas práticas de programação. Mesmo assim, cordialmente prosseguia entrevistando, sabendo que seria uma perda de tempo, tanto para os candidatos, quanto para eles próprios. E tenho certeza que o desenvolvedor entrevistado pensava: “ Como esse cara pode ser um arquiteto sem saber tudo sobre Spring, Hibernate e Struts? ” O que muitos entrevistadores não percebem é que o objetivo de um arquiteto não é dominar detalhes de implementações existentes. Ao contrário, o objetivo é aglutinar a essência de várias tecnologias para resolver problemas, ou melhor ainda, encontrar maneiras de criar implementações inteiramente novas.
Na essência, o trabalho do arquiteto é incorporar o núcleo da programação orientada a objetos: maximizar o re-uso de componentes. A disciplina de delinear claramente as funções do trabalho. Os arquitetos são geralmente idealizados como gurus. A realidade é que eles não são gurus. Ao contrário, eles são os visionários da criatividade de uma organização Java do futuro. Pense nisso da seguinte maneira: uma editora não contrataria um escritor esperando que ele faça o papel de um editor simplesmente pelo fato deles saberem escrever. Construtoras não contratam arquitetos esperando que eles vão cimentar paredes pelo fato deles saberem ler plantas baixas. Portanto, por que se espera que arquitetos Java façam o papel de desenvolvedor simplesmente porque sabem codificar? A Sun tem diferenciado claramente arquitetos de desenvolvedores pelo fato de oferecer dois tipos distintos de exame: o Sun Certified Developers Exame o Sun Certified Enterprise Architects Exam.
Como nos sairíamos se estudássemos o ano todo para o exame de arquiteto, aprimorando suas habilidades em análise orientada a objetos, desenvolvimento orientado a objetos, Unified Modeling Language (UML), etc., para depois aparecer no exame e descobrir que fazremos o exame de desenvolvedor? A única diferença seria o título do exame? Entretanto, encaremos a realidade das contratações em TI.
Para uma boa relação custo beneficio, as empresas, atualmente preferem contratar profissionais que são meio-arquiteto / meio-desenvolvedor. Sem dúvida, para ser um bom desenvolvedor, deve-se ter um sólido conhecimento na arquitetura da tecnologia Java. Inversamente, para ser um bom arquiteto, deve-se também ser um bom desenvolvedor. Consequentemente, quando se usa a idéia do profissional meio-arquiteto / meio-desenvolvedor, a organização acaba por contratar um generalista, não um especialista.
No final das contas, essa falta de decisão acaba por criar uma distorção no seu projeto. Comparada ás outras industrias, quando se discute a disciplina de delimitação clara de funções, a indústria de desenvolvimento de software ainda é relativamente imatura.
As vantagens de se definir papéis claros.
No ciclo de vida do desenvolvimento de software, quanto maior a perspectiva do domínio do problema, mais compreensível e confiável será a solução. As vantagens de se definir papéis claros entre desenvolvedores e arquitetos em uma organização, é a maneira pela qual serão capazes de visualizar e, por fim, resolver os problemas baseados em suas respectivas perspectivas.
Para ilustrar essa idéia, imagine-se olhando uma árvore á 100 metros. Quando se pede para focalizar uma folha da árvore, um desenvolvedor irá, de forma inata, focar nos detalhes da folha: sua forma, cor, textura, etc. Por outro lado, o arquiteto olha para a mesma árvore, porém ser perder de vista a árvore como um todo.
Portanto, quando se fala sobre desenvolvimento de software, os arquitetos vêm as folhas como componentes que se relacionam entre si, desse modo, deixando livre o desenvolvedor para se preocupar com o desenvolvimento de um componente. Grosso modo a força de um desenvolvedor está na habilidade de mergulhar e ajustar uma implementação existente como Java, Enterprise JavaBeans, Hibernate, ou C + + para resolver um dado problema. A força de um arquiteto reside na habilidade de desenvolver uma implementação para um contexto de uma solução, sabendo como resolver um contexto do problema versus resolver o problema em si distingue o arquiteto do desenvolvedor.
Um arquiteto deve ser adepto das metodologias de orientação a objetos, design patterns e UML e, mais importante, ter a disciplina para reforçar a utilização de padrões enquanto exerce as melhores práticas. Com tudo isso em mente, o objetivo desse artigo não é demonstrar que um arquiteto é mais valioso que um desenvolvedor ou vice-versa, mas que um complementa o outro. O objetivo é forçar a indústria de desenvolvimento de software a enxergar as diferença nos novos papéis na tecnologia Java.
A diferença é então a maneira como eles codificam? Ou nos anos de experiência? Enquanto em alguns momentos andar sobre a água seja uma tarefa mais fácil de ser atingida do que muitas das tarefas que encaramos em Java, a diferença entre um arquiteto e um desenvolvedor é a amplitude de conhecimento versus a profundidade do conhecimento.
Por exemplo, uma empresa, como havia anunciado, procurava por um arquiteto, mas na verdade, perdeu muito tempo até perceber que realmente precisava de um desenvolvedor disciplinado que seguisse as boas práticas de programação. Mesmo assim, cordialmente prosseguia entrevistando, sabendo que seria uma perda de tempo, tanto para os candidatos, quanto para eles próprios. E tenho certeza que o desenvolvedor entrevistado pensava: “ Como esse cara pode ser um arquiteto sem saber tudo sobre Spring, Hibernate e Struts? ” O que muitos entrevistadores não percebem é que o objetivo de um arquiteto não é dominar detalhes de implementações existentes. Ao contrário, o objetivo é aglutinar a essência de várias tecnologias para resolver problemas, ou melhor ainda, encontrar maneiras de criar implementações inteiramente novas.
Na essência, o trabalho do arquiteto é incorporar o núcleo da programação orientada a objetos: maximizar o re-uso de componentes. A disciplina de delinear claramente as funções do trabalho. Os arquitetos são geralmente idealizados como gurus. A realidade é que eles não são gurus. Ao contrário, eles são os visionários da criatividade de uma organização Java do futuro. Pense nisso da seguinte maneira: uma editora não contrataria um escritor esperando que ele faça o papel de um editor simplesmente pelo fato deles saberem escrever. Construtoras não contratam arquitetos esperando que eles vão cimentar paredes pelo fato deles saberem ler plantas baixas. Portanto, por que se espera que arquitetos Java façam o papel de desenvolvedor simplesmente porque sabem codificar? A Sun tem diferenciado claramente arquitetos de desenvolvedores pelo fato de oferecer dois tipos distintos de exame: o Sun Certified Developers Exame o Sun Certified Enterprise Architects Exam.
Como nos sairíamos se estudássemos o ano todo para o exame de arquiteto, aprimorando suas habilidades em análise orientada a objetos, desenvolvimento orientado a objetos, Unified Modeling Language (UML), etc., para depois aparecer no exame e descobrir que fazremos o exame de desenvolvedor? A única diferença seria o título do exame? Entretanto, encaremos a realidade das contratações em TI.
Para uma boa relação custo beneficio, as empresas, atualmente preferem contratar profissionais que são meio-arquiteto / meio-desenvolvedor. Sem dúvida, para ser um bom desenvolvedor, deve-se ter um sólido conhecimento na arquitetura da tecnologia Java. Inversamente, para ser um bom arquiteto, deve-se também ser um bom desenvolvedor. Consequentemente, quando se usa a idéia do profissional meio-arquiteto / meio-desenvolvedor, a organização acaba por contratar um generalista, não um especialista.
No final das contas, essa falta de decisão acaba por criar uma distorção no seu projeto. Comparada ás outras industrias, quando se discute a disciplina de delimitação clara de funções, a indústria de desenvolvimento de software ainda é relativamente imatura.
As vantagens de se definir papéis claros.
No ciclo de vida do desenvolvimento de software, quanto maior a perspectiva do domínio do problema, mais compreensível e confiável será a solução. As vantagens de se definir papéis claros entre desenvolvedores e arquitetos em uma organização, é a maneira pela qual serão capazes de visualizar e, por fim, resolver os problemas baseados em suas respectivas perspectivas.
Para ilustrar essa idéia, imagine-se olhando uma árvore á 100 metros. Quando se pede para focalizar uma folha da árvore, um desenvolvedor irá, de forma inata, focar nos detalhes da folha: sua forma, cor, textura, etc. Por outro lado, o arquiteto olha para a mesma árvore, porém ser perder de vista a árvore como um todo.
Portanto, quando se fala sobre desenvolvimento de software, os arquitetos vêm as folhas como componentes que se relacionam entre si, desse modo, deixando livre o desenvolvedor para se preocupar com o desenvolvimento de um componente. Grosso modo a força de um desenvolvedor está na habilidade de mergulhar e ajustar uma implementação existente como Java, Enterprise JavaBeans, Hibernate, ou C + + para resolver um dado problema. A força de um arquiteto reside na habilidade de desenvolver uma implementação para um contexto de uma solução, sabendo como resolver um contexto do problema versus resolver o problema em si distingue o arquiteto do desenvolvedor.
Um arquiteto deve ser adepto das metodologias de orientação a objetos, design patterns e UML e, mais importante, ter a disciplina para reforçar a utilização de padrões enquanto exerce as melhores práticas. Com tudo isso em mente, o objetivo desse artigo não é demonstrar que um arquiteto é mais valioso que um desenvolvedor ou vice-versa, mas que um complementa o outro. O objetivo é forçar a indústria de desenvolvimento de software a enxergar as diferença nos novos papéis na tecnologia Java.
Nenhum comentário:
Postar um comentário