For shocking purposes, I’m going to show a piece of Clojure code. You are probably going to think it’s esoteric and hard to reason about, but I promise you will undertand its awesomeness by the end of this article:
Still here? Guess you challenged yourself to get out of your confort zone! This article is going to show you the minimal theory and language constructs that you need to know to start writing simple Clojure programs, and how to (not even) setup your environement to start playing. Finally, I’m going to share some resources if you feel like deep diving. …
Agile Software Development relies on the ability to change fast. New user stories and enhancements to existing stories are going to happen. Therefore you code will change.
But what about S.O.L.I.D’s Open/Closed Principle ?
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification
The OCP preaches that once an entity is done, it’s done. You should provide them a way to be enhanced/extended.
In Object Oriented Programming this might be achieved with Design Patterns (like Strategy, Template Method), Inheritance, or just good modeling.
In Funcional Programming, otherwise, you could accomplish that with composition, partial application, currying, higher order functions, among other concepts. …
Design Sprint é uma técnica utilizada pelo Google Ventures para levantar hipóteses de produto e testá-las com protótipos e clientes reais em 5 dias.
Foi utilizada por startups como Slack e Airbnb.
O Design Sprint acontece em uma “sala de guerra” com um número aconselhado de no máximo 7 pessoas, com habilidades diferentes, para dar diferentes perspectivas de um produto. Portanto é importante que tenham pessoas de design, desenvolvedores, negocio, produto. Uma dessas pessoas é o Facilitador, que faz as dinâmicas irem pra frente sem impedimentos, e outra é o Definidor, que tem autoridade total para decidir.
O Design Sprint tem uma série de dinâmicas bem metódicas para cada dia, que são de certa forma bem rígidas. Mesmo assim, é comum que as empresas o adaptem para as suas necessidades. …
At Qualyteam, we are continuously improving. Therefore, we love code refactoring. Identifying problems and improvement opportunities in code is an important skill every developer should have. This week I was reviewing code that had a small change in a legacy code base method. It was a small, long forgotten piece of code. We usually balance between the importance of the touched code and the quality it must have. If it’s something that we know that is barely going to be touched in the future, we just let it go and move forward to something our clients are really going to care about. But I wanted to play around. …
There’s no agile without automated tests. Still, bad automated tests can slow down your product delivery.
Unit tests should help you with code refactoring and delivering features, ensuring your use cases work without introducing new bugs.
We’ve struggled years with annoying unit tests that would break even with small refactoring. They were hard to maintain and weren’t readable . And even worse, they wouldn’t ensure our app works.
And we fixed it.
We’ll show you the problems we identified and how we solved them with research and development.
Have you ever found yourself in a situation where you just wanted to test the ‘Apply for a job listing` use case, but you needed the applicant, its past experiences, its skills, the employer, and the job? The data required to run a test case is called test fixture. Complex test fixtures may be hard to read, which leads to developers just copying and pasting them through the tests, sometimes creating unnecessary data for a given test. The abuse of the new keyword breaks object instantiation encapsulation and leaks all over the tests, making them harder to maintain. …