diff --git a/posts/10.md b/posts/10.md index ca0ad5e..2ebeabc 100644 --- a/posts/10.md +++ b/posts/10.md @@ -1,28 +1,32 @@ --- -title: "10 - Introduza linguagens funcionais a sua stack de produção" +title: "Introduza linguagens funcionais a sua stack de produção" author: "Håkon Haga" translatedBy: "Celso Bonutti" -date: "2020-12-10" -published: false +date: "10 de dezembro de 2020" +published: true +description: "Nesse artigo, vamos compartilhar algumas experiências de como conseguimos usar linguagens funcionais em produção. Também vamos dividir algumas dicas de como convencer outras pessoas que programação funcional é o caminho certo. Nenhuma linguagem funcional, ou qualquer outra ferramenta, deve ser considerada uma bala de prata para todos os problemas, então é importante considerar cuidadosamente qual seria a melhor ferramenta." --- -## Introduce functional languages to your production stack +Nesse artigo, vamos compartilhar algumas experiências de como conseguimos usar linguagens funcionais em produção. Também vamos dividir algumas dicas de como convencer outras pessoas que programação funcional é o caminho certo. Nenhuma linguagem funcional, ou qualquer outra ferramenta, deve ser considerada uma bala de prata para todos os problemas, então é importante considerar cuidadosamente qual seria a melhor ferramenta. -In this blog post, we will share some experiences on how we got to use functional languages in production. We will also provide some tips on how to convince others that functional programming (FP) is the way to go. No functional language, or any other tool for that matter, can be regarded as a silver bullet for every problem, so it is important to consider carefully what will be the right tool for the job. +Pessoalmente, eu estive envolvido coom a introdução de linguagens funcionais ao meu cliente. Na primeira vez, a stack original não conseguia comportar a complexidade das expectativas do meu cliente. A segunda vez também foi devido a dificuldades com a tecnologia existente e nós experienciamos um tempo desproporcionalmente longo para mudar coisas que deveriam ser simples: isso levava a um longo processo que nos permitiu descobrir o que fazia mais sentido no nosso caso. Dessa vez, pudemos nos preocupar tanto com a forma quanto com a tecnologia que gostaríamos de usar. -Personally, I have been involved twice with introducing a functional programming language to my customer. First time, the original technology stack could not handle the complexity of our customer's expectations. The second time was also due to some challenges with the existing technology and we experienced that we used a disproportionately long time to change things that should be easily done. This led to a longer process where we could figure what suit us best. In this case we were able to use enough time to slowly learn both what would be the better way to go and also the technology itself. -Step 1: Scala +## Passo 1: Scala -The first time more in detail, we had stuck in a dead end with the standard J2EE stack back in 2011. There were not too many attractive Javascript (JS) frameworks at the time and we found it challenging to develop frontend in JSF and pure JS. On the team, we had two developers who had Scala experiences, and they were also familiar with a web framework that could help us solve many of our problems. Everyone agreed that the development was to slowly and something had to be done. Based on the current situation and a team of developers which were trusted advisors in the organization it was decided to move away from the standard J2EE stack. This allowed us to work full time with Scala. In the very beginning some of the developers, myself included, were somewhat skeptical of departing from the common and trusted syntax we were used to in Java. This soon proved to be needless worries. Scala gave us the tools we needed, and we quickly became productive in our new language. -Share your ideas +Em mais detalhes, estávamos presos num beco sem saída usando a stack J2EE em 2011. Não havia muitos frameworks JS bons na época, e nos encontramos no desafio de desenvolver front-end em JSF e JavaScript puto. No time havia dois desenvolvedores com experiência em Scala, e eles também eram bastante familiares com um framwork web que poderia resolver muitos dos nossos problemas. Todos concordamos que o processo estava muito lento e algo precisava ser feito. Baseado na nossa situação do momento e em um time de devs que possuíam a confiança da organização, decidimos nos livrar da stack J2EE. Isso no permitiu trabalhar _full time_ em Scala. No começo alguns desenvolvedores, incluindo eu mesmo, estavam céticos sobre abandonar a sintaxe confiável e comum que usávamos em Java. Isso rapidamente se mostrou uma preocupação desnecessária: Scala nos deus as ferramentas que precisávamos, e rapidamente nos tornamos produtivos na nossa nova linguagem. -In this case, we had a specific problem which we did not see how to get out of without replacing some of the frameworks. In turn, this also led to the use of a functional language. Of course, we cannot go around hoping to end up in such big trouble that the only way out is to replace the whole tech stack, but nevertheless there are plenty of challenges facing which might be solved in a better manner if we take the time to step back. Often the team needs an experienced trusted advisor to convince the business side that such changes are needed. The same trusted advisor might also be biased by earlier discussions and by how things are as is. Therefore I think it is important that trusted advisors also are able to see the possible changes that might have been thought of as unreachable. Since this is not always the truth less experienced developers are often the ones who come up with the ideas for change. Regardless of who suggested the change it is important that the team has an open arena where ideas like this can be shared and discussed. It is important that every team member feel the trust in the team so no one hesitates to share their ideas. After discussing with the team there has to be an agreement before it is advisable to approach the business side. Sharing knowledge within the team will lead to better ownership and it will be crucial for the viability of the new technology. It is not necessary that everyone in the team knows the language fully, but it is important that everyone in the team is comfortable with the change and that there are enough developers in the team to rely on for those with less experience. -Step 2: Elm +### Compartilhe suas ideias -My second experience introducing FP was in early 2017 and now we actually saw that the framework we introduced in 2011 did not provide the flexibility we needed. One of the main problems was the lack of separation between frontend and backend in our code. We decided that we had to move away from this framework and find a better way of writing frontend and backend more decoupled. But! The first good news is that we have no intention of walk away from Scala. Scala works perfectly well for us as a backend language, although we first got to use it due to introducing a web framework in 2011. As opposed to the first time we had a thorough review within the team and had a broad consensus that we wanted a new frontend technology. The team had Scala.js foremost among the options until we got a better understanding of what Elm could give us. It became clear to everyone that here they got something more stable than what we had previously seen among "languages" that compile to JS. What also became the nail in the coffin for the positive vibe around Scala.js was that no one else in Bekk uses this framework. Therefore, it would be more difficult for the team to seek help locally. We had already experienced this situation, as the framework we wanted to remove had the same lack of use within Bekk and not widely used elsewhere either. -Start small, learn fast +Nesse caso, tinhamos um problema específico que não víamos como nos livrar a não ser com uma troca de framework. Coincidentemente isso nos levou ao uso de uma linguagem funcional. Claro, não podemos que as coisas fiquem tão feias a ponto que a única solução seja a troca completa de stack, mas sempre haverá problemas que podem ser resolvidos de maneiras melhores se pudermos dedicar um tempo para eles. Geralmente o time precisa de alguém cujo time de negócios confie. Essa mesma pessoa também pode ser tendencioso por discussões anteriores e por como as coisas são hoje em dia, então acho que uma parte muito importante é que essa pessoa também possa ver as possíveis mudanças que podem ter sido consideradas inalcançáveis. Como essa nem sempre é a verdade, os desenvolvedores menos experientes costumam ser os que apresentam as ideias de mudança. Independentemente de quem sugeriu a mudança, é importante que a equipe tenha uma abertura para que ideias como essa possam ser compartilhadas e discutidas. É importante que cada membro da equipe sinta-se confiante na equipe para que ninguém hesite em compartilhar suas ideias. Depois de discutir com a equipe, deve haver um acordo antes de ser aconselhável abordar o lado de negócios. Compartilhar conhecimento dentro da equipe levará a uma melhor apropriação e será crucial para a viabilidade da nova tecnologia. Não é necessário que todos na equipe conheçam totalmente a linguagem, mas é importante que todos na equipe se sintam confortáveis ​​com a mudança e que haja desenvolvedores suficientes na equipe para orientar aqueles com menos experiência. -Although the main reason for introducing new frontend technology was a legacy application, we did not start introducing Elm here. We started with some smaller new applications to learn as much as possible so that we had more experience when meeting the larger and more complex challenges. This is also a good way to lower the risk when introducing new technology. Since spring 2017 we have arranged three summer internships with several students participating each summer. Elm has been involved every year and we have been equally amazed every year how quickly new developers learn to use Elm. This also negates the concern that new developers are unable to adapt to new languages. -Step 3: Profit(?) +## Passo 2: Elm -So, do you want to introduce a functional language in your project? Well, introducing just another language will in most cases not fix your problems by itself. What you might need is another library or framework. If you want to convince someone in your team, or even the business side, that functional programming is the way to go, you might not want to sell them the language directly, but find a framework that suits the problem and that accidentally happen to be written for a functional language. On that way you definetly have to fight some battles. Remember to also fight the ones you have lost before! And for the third time: Syntax does not define the difficulty in our field. Developers do know how to adopt new languages! +Minha segunra experiência introduzindo FP foi no começo de 2017: à época, vimos que aquele framework introduzido em 2022 não ofereceu a flexibilidade que precisávamos. Um dos maiores problemas era a falta de separação entre o front e back-end de nossa aplicação. Decidimos que deveríamos nos livrar desse framework e encontrar uma forma melhor de escrever nosso código desacoplado, mas... a primeira boa notícia é que não tinhamos intenção de nos afastar de Scala. A linguagem funcionava perfeitamente para nós no back-end, apesar de termos introduzido-a devido a um framework front-end. Ao contrário da primeira vez, reunimos o time para entrar num consenso sobre a nova tecnologia que gostaríamos de usar: o time tinha Scala.js como favorito até entendermos o que Elm poderia nos dar. Ficou bem claro para todos que era algo muito mais estável do que as outras "linguagens" que compilavam para JS. Outra coisa que matou a ideia de usar Scala.js foi que nenhuma outra pessoa na Bekk usava esse framework. Logo, seria mais difícil encontrar ajuda interna. Já experienciamos essa situação, já que o framework que queriamoms remover não era usado na Bekk e possuía uma adoção geral muito pequena, também. + +### Comece pequeno, aprenda rápido + +Apesar da maior razão de introduzir uma nova tecnologia ser uma aplicação legado, não começamos introduzindo Elm lá. Começamos com uma pequena parte da aplicação para aprender o máximo possível, para que então pudessemos enfrentar os desafios maiores e mais complexos. Isso também é uma ótima maneira de reduzir riscos quando introduzindo uma nova tecnologia. Desde a primavera de 2017, organizamos três estágios de verão com diversos estudantes participando todos os anos. Elm esteve envolvida em todos os anos e sempre ficamos impressionados com como as pessoas a aprendem muito rápido. + +## Passo 3: Lucro(?) + +Então, você quer introduzir uma linguagem funcional no seu projeto? Bom, introduzir outra linguagem qualquer - na maioria dos casos - não vai resolver seu problema por si só. O que você talvez precise é outra biblioteca ou framework. Se você quer convencer alguém no seu time, ou no timie de negócios, que programação funcional é a melhor forma, você talvez não queira introduzir a linguagem em si, mas achar um framework que resolva o problema e que _acidentalmente_ seja escrito numa linguagem funcional. Nesse caminho você com certeza vai encontrar algumas batalhas, mas lembre-se de também de lutar as em que você já perdeu antes! E, pela terceira vez: sintaxe não define dificuldade na nossa área. Desenvolvedores sabem se adaptar a novas linguagens!