জটিল ফ্রন্টএন্ড pull request আমি কীভাবে দেখি

জটিল ফ্রন্টএন্ড pull request দেখার সময় নিজের রুচি দিয়ে শুরু করা আটকাই। নাম, formatting আর ছোট refactor জরুরি। কিন্তু প্রথম ঝুঁকি খুব কম সময়েই ওগুলো। আচরণটা আসলে বোঝা যাচ্ছে কি না, প্রথমে সেটাই দেখি।

route বা feature-এর সীমানা ধরে শুরু করি। পেজে কী state আসছে? দায়িত্ব কার? ডেটা খালি, পুরনো, আসছে, অনুমতি নেই, অর্ধেক আছে বা ব্যর্থ—তখন কী হয়? প্রশ্নগুলোর উত্তর খুঁজতে ইতিহাস খুঁড়তে হলে পরের মানুষের ওপর কোড বেশি চাপ দিচ্ছে।

তারপর দায়িত্ব কোথায় গলে যাচ্ছে দেখি। parent child-কে ইমপ্লিমেন্টেশনের switch দিচ্ছে। সুবিধে বলে component-এ অসংলগ্ন state জমছে। service এমন প্রোডাক্টের সিদ্ধান্ত জানে যা জানার কথা নয়। template-এ condition-এর মধ্যে business rule লুকিয়ে আছে, যা পরে বদলাতে কারও মনে থাকবে না।

শুধু কোডের পথ নয়, মানুষের পথও দেখি। ভুল থেকে ফিরতে পারবেন? action কাজ করেছে কি না বুঝবেন? বন্ধ action-এর কারণ বলা আছে? update-এর পরে আগের কাজের প্রেক্ষাপট থাকে? শুধুই গঠন দেখে রিভিউ করার চেয়ে এই প্রশ্নে বেশি বাস্তব regression ধরা পড়ে।

ভালো review comment কোডবেস ভালো করবে, রিভিউয়ার কত চালাক তা প্রমাণ করবে না। ঝুঁকিটা বোঝাতে চেষ্টা করি: এখানে একই তথ্যের দ্বিতীয় উৎস হচ্ছে, child-কে parent-এর জ্ঞানের ওপর দাঁড় করাচ্ছে, retry state বাদ গেছে, design system থেকে আলাদা হয়ে যেতে পারে।

ভালো PR-এ সঠিক অর্থে রিভিউটা সাদামাটা হয়। আচরণের নাম আছে, state দেখা যায়, component-এর কাজ স্পষ্ট। কী ছাড় দেওয়া হয়েছে, প্রশ্ন করার আগেই বলা আছে।

ফ্রন্টএন্ডের কাজে এমন পরিবেশই চাই: ঝুঁকি নিয়ে সোজা কথা, কাজ শেষ করার চাপের প্রতি সম্মান, আর অস্পষ্ট UI-র চুক্তি যেন আগামীকালের রক্ষণাবেক্ষণের বিল না হয়।