"Big Ball of Mud" নামে একটা কনসেপ্ট আছে সফটওয়্যার ডেভেলপমেন্ট ওয়ার্ল্ডে।
ব্যাপারটা খুবই পরিচিত,
- প্রথমে ছোট একটা দোকান বানালেন, একতলা। কোডও ছিল পরিচ্ছন্ন, সবকিছু একদম ঠান্ডা।
- তারপর গ্রাহক বাড়লো। ভাবলেন, আরে একটু সাইডে ঘর লাগাই, পরে প্রয়োজন হলে ঠিক করবো।
- পরে আবার ঘর লাগালেন, দেয়াল ভাঙলেন, ছাদে টিন লাগালেন, কোথাও সিমেন্ট, কোথাও বাঁশ, সব মিশ্রণ একটা বিচিত্র ককটেল।
শেষে দেখলেন,
এটা দোকান না, এটা কাদার গোলা, যেখানে হাত দিলেই ডুবে যায়।
এটা একধরনের “ধীরে ধীরে ডুবে যাওয়া” যেখানে প্রতিদিন ছোট একটা ভুল, কাল আরেকটা ভুল, আর সেগুলো মিলেই পুরো সিস্টেমকে কাদায় পরিণত করে
কীভাবে Big Ball of Mud এড়ানো যায়
আপনার অ্যাপ যখন বাড়ছে, তখন মনে রাখতে হয় যে এটা “চালাবেন পরে” জাতীয় প্রজেক্ট না, এটা বাসযোগ্য জায়গা।
এড়ানোর উপায়গুলো আসলে খুব মানবিক।
১) প্রথমেই আলাদা ঘর বানান।
মানে, শুরুতেই মডিউল বা ফিচার অনুযায়ী কোড ভাগ করুন।
User service, product service, payment service, এসব আলাদা রাখলে, পরে এগুলো নিজের পায়ে দাঁড়ায়।
অনেকটা ঘরের রান্নাঘর আর বেডরুম আলাদা রাখার মতো।
২) shortcut-এর প্রেমে পড়বেন না।
“এইটা সাময়িক করে রাখি” এই বাক্যটাই Big Ball of Mud-এর জন্মসূত্র।
সাময়িক জিনিস নিজের মতো করে স্থায়ী হয়ে বসে।
পরে সেটা ঠিক করতে তিনগুণ খরচ লাগে।
৩) এক জাদুকরী জিনিস আছে: test.
পরিষ্কার architecture কখনো টেস্ট ছাড়া হয় না।
টেস্ট না থাকলে আপনি কোড পরিবর্তন করলে সে আপনাকে আঘাত করে
আজ left চেঞ্জ করলে tomorrow right ভেঙে যায়; বোধহয় দূরসম্পর্কের শ্বশুরবাড়ির মতো আচরণ।
৪) Refactor ছোট ডোজে।
রিফ্যাক্টর মানে কোডের ঘর ঝাড়ামোছা।
এটা যদি ছয় মাস পরে করেন, তখন সেটা রেনোভেশন হয়ে যায়;
একটু একটু করলে মাথা ব্যথা কম হয়, আর ঘরটাও থাকে পরিষ্কার।
৫) Dependency-গুলোকে শাসনে রাখুন।
রাস্তায় বেয়াড়া বন্ধুকে যেমন ঠিকমতো চালাতে হয়,
framework/library-গুলোকেও তেমন কন্ট্রোলে রাখতে হয়।
যেখানে দরকার নেই সেখানে npm প্যাকেজ এনে পুরো ecosystem ভারি করলে সেই ভার টেনে পরে project কাঁদে।
৬) আর্কিটেকচারকে evolve করতে দিন।
আপনি যেই আর্কিটেকচারে project শুরু করেছেন, হয়তো user ১০০০ হলে সেটা যথেষ্ট।
কিন্তু ১ লাখ হলে ঘর বড় করতে হবে,
এটা না করলে architecture নিজেই চাপ খেতে খেতে কাদা হয়ে যায়।
স্কেল-ready design মানে ভবিষ্যতের চাপ সহ্য করতে পারে।
৭) কোড রিভিউ: দলের বিবেক।
চোখ এড়িয়ে গেলে Big Ball of Mud চুপচাপ বাড়ে।
রিভিউ মানে একে অপরকে সেফ রাখার উপায়,
এটা কোনো ego contest না; এটা home-inspection.
কেন এগুলো কাজ করে?
কারণ Big Ball of Mud জন্মায় যখন কোড অসংগঠিত, হাস্যকরভাবে অস্থায়ী, এবং নিজের নিয়ম না মানা হয়ে যায়।
উপরের অভ্যাসগুলো কোডকে এমন এক পরিবেশ দেয় যেখানে কাদা শুকিয়ে কাঠামো তৈরি হয়।