Behind Premature Abstraction

Career এর এক স্টেজ এ এসে আমরা অনেকেই অনেক নতুন নতুন টপিক এর সাথে পরিচিত হয়। যেমনঃ Queue, Stack, Design Patterns, Different Technologies like (K8S, Kafka, Rabbit MQ etc.), SOLID, DRY, KISS etc সব যে আমরা ব্যাবহার করি ডেইলি লাইফে এমন টা নয় তবে এইগুলোতে হাত পাকানোর একটা আগ্রহ কাজ করতে থাকে। আর এখান থেকেই একটা গর্তে পরে যাওয়ার সমূহ সম্ভাবনা তৈরি হয় সেটা হচ্ছে Premature Abstraction.

Let’s say, আপনি একটা ইভেন্ট বুকিং সিস্টেম এ কাজ করছেন। আপনার কাছে একটা requirement চলে আসলো, যদি কোন সিট বুক হয় user একটা confirmation মেইল পাবে। সিম্পল কাজ।

আপনি একটা সিম্পল ফাংশন লেখলেন যেটাকে কল করলে রেসিপিএন্ট এর কাছে মেইল যাবে। simple as that right?

কিন্তু না আপনি assume করা শুরু করলেন,

• ইমেইল সেন্ডিং যদি slow হয়ে যায়? Lets add Queue with Producer Consumer pattern.

• এই সিস্টেম টা আরো রোবাস্ট করার জন্য Event Driven আর্কিটেকচার দিয়ে ইমপ্লিমেন্ট করা উচিত। Let’s add RabbitMQ

• সামনে হয় তো একাধিক ইমেইল প্রভাইডার আসতে পারে বা পরে হয় তো আমরা Push Notification-ও পাঠাবো আমার উচিত একটা একটা Abstraction Layer তৈরি করা যেখান থেকে ইমেইল ও সেন্ড করা যাবে আবার Push Notification Trigger করা যাবে। কোড ডুপ্লিকেসন ছাড়া।

এতো কিছু করা হল without sending an email.

এতে কি কি সমস্যায় পরলেন?

• সম্পূর্ণ implementation একটা Overengineering হয়ে গেল। এই কোড মেইনটেইন করা এখন আগের থেকে বেশই কমপ্লেক্স হয়ে গেছে। কিন্তু Noticeable কোন বেনিফিট আমরা পাই নি।

• শুধু মাত্র DRY Pricipal কে ঠিক রাখার জন্য এমন একটি Artificial Abstraction Layer তৈরি করলেন যারা আসলে একই ডোমেইন এর না। দুইটা আলাদা জিনিস। পরবর্তীতে Refactor করা আরো মুশকিল হয়ে যাবে।

  Code duplication is far cheaper than a wrong abstraction

  -Sandi Metz Rails Conf 2014

• প্রয়োজনের আগেই Abstraction কোড কে কমপ্লেক্স করবে এবং readibility কমায় দিবে।

আমাদের মধ্যে একটা insecurity কাজ করে আমাদের software কে Future Proof বানানোর জন্য, এটাই মূলত Premature Abstraction অথবা Premature Optimization এর জন্ম দেয়।

আমার পিরসাব এর একটা কোট আছে যদিও এটা অন্য কনট্যাক্সট কিন্তু রিলেটেবল,

"আমার নাতির পুতি কোন স্কুলে পরবে সেটা নিয়ে এখন মাথা ঘামানো দরকার নেই"

Premature abstraction is solving a general problem before you really have the general problem.

Solve the problem we have, not what we think we will have.