Skip to main content

Posts

Showing posts from 2022

Ruling the code with Rules Design Pattern

Greetings! As a big fan of Chain Of Responsibility design pattern I was thinking to move out the if condition into a separate method so that I can loop through chain externally. It turned out that I end up implementing Rules Design Pattern. I first encountered the pattern few years ago in a C# article ( https://www.michael-whelan.net/rules-design-pattern/ ). You can find the pattern in this course patterns-library . Rules Design Pattern In this pattern, we decouple the business rules from their processing by encapsulating them in to separate classes. We can add/remove rules without impacting the existing logic. This looks much like the Chain of Responsibility except processing rule is separated. One glitch I have faced is we are unable share one rules data with another as the rule and processing are decoupled. Anyway, it is worth to try. I'm not going re-invent an example. Instead i'll use the same example as in C# article but with minimum logic. public class Customer { pr

Let's Restore Agile

Greetings! I have been working in Agile environments for different companies for many years. We had/have a Scrum Master and Daily Standup, and that is it. That is Agile. This is what made me think "daily meetings are for bad managers". I started reading, practicing more on Agile and found this ( how-keep-your-team-from-getting-agile-wrong-hasitha-liyanage ) interesting article where I got more courage to apply Agile principles, values into my team. Where to Start? The first thing anyone should do is to read agile manifesto. It quite amusing that even certifed scrum masters/managers have no proper understanding on the manifesto. It Is Not About Processes The very first princile in Agile is "team over process". What does mean is, processes have value but the team has more value. For an example we don't need Daily meetings if the team decided so. It is the team decide how to work. Supoort and Trust Have you ever felt Trusted and Supported? If the answer is NO, you

Do not use magic in unit tests

Greetings! Working in legacy system is both fun and hard. It becomes harder due to lack of tests. Not only that, it is difficult to write tests due to the ways code is written. As our legacy system doesn't have a DI framework like Spring, we are maintaining object lifecycle manually. We have a policy to create singletons (I do not know why, I plan to remove them anyway) which made them harder for unit tests. The way to write unit tests for these classes is using reflection and mocking frameworks (scary isn't). Let's see a basic example of such a class. public final class AppointmentRepository { private AppointmentRepository() { } private static class LazyHolder { private static final AppointmentRepository INSTANCE = new AppointmentRepository(); } public static AppointmentRepository getInstance() { return LazyHolder.INSTANCE; } } public final class AppointmentService { private final AppointmentRepository appointmentRepository; private AppointmentS

Split your Loop

Greetings! It is common thing in programming that we need to iterate over items. Question is, how do you iterate over collection and implement your logics? Most of the time, people violate single responsibility principle as loops are having multiple logics. I would like to have cleaner separation between unrelated logics. If you pay attention, you can see that in loops, we are doing multiple things. Let's see a little (dirty) example. public class SplitLoop { public static void main(String[] args) { List<Subject> subjects = Arrays.asList(new Subject("Maths", 90), new Subject("History", 85)); int total = 0; int marksForMaths = 0; for (Subject subject : subjects) { total += subject.getMarks(); if ("Maths".equals(subject.getTitle())) { marksForMaths = subject.getMarks(); } } System.out.println("Total " + total + " for Maths " + marksForMaths); } static class Subject {

Are you a ticket closing developer?

Greetings! "I have done my work. I'm taking another ticket." "Can we close this ticket end of the sprint." "Why is this ticket still open." "We need to work extra and close these tickets." Those are only a few phrases. If you have not heard those words, congratulations!! you are working in a super nice environment. Unfortunately for most, these are daily sentences they encounter. The definition I'm using this term for anyone, be it an intern, architect, manager or anyone whose main target is to close the ticket by themselves or by forcing others. They do not focus on, do not allow code improvements. Why do they do it As I can't read minds, I don't know. However they may be targeting big paychecks, promotions, praises, etc by showing they are very efficient, committed, etc. However they are just moving from one ticket to another. How do they look like Lazy to learn Do not understand the value of good code No proper use of design pr

Replace HashTable with Map

Greetings! While I was reviewing a code, I noted that there is a Sonar violation saying not to use HashTable. Which is correct. Also it suggested to use something like HashMap instead of HashTable. I reached out the developer and asked to remove the HashTable but she said that use of HashMap did not work. Also when I asked why did you use HashTable at first place, the answer was legacy code expects it, hence for new code we need to add HashTable. Let's see how we can solve such cases.  Problem First of all we need to understand why these kind of rules exists. Our codebase is very old hence we have lots of deprecated class usages. Former developers have used whatever the API available those days. As a junior developer you need to understand, learn that classes like HashTable, Vector should not use in modern codes because those are synchronized. You need to replace those with modern APIs. Hashtable<Integer, String> ht1 = new Hashtable<>(); Problem... Again One of thos

Do not judge a design by sonar coverage

Greetings! I have been using SonarQube as a quality tool for quite some time now. It is used for continuous inspection of code quality to perform automatic reviews with static analysis of code to detect bugs, code smells, and security vulnerabilities. Eventhough the intention is to detect issues, top level managers, architects, etc use it to measure team's working quality progress in their visual boards. As they are usually busy people they will not have time to look into real code and to see the real issues there. What happen then? developers will start to write "sonar satisfy" codes. I have seen very unreadable bad codes with zero sonar quality issues. And also there are good quality codes with some unnecessary sonar issues. Reason for that is it can detect prefined rules but not all design flows. If you want to be a good developer, don't try to write "sonar quality" code, instead use "clean codes" and get the Sonar support when necessary. Let

Breaking if/else with a Chain

Greetings! There are If/Else or switch statements in any Software. We need to use that logical branching for object oriented programming as well. The question is how do you use that? are they readable? maintainable? or looks beautiful? What I normally see in such codes is those are very fragile, hard to read, ugly. Needless to say about the vulnerability of the branching levels in this case. Most of the developers might add few private methods and call those to show that the code is clean. This can be solved in multiple ways depending on the situation. Simple Conditions When you see such a code, consider it as a candidate for polymorphism. In most of the cases, you can deal this with abstraction. A simple factory will do the rest. Multi level branches Complexity arrives with multi levels. It is quite difficult to identify common factors, abstraction. However, it does not mean you can't do it. It depends on the problem at hand. You might still fix this with a simple interface, using

What we learned (in each Sprint)

Greetings! Another job change, another team. That is how my career goes as I tend to change jobs (for obvious reasons). This time I'm working with a team where almost everyone is new to the business and product domain. Not only that, more than half of them are freshers. If I don't teach them who will? I have tried various ways to teach the team about the business and product domain (this is even new to me), internal frameworks (again new to me), and other technical aspects. Things we do/ did Clean Code chapter by chapter by each member Domain knowledge sessions with QA/ BA Internal framework sessions by each team member (learn and teach) Continues knowledge trainings (Java, Design Patterns, Angular, any useful technical thing) Gaining knowledge and insights from from other team. (lucky that we have friendly people here) Question of the Day - separate team chat group in which each teammate gets the opportunity to ask a question. (though people often forget this due to busy work)