Dicas de programação e gerência de software

[mad.onion 0]

Saudações pessoal.

 

Sou novo aqui no fórum iMasters, mas já gostaria de iniciar minha participação deixando algumas dicas de desenvolvimento de software que colhi ao longo do meu tempo de estudo, formação e experiência. Obviamente pode haver subjetividade, por isso tento abrir aqui um espaço para discussão e postagem de novas dicas.

 

um abraço!

 

8 dicas de programação, gerência e projeto de softwares (.NET, Java ou outros)

 

Engenharia e desenvolvimento de software, ao mesmo tempo que é um trabalho, pode ser um hobby para quem está no comando, principalmente para os profissionais que estão totalmente comprometidos com sua obra. Por este motivo o assunto programação acaba se tornando delicado no meio destes profissionais, pois quase sempre tem sido combustível de discussões entre colegas e companheiros de trabalho. E por incrível que pareça, na grande maioria das vezes, todos os lados quase sempre estão errados quanto aos seus conceitos. É por causa disso que destas discussões pouco ou nada se aproveita. Mas o porquê do profissional de software agir desta forma, um pouco egoísta, ainda é uma incógnita para mim (e para muitos). Uma hipótese que levantei seria que, por sempre se tratar de um assunto complexo, as pessoas naturalmente evitam perder tempo pesquisando e tentam deduzir por si só, causando assim inúmeras discórdias ou enganos.

 

Listarei aqui algumas dicas de trabalho que aprendi com o tempo. Como são dicas pessoais, naturalmente muitos podem discordar, mas encorajo ao leitor a corrigir, contribuir e aumentar essa lista com as suas próprias experiências.

 

 

1 – Estude. Estude muito. E estude certo.

 

Não seja um programador “achista” ou um enganador. Um bom programador nunca deve parar de estudar, buscar, ler (livros e não besteiras) e tentar entender os limites e detalhes de qualquer plataforma ou linguagem, inclusive dos bancos de dados. Ninguém pode desenvolver um bom software em Java, .NET ou qualquer linguagem de programação, ou modelar uma base de dados decente, sem antes dominar os limites e as possibilidades de cada plataforma de desenvolvimento.

 

É comum um programador tentar deduzir como alguma coisa deve funcionar baseando-se em “achismos” criados por sua forma de pensar ou apoiando-se em opiniões de outros “achistas respeitados”, assumindo um erro como se fosse a mais pura verdade, enganando a si mesmo por muito tempo e propagando informação incorreta. E tudo, muitas vezes, graças à preguiça de pesquisar ou até mesmo em não conhecer que dúvidas que parecem "problemões" podem ser esclarecidas de forma rápida e muito fácil em bons livros ou na própria documentação da plataforma. Além disso, as atualizações e novos conceitos nunca param de surgir. Se você para de estudar, deixa de conhecê-las.

 

Costumo dizer que uma linguagem de programação como C/C++ ou Pascal (Delphi) são complexas como grandes livros, mas que plataformas como Java ou .NET são como bibliotecas ou livrarias destes grandes livros. Por causa deste enorme conjunto de classes e conceitos que formam as duas plataformas, é bem fácil encontrar pessoas que aprendem o “hello world” e a partir disso passam a acreditar que já acumulam conhecimento suficiente para desenvolver um bom trabalho (muitas vezes negando a possibilidade de que precisam ler e estudar). Quando lêem o primeiro livro (de dezenas), aquele de 800 páginas, ficam surpreendidos e acordam para a realidade de que há muito ainda a aprender. Infelizmente, são poucos os que acordam e muitos os que continuam vivendo no maravilhoso mundo filosófico da programação.

 

 

2 – Não guarde todos os detalhes, mas não seja apenas um "programador Google"

 

Um “programador Google” é aquele programador que não conhece quase nada, apenas entende a lógica de programação (ou as vezes nem isso), mas que busca resolver os seus problemas pesquisando no Google e copiando código e ideias de outros. Isso não é um crime, mas não é uma boa prática visto que desta forma o programador geralmente não sabe o que está fazendo, perdendo o controle de parte ou de todo o software. Se algum problema ocorrer com a ideia ou código achados na internet, o programador Google terá dificuldades para resolver e será bem difícil encontrar o autor original para ajudar.

 

Pesquisar em fóruns, perguntar a outros programadores, procurar no Google, tudo isso é saudável e ajuda a ganhar conhecimento, desde que este comportamento não se torna a prioridade na vida do desenvolvedor. A prioridade tem que ser sempre buscar ajuda em livros, de preferência de autores da plataforma ou na documentação oficial. O restante sempre tem que ser a segunda opção de pesquisa, até mesmo por causa da comum disseminação de informação equivocada ou incompleta. Em livros da Microsoft sobre o .NET, de autores do Java e suas classes ou de gigantes do mundo C++, não há espaços para imaginações ou deduções, são a verdadeira fonte de informação, vinda de quem criou a plataforma ou de quem a vivencia diariamente a longos anos.

 

Ler livros oficiais também requer um bom domínio de inglês, pois as melhores e mais confiáveis publicações são aquelas escritas por seus autores e geralmente não são traduzidas para português. Se tempo for um problema, estude em casa, proponha um novo cronograma para o chefe ou na pior das hipóteses, vá trabalhar em um lugar mais sério.

 

É muito comum ver isso acontecer com Javascript, uma linguagem poderosa e relativamente de fácil compreensão, mas que a grande maioria de web designers nem querem tomar conhecimento, apenas copiam scripts prontos e encaixam em suas soluções. Javascript possivelmente é a linguagem mais utilizada por programadores que a desconhecem.

 

Outra dica valiosa: cuidado com livros de autores enganadores, que julgam anos de experiência com isso ou aquilo, prêmios, etc. etc. Novamente, procure sempre livros dos autores das plataformas. Por exemplo, se vai estudar .NET, dê preferência às publicações da Microsoft Press, que são escritas pelas pessoas envolvidas diariamente no desenvolvimento do .NET, (do Java, procure da Sun Press, livros da própria Sun) ou procure livros de autores largamente recomendados, que tiveram contato com o desenvolvimento da plataforma (como é comum em Java). Cuidado com autores que só querem fazer dinheiro. Seus livros são pura perda de tempo, não dão conhecimento consistente para as certificações e possivelmente, nem para o dia a dia. E por falar em certificações, se o objetivo do estudo é este, recomendaria nem pensar em outro material de estudo que não seja o oficial.

 

 

3 – Seja flexível e humilde

 

Ninguém sabe tudo. Se você sentir que encontrou um programador mais experiente e sábio que você, seja humilde, reconheça e aprenda com ele. Nunca fique batendo boca ou discutindo em vão, afirmando algo que não sabe ou não tem certeza. Se não tem certeza, não dê certeza. Procure ter embasamento antes de falar, cite as fontes de onde você tirou a informação para dar créditos e embasar suas opiniões. Não seja orgulhoso ou queira mostrar que tudo aquilo que você sabe, você tirou da cabeça apenas deduzindo. Isso é o bastante para seu chefe ou gerente não te dar credibilidade. Se falar alguma "borracha" em uma discussão de ideias, volte atrás o mais rápido possível assim que identificar o erro e corrija você mesmo. Isso vai te dar créditos para discussões futuras em reuniões técnicas.

 

Não dê ouvidos ou se preocupe com aquelas pessoas fracas de cabeça, gerentes tóxicos ou colegas de trabalho ignorantes, que acham que sabem tudo, mas na verdade só falam besteira. É questão de tempo até que estas pessoas sejam vítimas de seus próprios erros e enganos. Faça sua parte tentando ajudá-los.

 

Manter essa postura, juntamente com as dicas acima, fará com que você aprenda bastante e evolua em pouco tempo. Superando o conhecimento médio dos profissionais do mercado, você pode começar a ter maiores dificuldades em encontrar pessoas que conhecem mais do assunto do que você. Isso não é uma piada ou brincadeira, é naturalmente o que vai acabar acontecendo a cada dia que você evolui devido a postura excessivamente complacente da maioria dos profissionais desta área. Por causa disso, fique atento para não perder a humildade e não ser vaidoso e ignorante com quem conhece menos. Ninguém é melhor do que ninguém, nem por saber menos ou mais. Aproveite suas experiências adquiridas e ajude o teu próximo, porque um trabalho mal feito pode afetar a todos, inclusive você.

 

Não subestime as pessoas, pois você poderá ser pego de surpresa. Sempre haverá alguém que sabe mais do que nós, por mais difícil que se torne isso a cada nova lição que aprendemos. O conhecimento é aberto a todos e todos possuem a capacidade de superar.

 

 

4 – Programe didaticamente e explicitamente. Crie um código auto-explicativo. Não sacrifique o entendimento por fantasias de um desempenho milimétrico onde não há necessidade. Não seja ocultista ao programar em equipe, nem crie códigos obscuros.

 

Se você trabalha em uma equipe, não pode ser egoísta e programar para seu próprio entendimento. Um programador sempre tem tendência a criar rotinas exatamente na forma como se sente mais confortável e pior ainda quando começa a tirar da cabeça que deve sempre levar o desempenho máximo em questão. Não se engane: nenhum software gestor de negócios no mundo precisa do desempenho de um software científico ou de alto consumo computacional, a ponto de que fará diferença cada milissegundo ou byte consumido na memória, comprometendo assim a legibilidade e a estrutura do código a fim de favorecer uma fantasia pessoal.

 

É comum programadores quererem sempre desempenho em primeiro lugar, mas é óbvio que isso depende do tipo de software a ser construído. Além do mais, nem sempre é possível chegar ao desempenho esperado por culpa de falhas no projeto e não da forma como se programa (por exemplo, uma base de dados mal projetada). Novamente, não tire as coisas da cabeça. Em caso de dúvidas quanto ao desempenho de determinada rotina versus a outra, pesquise e faça testes, conferindo se vale a pena realmente sacrificar uma boa estrutura e organização de código em prol de alguns milissegundos ou bytes a menos. Para isso, aprenda antes a como calcular custo computacional (que tal uma pesquisa rápida do assunto?), principalmente se for em um ambiente distribuído ou Web.

 

Determinado que desempenho milimétrico não é um fator importante em aplicações comerciais, projete seu código para ser mais didático e auto-explicativo, mesmo que isso custe alguns milissegundos (nem sempre irá custar e se bem trabalhado, pode ficar inclusive mais performático do que o modo Formula 1 fantasioso). Didática é a arte de ensinar com método os princípios de uma ciência ou as regras e preceitos de uma arte, segundo o dicionário Priberam da língua portuguesa. Para facilitar o entendimento do código para o seu companheiro programador, e até mesmo para você no futuro, descreva seu código como se estivesse ensinando o processo para alguém que não sabe nada. Procure dividir (lembre-se do dividir para conquistar!) a rotina em blocos que façam sentido e que instrua o cérebro de qualquer ser humano (até mesmo os de menor capacidade) sobre como se deve proceder em determinada rotina. Sempre que pensamos em um algoritmo, nós pensamos no passo-a-passo, mas nem sempre que passamos isso para o código, o fazemos desta forma. Fazemos buscando atalhos e diminuindo linhas de código (alguns inclusive, conseguem tirar totalmente o sentido de um algoritmo quando o passam para o código) porque dentro da nossa cabeça já conhecemos o processo. Entretanto, o código é público à equipe e o próximo programador pode ser um que nada conhece daquele processo. A situação pode ainda piorar se o software não possuir documentação, algo muito comum hoje em dia. Portanto, ensine-o no próprio código! E não se engane novamente: nem sempre diminuir as linhas de código pode ser uma vantagem ou sinal de desempenho.

 

No exemplo abaixo, verifique qual é a melhor e mais rápida forma de localizar um problema, momentos após mexer os ovos em uma rotina para se fazer uma omelete:

 

//Rotina para fazer omelete, modo obscuro com função [i]Megazord[/i]:

Fazer_Omelete(ovos, frigideira, prato, tempo_espera, geladeira, verificar()...);  
Comer();

//Rotina para fazer omelete, modo didático:

Abrir_Geladeira();
Ovos = Pegar_Ovos(3);
Verificar_Integridade(Ovos);
Prato = Quebrar_Ovos(Ovos);
Mexer_Ovos(Prato);
Colocar_na_Frigideira(Prato);
Esperar_Minutos(5);
Comer();

Claro que o exemplo é bobo, mas é fácil perceber que a rotina didática e auto-explicativa já te leva direto ao assunto onde está ocorrendo o problema sem fazer você perder tempo procurando onde está o código que mexeria os ovos em meio a centenas de linhas. Esta é só uma pequena vantagem de se programar orientado ao entendimento. Além disso, não é preciso perder desempenho para favorecer o entendimento, na maioria das vezes é possível conciliar os dois, basta conhecer bem a plataforma e suas possibilidades e parar de tirar as coisas da cabeça sem antes validar a realidade. Só tome cuidado para não criar uma “rotina mosaico”, formada por centenas de funções que isoladas perdem a utilidade, causando um function overhead (que tal outra pesquisa?) e uma canseira desnecessária no leitor de seu código.

 

Procure deixar junto, na mesma função, as rotinas que tenham ligações uma com as outras. Procure isolar as funções do meio externo, evitando variáveis de escopo global (isso é um saco para quem está dando manutenção). Deixe os blocos do seu código o mais independente de variáveis externas possível. Com o tempo e treinamento, a ideia fica mais fácil.

 

Outra dica valiosa: use e abuse da orientação a objetos para favorecer o entendimento. É visto a seguir.

 

 

5 – Entenda orientação a objeto de uma vez por todas e use e abuse deste conceito.

 

Tenho visto uma imensa quantidade de programadores que ainda não conhecem e outra imensa quantidade que “conhece” o conceito de orientação a objetos, entretanto, ainda possuem uma enorme dificuldade em aplicá-lo de forma correta. Muitos erroneamente utilizam o conceito para definir módulos (culpa de um vício antigo), outros utilizam classes para definir uma “cesta de atalhos e utilitários” ou até mesmo aglomerar métodos e atributos que não têm ligação com o objeto em questão, transformando algo que era pra ser um objeto em algo totalmente sem sentido, servindo apenas para uso do próprio criador ou para apenas uma aplicação. O paradigma de orientação a objetos foi criado pensado exatamente em melhorar a reutilização de um código já escrito, no entanto, muitos programadores ainda teimam em não entender isso de forma clara. Não vou aqui entrar em detalhes sobre o conceito de orientação a objetos (para isso existem bons livros por aí), mas vale destacar algumas dicas rápidas:

 

Use orientação a objetos com a mentalidade de que é um conceito criado de programador para programador, isto é, o usuário de sua(s) classe(s) será um programador. Cria-se uma classe pensando que outro programador vá consumi-la (claro que pode ser você também), e, portanto, você precisa decidir com atenção o que e o que não deve ser exposto de forma pública, evitando abrir brechas para o usuário de sua classe cometer algum erro ou comprometer a integridade dos dados dentro dos objetos.

 

Nunca se esqueça de direcionar o desenvolvimento de suas classes pensando em outros programadores: o que eles poderiam fazer de errado consumindo sua classe, o que eles vão precisar para ter acesso a todas as funcionalidades necessárias e se a classe abstrai o objeto de forma coerente, a fim de aliviar o peso do usuário de tarefas maçantes e “perigosas”, sem tirar dele o controle necessário para atingir o objetivo final. Usando o exemplo básico do carro, o motorista (programador usuário) não precisa colocar a mão dentro da caixa de câmbio do veículo, empurrar as engrenagens para o local certo e no momento exato das rotações do motor e das rodas, para mudar a marcha. Ele só pisa na embreagem e coloca uma marcha através do câmbio do carro. Mudar a marcha é uma função que está encapsulada dentro do carro (classe) e o motorista (programador) não precisa conhecer os detalhes (a função abstraiu o processo), apenas a utiliza para mudar a marcha.

 

Sua classe precisa representar um objeto (geralmente abstrato), e não dois ou três objetos, ou nenhum. Muitos programadores têm a péssima mania de misturarem funcionalidades de vários objetos dentro de uma só classe, tentando criar uma espécie de cesta de utilitários, mas que na verdade fica extremamente confuso para outro programador entender. Um objeto é um objeto. Um carro não pode ter uma asa ou uma hélice. Se tiver, não é mais um carro. Para tal, criar-se-ia outra classe batizando-a de avião. Por exemplo, uma classe de acesso a dados deve expor métodos e propriedades para tal (prover acesso aos dados) e não para buscar colunas em uma tabela de cliente ou buscar todos os registros de determinada tabela. Entenda que esse papel seria de outro objeto, como por exemplo, no modelo ORM onde as tabelas do banco de dados são encapsuladas em objetos. No início, é muito comum um programador inexperiente cometer estes erros, porque criar uma representação sólida de um objeto abstrato nem sempre é fácil. Mas, com o tempo e exercícios, essa tarefa vai ficando cada vez mais natural.

 

Codifique suas classes deixando-as o mais independentes possível do meio externo. É comum ver programadores criarem classes de acesso a dados que, teoricamente, deveriam ser só isso, mas que entre seus métodos ,realizam tratamento de erros fazendo chamadas a outras classes específicas (como formulários do Windows ou Web), impedindo assim que a classe seja reutilizada fora do escopo ao qual ela foi criada. A ideia de uma classe de acesso a dados é prover, de alguma forma, acesso ao banco de dados, mas não tratar erros, exibindo mensagens em caixas de texto ou páginas Web. Se no exemplo citado os erros de acesso a dados forem tratados diretamente dentro da classe, fazendo chamadas, por exemplo, a formulários do Windows para exibir mensagens de erro, sua classe não terá utilidade em formulários Web sem ter de ser reescrita. Ao contrário disso, não trate o erro dentro de sua classe de dados (tratar uma exceção significa dar sentido do erro para o usuário final, por exemplo, com uma mensagem mais amigável). Uma forma de resolver o problema do exemplo citado é retornando o erro em um formato desejado (uma classe de exceção ou uma classe customizada) deixando o tratamento da exceção para a camada visual (recebendo o código do erro e procedendo da forma necessária), qualquer que seja ela. Desenvolva as suas classes pensando sempre em reutilizar o código, afinal, essa é uma das maiores vantagens da orientação a objetos. Isso exige que haja um cuidado com referências externas e métodos específicos dentro de classes.

 

Lembre-se que ao criar uma classe, você deve pensar em abstrair o trabalho delicado e minucioso, tornando-o transparente para o programador que vá consumir o objeto. Isso exige que você pense em o quê e onde deve ser tirada a responsabilidade do programador usuário da sua classe. Ainda com o exemplo acima, você não pode garantir que todos os usuários de sua classe de acesso a dados vão se lembrar de colocar dentro de um bloco try, funções que potencialmente podem gerar exceções e finalizar a aplicação. Conhecendo esta limitação, você resolveria esse problema tirando essa responsabilidade do usuário de sua classe, tratando as potenciais exceções dentro da classe e retornando ao programador usuário uma mensagem mais amigável, como por exemplo, um número indicando uma mensagem de erro específica ou sucesso na execução. Desta forma, caso ele não trate eventuais problemas, um método de sua classe não irá finalizar a aplicação com uma mensagem de exceção não tratada, algo extremamente deselegante e amador.

 

 

6 - Deixe o código consistente

 

Programador adora falar em padrão, mesmo quando nem sabe o que é isso. Se você começou um projeto de um jeito, termine-o do mesmo jeito. Quando se fala em padrão, as pessoas têm de entender que isso não são apenas regras a serem seguidas de como declarar variáveis. Padrão é principalmente seguir um modelo consistente de ideias, fluxo e ordem de etapas, do início ao fim do projeto.

 

Consistência não é só usar um padrão para dar nome às variáveis e funções, é também consistir a forma e a ordem com que os procedimentos são utilizados. Não queira alterar uma ideia no meio do projeto porque você percebeu que algo poderia ser melhor, sem corrigir tudo o que já foi feito. Se não tiver tempo para corrigir o passado, não mude para melhor agora, termine o projeto do jeito que foi iniciado e implemente as melhorias em um próximo projeto, a fim de não prejudicar o entendimento do próximo profissional que for manter o seu trabalho.

 

Como exemplo, posso passar uma experiência que tive, onde peguei um código fonte para alterar. Havia algumas funções de acesso a dados (com uns "500" overloads cada) já prontas para serem utilizadas, criadas ao longo do tempo por diferentes programadores. Quando fui tentar entender como reaproveitá-las, tive uma certa dificuldade em determinar a forma correta de usá-las, já que a cada momento no código elas eram utilizadas de formas diferentes, mas sempre com o mesmo resultado. Uma função era responsável por criar um comando para ser executado no banco de dados e havia três modos diferentes de preencher os parâmetros deste comando. Em várias partes do código era usado um vetor com os parâmetros, passados através de uma função. Já em outras, criavam-se os parâmetros um a um e atribuía-se posteriormente ao comando, sem utilizar a função criada para tal. A terceira era uma função megazord usada para preencher parâmetros de stored procedures. Essa função conectava no banco de dados, pegava os tipos e números de parâmetros da procedure e só se passava os valores através de um vetor (maldita mania de criar vetores no lugar de variáveis!). Isto é, com esta última função, além de quebrar a consistência das rotinas de acesso a dados criando três modos distintos de preenchimento de parâmetros de comandos SQL, não satisfeito o autor foi adepto do ocultismo, deixando encoberta várias informações importantes, como os nomes e tipos dos parâmetros que devem ser explícitos no código a fim de facilitar o entendimento e a manutenção.

 

 

7 – Adote um modelo de programação modular, independente, mais conhecido como Modelo em Camadas.

 

Novamente bato na tecla de independência. Quanto mais suas classes, blocos, camadas, módulos ou funções forem independentes do meio externo, maior será sua utilidade em outras aplicações (ou até mesmo dentro da própria aplicação, quando se trata de funções) e consistência dentro da aplicação em que foram criadas. No entanto, alguém pode pensar porque é que se deveria preocupar tanto com independência.

 

A princípio, temos duas vantagens. A primeira é justamente reutilizar o código em outras aplicações. Se você já fez uma vez, porque irá fazer novamente o mesmo serviço? Planeje para fazer uma vez só e bem feito. A segunda e a mais importante está em NÃO criar um relacionamento direto de uma estrutura com a outra, de modo que a alteração em uma não afete o funcionamento da outra. Por exemplo, uma estrutura A (camada de negócios) tem de depender apenas do produto de saída da estrutura B (camada de acesso a dados). Desta forma, a camada de negócios trabalha com e espera apenas o retorno da camada de acesso a dados, de modo que qualquer alteração no interior desta última não afete o funcionamento da camada de negócios.

 

A arquitetura de software em camadas casa melhor com linguagem orientada a objetos, de modo que uma camada pode vir a ser representada por uma classe e utilizada como um objeto. Contudo, dependendo da complexidade de uma aplicação, uma ideia melhor é dividir as camadas em projetos (bibliotecas dll, por exemplo) e dentro de cada projeto cria-se quantas classes forem necessárias para uma melhor estruturação. Outra ideia, já bastante comum e elegante, é implementar, quando possível, uma camada dentro do banco de dados. Geralmente é uma ótima ideia codificar a camada de regras de negócio dentro do banco de dados, dando assim uma maior portabilidade à aplicação (fora a consistência melhorada), caso no futuro seja necessário trocá-la de plataforma (por exemplo, de Windows Forms para Web). Aqui entra o fator "pessoal" (e as vezes o fator "falta de conhecimento de constraints, triggers, e afins), pois existem pessoas que preferem criar a camada de negócios no banco, outras na aplicação (geralmente quem não gosta de lhe dar com banco de dados) e outras que misturam. Pessoalmente, para aplicações Web eu prefiro deixar tudo no banco. Em um servidor Web, tanto faz as regras serem processadas na aplicação ou no banco com relação ao desempenho, porque o processamento continuará ficando centralizado (diferentemente de aplicações desktop, onde cada máquina rodando a aplicação cliente é responsável pelo processamento das regras). Uma vez que o processamento continuará centralizado e não distribuído, eu prefiro tratar esta camada no banco, até porque eu acho mais elegante e útil deixar este tratamento mais próximo dos dados, já que não é difícil hoje em dia aplicações externas acessarem o banco de sua aplicação para capturar dados ou fazer outro trabalho. Desta forma, se as regras estão no banco, você tem uma garantia de que qualquer outra aplicação (ou acesso manual) que acessar o banco não estará infringindo as regras de negócio e criando inconsistências. Se você é um daqueles que odeia banco de dados e prefere a facilidade do Java ou C#, recomendo estudar os benefícios de se programar diretamente em um sistema de banco de dados. Em uma empresa bem estruturada, um programador não teria a responsabilidade do banco nem das regras. No entanto, hoje em dia empresas bem estruturadas com DBAs, arquitetos e cia., estão em extinção. Sendo assim, uma grande dica para o desenvolvedor de aplicações cliente-servidor que não gosta ou não conhece bem como funciona um sistema gerenciador de banco de dados é passar a gostar e a aprender, pois já é uma necessidade real do mercado.

 

Basicamente a maioria das aplicações comerciais e de gestão é desenvolvida em três camadas: a camada de dados, a camada de negócios ou de controle e a camada visual. Porém, se for preciso granular mais ainda a modularidade, que seja feita de forma cuidadosa e planejada. Sempre que for criar uma camada (ou mesmo classes, funções, módulos, etc. a idéia é a mesma), pense em:

 

1 - Como eu poderia desenvolver uma camada a ponto de deixá-la útil para outra aplicação ou torná-la portável, sem que eu tenha que carregar junto um caminhão de outros módulos dependentes ou tenha que fazer modificações na camada?

 

2 - Como eu poderia estruturar uma camada a ponto de deixá-la imune ao meio externo (encapsulamento) e ao mesmo tempo, dar todas as suas funcionalidades lógicas necessárias?

 

Vale lembrar que a ideia de independência é a mesma para criação de camadas, classes, funções ou de qualquer trecho de código. Quanto maior a modularidade de sua aplicação, maior a consistência, a organização, o entendimento por outros programadores e consequentemente, menor o número de erros e trabalho gerado na sua manutenção. Um ótimo exemplo de independência ou de modularidade são os serviços Web ou Web Services. Web Services são serviços que são executados em um servidor Web, onde qualquer site ou aplicação, independente de plataforma, pode consumi-lo, trabalhando apenas com envio e retorno de informações (definidas em um arquivo WSDL), sem a necessidade de conhecer como o processo é feito dentro do serviço ou em qual plataforma, e principalmente, sem a necessidade de acessar qualquer outro módulo, biblioteca e etc.

 

Uma recomendação que faço é estudar o modelo MVC, que é ligeiramente diferente do modelo padrão de três camadas.

 

 

8 – Projete, planeje e documente

 

Muitos desenvolvedores, analistas e até empresários possuem a terrível mania de começar um novo trabalho partindo do fim, codificando-o, sem ao menos ter um plano de execução. Imagine você, programador, se um SGBD (sistema gerenciador de banco de dados) como Oracle ou SQL Server começasse a executar sua consulta SQL sem planejar antes a melhor forma de fazê-lo! Seria um caos! É por esta razão que eu sempre digo, gastar “papel e caneta” é muito mais barato do que desperdiçar horas de trabalho e descobrir que algo não vai dar certo depois de já ter feito metade do serviço. E se a data de entrega estiver próxima, como fica? Trabalho, tempo e consequentemente dinheiro, todos jogados no lixo.

 

Quando se fala em UML, DFD, diagrama de sequência, MER, muitos desenvolvedores ou gerentes de projeto quase têm um ataque cardíaco, pensando que é tudo uma grande perda de tempo. Mas a remissão deste trabalho chato vai custar muito caro lá na frente. O gerente de projeto não pode esquecer que a sua equipe de trabalho é mutante, isto é, hoje é uma, amanhã será outra. Todo o know-how de um produto precisa ficar na empresa e não na cabeça dos funcionários que vêm e vão a qualquer momento. Mantendo o know-how dentro da empresa (eu nem deveria falar uma coisa tão básica, mas infelizmente isso acontece e muito), faz com que novos colaboradores possam consultar essa documentação e trabalhar corretamente, sem depender de alguém que não integra mais a equipe ou até mesmo atrapalhar outras pessoas.

 

Vejo muitos empreendedores reféns de funcionários, exatamente porque nada foi documentado. Centralizar o conhecimento em algumas pessoas é um dos piores erros que um gerente ou chefe de empresa pode fazer e isso pode ser fatal para o negócio. Quantas e quantas empresas têm que pagar salários altíssimos para manter um ou dois funcionários improdutivos, enquanto outros que realmente trabalham, recebem a “cesta básica” de cada dia, tudo porque a informação está retida e centralizada em poucas pessoas que não podem sair da empresa, caso contrário, o caos estaria instalado. Outro problema que isso gera é que elimina a competição natural dentro da empresa, fazendo com que vários (ou todos) colaboradores fiquem intoxicados e limitados pela forma de ser do detentor da informação e não pensem mais em melhorias, inovações e superação.

 

Existem “zilhões” de ferramentas que ajudam a projetar, desenhar e a documentar o trabalho de forma rápida e eficiente. Se você é empresário ou um gerente sério, que quer resultados na sua equipe, projete, planeje e documente o know-how da empresa, guardando-o a sete chaves. Desta forma você não coloca o maior patrimônio do negócio na cabeça de alguém que pode sair a qualquer momento ou te fazer de refém (“pague-me tanto ou eu pulo do barco!”).

 

_____________________________________________________________________________________

Dicas de livros:

 

Microsoft Press - .NET e tudo relacionado a Microsoft.

Sun Microsystems Press (agora Oracle) - Java e tudo relacionado a Sun

Oracle Press

 

C++

The C++ Standard Library: A Tutorial and Reference - escrito por um ex- membro do comitê de padrões C++

Modern C++ Design: Generic Programming and Design Patterns Applied

The C++ Programming Language: Special Edition (Hardcover)

 

 

 

Até a próxima!

[Prog 183]

Mais uma vez... Parabéns! ;)

 

Dicas muito valiosas, leitura recomendada.