Podcast URL: https://www.youtube.com/watch?v=alUfh7Nk4eE

The podcast I chose is presented by Patrick Akil, and this specific episode features Eugene Fidelin. Eugene, as described on his LinkedIn profile, is an Engineering Manager and Frontend SME at eBay Advertising. The two participants discuss many subjects related to high-quality software development, including topics like bug prevention, testing, the balance between speed and quality, team performance, and many other subjects. One piece of advice, in case you would like to listen to the podcast, is that its timeline on YouTube is broken down into various topics, making it easy to find a specific subject

Many times, I start reading an article or listening to a podcast, and it does not hold my attention. However, this podcast kept my attention throughout its entire length for two reasons: the way it is produced and the way the topics transition from one to another. It is not very technical, which makes it easy to understand, and it dispenses the need for visual aspects deliver all the information. It feels very much like a conversation between two people who enjoy what they do.

While listening to the podcast, I took notes on a couple of topics and phrases that caught my attention. Right in the first few minutes of the podcast, Patrick and Eugene discuss resilience and predictability. They make a great point, stating that every program’s goal should be to be both resilient and predictable. However, creating software that is completely resilient can make it difficult to modify, meaning that adding or changing something could break a certain part of it.

The last three topics that caught my attention are all about testing. I believe they interested me most because I have not delved deeply into any kind of testing. The first topic is about good practices for testing programs, which includes testing the frontend and the API separately, and then running tests on both together. Another interesting topic related to testing is observability over prevention in edge case tests, meaning that sometimes observing behavior over time might be more beneficial than running tests on edge cases, especially since continuous testing of such cases may slow down the testing process. Another great comment was about which type of test to use for either frontend or backend; not every type of test will fit every backend, and not every type of test will fit your frontend design.

I plan to use this advice and these practices in my career to achieve better results. I would also like to highlight another topic mentioned at the end of the podcast: not every person fits every team. It takes more than just a resume to determine if someone fits the team’s style.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

Article URL: https://dev.to/moh_moh701/part-1-what-is-clean-architecture-4bn1

The article chosen, written by Mohamed Tayel, discusses a software design philosophy introduced by Robert C. Martin (Uncle Bob) called Clean Architecture. Mohamed’s article explains what Clean Architecture is and why it could be a good software design option. The goal of Clean Architecture is to create and build systems that are easier to understand, flexible in terms of scalability and modifications, and easy to maintain. Initially, he presents the main objective of Clean Architecture and later discusses the design’s principles, benefits, and key components.

Interestingly, Robert C. Martin’s (Uncle Bob) blog was one of the blogs I discovered a couple of weeks ago while searching for articles on Object-Oriented Programming. His blog contains a lot of great content and well-written articles on various Computer Science subjects. However, that is not the reason I picked this specific article to discuss today. After reading the first paragraph, I found myself engrossed in the article until the end. I have always been interested in finding ways to make my own code more readable and easier to maintain. I have been amazed by how Object-Oriented Programming, based on its principles, is very organized, making it easy to understand and modify. Clean Architecture seemed to me like a way to achieve similar benefits from Object-Oriented Programming in programs not built with languages that support it.

I honestly believe that Clean Architecture’s goals can be applied to any program. I am not trying to undermine Clean Architecture’s merit as an excellent way of designing programs, but I truly think that every program should be planned and built to achieve the five benefits Mohamed Tayel mentioned in his article about Clean Architecture:

1. Improved Testability
2. Flexibility
3. Maintainability
4. Reusability
5. Scalability

I plan to incorporate its objectives and main characteristics into my next programs. Especially by applying two of Clean Architecture’s principle, flexibility and improved testability. Flexibility consists of building a software that can support changes to it (e.g. replacing a database or a web framework) with minimal impact to other parts. And Improved Testability consists of “decoupling the business logic from external dependencies, to achieve higher test coverage” (Mohamed Tayel).

Clean Architecture seemed to me as an attempt to implement certain Object-Oriented Programming principles in software built with languages that do not support it. Clean Architecture breaks down software into four layers: Entities, Application Core, Infrastructure, and User Interface. By breaking down the software and having each layer encapsulate another, it is very similar to OOP design.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

This is my personal blog…

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.