Postagens

Capítulo 1 – Uma filosofia pragmática

Em termos de abordagem pragmática, uma das coisas mais importantes é tomarmos para nós a responsabilidade total daquilo que executamos.

Seja em planejar uma nova iteração, seja ao desenhar uma nova arquitetura ou seja fazendo um simples código CRUD. Uma das coisas mais difíceis (sim é sempre difícil e aprendemos isso com o tempo e humildade) é admitirmos nossos erros (segundo os autores) e adiciono aqui algo não mencionado pelos autores, aceitar críticas e melhorar continuamente. Se lembram do “Hoje melhor que ontem e amanhã melhor que hoje”?

Devemos ter atenção as situações em que riscos devem ser ponderados com responsabilidade, por exemplo, quando a execução de algo não depende apenas de nós, como entregas de outras equipes, contato com clientes ou prestadores de serviços externos. Estas situações, devem ser tratadas com cuidado, pois não devem servir como desculpas, ou as famosas “muletas”, para possíveis problemas do dia a dia. Uma boa abordagem a ser praticada é antes que esse tipo de problema ocorra já estejam mapeados os casos de contorno para cada um deles, ou ao menos que esteja clara a situação que futuramente pode vir a impactar de alguma forma as atividades que desempenhamos.


Além de estarmos atentos aos problemas que possam ocorrer, caso algo saia fora do planejado e sairá com toda certeza, pensemos em opções para contornar o problema, seguindo a dica #3:“Apresente opções, não desculpas”, dos autores.

As vezes essas opções serão coisas como propor a escrita de testes (unidade/integração), propor fluxos de trabalho (as vezes engessados e dolorosos), refatorar um legado problemático (ainda que nem sempre as pessoas entendam o valor de um código manutenível e escalável), dentre outras. De toda forma, tenha sempre opções, é como dizia Henry Ford “Não encontre defeitos, encontre soluções. Qualquer um sabe queixar-se”.

Um ponto sobre responsabilidade e transparência não abordado, é a questão psicológica de Ancoragem(discutida no livro Digital Work in Analog World, irei escrever sobre ele no futuro),quando somos ancorados por vieses implantados por outras pessoas, imagine a seguinte situação:

Você é um desenvolvedor experiente, conhece bem o sistema em que trabalha e seu “chefe” chega e diz: – Essa funcionalidade sai hoje né? Certeza que você mata isso ainda hoje.Nesse momento seu psicológico é posto a prova, como uma necessidade de auto afirmação, ou de confirmação do que se é, e faz com que você seja ancorado a esta afirmação, fazendo com que você (nós) caia nela, mesmo sabendo que provavelmente terminar a tarefa naquele dia é completamente infactível, ou no mínimo implicará em horas extras, ou algum contorno não desejado para finalizá-la. 

O tipo de situação acima citado pode e deve ser enfrentado sempre, com base na transparência e sinceridade sobre a situação real daquilo em que estamos envolvidos. Quando alguém fizer este tipo de abordagem, seja honesto consigo mesmo. Justifique os motivos pelo qual as coisas não são tão “simples” como aparentam, ou proponha uma solução de escopo reduzido para o que é esperado como entrega de valor (uma hora falarei sobre MVPs). 

Antes de dar qualquer resposta sobre um problema, pare e pense se a resposta parece razoável ou se ela soa completamente estúpida, seja transparente, não pense apenas no problema, pense em soluções (inclusive as de contorno, elas podem salvar o seu dia) e não se deixe ancorar, isso não faz mal apenas a você. 

Resumindo, dizer que o gato (ou cachorro) comeu seu código não é uma desculpa honesta, pense sempre em formas de superar as barreiras que venha a enfrentar e não apenas nas barreiras.

Se você gostou desde texto compartilhe e comente! =)

Informações úteis aos meus/minhas nov@s alun@s

Neste texto falarei sobre algumas coisas que você ouvirá em aula de forma breve pois talvez não façam parte de nosso plano de aulas (diretamente), mas que considero útil você saber, para em algum momento (talvez) se dedicar a estas coisas, caso faça parte do seu plano futuro para sua carreira. (resumindo, conselhos/dicas que eu gostaria de ter tido na faculdade e aprendi “sozinho”)

Antes de mais nada, é sempre bom lembrar, você gostar de programação não é sua obrigação (e ta tudo bem!), mas como aluno de um curso de “exatas”/computação/sistemas é esperado que você ao menos entenda o básico (suficiente) para ser capaz de entender trechos/fluxos/estruturas de códigos e perceber se alguma solução apresentada a você é impraticável, ou ao menos razoável.

Comecemos do início, programação, seja estruturada ou orientada a objetos, uma linguagem de programação nada mais é do que uma ferramenta através da qual realizará a implementação de seus algoritmos para que o computador entenda o que ele deve fazer. 

Em meus cursos de graduação trabalho basicamente com 2 linguagens, Java e C, e como linguagens de programação nem sempre são coisas triviais é bom termos um caminho para estudarmos de forma efetiva, levando em consideração que todos temos dificuldades com uma coisa ou outra relacionadas ao tema.

Java: linguagem de programação orientada a objetos, muito famosa e largamente utilizada no mercado de trabalho brasileiro.

Caso tenha dificuldades, recomendo que procure livros como Use a cabeça! – Java pois se trata de uma série (“Use a cabeça!”), focada em apresentar conceitos de forma simplificada e sempre muito ilustrativa.

O livro do Deitel também é interessante, mas deve estar na centésima edição, ter umas 2 mil páginas e dar dor nas costas só de pensar em colocar na mochila. No entanto, o livro do Deitel possui muitas dicas relevantes sobre aspectos de engenharia de software, abrangendo diversas informações valiosas e dicas, além do conteúdo sobre a linguagem Java.

Outro caminho muito interessante para a linguagem Java que recomendo, são cursos online, recomendo analisar a Alura (em português, mas com cursos pagos), da empresa Caelum que também possui uma apostila em português muito completa e gratuita sobre Java (clique aqui). Também recomendo os cursos das plataformas Code School, Code Academy e Solo Learn, que possuem alguns cursos introdutórios gratuitos, mas na língua inglesa. 

Sobre a Udemy, é uma ótima plataforma, mas é sempre complicado filtrar um curso realmente relevante, dado a enorme quantidade de cursos ofertados (opinião pessoal).

A Udacity não possui cursos específicos de Java.

Linguagem C: linguagem de programação estruturada, muito poderosa (rápida) e importante em termos de seu uso no passado e também nos dias de hoje.

A linguagem C não é tão popular nestas plataformas de cursos online, mas de toda forma possui alguns cursos interessantes na Coursera e na Learn C (https://www.learn-c.org), mas a minha escolha para aprender C de forma efetiva é o livro “C completo e total” (ele me salvou na faculdade), é um livro de conteúdo fácil de digerir e com um encadeamento de temas muito bom para quem quer aprender sozinho (os capítulos iniciais já irão salvar seu semestre).

Também deixo a dica de usar o site https://www.onlinegdb.com/online_c_compiler que possui um compilador online e descomplicado para estudar e programar algo caso precise.

Agora que as dicas para o caminho das pedras em programação foram dadas, vamos falar um pouco sobre programação orientada a objetos.

Normalmente nos ensinam que POO é representar entidades do mundo real no mundo computacional. Bem, é uma forma poética de ver as coisas, mas vai muito além disso, a POO trouxe grandes avanços ao desenvolvimento de software por nos permitir abstrair melhor as entidades que representamos em nossos sistemas através de todo o ferramental oferecido por ela (encapsulamento, composição, herança, polimorfismo e etc).

No entanto, comecemos do básico, creio que um dos livros mais palatáveis para aqueles que tem dificuldade no tema, seja o livro “Use a Cabeça! Análise e Projeto Orientado ao Objeto”, as justificativas para o uso deste livro permanecem as mesmas ditas anteriormente.

Outro livro de peso que utilizei e gostei muito durante a faculdade, porque ele trabalha diretamente com o pensamento de um projeto, onde se modela com foco em orientação a objetos é o livro “Utilizando UML e Padrões” do Craig Larman. É um livro um pouco extenso, mas vale a penar ler ao menos os seus capítulos iniciais.

RECOMENDO OUVIR O PODCAST HIPSTERS PONTO TECH, especificamente o episódio sobre orientação a objetos: https://hipsters.tech/praticas-de-orientacao-a-objetos-hipsters-129/

Agora vamos a recomendações um pouco mais “advanced”, para você ler em seu tempo livre, ou depois de se formar e não precisar dividir seu tempo entre sobreviver a uma matéria que não gosta ou ao prazer de estudar alguma coisa que seja do seu interesse.

Ainda no tema de programação e afins, recomendo o livro “Código Limpo” do Autor Robert C. Martin (mais conhecido como Uncle Bob), é um livro muito interessante, sobre boas práticas de programação, um pouco de design, TDD (test driven development) e mais algumas coisas. Já sobre “comportamento” profissional de um programador, recomendo o livro O Codificador Limpo. Uncle Bob é amado por uns, ligeiramente criticado por outros, mas o fato é que ele soube sintetizar e tornar alguns conteúdos de um linguajar bastante acadêmico para o fácil entendimento do público em geral.

Um tema um pouco mais avançado, mas que vale a pena olhar após estar mais amadurecid@ sobre o tema de orientação a objetos são os padrões SOLID, mais informações em:http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Ou assistir a essa aula sobre o tema, do próprio Uncle Bob em Yale:


Outros livros (interessantes):
  • 97 Things Every Programmer Should Know: Collective Wisdom from the Experts
  • 97 Things Every Software Architect Should Know: Collective Wisdom from the Experts 
  • Padrões de Projeto – Soluções Reutilizáveis de Software Orientado a Objetos (considero um grande dicionário para programadores, que você deve passar os olhos ao menos uma vez na vida se você pretende seguir na carreira de programeir@)

Irei fazer outros posts, sobre carreira e etc com dicas interessantes sobre quais (infinitos) caminhos podemos seguir em nossa carreira, mas por hora este texto está bem longo e suficientemente completo, com relação ao conteúdo que gostaria que fosse priorizado para vocês!

Fique a vontade para compartilhar e principalmente comentar, ou me chamar para um café para falarmos sobre estes temas!

Espalhem a palavra! 😀

Parte 2 – A entropia do software

Ainda que comparado com engenharias que tratam mais do mundo físico (como a Engenharia Civil), a Engenharia de Software está imune a praticamente todas as leis físicas. Entretanto uma delas nos atinge em cheio quando se trata de “complexidade” são elas as leis da entropia. Entropia (do grego εντροπία) significa o grau de desordem de um sistema.

A entropia é uma característica inerente a sistemas complexos (assim como o software) que são caracterizados pela sua grande quantidade de componentes e relações/interações entre si.

As leis da entropia garantem que no universo a entropia tende ao máximo. E quando a entropia aumenta (a palavra complexidade é muito genérica e muito má utilizada em diversos contextos) o grau de controle do que se está observando cai.

Para ilustrar a questão de complexidade analisemos a figura abaixo:

Perceba que para N  nós de uma rede, se todos estes nós se comunicarem uns com os outros, seguimos uma quantidade de relações que seguem a fórmula onde o número de conexões total é dado por C = (N x  (N – 1)) / 2, ou seja, ao passo que introduzimos novos componentes em um sistema a quantidade de relacionamentos e dependências também tende a aumentar. 

Estendendo um pouco esta discussão (não tratada no livro), podemos imaginar nossas arquiteturas atuais, sistemas distribuídos, baseados em SOA ou até mesmo em Microsserviços (SOA feito da maneira correta), APIs e etc onde possuímos inúmeros pequenos componentes independentes e distribuídos que são organizados de modo a resolver os desafios específicos de cada sistema.

 Outra característica interessante de se comentar são as propriedades emergentes de sistemas complexos. Pense em um avião, que é um sistema complexo, a união de todas seus componentes fazer com que ele seja capaz de voar, mas se pegarmos apenas uma turbina, ou apenas as asas, ou somente um pequeno conjunto de seus componentes, essa capacidade emergente não aparece, sendo necessária a união de tudo o que há no avião para que essa capacidade se manifeste. 

O mesmo ocorre com seu sistema, apenas um de seus algoritmos, ou um de seus serviços, não resolve o problema por completo. Apenas a junção e organização de seus componentes serão capazes de resolver o desafio enfrentado por completo.

Muitos são os fatores que contribuem para a Entropia no software e os mais importantes aparentam ser os psicológicos e os culturais. Todos nós já vivenciamos projetos que mesmo muito bem planejados acabam em uma desordem total, ou então projetos que apesar de seus problemas e dificuldades, terminam com boa organização e código bem escrito.

Então, o que faz a diferença par “controlar” a Entropia no software?

Você já ouviu falar da “Teoria da Janela Quebrada”?
Pesquisadores chegaram a conclusão que edifícios limpos e bem conservados podem rapidamente se tornarem feios e destruídos e tudo começa com uma simples janela quebrada.O que isso quer dizer? Pense em um belo prédio, agora imagine que uma janela desse prédio seja quebrada. Nesse momento ele deixa de ser tão belo, certo? E se essa janela não for rapidamente consertada, o que pode acontecer? Esse é o ponto central desta teoria. A partir deste momento, quando uma janela não for rapidamente consertada as pessoas que ali convivem e interagem com aquele espaço, mudarão rapidamente sua visão sobre a conservação do prédio e até mesmo a sua utilidade e poderão passar a vandalizar o local, quebrando não somente as janelas mas com o passar do tempo levando o prédio a uma completa destruição.

No software é exatamente o mesmo que acontece, tudo começa com um bom plano e a melhor das intenções quanto ao que será desenvolvido, mas com o passar do tempo e conforme as dificuldades vão surgindo, acabamos assumindo débitos técnicos e tomamos decisões que nem sempre são as melhores, com a ideia de que no futuro (doces mentiras) conseguiremos tempo para corrigir e colocar as coisas em ordem como deveria.

É aí onde mora o perigo. A partir desta decisão postergada, próximas pessoas que terão contato com aquele software já declaradamente com problemas não dará importância ao que está fazendo, afinal, o que é uma gambiarra a mais ou a menos? 

Resumindo, desordem só gera mais desordem.

E se o software estiver “impecável”, com boas decisões de arquitetura, boa orientação a objetos, tecnologias bem aplicadas e etc? Neste caso, todos que entrarem em contato se sentirão no dever de manter aquela bela forma, de cultivar as boas práticas e organização que ali foi plantada.

Desta forma, anotemos mais uma das dicas dos autores:
#4 – não conviva com janelas quebradas

Contribuindo um pouco mais com esta ideia, no Livro “Código Limpo” do Uncle Bob (recomendo a leitura) ele cita a regra dos escoteiros:
“Deixe o lugar mais limpo do que estava quando você chegou”

Esta regra nos serve também como mais um mantra para o dia a dia, tenhamos em mente sempre manter a organização daquilo que estamos fazendo e deixá-la melhor do que a encontramos.

Seja um código, arquitetura, documentação ou processo.
Não convivamos com janelas quebradas! 🙂

O programador pragmático – O início

O que faz um programador pragmático?

  • Pragmático (adj):  – Que é prático; que realiza algo objetivamente. – Que se preocupa com uma ação concreta e eficaz; prático. – Que considera o aspecto objetivo das coisas, por oposição ao abstrato; objetivo.

Partindo do princípio de que cada programador possui características únicas (assim como todo os seres humanos, sim também somos humanos) os autores elencaram algumas características as quais acreditam que todos programadores pragmáticos compartilham, tais como:

  • Adotar tecnologias antes de se tornarem populares (early adopters), mas também se adaptar rapidamente ao lidar com algo novo (fast adapters).
  • Curiosidade, tendem a se perguntar como as coisas funcionam, pois assim podem tomar decisões melhores baseados em novas informações.
  • Pensamento crítico, não assumem nada como cem por cento verdadeiro ou porque as coisas são “simplesmente assim”.
  • Realistas, tentam sempre entender a natureza de cada problema que enfrentam. Isso faz com que possam avaliar o grau de dificuldade de cada desafio. E isso os motiva.
  • São bons generalistas, se esforçam para se manterem atualizados sobre novas tecnologias ainda que continuem especialistas nas tecnologias do seu dia a dia. 

Sendo estas as características consideradas básicas a todos os programadores pragmáticos elas são inseridas como dicas pontuais ao longo dos demais capítulos, sendo as duas primeiras: 

#1- Importe-se com seu ofício

  • Não há nada mais importante em fazer software do que você se importar em fazer isso bem feito.

#2- Pense! Sobre o seu trabalho

  • Como um mantra para programadores pragmáticos, não como um pensamento pontual, pense sobre tudo o que você faz, sobre suas decisões, ou a forma como age com relação aos desafios que enfrenta em sua carreira. Ainda que pareça custoso, questionar-se terá um retorno muito importante sobre o tempo investido conforme você e seu time se tornam mais eficientes.

Um pragmatista, de acordo com os autores, é alguém que preza pela individualidade do trabalho, sem deixar de lado a importância do trabalho em grupo, mas que cuida e preza pela qualidade do que faz e de cada decisão individual que toma sobre a execução do seu ofício.

Como metáfora, pense nos construtores das catedrais da idade média. Elas levavam anos/homens para serem construídas e cada cortador de pedra, pedreiro, carpinteiro e vidraceiro acreditavam em sua contribuição individual para a completude e sustentação do todo ao longo do tempo. Assim como a passagem do conhecimento para cada nova geração de trabalhadores que se juntavam a grande empreitada eram ensinados da importância de cada detalhe que passavam a assumir dali em diante.

Esse pragmatismo, deve ser visto como uma execução contínua e responsável do trabalho diário com foco em seu impacto com a visão do todo a longo prazo.

“Um turista visitando o Eton College, no Reino Unido, perguntou ao jardineiro como ele conseguiu aquele gramado tão perfeito. 
– Isso é fácil. Respondeu. – Regue toda manhã, apare todos os dias e enrole a grama uma vez por semana. 
– Mas é só isso? Impressionado disse o turista.
– Sim! Respondeu. Faça isso por 500 anos e você também terá uma grama perfeita.”

Um programa é como um gramado, diariamente precisa de uma grande quantidade de pequenos cuidados. Inclusive onde ninguém vê, com relação ao cuidado com a terra, fazendo diariamente sua irrigação e adubamento quando necessário. 

Essa melhoria contínua é o que conhecemos através da cultura japonesa como Kaizen, que refere-se a filosofia ou práticas que incidem sobre a melhoria contínua de processo. Filosofia responsável pelo grande aumento da produtividade da manufatura japonesa no pós segunda guerra. Tendo um de seus princípios centrais o “mantra”:

“Hoje melhor do que ontem, amanhã melhor do que hoje!”

E sob este mote, seguiremos com as reflexões e aprendizados passados ao longo de todos os capítulos do livro, sempre com comentários e reflexões baseadas em experiências reais pelas quais já passei.

Fique a vontade para comentar!