DEV Community: Felipe Martins

Pivotal Partnership Integration

Felipe Martins — Wed, 10 Jan 2024 18:00:00 +0000

TL;DR

How I quickly got onboarded onto a pivotal project and led the team to make a crucial architectural decision, enabling its delivery in half of the initial estimated time by leveraging the existing CQS design and correctly applying simple Domain-Driven Design and Hexagonal Architecture principles.

Project

Integrate the company’s financing product as a payment option within e-commerce checkouts through a partnership with a well-established brand that already holds a widespread presence across numerous online stores.

Context

The project held immense pivotal and strategic value, with expectations set remarkably high.

Given its extensive presence and renowned brand in the e-commerce market, the partnership not only promised immediate access to a vast customer base but also aimed to associate the company’s maturing financing product with a trusted brand. A failure would have been catastrophic as such an opportunity with a major partner was a once-in-a-lifetime chance for a startup.

The project’s execution fell under the scope of the “e-commerce integration” department, then composed of two product teams with around 8 engineers in total. These teams had recently encountered delivery delays and inconsistencies, making the successful accomplishment of this partnership project a crucial opportunity to rebuild trust.

And this is where I stepped in.

Joining as a Senior Software Engineer in one of those two teams just weeks before the much-anticipated kickoff, I found a draft solution already on the table.

Technical Context

To bring this partnership to life, we needed to create a public HTTP API that complied with the specifications our new partner has handed over to us. It looked like:

POST /start-payment
POST /authorize-payment
GET /autorized-payments/{id}
POST /...

The entire specification included around 10 REST-like endpoints with request and response bodies clearly defined. Additionally, there were response time limits. Pretty straightforward, right?

The company’s existing architecture followed a microservices-like approach, using both asynchronous and synchronous communication methods. While most services adhered decently to bounded contexts, a few technical concerns immediately caught my attention, but that is another discussion not relevant here… let’s get back to the project.

As mentioned earlier, there was already a preliminary solution in place which entailed the creation of a new shiny microservice with the purpose of housing partnership mapping data and redirecting calls to the involved services. Essentially, the solution was an anti-corruption layer (ACL) as a microservice between the partner client and our internal services.

Another justification for creating this new service was scalability. The argument presented was that this new service could supposedly scale independently based on the partner’s demand.

My Contribution

After familiarizing myself with the project’s context, understanding the related microservice’s domain and delving into their relevant use cases, getting to know my teammates, and absorbing the technical details crucial for project success, I began questioning and challenging the new microservice. It became evident to me that implementing it posed significant risks.

Upon scrutinizing the endpoints demanded by the partner, I noticed an important detail: all use cases behind each required endpoint were already implemented in one existing service. This service held many responsibilities, being one of them the direct integration with common e-commerce checkout solutions, such as Magento. There was only one use case previously unnecessary to the directly integrated e-commerce platforms but required for this project. Since its logic was also closely related to e-commerce integration, it would fit well in this same service.

Within my second week at the company, I presented my takes to the team:

Creating a new service for this project seemed unnecessary as there wasn’t a meaningful bounded context justifying such segregated codebase and deployment isolation.
Scalability wouldn’t be resolved solely by creating a new service. The existing service would remain the bottleneck regardless of a new and faster service. Moreover, the new service would likely compromise response time and reliability by introducing another potential failure point, hurting our SLA agreement.
The high complexity associated with setting up the new service would heavily drain team resources without commensurate future benefits.

Following discussions, a consensus was reached and documented. With this simpler solution, the implementation scope was streamlined from a new microservice to a collection of controllers contained in a designated module for this new client type, alongside a table to map inner-vs-outer data and other minor changes.

Result

We surpassed the original tough 4-month estimation by delivering the first store integration within a remarkable 2 months. What initially was apprehension of failure turned into an impressive outcome that resonated throughout upper management and investors. This success affirmed our identity as a startup capable of timely delivering a product meeting the expectations of a major market player.

During the subsequent quarterly meetup, our team received immense recognition for our work. We transitioned from being known for delays to celebrating how our achievement could pivot the product and company.

Learnings

After reading this story, you might think: “Yeah, that was the obvious solution… not impressed”. It was indeed obvious, but not so much for those immersed in context and facing problems in the service we ended up changing.

My past experience with microservices combined with relevant technical knowledge and argumentation skills has proven key to guiding the team to an architectural decision that would really help us instead of causing future frustration.

A second and even more important learning emerged almost two years later. My contribution could only hold significant weight because of:

My teammates’ openness to listening to a fresh newcomer with far less overall context than they possessed.
Management full trust and support.

I am immensely grateful to all my teammates during that period. Their openness and support enabled me in ways I couldn’t fully comprehend at the time.

Moving forward, I gotta watch myself to never push others back.

Takeaways

The next statements are probably irrelevant to most of the audience, but this is still a blog :)

I had many personal taken from this project since it is the work from my recent career path I am most proud of.

I do believe I nailed this one. While I still gotta much to improve on my argumentation skills, I naturally had the courage to challenge a solution that I knew would burden the team with unnecessary stress and useless work, ultimately escalating costs for the company. Standing up allowed us to collectively deliver a successful outcome with considerably less effort.

Moreover, this project marked my realization that my enthusiasm for microservices isn’t an all obsession. Prior to this project, I had primarily operated in environments where careful extracting services from monoliths brought or could bring substantial benefits. However, here, I proved to myself the importance of striking a balance between the advantages and disadvantages of any decision.

This project also presented to me as the first clear opportunity to bring technical impact beyond coding. While I did also code, the real impact came from learning, challenging, discussion, assessment, and decision. This milestone is aligned with my career goals.

Your Foreignisation

Felipe Martins — Sun, 03 Jan 2021 23:00:00 +0000

What is that?

By googling the term foreignisation, you will find out that this word is used to name a translation style.

Translation work is much more than just converting words from a language into another one just by using a dictionary. Let’s take this text from the web:

“Every morning, I walk through the nearby forest to pick up the cherries on the ground.”

Cherries are not common in Brazil, so in a domestic approach the translator could translate “cherries” into “pitangas” (a very Brazilian fruit) without any content loss, prioritizing the target culture and audience. In the foreignizing approach “cherries” would be literally translated into “cerejas” (cherries in Portuguese) although most Brazilians never saw a cherry tree. The cultural gap would outweigh the audience’s culture in the translator’s preference.

Yet another text from the web gives us a more disgested definition:

[…] translators divided into two translation groups: those who opted for foreignisation and those who supported domestication.

The best distinguished difference between these two main translation strategies was made by Lawrence Venuti, who explained that “you can bring the author back home” or just “sending the reader abroad”.

Many of you there are just like me and have decided at some point to leave your country of birth. Many others have already returned, others are still dreaming about it, and few might be packing just right now (few… well, this text was written within corona times).

The word Your in the title is probably even more significant since it is indeed very personal. Your foreignisation, which are composed of the steps you’ve taken in the past and the ones you will take in the future, is highly attached to you, to your goals, to your feelings, to your experiences, to the opportunities which were offered to you, your choices… it is your path.

Moving to an European country sounds exciting and many are jealous of me, but they don’t realize the entire thing is also:

A process of losing your identity.

Buhhh! Get out of the stage! This is so negative!

Okay… okay… for this world demanding positiveness from us all the time, let’s pretend to be positive and formulate your foreignisation as:

A process of rebuilding your identity.

Come on, what are you talking about?

First of all, let me introduce myself.

The very first thing you need to know about me is: everybody calls me fefas (well, except my dad). I am a Brazilian software developer currently living in Berlin. I am 31. I am more exactly from São Paulo city; a huge metropole. My background is Physics and I somehow got very much interested in software. I started learning it during my Bachelor’s degree. I love music, especially rock. I spend a lot of my free time playing my acoustic guitar. I am also into cycling, chess, photography, skating, tattoos. I enjoy getting drunk sometimes. Recently I have become more interested in history as well (not unexpected for someone living in Berlin). Ahh… you will hardly be able to square me in any well known standard stereotype. Living in Berlin was a dream. I am a happy and optimistic person, but very melancholy at the same time… well, it is not that hard giving all this sh&! happening around us every day.

Having this all, you start understanding my path. It is important to know who I am since this post is a result of my so-far-foreignisation.

Mh… what is your point then?

It is hard to explain.

Let’s ask the expats: your foreignisation is being harder than you expected, or am I mistaking? At least mine is being much harder than I expected.

Another important thing to mention is once you did it, there is no turn back. The song My My Hey Hey from Neil Young says:

Once you’re gone, you can never come back

When you’re out of the blue and into the black

Back in 2015, I and my dad were talking about these very same lyrics. I still remember like it was yesterday he telling me his interpretation of this passage:

It is just like when you read a book. Once you did it, you cannot unread it. You are now yourself plus this book forever.

Well, moving to a country with a different culture changes you. I mean… a lot!

Have you noticed I am using “country of birth” instead of “home country”? Why? For the expats I ask: which is your home country? Where is your home? Is it hard to find an answer? What kind of feelings did you have while trying to find an answer?

It is hard to describe your foreignisation with words. It is a feeling you have in there: some days it makes you feel like a stranger in a very wrong place, some other days it makes you feel like conquering the entire world.

Each time I am back in Brazil, I am happy and relieved, I feel just back home… but not really. After some days I start missing my place, my home. A friend of mine which has a very particular path once told me:

What I have here, I don’t have there. What I don’t have here, I have there.

Is moving abroad that bad?

Don’t get me wrong! It is fu&!ing incredible!

Putting yourself in such a challenge requires a lot of courage and brings outstanding experiences. Just thinking how much I have learned and how many times my life has completely changed since Aug 2017 is mind-blowing.

I have worked at two companies in Germany so far. The first one is huge and my team of ten was composed of seven different nationalities, while my team at the second company had six people from four different countries.

Another interesting stat: I have worked with people from Germany, Brazil, India, England, Poland, Serbia, Russia, Lithuania, Ukraine, Turkmenistan, Nigeria, Spain, France, Italy, Hungary, and others I can’t remember right now… this has been being quite a culture exchange.

Even though now I want to create some roots and reduce the number of crazy changes in my life, I can do it with confidence just now. I mean… in the past, it was impossible to see myself living in São Paulo, and nowadays it seems natural to just settle in Berlin.

That all was possible only because I moved out.

Quitting my job, canceling my rent and all other contracts, selling/donating everything I had, packing the rest into two bags, applying for a visa, saying goodbye to friends, family, and girlfriend… that all to get into a plane in less than 30 days and never walk back… that was a thing! It changed my life in such a manner that I would never imagine back there. Here I also want to thank everyone who supported me somehow.

So, what then?

I don’t wanna bring any bad mood to anyone. If you do consider moving, don’t think too much about the negative parts, otherwise, you might even give up.

My goal after sharing this all is to let everyone aware it is hard! Be prepared for hard times. Be resilient and don’t give up. It will be normal to struggle for basic stuff and it is fine to make mistakes.

Just go through it and find your place! If you feel something is wrong, don’t be afraid to move again, or don’t be ashamed if you ever decide to return. After all it is your path.

Pack, go, enjoy, and be proud of your achievements. Great things will happen.

I hope this open letter helps you :)

Clean Code, bullshit or common sense?

Felipe Martins — Sun, 08 Apr 2018 03:00:00 +0000

Common story

Bob started to work at a new company. Soon he realized his new job would have a lot to do with a very old and complex legacy system. It was an anemic code without tests. There was neither any documentation. No explanations about underlying workflows which should represent the decisions made to solve business requirements which someday were asked by some stakeholder, then added to the backlog, implemented and delivered. However, that stakeholder wasn’t in the company anymore as well as the first developers.

What should be called the domain was always very coupled to the infrastructure concerns… many classes had more than one thousand lines… methods had so many if statements creating so many paths to go through… namespaces 10 levels deep… a large usage of classes extensions…

Almost every task would be to solve a bug. Some of them were created a long time ago and others were introduced recently by a new fix. Trying to investigate the code history to figure out the reason of some changes and how they could be related with other parts of the code wasn’t even helpful because the commits weren’t well-organized and had poor messages…

For changing a small behavior he had to spend hours debugging and trying to understand what was written there. After a whole day of work, the result sometimes was changing or adding ~10 lines. Most of the new code was one more if statement deciding to update some value because it was wrong somehow causing a bug… the classes didn’t validate themselves… there were getters and setters everywhere…

He was experiencing bad code…

Why does it happen so commonly?

Let’s start clarifying something: please, don’t get me wrong! I don’t want to say simply the code is a $#@& and to blame developers or companies, because it won’t lead us to anything. That is true, we do have a lot of unprofessional developers, but just blaming isn’t the point and we have to consider a broader scenario to get deeper.

So, why does it happen? Why are we always wading?

There are many factors that contribute to it. Let’s picture a company growing, hiring more employees to grow faster, new developers come in, old developers leave, the dynamic business changes the requirements quite constantly, the communication between IT and business has gaps, developers are so focused to achieve the sprint commitment, the rush is always putting pressure on everyone working on the project, no one cares to learn about the user-product relationship, no one cares to write tests, developers cannot design as it seems not to deliver short term value, TDD is philosophical, the company doesn’t invest time to train its teams, the most valuable practice is what solves the today’s problem, hero culture rises, we always need more logs to try to realise what is going on, we need to lead the market…

I could summarize it as the result of rush and no study.

Given that scenario, the output bad code is at least comprehensive. Our world isn’t a nice place sometimes and we have to deal with this reality.

What is the point then?

I haven’t brought you here to give an easy-solution-answer, because it simply doesn’t exist.

My goal with this post is to reply the person who has that canned answer when developers complain about bad code: Look… the system works and makes money for the company. That is what matters and the developers are paid to maintain it.

Okay… I see the point and I agree with “the most valuable thing is a running software”. It sounds like magic and can comfort us, developers. However, we still have a big problem there.

Is it really a running software valuable?

A company which highly depends on technology to be running and wants to be innovative will never achieve its goals when software turns into a maintenance issue instead of pushing up the business. Coming back to Bob’s situation, it’s almost impossible to add or change behaviors of the application. How would be possible to deliver a new feature which would change the business workflow without breaking anything else? The risk is too high, the unknown side effects could be catastrophic and, in this way, the company is trying to survive instead of being innovative… it’s now just brute force… the competition is out there rising up.

For me, it’s hard to see the value being generated given this scenario.

Software making money today doesn’t mean software still making money in the future.

Bad code can break established companies and make startups die early… it isn’t because developers aren’t the front line that we can’t be the fault reason.

Clean code, aka having care for code, aka testing first, is the way to achieve a software the business can truly grow with. Let’s study, let’s improve our craft, let’s learn how to manage the rush!

As developers, it’s our responsability to write clean code… that isn’t about achieving the goal of tomorrow faster, that is about achieving the goal of the next year faster and safer…

Have you ever asked yourself what your manager expects from you? Would you guess short time result or long time result?

I know, I know… the perfection isn’t reachable… sometimes we do have to work on urgent issues. Nevertheless, my point is we shouldn’t conform ourselves to the bad code just going along with it…

What does my experience say?

I do have a real case where we’ve spent more time in the beginning to achieve well parity dev-prod environments, completely isolated database for each running instance of the project, end-to-end tests for the whole application, feature and unit tests for each codebase, automated deployment, hexagonal architecture… well… a lot of themes which are unreachable and philosophical for many out there… just bullshit for them…

It wasn’t easy… it was challenging. However, the result of our work turned into a product with almost zero bug rate. When a new bug is discovered, a new test scenario is written. Deployments are fast, safe and can be executed anytime. New features are easy to add and the old ones easy to change… that are the TDD benefits… that is an agile team!

We should fight against bad code and always do our best. There is only one error: not to try…

Here are some references:

Robert C Martin, 2008. Clean Code: A Handbook of Agile Software Craftsmanship
Nat Pryce; Steve Freeman, 2009. Growing Object-Oriented Software, Guided by Tests

What should a developer really catch?

Felipe Martins — Thu, 04 Jan 2018 21:09:53 +0000

Originally published at blog.fefas.net in 2017-06-18.

In my first post I would like to write about something that isn't found so often on the internet and most ~~experienced~~ developers are missing.

Maybe because they seem to worry more about tech-hacks than realistic professionalism... that is my guess.

First of all, I would like to say that this post is both something I have to vent out and a self-critique.

What are we, developers?

Stop it! Let's bring something up:

When we write code, we write solutions... or that's what we're supposed to do.

No, we aren't coding the next ~~magic~~ wonderful architecture. We SHOULD just translate business solutions to a code language that SHOULD solve business problems by adding some value somehow and it SHOULD be delivered in the simplest and fastest possible way. But we don't!

"We are unprofessional", Robert Martin has already said that.

In my short career I've seen more than once smart developers having the opportunity to work on an outstanding business model and using that business complexity as their motivation to build nice, sophisticated and high-tech applications which, as it turned out, ~~helped the company grow up~~ were just another group of hard-to-understand words and far far away from the business itself. In other words, a waste of time and money resulting in a code that was already legacy at the first day after deployment. A total mess!

What I am trying to put in words is strictly related to the professional attitude of a software developer. You are never going to be a respected CTO or even a senior if you don't give a damn to the next people that will continue the work; the next person can always be you again and again...

We have to face the truth by caring about how our current code will help the next developer in maintaining it. When we go a little deeper, we should ask why, what, how before coding anything. We have to know the way our work is going to impact the users. Understanding the final users and the business requirements is a critical gap between good and bad code.

If a developer doesn't have those concerns in mind, he is writing a bunch of lines that don't make sense together and, instead of improving users' experience, the growing mess isn't adding any value... the company may go out of business quickly.

Just to be clear: when I say good code I mean expressive code, not an agglomeration of design patterns. Good code is simple and direct.

Where is our problem then?

This could be an endless discussion. So, I selected only two of my guesses I judge being the most critical ones.

Many developers, just like me, didn’t pursue software-related degree at university. Actually, some of us didn't even go to college; and those who took software-related courses realized they didn't study exactly what is required to solve real problems. In other words, we teach ourselves almost everything by digging the internet.

That proves we are extremely self-motivated and curious. Indeed, we really enjoy learning more and more. The problem is that the internet has so much information that the beginners end up placing so much importance on what gives short-term results, that is tools.

Programming languages, frameworks, libraries and so on are important and make you powerful, but they all are still just tools.

A very important point to note on tools is when you stop to follow that nice framework for a couple of months and then you are suddenly out of date. But don't bother! You can read the new documentation and update yourself again quickly. Tools are ephemeral, easy to learn, abundant on the web and, trust me, most of them don't give a &$%# to your business domain.

On the other hand, when developers come across some new subject or tool, instead of taking the needed time to search and really understand it before coding, they go straight ahead and want to adopt it everywhere, because the ~~new silver bullet~~ solution was discovered. The result (not to say problem) is predictable...

For me, this kind of developer is the most dangerous, because they normally have more work-experience and are still acting like the ninja ones. Their attitude brings premature and wrong usage of tools, procedures and methodologies, putting the whole business and the collaborators in risk. They have no idea about their positions' value.

So, what should we really study?

Years ago at university I heard someone saying:

"What makes a snooker player stand out is not just trying to pocket the most challenging balls, but rather to best place the white ball for the next shot."

During the last two years I worked with great teams that introduced me to some terms: Clean Code, Test Driven Development (TDD), Domain-Driven Design (DDD), Behavior Driven Development (BDD), Continuous Integration (CI), (real) Object Oriented Programming (OOP), DevOps, Agile Manifesto, Software Craftsmanship etc.

I still have a lot to learn about those subjects, but they already changed my professional attitude and today I know I am on the right way to become that respected developer I've always dreamed to.

Meetups and daily knowledge exchange with team members are all important to discuss different readings about those terms, but they alone will still give you a limited understanding. Therefore, the only way to have a deep knowledge is by searching it by yourself through books, podcasts, events and so on.

The following books list is the main reason I wrote this post. Of course I haven't read all of them yet, but the ones I did have changed the way I develop every couple of pages, turning me into a more conscious and mature developer:

Jeff Langr, 2015. Pragmatic Unit Testing with JUnit in Java 8
Nat Pryce; Steve Freeman, 2009. Growing Object Oriented Software, Guided by Tests
Erich Gamma; Richard Helm; Ralph Johnson; John Vlissides, 1994. Design Patterns: Elements of Reusable Object-Oriented Software
Robert C Martin, 2008. Clean Code: A Handbook of Agile Software Craftsmanship
Martin Fowler, 2002. Patterns of Enterprise Application Architecture
Bertrand Meyer, 2009. Touch of Class: Learning to Program Well with Objects and Contracts
Vaughn Vernon, 2013. Implementing Domain-Driven Design
Vaughn Vernon, 2016. Domain-Driven Design Distilled
David Farley; Jezz Humble, 2010. Continuous Delivery
Mark Massé, 2011. Rest API Design Rulebook
Michael Nygard, 2007. Release It!
Ken Schwaber; Jeff Sutherland, 2016. The Scrum Guide
Thomas Björkholm; Jannika Bjorkholm, 2015. Kanban in 30 days
James Shore, 2007. The Art of Agile Development
Sandro Mancuso, 2013. The Software Craftsman: Professionalism, Pragmatism, Pride
Ash Maurya, 2012. Running Lean

And you can also follow the authors:

My recommendation is to start with The Software Craftsman by Sandro Mancuso.

I hope you can also find a reference to follow on those books. And remember, simplicity is a keyword.

Is there already any T-shirt with "Don't worry and keep it simple"?

Thank you Eriksen Costa for sending both lists when you were my boss and also thank you Eduardo Dobay for helping me with typo and english mistakes.

TDD is an ethical matter

Felipe Martins — Thu, 04 Jan 2018 02:00:00 +0000

My first talk

Some months ago I gave my first talk: “An Introduction to TDD”. I started it telling about my personal motivation of adopting this practice daily. Therefor I cited how the development process is a waste of time when we don’t have something helping us to focus on the requirements or guiding us to the next step. I cited also how developers put too much effort trying to predict all possibles scenarios from inside to outside.

After that I basically presented the feedback cycle with the three famous steps, explained the concerns behind each of those steps and introduced to the existing levels of tests in order to be able to show a sample code which illustrates how TDD can work on real. At the end I mentioned some good practices like AAA and FIRST that are helpful to improve both legibility and quality of the tests.

The goal of the talk was to give an introduction to the basics elements that a developer needs to write test first and an overview how the tests should guide the development process. However those who were interested on the subject, would still need to go deeper by theirselves.

A good summary: no waste, no effort on useless stuff, no “what if this happens? Or what if that happens?”… TDD gives us the opportunity to focus on the required business behaviors and just solve the problems.

I like to say that TDD is straight to the point.

The reaction

At the end what surprised me weren’t some questions and the positive feedback, rather some developers that started to put on balance time versus results, saying that TDD is an unreachable ideal and just a philosophical subject…

I was there asking myself: why would they be feeling so attacked if I haven’t even said that TDD is a must?

Since then I’ve been thinking about what happened and here I answer with almost the same arguments used on my last post: we have to be aware of our professional attitude and of the consequences of our work.

Just complaining is the real waste of time.

We have to face the truth and realise that if we aren’t writing tests today, we and others are going to have a lot of problems tomorrow. We also need to study to be able to delivery the better code as possible… I ensure that tests first is a good starting point to learn a lot.

Anyway, the main concern remains: TDD is really hard to adopt 100%.

Yes, I know that and I don’t believe everybody will start applying it perfectly overnight. Testing in the right way can be really challenging even for the most experienced developers, because you need not just to have a good understanding of Dependency Injection, Clean Code, OOP, Refactoring etc., but also to handle errors decently… the learning curve is relatively long.

However, I will also mention that TDD is a discipline.

When you start to use it, to understand it and to experience how TDD helps to develop faster and to improve code quality, writing tests first will be natural. It will be easier after each complete cycle and you will do it in a more consistent way… then suddenly TDD simply composes your development process and you finally agree TDD is the opposite of a waste of time.

I am sure you will be quickly asking yourself: Why are some developers still complaining about test first?

Why is TDD an ethical matter?

Uncle Bob starts the Clean Code book with:

“Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.”

Sorry, but there is no excuse to skip the tests just by argumenting that TDD is a waste. At the other side are teams emailing the wrong persons while developing and spending a lot of effort to reproduce and understand bugs already in production. Those are common situations on incidents where companies simply lost millions because they couldn’t predict simple issues…

Are you still complaining? If your team is slow, you should review your processes and your application design, if it is hard to adopt TDD, you should have a plan to teach your team… skipping tests will be always the wrong choice.

Let’s analyse what Uncle Bob said during a talk at GOTO; Amsterdam (video here):

“I will provide with each release a quick, sure and repeatable proof that every element of the code works as it is supposed to (…) otherwise known as tests (…) When did we decide that it is OK if some of that code doesn’t work? [No,] it is not OK if some of that code doesn’t work. And so, we should provide proof (…) that the code works as you believe.

We are all humans. We all make mistakes (…). It is not possible to achieve perfection, but it is always an error not to try. And the idea that we will simply accept a certain level of defects is inappropriate. [It] is unethical. We can’t accept that.”

TDD can take a little more time at the beginning, but trust me it has so many benefits.

Here are great books to read:

Jeff Langr, 2015. Pragmatic Unit Testing with JUnit in Java 8
Nat Pryce; Steve Freeman, 2009. Growing Object-Oriented Software, Guided by Tests
Robert C Martin, 2008. Clean Code: A Handbook of Agile Software Craftsmanship

Thanks and let’s test first!

Originally published at blog.fefas.net.

Hi, I'm Felipe Martins

Felipe Martins — Tue, 11 Jul 2017 02:41:43 +0000

I have been coding for 5 years.

You can find me on Twitter as @eufefas and on GitHub as @fefas.

I live in SÃ£o Paulo and I work for UPX.

I mostly program in PHP, but I worked already with C++, Python and Javascript and I've been trying Scala.

I've been learning a lot about TDD and Clean Code and now I am discovering more about DDD and DevOps.

Nice to meet you.