কতগুলো PR Stalled হতে দেখেছি কেউ দুইটা Similar দেখানো Code Block Point out করে "Unified" করতে বলেছে। শুনতে Great Idea মনে হয় যতক্ষণ না তুমি তিন মাস Deep হও একটা "Generic" Validation Function-এ যেটা এখন Eight Boolean Flags নেই শুধু Billing Service-এর একটা Edge Case Handle করতে।
...আর সেই Trap-টাই। আমাদের DRY শেখানো হয় কোনো Moral Imperative হিসেবে, কিন্তু Microservice Environment-এ, DRY principle programming এর ভুল ধারণা সাধারণত শুধু Hidden Dependency Build করা মানে — যেটা তোমার পরের Deployment-কে Nightmare বানাবে। "Shared Utils" Era দেখেছি যেখানে এক জায়গায় Date Formatter Change করলে Entire Auth Flow Break হলো কারণ কেউ ভেবেছিল Unrelated Domains-এর মধ্যে Code Share করা "Elegant"।
"Wrong Abstraction" হলো Refinance করতে না পারা Debt
Code "Un-abstract" করা Copy-paste পাঁচ লাইন Logic করার চেয়ে অনেক Harder। একবার পুরো Friday Afternoon Spend করেছিলাম GenericEmailService Decouple করতে কারণ Marketing Team Transactional System-এর চেয়ে Different Template চাইছিল। দুই লাইন SMTP Setup Copy-paste করলে পাঁচ মিনিটে শেষ হতো। তার পরিবর্তে, if Statements আর Optional Parameters-এর Web Untangle করতে হলো।
DRY principle programming এর ভুল ধারণা: Duplication আসলে Cheaper
Backend Service-এ, দশ লাইন Duplicated Logic থাকলে 50-line "Utility"-এর চেয়ে অনেক বেশি Prefer করি যেটা পাঁচটা Different Use Case Handle করে।
- Readability: Logic ঠিক সেখানেই চাই। তিনটা Nested Helper Follow করে দেখতে চাই না কিভাবে Simple Validation হচ্ছে।
- Decoupling: Logic Duplicate করলে, Billing Service Change করতে পারি Inventory Service Break করেছে কিনা Check না করেই। তারা Different Speed-এ Evolve করতে পারে।
শেয়ারড ইউটিলিটি লাইব্রেরি নিয়ে আমার একটা চরম ঘৃণা আছে। কেউ একজন একটা CommonUtils ফাইল বানায়, আর তারপর সবাই সেখানে আবর্জনা ফেলতে থাকে। মাসখানেক পর সেটা এমন এক মনস্টার হয়ে দাঁড়ায় যে কেউ আর সেটা টাচ করতে চায় না।
আমার Rule (যেটা সবসময় Change করি)
আর "Rule of Three" Follow করি না। পাঁচ বা ছয়বার Duplicate হওয়া পর্যন্ত Wait করি, আর তখনও নিজেকে জিজ্ঞাসা করি সত্যিই কি Same Business Concept। কখনও কখনও জিনিস Coincidence-এ Same দেখায়।
শুরু করেছি ভাবতে DRY শুধু "Low-level" জিনিসে Apply করা উচিত — Math, Encryption, হয়তো কিছু Very Stable Protocol Implementation। Business Logic Involve করে এমন কিছু? Perfectly happy to repeat myself। Rest of Codebase-এ Surgery না করে একটা Feature Delete করতে পারার Small Price এটা।
PR Review Weapon
সবচেয়ে বড় Gripe হলো যখন People DRY-কে Code Review-এ Weapon হিসেবে Use করে। এটা Point out করতে সবচেয়ে Easy জিনিস — "Hey, এটা অন্য জিনিসের মতো দেখায়" — আসলে দুটো জিনিস Couple করার Architectural Cost না ভেবে। এটা Lazy "Clean Code" Dogma যেটা Software কীভাবে Actually Change হয় সেই Reality Ignore করে।
Meta Description: DRY principle programming এর ভুল ধারণা এবং কেন কোড ডুপ্লিকেশন মাঝে মাঝে ভালো হতে পারে। জানুন ভুল অ্যাবস্ট্রাকশন থেকে বাঁচার উপায় এবং রিয়েল-লাইফ কোডিং অভিজ্ঞতা।
About the Author
Asaduzzaman Pavel is a Software Engineer who actually enjoys the friction of a well-architected system. He has over 15 years of experience building high-performance backends and infrastructure that can actually handle the real-world chaos of scale.
Currently looking for new opportunities to build something amazing.