Author Archive for

18
jun
08

A importância de estudar constantemente

Já faz tempo que venho ensaiando este post. Minha idéia é mostrar como é importante na nossa profissão de “desenvolvedor” estar constantemente aprendendo novas técnicas, linguagens, frameworks, metodologia, etc. Com um mercado tão competitivo como o de Desenvolvimento de Software, não podemos nos dar o luxo de conhecer apenas uma linguagem. Evidente que é bom que você escolha uma para se especializar, mas de forma alguma deve ser a última linguagem que você aprenderá.

Há algum tempo atrás, orientação a objetos era uma coisa de outro mundo para mim. É sério, não conseguia pensar na possibilidade de existir outro paradigma de programação. Bem, depois que estudei muito sobre OO e passei a utilizar profissionalmente, hoje não consigo me imaginar trabalhando sem OO. Tudo fica claro, organizado, abstraído… O que eu ganhei com isso? Com certeza consegui ser mais produtivo, mais organizado e mais eficiente e, como consequência, melhor remunerado. Se ainda desenvolvesse proceduralmente, certamente ainda desconheceria conceitos e técnicas, sendo apenas mais um na multidão. E não é assim que um verdadeiro desenvolvedor ágil quer ser visto, certo?

Outra coisa que estudei muito e hoje fico feliz em utilizar profissionalmente são Testes Unitários. Uma das premissas do desenvolvimento ágil está relacionada à qualidade do código. Com testes unitários é possível desenvolver incrementalmente e responder rápido às mudanças pois seu código está “protegido”. Além de servir como apoio à refactoring. O que eu ganho com isso? Consigo me preocupar apenas com o desenvolvimento de uma pequena funcionalidade por vez, meu código fica mais “limpo” e manutenível. Em consequencia disto me torno mais ágil e sou melhor remunerado. Além de poder dormir mais tranquilo…

É importante reconhecer que há muito para aprender ainda. Nosso cenário de trabalho muda constantemente e os “usuários” são cada vez mais exigentes. Além disso, é importante lembrar que não existe bala de prata, não existe uma tecnologia que resolve todos os problemas. As linguagens e tecnologias são limitadas e precisam evoluir. Você precisa evoluir junto! Não se esqueça também que lá fora tem um mercado de trabalho começando a enxergar essas qualidades ágeis.

Anúncios
28
maio
08

Ressuscitando o webdesigner

Ultimamente temos acompanhados posts-desabafo sobre metodologias e o cenário atual do mercado de desenvolvimento de software. Pois bem, mudemos de assunto um pouco.

Outro dia estava tendo uma conversa discussão com meu amigo Nivaldo sobre interfaces web com uso abusivo de javascript. Aí lembrei o que o Miguel disse sobre interfaces citando como parâmetro o Google e a Apple e a pouca importância que as empresas dão para esse assunto.

O mercado (alvo) está cada vez mais competitivo. Usuários não querem simplesmente um sistema funcional; ele deve ser bonito, intuitivo, agradável de usar. Um bom exemplo do que estou falando é o popular Goggle Reader: será que estaria tão popular se não fosse sua interface “rica”?

Acredito que atualmente, para sistemas web, a interface deve(ria) ser o principal “exciter” e onde as forças devem atuar consideravelmente. Digo isso porque as outras partes de um sistema (estou falando do negócio e banco de dados) estão razoávelmente maduras em termos de conceitos (OO, Teste, ORM), frameworks, etc.

Foi o tempo em que precisavamos saber apenas escrever código funcional. O desenvolvedor de hoje precisa saber muito bem HTML, CSS e JavaScript. E para isso, felizmente podemos (e devemos) utilizar recursos e frameworks para isso.

26
maio
08

O paradoxo: iterativo-incremental x confiança

Recentemente trabalhei em uma empresa de pequeno porte tentando implantar (ensinar, vender, disseminar, ou outro termo que caiba aqui) Scrum na tentativa de organizar e agilizar o processo de desenvolvimento do software da empresa, que até o momento só conhecia (e conhece) Waterfall.

As desculpas da empresa para não adotar Scrum (ou outro processo ágil) são todas apoiadas em confiança (ou desconfiança): como confiar num projeto que não tem tudo detalhadamente especificado desde o início? Era comum ouvir: “só isso não vai dar certo”, “precisamos detalhar todas as funcionalidades primeiro”, “não quero chegar lá na frente e ter que mudar alguma coisa hein”, “o cliente não vai querer comprar uma coisa que ele nem sabe o que é”.

Na ocasião, encontrei este artigo falando sobre desenvolvimento iterativo e incremental, e utilizei estas imagens para (tentar) argumentar meu ponto de vista.

Iterativo:

Incremental:

É evidente que ninguém entendeu a mensagem. Para eles, a confiança ainda estava em jogo. Em termos de proteção, o Waterfall ainda garante uma “falsa segurança” à empresa: “estamos entregando apenas o que estava documentado nas especificações”, “a documentação nos protege”.

Bom, tá aí um resumo da minha experiência e tenho certeza que vocês já passaram por algo parecido. Continuamos nos comentários…

16
maio
08

Proposta de discussão: banco de dados

Diferente do meu blog, onde o foco é apresentar as idéias “mastigadas”, aqui eu pretendo gerar discussões para que possamos entrar num consenso.

Primeiro, deem uma olhada neste artigo que apresenta bancos de dados como commodities, ou seja, qualquer um serve. Depois tem mais esses posts sobre ORM e Frameworks que também acho interessante.

Agora gostaria de saber a opinião de vocês: dado um sistema não crítico de mercado (tipo um CRM, e-commerce, portal, etc), onde mais de 50% das funcionalidades são CRUD, 30% relatórios e os 20% restantes alguma lógica e processamento, a escolha do banco de dados e a forma com que os dados serão manipulados são os principais fatores determinantes do sucesso de um projeto?

1… 2… 3… Valendooo!

15
maio
08

A ferramenta/metodologia que ainda não existe.

Este é meu primeiro post aqui no 1up4developers e tentarei ser objetivo.

É fato que a maioria das empresas de desenvolvimento de softwares são desorganizadas, têm problemas nas entregas, falta documentação, etc. Outro ponto em comum é a espectativa de resolver todos os problemas apenas adotando uma ferramenta/metodologia de nome forte ou que ainda não foi inventada.

Só para ilustrar essa afirmação, vou expor algumas situações reais que presenciei:

Multinacional alemâ com dificuldades no levantamento de requisitos e testes buscou resolver seus problemas com uma suíte de produtos da Borland. Não deu certo.
Empresa nacional de médio porte quando enfrentou uma crise financeira por não conseguir cumprir datas buscou solução contratando uma consultoria especializada e “organizar” a bagunça. Não deu certo e deixou a empresa à beira da falência.
Empresa nacional de pequeno porte pretendia migrar a tecnologia/plataforma de desenvolvimento fornecendo cursos para seus desenvolvedores na esperança de melhorar o processo e a qualidade de seu produto. O resultado foi desastroso.

É comum hoje ouvirmos nomes como RUP, XP ou Scrum como a solução para todos os problemas de uma empresa. Outros nomes como UML, Testes Unitários e TDD também têm ganhado espaço nessa lista de “celebridades”. O erro das empresas é achar que esses nomes são “roupas” que podem ser vestidas ou trocadas facilmente. Elas têm um problema X e acham que resolvem aquilo adotando uma ferramenta/metodologia Y.

A grande solução para esses problemas são as pessoas, os profissionais da empresa. Encorajar o desenvolvimento profissional, incentivar financeiramente, deixar os profissionais à vontade para opinarem são alguns pontos que geram resultados a longo prazo. Valorizar o profissional na contratação também é muito motivador ao invés de tentar negociar seu salário com base em seu tempo de experiência ou quantidade de ferramentas que já trabalhou.

Só para finalizar o post, esperando que tenham entendido a mensagem, fica um artigo do Fowler falando de quando o barato sai caro.




Saiba mais sobre nós

RSS Feeds

outubro 2017
S T Q Q S S D
« ago    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Feed Counter

Blog Stats

  • 1,115 hits

tail -10f /top-posts

RSS job4dev

  • Ocorreu um erro. É provável que o feed esteja indisponível. Tente mais tarde.