Saiba como ser um melhor programador!

Em todas as profissões existe o interesse pela autosuperação. A profissão de programador não foge à regra. Esta reveste-se da particularidade de exigir lucidez de raciocínio, por um lado, e por outro, criatividade e inspiração.

Tentarei refletir sobre o assunto e sintetizar ideias resultantes da minha experiência e forma de estar na área. Afinal de contas, a instrospeção fomenta a melhoria. É por isso natural que alguns pontos sejam subjetivos e muitos não estejam isentos de exceções. Os objetivos passam por pensar, fazer pensar e promover a discussão.

Envolvência

• Conhece os recursos à tua disposição, principalmente das API em uso. Por exemplo, uma simples leitura na diagonal da API do jQuery pode fazer a diferença no futuro (ex: “Sim é possível; já vi isto em algum lado”).
• Conhece o projeto: roadmap, objetivos, pessoas envolvidas e a “big picture”. Só com plena consciência do ambiente se pode fazer o ideal. Saber os “porquês” terá muito impacto na direção do desenvolvimento.
• Comunicação: tenta promover a comunicação para evitar situações como “não sabia que tinhas resolvido” ou “não sabia que isso tinha sido abandonado”.
• Espírito crítico: envolve-te no levantamento de requisitos. Se isso não for possível, “exige” que estes cumpram critérios SMART. Não aceites tudo sem antes pôr em causa (mas sê moderado). Não sejas apenas um executante.

Fig. 1 - Gestor que compara os programadores a robôs de uma linha de montagem

• Orientação para o utilizador/cliente. É para eles que trabalhas. O ideal não é o que achas, mas sim o que os utilizadores/cliente querem e precisam. Deves dar opinião, mas sempre com o foco neles e não na tecnologia ou em ti.
• Conhece as regras para as poderes quebrar. Se o resultado final for melhor para a empresa, podes arriscar um pouco, propondo novas formas de fazer as coisas.
• Cultiva um espírito positivo: não te irrites ou amues por algo não ter acontecido como previsto ou com algo que não podes mudar; tenta mudar ou muda.

Simplificação

• Simplifica o texto: tenta ter o mínimo de parágrafos, frases, palavras para dizer a mesma coisa. DRY.
• Não repitas código: (copy/paste de mais do que uma linha deve lançar o alerta); considera procedimentos reutilizáveis, criar/partilhar bibliotecas entre projetos, componentes GUI, templating, etc. DRY.
• Simplifica o código: tenta ter o mínimo de funções/métodos, classes, linhas de código, etc., mas sem sacrificar a legibilidade e modelo concetual.

“Simplicity – the art of maximizing the amount of work not done – is essential.”

Agile Project Management QuickStart Guide, Ed Stark

• O código deve falar por si. Qualquer programador deverá conseguir perceber e alterar o teu código.
• Não comentes o código com frases inúteis como por exemplo: “aqui coloco mais um elemento na lista”. Comenta para complementares o código de maneira a ajudar a perceber a ligação ao negócio. Faz o exercício de perguntar: “se voltar a ver este código daqui a um mês vou perceber rapidamente?” Se a resposta for “não”, comenta com uma explicação.
• Reduz as dependências técnicas: usa o mínimo de tecnologias (ex. bibliotecas, frameworks, bases de dados, serviços).
• Divide para conquistar: pensa sempre como um engenheiro; reparte os problemas em subproblemas até ficarem simples e manipuláveis.
• Não reinventes a roda: é altamente provável que o problema que estás a resolver já tenha sido resolvido por outrém; procura primeiro. Mas cuidado com o peso das frameworks/bibliotecas (pergunta-te quanto irás usar de cada uma).
• Adequa a solução ao problema. Não arranjes soluções mais complexas que o próprio problema. Nao uses “um canhão para matar uma mosca”. Isto não invalida preparar o código para o futuro (daí ser importante a envolvência).

Fig. 2 - Escolha da solução para problema

• Não te contentes com a primeira solução a que chegaste; de certeza que com mais algumas iterações ela fica mais simples. Itera e pratica o refactoring.

Tecnologia

• Não sejas um obcecado por tecnologias: não as uses sem argumentos lógicos. Evita argumentos como: “vamos usar porque o Twitter usa”, “toda a gente usa isto agora”, “isto é o que está a dar”, “porque estou curioso em experimentar”.
• Não uses frameworks/bibliotecas cegamente, mas sim se os ganhos superarem as perdas. Tenta sempre saber o que fazem “por baixo do capô”. Não tentes forçar o seu uso (Fig. 2), pois as frameworks/bibliotecas não encaixam em todos os problemas.
• Repensa o uso de tecnologias a que estás habituado, especialmente quando começas um novo projeto ou tarefa. Podem estar ultrapassadas ou ser inadequadas ao caso. Cada uma tem as suas vantagens, aplicação e domínio.
• Não descartes tecnologias que desconheces (é provável que sirvam outros propósitos). Mantém-te a par de tecnologias concorrentes às que usas, nem que seja só para ter opinião. Não aches que as que sabes resolvem tudo (ex. PHP) da melhor forma. Desconfia de tecnologias que sirvam para tudo.
• Não aprendas tecnologias sem aprender conceitos: as tecnologias são efémeras: nascem, vivem e morrem; os conceitos ficam. Saber programar não é saber linguagens de programação.
• Automatiza o que é automatizável e reduz as dependências humanas. Se algo pode ser feito por uma máquina, então que o seja; liberta os humanos (programadores e utilizadores) de tarefas repetitivas ou que exijam lembrança. Isso evita, por exemplo, que alguma coisa deixe de funcionar porque alguém se esqueceu de fazer algo.
• Ferramenta ideal != melhor ferramenta. Escolhe ferramentas de trabalho que se adequem às necessidades (ex. saber reconhecer quando basta o SVN e não o GIT) (ver Fig. 2). Cuidado com o deslumbramento tecnológico (ex. usar um documento eletrónico quando bastava um caderno).
• Não tentes impôr tecnologias, aceita que cada uma tem as suas vantagens. Evita discussões do tipo Win. vs Mac ou Android vs iOS; a diversidade é algo positivo. O importante não são os sistemas mas sim o que fazes com eles.
• O teu foco não é a tecnologia. Nunca escolhas tecnologias antes de conhecer bem o problema. Não forces tecnologias nem obrigues as pessoas a adaptarem-se às mesmas. Pelo contrário, defende que a tecnologia se adapte às pessoas.

Boas práticas

• Cria software flexível e que não “castiga”. Não o prepares só para a situação ideal e aumenta as situações em que este não falha. Trata os erros, recuperando com graciosidade e com fallbacks.
• Prepara-te para a mudança constante. Bom código está preparado para a mudança que o negócio naturalmente sofre. Não esperes pela estabilidade…
• Ambiciona código escalável: uma boa prática é pensar “e se isto aumentar muito?”, “e se houvesse muitos ficheiros?”, “e se houvesse um ataque DoS? isto recuperaria?”, “e se fosse reiniciado?”.
• Ambiciona separação de conceitos (a encapsulação, modularidade, separação entre camadas). Exemplos clássicos são o MVC e o unobtrusive JavaScript.

Fig. 3 - Unobtrusive JavaScript (retirado de jQuery - A Sua Biblioteca JavaScript, Luís Soares)

• Desenvolve interfaces autónomas: uma boa interface (seja uma GUI ou uma API) deve ambicionar “falar por si”.
• Mantém testes unitários e de integração em continuous integration. Considera praticar TDD.
• Limpeza de código: tenta que o teu código caminhe apenas para ser a resolução dos problemas do negócio e não dos teus (ex.: logs) ou outros. Por exemplo, evita blocos de código todo comentado (usa o controlo de versões) e não sujes o código/logs com prints (usa debug interativo).
• Não sejas um freak da performance. Tem também em conta o tempo de desenvolvimento, a legibilidade, entre outros. Por vezes, alguns milisegundos não justificam o impacto no projeto. A performance tem de ser relativizada.
• Conhece e usa software design patterns.
• Lê as guidelines UI do sistema para o qual desenvolves (ex. iOS Design, Android Design, Windows Platform Design). Conhece e usa patterns de design de interação.

Humildade

• Aceita a crítica ao teu código e ao teu trabalho em geral. Aceita que o teu código não é teu mas sim da empresa e de todos. Temos sempre a aprender, com júniores e séniores.
• Repensa o papel do programador. Não aches que és um grande programador por dominares if/else, ciclos e funções. Programar envolve muitas mais disciplinas: análise, resolução de problemas, conceção, arquitetura, gestão, standards, trabalho em equipa, QA, integração, etc. Não aches que ser programador é ser mais inteligente.

Fig. 4 - Tarefas de um programador (retirado de Computer Programmer, Antonin Karlo Tilaon)

• Cuidado com as assunções e ideias preconcebidas. Parte para uma nova tarefa com uma mente livre e aberta. Usa a experiência mas não sejas sua vítima: sê imparcial e objetivo nas decisões.
• Questiona. Perguntas estúpidas são as que não são feitas. Não tenhas medo de perguntar ou de admitir que não sabes. Mesmo assim, investiga primeiro e aprende a fazer questões, evitando problemas XY.
• Não metas logo as mãos na massa. Não aches que és tão inteligente que não precisas de desenhos, fluxogramas, pseudocódigo, protótipos/mockups, etc. Perceber bem um problema e a sua solução previne fazê-la várias vezes. Uma hora de análise/conversa pode poupar horas de implementação.
• Não culpes o utilizador. Se o utilizador não consegue fazer algo ou se queixa, a culpa não é dele, é tua. Pensamentos como: “ele não viu o botão” ou “ele que leia o manual” são inadmissíveis.
• Testa-te: regista-te em HackerRank e vê como estás a nível de algoritmos. Usa o StackOverflow e ganha estatuto contribuindo para a comunidade. Tenta participar em projetos open source via GitHub. São três serviços que enriquecem muito o teu CV.

Melhoria contínua

• Pede que revejam o teu código, quando fazes algo complexo (no GitHub, isto é um pull request).

Fig. 5 - Pull request no GitHub

• Quando descobres e resolves um bug, cria um teste automático para cobrir casos semelhantes.
• Tenta sempre a solução ideal. Mesmo que demore mais tempo, compensa a médio/longo prazo. Quando tiveres de fazer algo parecido, já sabes fazer da maneira ideal.
• Analisa a complexidade algorítmica e aprende a notação O(n); muito mais importante que otimizar ao nível da instrução, é otimizar a nível algorítmico.
• Não maltrates a Língua Portuguesa: não és de Letras mas não tens de escrever com erros, até porque lidas com entidades externas (dando imagem de ti e da tua empresa) e fazes interfaces-utilizador com inúmeros textos. O novo A.O. não é desculpa para escrever mal.
• Experimenta software semelhante ao que desenvolves, para poderes comparar. Tenta reconhecer tendências e padrões (especialmente em apps mobile).
• Aprende algo novo: uma linguagem de programação ou ambiente (ex: aplicação Android, aplicação Chrome, aplicação Go). Tira certificações.
• Segue os blogues das tecnologias que mais usas. O bom programador alia a teoria à prática e está a par das novidades das tecnologias que usa.
• Acompanha blogues e canais de pessoas importantes/influentes na tua área (ex. com leitor de RSS, Twitter, Youtube).
• Assiste a palestras; há muitas que são gratuitas ou de baixo custo. Tenta que a tua empresa pague. Além de aprenderes, fazes networking.
• Cria o teu blogue de desenvolvimento de software; falar sobre algo obriga-te a pensar no assunto, e, consequentemente, a estruturá-lo/consolidá-lo na tua mente.

Em suma

• Conhece o ambiente: cliente/utilizadores/projeto;
• Reduz ao mínimo: código, dependências tecnológicas, etc.;
• Conhece a tecnologia e repensa o seu papel;
• Conhece e usa normas;
• Conhece-te e repensa o teu papel como programador;
• Interessa-te, sê curioso e crítico.