Forem: J0sueTM

O que realmente significa ser um Engenheiro de Software?

J0sueTM — Tue, 04 Jun 2024 13:10:55 +0000

Introdução

Iniciei minha carreira na área de TI por volta de 2018, enquanto ainda era estudante. Após alguns anos, já no meu primeiro emprego, comecei a me autodenominar "Engenheiro de Software" nas redes sociais. Não, esse não era meu título profissional, nem eu compreendia completamente seu significado; simplesmente gostava da seriedade e experiência que essa designação conferia aos meus perfis online.

Caso o leitor se identifique com minha experiência (ou não, também 😅), esta redação será de seu agrado. Nela, busco contextualizar a filosofia e a história por trás dos títulos e cargos utilizados por todos nós, "povo da computação", e, ao final, tento trazer luz a esse tema tão raramente discutido.

Nota ao leitor

Antes de prosseguir com a leitura, é importante esclarecer alguns pontos:

Este texto pode ser categorizado como uma crítica, porém não é direcionado a ninguém ou a nenhum grupo específico (exceto aos profissionais da área computacional). Portanto, peço que o leitor o encare apenas como um artefato informativo;
A pesquisa foi realizada deliberadamente por mim, movido pela curiosidade. Portanto, não considere tudo que é apresentado aqui como dogma. Faça sua própria pesquisa e verifique as referências antes de aceitar qualquer informação;
Tentei ser o mais didático possível, incluindo referências e sendo crítico em minhas opiniões. No entanto, sou humano e posso estar equivocado. As críticas não apenas são bem-vindas, como também são necessárias;

Conferências de Garmisch

Em 1968, o Comitê de Ciência da NATO (Organização do Tratado do Atlântico Norte) organizou algumas conferências em Garmisch, na Alemanha, onde mais de 50 participantes internacionais discutiram sobre os problemas emergentes dos softwares da época. Devido à evolução não apenas das tecnologias disponíveis, mas também dos problemas reais que essas tecnologias enfrentavam, tornou-se urgentemente necessário o desenvolvimento e a regulamentação de uma nova metodologia capaz de produzir Software para suprir as necessidades da sociedade moderna (NAUR; RANDELL, 1969).

Embora o conceito de "Engenharia de Software" por si só não tenha sido o único tema discutido nessas conferências, muito menos o produto final, elas foram determinantes para a valorização e popularização dessa nova disciplina com o passar do tempo. Nas palavras de Margaret Hamilton (HANCOCK, 2014):

Quando comecei a usar essa expressão [Engenharia de Software], ela era considerada um tanto engraçada. Foi motivo de piada por um bom tempo. Eles [provavelmente outros desenvolvedores do Apollo Guide Computer] gostavam de brincar comigo sobre minhas ideias radicais. O Software eventualmente e necessariamente ganhou o mesmo respeito que as outras disciplinas.

-- Margaret Hamilton, entrevista para El País, 2014

Claramente, as conferências foram uma resposta a um contexto da época. Portanto, é importante, antes de prosseguirmos, esclarecer por que o conceito de "Engenharia de Software" encontrou resistência durante sua concepção e implementação.

As três tradições da computação

Apesar de ser uma disciplina relativamente nova, a computação, em seu primeiro século de existência, passou e ainda passa por transformações e ramificações únicas, fazendo da Engenharia de Software um conglomerado de outras disciplinas que, simultaneamente, se complementam e disputam entre si (TEDRE; SUTINEN, 2008). São elas:

Tradição Matemática: programas são tratados como objetos abstratos, estruturas teóricas e sistemas axiomáticos que avaliam de maneira booleana. (MCCARTHY, 1960) é um ótimo exemplo de uma definição de um software com uma grande influência da tradição matemática;
Tradição Científica: programas são tratados como modelos de informação que buscam, seguindo algum sistema científico idealizado, satisfazer dados que comprovam uma hipótese ou seguem o processo científico;
Tradição da Engenharia: programas são processos que afetam e são afetados pelo mundo real. Trata-se da agregação de sistemas computacionais existentes de forma a produzir um novo sistema;

É interessante ressaltar que muitas autoridades têm formulado diversos argumentos e contra-argumentos para cada uma das tradições detalhadas. Um dos exemplos mais difundidos é o do Prof. Dr. Edsger Dijkstra, renomado matemático por trás de muitos fundamentos da computação, que definiu a Engenharia de Software, em seu ensaio "Sobre a crueldade de realmente ensinar Ciência da Computação" (E.W. DIJKSTRA ARCHIVE, 2023), como "A Disciplina Condenada":

Assim como a economia é conhecida como "A Ciência Miserável", a Engenharia de Software deveria ser conhecida como "A Disciplina Condenada"; condenada porque nem chega perto de atingir seu objetivo, já que seu objetivo é contraditório por si próprio. Claramente, a Engenharia de Software se apresenta como uma causa válida, mas isso é enganação: se você ler sua literatura e analisar o que seus devotos realmente fazem, descobrirá que a Engenharia de Software aceitou como sua missão "Como programar se você não o sabe.".

-- Edsger W. Dijkstra, EWD 1036

Em contraste, detalharei alguns argumentos que não buscam provar a superioridade da tradição da engenharia, mas sim demonstrar a necessidade de sua existência quando comparada às outras disciplinas:

Modelos Teóricos vs. Mundo Real

Se o leitor estiver familiarizado com teorias dualistas, idealistas, fenomenológicas, platônicas (por ex. PLATO, 1986) ou neoplatônicas, terá mais facilidade em reconhecer a validade deste primeiro argumento.

A matemática trata principalmente de abstrações teóricas que, em sua maioria, mas não necessariamente, correspondem aos fenômenos naturais (THOMAS; MAURER, 1986). Com essa definição em mente, surge naturalmente um problema quando a matemática é aplicada à computação: Modelos teóricos de programas podem ser validados puramente de forma axiomática; o mesmo programa em execução em uma máquina entra em contato com variáveis naturais que impossibilitam sua validação (TEDRE; SUTINEN, 2008, p. 156). Não existe sequer um modelo matemático que consiga provar (exceto em teoria) com 100% de certeza como os elétrons de um computador se comportarão durante a execução do mesmo programa (TEDRE; SUTINEN, 2008, p. 157).

Imagine que o leitor está executando o programa mais bem testado do mundo no computador mais confiável do mundo. De repente, um terremoto de nível 9 na escala Richter ocorre, seguido por uma chuva contínua; alguns segundos depois, o sol explode e incendeia tudo o que existe... Deseje boa sorte aos modelos teóricos.

Sim, este exemplo está longe de acontecer. No entanto, a ideia continua sendo verdadeira: não controlamos, nem conseguimos prever todas as variáveis do universo. Nenhum programa em execução é 100% eficaz.

Ao reconhecer essa diferença, a Engenharia de Software procura lidar da melhor maneira possível com esses problemas do mundo real. Não é à toa que desenvolvemos e aprimoramos algoritmos como os de tolerância a falhas, replicação, consenso, balanceamento de carga, etc., que compõem os sistemas que fazem a sociedade atual funcionar. O leitor talvez se recorde das primeiras máquinas computacionais do início do século passado: sistemas elétricos enormes que falhavam constantemente. Sem a influência dos engenheiros elétricos, é discutível a hipótese de que a computação estaria, ainda hoje, nos gabinetes teóricos da matemática (TEDRE; SUTINEN, 2008, pp. 161-162).

Processo Científico vs. Construção de Software

Aqui entramos em um território altamente contraditório, completamente fora da minha atual autoridade para argumentar de forma a adicionar qualquer progresso: "O território das Definições Inacabadas".

A ciência em si é um conceito amplo que, consequentemente, possui diversas lacunas de definição autoritárias como "O que é ciência?" ou "Qual o modelo ideal de processo científico?". Esta falta de definição (que por sua vez não é algo necessariamente ruim ou proveniente de inexperiência, mas sim da natureza da filosofia e dos limites humanos em geral) torna possível que uma questão em específico emerja: A computação pode ser considerada, por definição, uma ciência? Ou até mais, uma ciência natural? Em outras palavras, levando em conta a definição de que as ciências naturais tratam da observação e estudo de fenômenos naturais (THOMAS; MAURER, 1986), é possível categorizar a ciência da computação como uma?

Diversos autores têm adentrado em detalhes acerca desse questionamento e o debatido. Entretanto, irei focar em apenas um contestamento, para que possamos avançar no fortalecimento da nossa visão atual sobre a Engenharia de Software.

O contra-argumento mais difundido é de que a computação não procura estudar um fenômeno natural de forma a produzir um mais amplo entendimento do mundo. Em realidade, os únicos dados e fenômenos observados são, em suma, o computador e seus processos, os quais já são muito bem entendidos na disciplina. Isso torna a pesquisa não um entendimento acerca dos fenômenos naturais, mas sim de fenômenos artificiais que não apenas são entendidos, como também foram criados. Segundo esse contra-argumento, a única resolução dessas pesquisas é validar o quão bem os últimos pesquisadores construíram seus Softwares (HARTMANIS, 1993).

Considerando também este ponto, a Engenharia de Software entende sua artificialidade e suas limitações de pesquisa, procurando voltar seus métodos de aprimoramento especialmente para o entendimento dos sistemas computacionais já existentes.

Conclusão

Meu objetivo inicial ao começar a escrever este ensaio era apenas sanar minha curiosidade. Porém, conforme o texto foi se preenchendo, julguei inconveniente não compartilhar o conhecimento adquirido.

Como foi requisitado na introdução, eu espero que a leitura tenha sanado lacunas de conhecimento que o leitor possuísse, e que finalmente entenda o porquê de nos chamarmos Engenheiros de Software.

Obrigado pelo seu tempo. Não hesite em comentar qualquer dúvida ou opinião!

Josué Teodoro Moreira
https://j0suetm.com, teodoro.josue@pm.me, https://www.linkedin.com/in/josue-teodoro-moreira/

Referências Bibliográficas

MCCARTHY, J. Recursive functions symbolic expressions and their computation by machine, Part I. Communications of the ACM, v. 3, n. 4, p. 184–195, 1 abr. 1960.
HANCOCK, Jaime Rubio. Margaret Hamilton, la pionera de la programación que llevó el Apolo a la Luna. 2014. Disponível em: https://verne.elpais.com/verne/2014/12/11/articulo/1418314336_993353.html. Arquivado em: https://web.archive.org/web/20141225145142/https://verne.elpais.com/verne/2014/12/11/articulo/1418314336_993353.html.
NAUR, P.; RANDELL, B. (EDS.). Software Engineering: Report on a conference sponsored by the NATO SCIENCE COMMITTEE. [s.l.] Brussels: Scientific Affairs Division, NATO, 1969.
PLATO. Republic. Translated by G.M.A. Grube, revised by C.D.C. Reeve. Indianapolis: Hackett Publishing Company, 1992.
TEDRE, M.; SUTINEN, E. Three traditions of computing: what educators should know. Computer Science Education, v. 18, n. 3, p. 153–170, set. 2008.
THOMAS, A. S.; MAURER, A. A.; PONTIFICAL INSTITUTE OF MEDIAEVAL STUDIES. The division and methods of the sciences : questions V and VI of his Commentary on the De Trinitate of Boethius. Toronto: Pontifical Institute Of Mediaeval Studies, 1986.
E.W. Dijkstra Archive: On the cruelty of really teaching computing science (EWD 1036). Disponível em: https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html. Arquivado em: https://web.archive.org/web/20240330000400/https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html.
HARTMANIS, J. Some observations about the nature of computer science. In: SHYAMASUNDAR, R.K. (Ed.). Lecture notes in computer science, Vol. 761. Berlin: Springer, 1993. p. 1–12.

How to handle concurrency in Clojure with core.async

J0sueTM — Mon, 15 Jan 2024 23:50:07 +0000

Introduction
The building blocks
- Channels
- Messages
- Producers and Consumers
Implementation
- Include it
- Behold! the channel
- Put and Take
- Ordinary Threads
- Go Blocks
- Alts
References

Introduction

Hey, how you doing? This article was written right after I had to painstakingly read the clojure.core.async source code in order to finish a task. So, I hope I save you from the same fate as I had 😄.

Also, since I tried to create content that can be used on both Clojure and ClojureScript systems, I opted for a more generic option core.async. There are other libraries out there, like the java virtual Threads, which can, in certain use cases, be a better suit than the one presented here.

If you're a visual learner and prefer video, I recommend this talk by Rich Hikey, the creator of Clojure, that goes a bit deeper into the inner concepts that went into the design of this tool.

Anyhow, I hope this may help you. Feel free to contact me in any case.

The building blocks

Before working our way into Concurrency de-facto in Clojure, I want to make sure that everyone is one the same basis. If you already know what is concurrency, then you can skip this section.

Channels

Channels are one of the main pillars in the clojure.core.async lib and most other concurrency libraries out there; you can think of them as tunnels where things get into from one side, go through, and then get out from the other side.

Messages

The thing that goes through a channel is called a message, or an event. Messages can be anything really, as long as it can be produced and sent through the channel, it's good to go!

Producers and consumers

The thing that creates the message and puts it into the channel is called a producer, and the thing that receives the message on the other end, is called a consumer.

That's really all there is to it, a channel is theoretically a place where messages sent by producers are received by consumers.

If you're a student and know a bit about CS, its also valid to know that most Channels implementation are built upon the Queue Data Structure, i.e. FIFO.

Clojure Implementation

First of all, I'd like to note that there are multiple ways of working concurrently in Clojure/Script, based on your needs. In this article, I'll tackle the clojure.core.async lib. Its available on both JVM and Javascript ecosystems, and can be used to build powerfull asynchronous applications.

I made this article with JVM in mind, so please be aware that since there are small (but important) differences between the JVM and JS implementations, your walkthrought using Cljs might be slightly different from the one shown here.

Javascript applications are single-threaded, so blockeable actions aren't going to work (they'll actually not even transpile). Examples that might not work on JS will be signalized.

Include It!

You can include the library like this:



(:require '[clojure.core.async :as async :refer :all])

or you can be more specific and include only the used items:



(:require '[clojure.core.async :refer [chan <!!]])

or you can use the namespace instead of including unique items:



(:require '[clojure.core.async] :as async)

;; example
(async/chan)

Behold! the channel

First thing first, a channel needs to be initialized in order for the async functionalities to be able to work:



(def my-channel (chan))

A channel will close automatically, but you can close it manually:



(let [my-channel (chan)]
  ;; do powerfull asynchronous computations
  (close! my-channel))

Also, a channel doesn't necessarily needs to begin unbuffered, (without any messages). You can create a channel that already has messages in it:



(def my-buffered-channel (chan 10))

Put and Take

As stated before, a channel is usually a Queue, where its operations follow the order FIFO (First In First Out, where the First inserted element will be the first to be taken out as well).

Non CS people can assimilate this to the boring tuesday FastFood queue: The first person to ask for a burger will be the first to receive it, and consequently, the last one (the timid guy) to ask for his sandwich will be the last one to receive this.

In core.async, we use the operations named PUT AND TAKE to do the operations of inserting and removing. They assume the forms > and < to signalize the operation, respectively. Not only that, but the symbols are actually >! and >!! for PUT, and <! and <!! for TAKE. We'll learn the differences in a second, but I hope you got the visual idea of the these symbols.

If you didn't, think of the PUT as a spear poking the channel, hoping it will open in order to PUT something in there. The TAKE, on the other hand, is like a spear already inside the channel, poking it from the inside, hoping it will open in order for something to get out of there, to be TAKEN from the channel.

Ordinary Threads

This entire section might not work in JS

When creating a channel, any raw operation will be a fake asynchronous operation, because the only thread owning it is the main thread, meaning it will still block the main thread (which will consequently block the other tasks of the application).

To circunvent that, it's necessary to create a thread that doesn't impact the main one. There're two ways of doing that. The first one is to literally open a child thread:



(let [people-channel (chan)]
  (thread (>!! c "josue"))
  (println "the first person to enter was " (<!! c)))
;; => the first person to enter was josue

Did you note the >!! put operation there? The meaning of the double ! is that that operation is blocking. i.e. The thread it is in will be blocked. The same applies to the <!! take operation after that. It means that the thread its in (in this case the main one) will be blocked until the operation is finished.

Go blocks

Now, usually, any asynchronous operation should take the minimum amount of overhead on top on the main thread. And whats that operation? The final taking one. Its a crucial step for communication with the rest of the modules of your application, so we technically let it take its time. However, any other operation, putting or taking, as long as its not the final retrieval, should be done in a non-blocking manner.

Theres where our go blocks enter the scene. They're a less explict version of thread that handles the IOC (inversion of control).



(let [people-channel (chan)]
  (go (>! people-channel "josue")
  (go (>! people-channel "maria"))
  (println (<!! (go (<! people-channel))))))
;; => josue

Now, comparing to the ordinary threads, can You see that the operations inside the go block have only a single !? That's because they signalize that. Also, pay attention to how, on the last block of code, we take the content from the people-channel, and then do a blocking take <!! again. This is necessary in order to retrieve data from an asynchronous channel (this time created by go) back to the main thread.

Alts

Lets suppose we're creating a chat application. First things first, I think about creating a channel for the josue user:



(let [josue-channel (chan)]
  (while true
    (let [message (<!! (go (<! josue-channel)))]
      (when message
        (println "josue sent a message: " message)))))

Hey, that looks nice. But wait, I just received an email from my client, and he's asking me to add 2500 more channels, they're marketing geniuses and the userbase grew from a weird nerd that uses the app every night to a quarter thousand people. I can't add all of those channels manually, there must be a better way to do that, right? Please tell me there is.

Of course there is, my friend, with Alts. They are a powerfull tool in core.async that lets you work with waiting for messages on multiples channels on the same time.

Now, with that feature in mind, our code can support as many channels as possible (as long as our memory doesn't explode 😄), and look as simple as it has ever looked:



(defn create-channels [people-count]
  (let [channels (repeatedly people-count chan)]
    (go
      (let [[message channel] (alts! channels)]
        (println "New message to " channel ": " message)))))

(create-channels 2500)

That's all folks! It's always a great day to wake up and learn something new. And look, you just did that! I'm proud of you!

Thanks for taking the time to read my words, I'm really grateful.

Sincerely yours, Josué Teodoro Moreira | teodoro.josue@pm.me

References

clojure.core.async source code

Separação de Conceitos e Localidade de Comportamento - Um guia imparcial

J0sueTM — Mon, 21 Aug 2023 16:13:46 +0000

Você agora é um pedreiro. Isso mesmo, o melhor da cidade ainda. Um cliente te pediu para construir uma casa; já comprou as ferramentas, o cimento e os tijolos, o engenheiro civil até já fez a planta. Agora basta você pegar todos esses recursos, organizá-los e utilizá-los de alguma forma a ter o produto final: a casa. Como você vai fazer isso?

Talvez você não consiga resolver esse problema; Quem sabe, se eu trocar um pouquinho a história... Pronto! agora você é um engenheiro de software que precisa construir um produto. A IDE tá aberta, o café tá na mesa, a daily é daqui 5 minutos. Até os juniors estão prontos pra trabalhar como um sênior pelo preço de um estagiário!! Como você vai juntar seus recursos e produzir esse Software?

Glossário

SoC / SdC : Separation of Concerns / Separação de Conceitos
LoB / LdC: Locality of Behavior / Localidade de Comportamento
EdS: Engenharia de Software

Balas de prata e favoritismo

Um dos maiores problemas da EdS é o famoso favoritismo/elitismo. Existe um errôneo ideal de estar sempre do lado certo. Isso não acontece só na EdS, mas é muito prevalecente nessa área, devido a enorme quantidade de escolhas. Não é à toa que não temos um dia de paz na bolha tech.

Venho antes de tudo declarar que este artigo é uma apresentação dos conceitos e aplicações de SoC e LoB. Não estou colocando nenhum acima do outro. Existem momentos certos para um, e para o outro. Ser Engenheiro é também ser crítico e entendedor. Já diziam os sábios:

Depende.

O que são estes palavrões?

SoC e LoB são princípios que procuram descrever como uma codebase é organizada, em quesitos como árvore de arquivos, nomenclatura, alinhamento, posição de código, etc. Não se preocupe, irei entrar em mais detalhes a seguir. Trazendo como exemplo o problema do pedreiro no começo, a forma como os tijolos serão colocados, o tamanho dos cômodos, etc. são prováveis princípios seguidos durante toda a construção da casa.

Separação de Conceitos

A Separação de Conceitos trata da modularização dos aspectos de um Software, de forma a prover coesão ao separar blocos de código baseado em seu aspecto e função primordial. você cuida de X? Então vai pra pasta dos Xs. Você cuida de Y, vai pra pasta do Ys, etc.

In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained—on the contrary!—by tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by "focusing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously. - Edsger W. Dijkstra

O exemplo mais canônico é a forma como as aplicações Web são criadas (vanilla): por meio de 3 tipos de arquivos diferentes: HTML, CSS e Javascript. Dessa maneira, existe uma separação de aspectos: O HTML fica com a declaração dos elementos da DOM, o CSS com a estilização desses elementos, e por fim o Javascript complementa a interação entre esses próprios elementos e o usuário.

Localidade de comportamento

A localidade de comportamento trata da organização dos módulos de uma codebase com base na proximidade do comportamento de uma seção de código, ao invés do aspecto em si.

“The primary feature for easy maintenance is locality: Locality is that characteristic of source code that enables a programmer to understand that source by looking at only a small portion of it.” - Richard Gabriel

O LoB tem suas origens nessa citação de Richard Gabriel, do qual o princípio em si é formulado da seguinte maneira:

O comportamento de um pedaço de código deve ser o mais óbvio possível olhando apenas para esse pedaço de código.

Qual a diferença na prática?

Um exemplo prático que posso dar são as recentes Frameworks Javascript e CSS. Nesse caso, vou estar falando de React e Tailwind. Observe o seguinte arquivo jsx:

function formatName(user) {
  return user.firstName + ' ' + user.lastName;
}

const user = {
  firstName: 'Josué',
  lastName: 'Teodoro'
};

const element = (
  <h1 class="px-4 py-2">
    Hello, {formatName(user)}!
  </h1>
);

Talvez você nunca tenha usado React ou Tailwind, mas se você tem a base de lógica da programação, não seria nenhum pouco complexo entender o que essa porção de código está fazendo.

Agora imagine se estivéssemos utilizando uma abordagem de SoC, a formação desse mesmo bloco seria separada entre os seguintes arquivos:

user.html

<h1 id="title">Hello, </h1>

user.css

h1 {
    padding-left: 1rem;
    padding-right: 1rem;
    padding-top: 1rem;
    padding-bottom: 1rem;
}

user.js

function formatName(user) {
  return user.firstName + ' ' + user.lastName;
}

const user = {
  firstName: 'Josué',
  lastName: 'Teodoro'
};

var title = document.getElementById("title")
title.onload = sayHello()

function sayHello() {
    title.innerText = "Hello, " + formatName(user)
}

Qual devo usar?

Existem alguns pontos que você pode tomar em conta na hora de decidir qual princípio tomar a frente no desenvolvimento da aplicação. Vale lembrar que estes não são os únicos, e que é necessário que você dê uma pesquisada antes de colocar a mão na massa.

Ferramentas

Se seu cliente te pediu uma casa de madeira, pra que comprar cimento?

Muitas das ferramentas disponíveis para nós desenvolvedores foram criadas com um ideal em mente. Java por exemplo, é uma linguagem de programação Orientada a Objeto. Não faria sentido programar Orientado a Procedures na mesma língua.

Da mesma maneira, se o seu time está acostumado com um conjunto de ferramentas orientados a SoC (como por exemplo uma Framework MVC), continue do jeito que está, a não ser que seja necessário mudanças.

Complexidade desnecessária

Por quê usar 8 tábuas pequenas para fazer uma porta, se você pode usar 1 tábua grande?

Outro princípio importantíssimo na EdS é o DRY (Don't Repeat Yourself), onde a repetição de informação deve ser reduzida e reposta por abstrações, removendo redundâncias. Um dos embargos do DRY, entretanto, é a Over Abstraction: existe um medo da repetição; dezenas de interfaces, Singletons, Abstract Factories, etc. se espalham pela codebase, criando complexidade que dificultam mais do que ajudam.

Uma das minhas talks preferidas é a "Simple Made Easy - Rich Hickey (2011)", do criador do Clojure. Nessa talk Hickey explica a necessidade da simplicidade (não facilidade) nas ferramentas e softwares atuais. Recomendo muito que assista, mas em suma:

A cada linha de código, arquivo, etc. que é criado, a complexidade da codebase aumenta. Nós, humanos, não somos máquinas capazes de armazenar milhares de informações ao mesmo tempo; no máximo 3 coisas e olha lá. Sendo o ato de programar entender sequencialmente os passos de uma aplicação, as abstrações são uma informação a mais a levar em consideração.

Um código simples é aquele que tanto um ser humano quanto a máquina conseguem entender. Ter que fazer malabarismo mental toda vez que tiver que ler uma base de código é custoso não somente pro time, mas para a própria empresa.

Tendo isto em mente, e o seu produto final, responda a si mesmo: Eu e meu time, como seres humanos, temos capacidade para manter esses diversos conceitos dispersos em um bloco de código na mente?

Conclusão

Como disse anteriormente, não existe uma bala de prata na EdS. É seu trabalho, como Engenheiro e/ou Desenvolvedor, estabelecer o caminho a ser tomado para chegar no produto final. Os princípios apresentados aqui são uma base que podem criar uma fundação; nem toda casa é de cimento, e nem toda é de madeira.

Obrigado!

Josué Teodoro Moreira.

Forem: J0sueTM

O que realmente significa ser um Engenheiro de Software?

Introdução

Conferências de Garmisch

As três tradições da computação

Modelos Teóricos vs. Mundo Real

Processo Científico vs. Construção de Software

Conclusão

Referências Bibliográficas

How to handle concurrency in Clojure with core.async

Table of Contents

Introduction

The building blocks

Channels

Messages

Producers and consumers

Clojure Implementation

Include It!

Behold! the channel

Put and Take

Ordinary Threads

Go blocks

Alts

References

Separação de Conceitos e Localidade de Comportamento - Um guia imparcial

Glossário

Balas de prata e favoritismo

O que são estes palavrões?

Separação de Conceitos

Localidade de comportamento

Qual a diferença na prática?

Qual devo usar?

Ferramentas

Complexidade desnecessária

Conclusão