প্রথম রিলিজের পরে বদল সামলানোতেই ফ্রন্টএন্ড আর্কিটেকচারের পরীক্ষা

ফ্রন্টএন্ড আর্কিটেকচার মূলত folder, state library বা এখন কোন pattern চলছে, তা নিয়ে বলে মনে করি না। এগুলো জরুরি, কিন্তু লক্ষণ মাত্র। আসল প্রশ্ন আরও সোজা: প্রোডাক্ট বদলালে চাপটা কোথায় গিয়ে পড়বে?

ভালো UI আর্কিটেকচার সৎ একটা কথা দেয়। এই ফিচার এখানে বাড়তে পারবে, ওই আচরণের দায়িত্ব এই component-এর, state বদলানোর এই ধাপটার নাম আছে, আর গ্রাহক দেখার আগে error-এর পথটা ভেবে দেখা হয়েছে। চতুর দেখানোর চেয়ে ওই ভরসাটা বেশি কাজের।

এর উল্টোটা হল ভালো লাগার ওপর দাঁড়ানো আর্কিটেকচার। শুরুতে সব দ্রুত লাগে, কারণ এখনও কোথাও সীমানা নেই। দ্বিতীয় সংস্করণে parent child-এর ভেতরে হাত দেয়, route টেবিলের বেশি খবর জানে, loading আর error state আন্দাজ করে কপি হয়। প্রোডাক্ট এক রাতে জটিল হয়নি। জটিলতা রাখার জায়গাই কোডে ছিল না।

আমার ঝোঁক, বদলটা আগে থেকে দেখা যাক। state-এর নাম থাকুক। প্রোডাক্টের ভাষা কোডে থাকুক। feature area-র দায়িত্ব থাকুক। সাধারণ কাজ সহজ হোক, বিপদের কাজ চোখে পড়ুক। পরে কোনও ইঞ্জিনিয়ার ফাইল খুলে যেন বোঝেন, প্রোডাক্টের কেমন সিদ্ধান্তে হাত দিচ্ছেন।

তাই শুধু আর্কিটেকচার মনে হওয়ার জন্য বানানো abstraction নিয়ে সন্দেহ হয়। যে layer বদলের চাপ নেয় না, সেটা সাজসজ্জা। যে reusable component নিজের প্রোডাক্টের দায়িত্ব বোঝাতে পারে না, সেটা সুন্দর API-ওয়ালা ঝামেলা।

দল ইন্টারফেসের ওপর ভরসা না হারিয়ে এগোতে পারছে কি না, সেটাই আমার মাপ। ব্যবহারকারী আর্কিটেকচার টের পান গতি, মিল থাকা আচরণ, ভুল থেকে ফেরার সুযোগ আর কাজের ধারা বোঝা হয়েছে কি না দিয়ে।

এমন ফ্রন্টএন্ড আর্কিটেকচারই বানাতে চাই, যা diagram-এ চমক দেখানোর বদলে সংশোধনের সময় স্থির থাকে।