Hábitos saudáveis podem virar um processo

21/11/2013 22:50:06 - Fábio Ferreira de Souza

Recentemente tenha assistido alguns vídeos e lido algumas matérias do Produtividade Ninja (curso Arata Academy), e achei muito interessante o PDF e o Vídeo sobre Hábitos

http://www.produtividadeninja.com/baixar-comocriaremodificarhabitos

E refletindo bem, acho que o Hábito é a “cola”, o argumento perfeito que eu estava precisando, para juntar muitas coisas interessantes que tenho lido recentemente.

Os padrões e normas NBR/ISO, os processos CMMI, MPS-BR, a praticas do PMBOK, e toda teoria de Engenharia de Software, na verdade giram em torna de um Ciclo de Vida de Software eficiente, com programadores que priorizam os hábitos seguros e maduros, que não cedem a pressão do prazo ou custo.

Se um programador e a empresa não cometer “pecados” tão primários do desenvolvimento de software, e ter como habito seguir as dicas do artigo da NASA, isso seria tão eficiente quanto seguir os diversos processos e padrões..

Os 7 Pecados do Desenvolvimento de Software (Google Translate)

  1. Preguiça (Sloth)
    Documentação: Esse é o principal pecado da no desenvolvimento de software!
    Grande parte das principais informações estão na cabeça do desenvolvedor, e quando ocorre um problema, somente quem desenvolveu consegue resolver, conforme ele mesmo for lembrando.
    É preciso vencer a preguiça para documentar, criar scripts de automação, testes automatizados, monitoramento, check-lists de solução de problema, para que qualquer pessoa possa implantar ou dar suporte ao sistema, e assim o programador pode ficar livre para novos projetos e oportunidades.
  2. Ganância (Greed)
    Ter um ambiente de teste que reflita de forma real o ambiente de produção custa caro, mas o quanto mais caro seria ter o ambiente de produção fora do ar, ou o quanto mais satisfeitos forem os clientes, mais poderia ser recomendado e vendido o sistema.
    O Desenvolvimento e testes apenas baseado nos ‘notebooks’ dos programadores não refletem a real performance que a aplicação terá.
    Também quando o ambiente de produção usa centenas de servidores é impossível ter um ambiente de teste igual.
    É preciso sim de investimento para um ambiente de teste que reflita o ambiente de produção de forma proporcional, e até um ambiente de redundância, ter procedimentos de restauração e  rollback.
    Economizar, gastar menos para lucrar mais, é contar apenas com a ‘sorte’, e um dia sim vai dar problema e quando der a ganancia será evidente.
  3. Glutonaria (Gluttony)
    Manter o sistema operacional e os componentes do software atualizados é importante, mas também pode ser perigoso.
    Aquela mania de usar sempre a versão mais recente do Kernel, dos componentes, deixar o Windows Update para instalar tudo automaticamente, é apenas uma bomba relógio.
    E mais grave ainda quando se quer rodar versões beta, alfa, de alguma coisa só por luxo, por estar a frente, por prazer.
    Há componentes que usam componentes, e que em um processo de atualização podem descontinuar métodos, mudar funcionalidades, e assim gerar uma catástrofe caótica difícil de ser concertada, e até de ser restaurada por processos de rollback, pois não só a aplicação mudou, mas o local onde ela está implementada, corrigir isso demora!
    Se por causa da Ganancia, não houver um bom ambiente de teste, e por causa da preguiça não houver um processo claro de testes, um dia que você precisar atualizar componentes, sistema operacional, ou sistema gerenciador de banco de dados, há um grande risco de tudo parar.
  4. Orgulho (Pride)
    Tem programador que ‘se acha o bonzão’, que pensa que previu todas as situações, mas não se pode planejar o inesperado.
    Temos que programar contra nos mesmos, validar parâmetros, preparar o código contra erros, ter logs das falhas, afinal o usuário é agende do caos.
    O ser humano, é falho e erra, e consequentemente tudo que criamos, pode ser tão ruim quanto nos mesmos.
    Precisamos ser humilde e pedir revisões, aceitar criticas, seguir boas praticas e conselhos de outros programadores, vencer a preguiça e criar rotinas de testes para nosso código.
  5. Luxuria (Lust)
    Some tudo que foi dito anteriormente: programa não documentado, sem testes, sem check-list, a ser implantando em ambiente desconhecido, usando versões beta, ou alfa, não instável de componentes, Kernel, serviços, em fim, realmente é como sair com uma prostituta (desconhecida) em uma farra, qualquer coisa pode acontecer! É uma grande aventura, que os orgulhosos adoram fazer apenas para se se tornarem mais orgulhosos: “Olha só consegui instalar o sistema .Net em um Linux/ARM , rodando Apache com uma versão especial Alfa do Mono, e uns componentes especiais que achei!”… isso não é nada seguro, instável, atualizável, continuável, escalável! É um sistema ‘bastardo’!
  6. Inveja (Envy)
    Onde há competição, pode sim haver muita inveja, querer estar sempre certo, ter as melhores respostas, melhores ideias, melhores softwares, ser o detentor das senhas principais senhas.
    Não querer ser ajudado, e admitir que outras pessoas podem sim ter boas ideias, sugestões, é um indicio de inveja.
    O invejoso é alguém isolado, pois não quer dividir o que tem, não quer ser igual a outros, quer ser maior, sempre o melhor, o “ego”.
    E quando um invejoso, vê alguém melhor, ele sempre irá buscar e apontar os erros dos outros, criticar, e ser negativo, para que ele possa se aproveitar das situações.
    Todo “nerds”, nasceu com um grande dom intelectual, mas isso pode ter trazido junto vários traumas de infância, e na vida adulta toda a inteligência na verdade se torna uma grande vingança arrogante, contra todos que tentam ofuscar seu brilho.
  7. Ira (Wrart)
    Quem nunca varou uma madrugada em algum projeto, e que no final não deu nada certo, tudo deu errado, nervoso, frustração, raiva.
    Parece pequenas peças que são pregadas pela “Lei de Murphi”, onde tudo que pode dar errado, realmente vai dar, e em meio ao stress e cansaço de diversas horas de trabalho seguidas, tomar decisões certas e coerentes sem ser influenciado pelo pensamento “isso será rápido”, é pura mentira.
    É preciso de paciência, é melhor fazer as coisas sem pressa, calmo, em paz, mesmo perdendo o prazo, e alguém tendo algum prejuízo, do que viver um momento de stress.

Padrões de Programação, NASA, Março/2009 (Google Translate)

Conceitos elementares

  • shall (deve) – Qualquer software primeiro DEVE cumprir os REQUISITOS, a Finalidade Principal.
  • should (deveria) – Apos ter cumprido o requisito principal, é possível ir um pouco além

31 Regrinhas que precisam ser nossos hábitos (algumas só são aplicaveis a algumas linguagens) e outras adaptei a minha realidade:

  1. Codificar de forma simples e humilde, não “ofuscada”, sem sintaxe mágicas, garante tanto para um ser humano a compreensão, quanto para o compilador a melhor otimização dos recursos.
    Ter um programa que só o próprio autor consegue dar suporte ou evoluir, mostra o quanto está mal feito, fortemente acoplado, e consequentemente mal estruturado.
  2. Revise a lista de  “Warnings”, e outros parâmetros de compilação que detectam possíveis funcionalidades obsoletas, ou código inseguros.
    Não ignore nenhuma possibilidade de erro, o usuário final é criativo, e qualquer coisa pode acontecer.
    Se nem o compilador consegue entender claramente o que seu código na integra, é hora que revisar sua lógica.
  3. Cuidado com “loops”, todo laço precisa de alguma forma ter uma garantia de finalização, seja por um número máximo de iterações, ou alguma condição especial de saída.
  4. Evite recursividade, e quando usar, tenha algum controle do numero máximo de chamadas
  5. Cuidado com alocação de memória, pois é um recurso finito, e em ambientes em que há memoria virtual existe uma grande latência devido a paginação que também consome processamento extra, e consequentemente o tempo de resposta não é mais linear.
  6. A comunicação entre modulos precisam ser po IPC, infelizmente hoje em dia é muito fazer este tipo de comunicação usando WebServices, Sockets, o monitoramento de arquivos, em fim formas que não são tão eficientes, que consomem muitos recursos, alem de abrir brechas de segurança.
  7. Não use Sleep (pausas) entre tarefas para sincronizar tarefas, ou outros processos. Nem sempre é possivel estimar com exatidão processamentos paralelos.
  8. Dados compartilhados que precisam ser alterados, só devem ser alterado pelo proprietário desta informação, a menos que isso realmete faça parte do escopo como no caso de comunicação IPC.
  9. Evite usar Semáforos, seja para gerenciar dados compartilhados, ou controlar processos paralelos, é necessário muita experiência para fazer da forma correta.
  10. Proteja os dados da memória, crie controle de checagem de memoria, ou de estouro de memória, em fim o que for necessário para evitar coppupcçoes de memória.
  11. Não use “jump”, “goto”, ou qualquer chamada direta para parte de código, use sempre laços estruturdos.
  12. Enumeradores devem ser usados da forma correta, sem definições explicitas de valores alem do primeiro elemento.
  13. Ter bem claro o escopo das variáveis globais, e locais gera um código mais limpo e de facil entendimento, principalmente na hora de encontrar erros.
  14. Os valores retornados por rotinas devem ser usados, se não a rotina não precisaria retornada nada.
  15. Todos os parametros passados para rotinas precisam ser verificado logo no inicio da rotina.
  16. Usar “Assert” durante todo o desenvolvimento monitorando assim sempre o código alem de tratar só excessões.
  17. É preciso saber de forma bem claro os limites de cada tipo de dado, inteiro em algumas linguagens ou plataformas são de apenas 16 bits, mas na maioria são 32 bits, entender os limites dos tipos de váriáveis primitivas, e a forma de sinalização é fundamental.
  18. Não custa nada colocar parenteses nas expreções a fim de facilitar o entendimento, por mais que o compilador saiba priorizar os conceitos matemáticos.
  19. Validar booleanos é simples, e deve ser feito.
  20. Macros de pré-processamento (#DEFINE em C/C++) devem ser simples e usada com cautela para simplificar expressões, ou fazer inclusões condicionais de códifi (#IFDEF)
  21. Em C/C++ nunca criar macros em qualquer lugar
  22. Em C/C++ nunca ecluir maros com o comando #undef
  23. Diretivas de pre-processamento de blocos devem se limitar ao mesmo arquivo (#IFDEF..#ELSE)
  24. Não usar mais do que uma declaração de variável por linha
  25. Funções não devem exceder 60 linhas, e não usar maid de 6 parametros
  26. Qualquer objetos não devem ter mais de 2 meios de ser acessados
  27. Evite criar classes com muitas derivações
  28. Ponteiros não podem ficar ocultos dentro de macros (C/C++)
  29. Ponteiros de funções não devem ser usados (C/C++)
  30. Não manipular dados brutos de um ponteiro, principalmente de funções (C/C++)
  31. Includes devem ser usados de forma lógica, sem baguança.

Referencias: