এখনকার ভাবনা · ছয় পর্বে
6টির মধ্যে পর্ব 5 AI-কে নিয়ে ডেভেলপমেন্টের গোটা ব্যবস্থা গড়া
প্রমাণ দেখাতে না পারলে এজেন্টের কাজ এখনও শেষ নয়
তৈরি হওয়া diff একটা প্রস্তাব। কাজ শেষ বলতে হলে ঝুঁকি মেনে চাহিদা, পরীক্ষা, ব্রাউজারের আচরণ আর জানা সীমাবদ্ধতার মধ্যে প্রমাণের যোগ চাই।
diff-টাই প্রমাণ নয়। আর build পাস করলেই প্রোডাক্ট ঠিক হয়েছে বলা যায় না।
তৈরি কোড আসলে একটা দাবি
এজেন্ট একটা বদল দিলে সে দাবি করছে: আশপাশের ব্যবস্থা নষ্ট না করে এই ইমপ্লিমেন্টেশন চাহিদা মেটাচ্ছে। কোডটা সেই দাবির প্রমাণ নয়। কোডটাই যাচাই করার জিনিস।
কম্পাইল হওয়া প্রমাণ করে ভাষা আর framework ওই সংস্করণের program মেনেছে। unit test প্রমাণ করে সে যে আচরণ দেখার জন্য লেখা, সেটা হয়েছে। screenshot ওই মুহূর্তের একটা rendered state দেখায়। সব কটি কাজে লাগে। কিন্তু কোনও একটিই গোটা প্রোডাক্টের শর্তের বদলি নয়।
ইমপ্লিমেন্টেশনের পাশাপাশি যাচাইয়ের পরিকল্পনাও চাই। কোন আচরণ ঝুঁকির, আগের কোন নিশ্চয়তা নড়তে পারে, আর কী প্রমাণ লাগবে—কাজ শুরু করার আগেই জানা থাকুক। শেষে প্রমাণ যোগ করতে গেলে অনেক সময় দেখা যায়, কাজটা এমনভাবে বানানো হয়েছে যে যাচাই করাই কঠিন।
ছোট স্ক্রিনে সামনে এল অন্য ভুল
পরিচয় বাদ দেওয়া এক ইন্টারফেসের বদলে এজেন্ট panel বন্ধ করার কাজ ঠিক করে component event-এর নির্দিষ্ট test যোগ করেছিল। অ্যাপ build হল, desktop-এ পথটাও ঠিক চলল। ছোট viewport-এ panel চোখ থেকে সরল, কিন্তু overlay সক্রিয় রয়ে গেল। নিচের পেজে tap আটকে দিচ্ছিল।
component-এর হিসাবে দাবিটা মিটল, ব্যবহারকারীর আসল চাহিদা মিটল না। action-এর পর মানুষকে কাজ চালিয়ে যেতে পারতে হবে। layout-এর ধরন যে মাপে বদলাচ্ছিল, সেখানে ব্রাউজারে interaction চালিয়ে দেখা হয়নি।
ফাঁকটা বন্ধ করতে verification packet কাজে লাগাই। চাহিদার পরিচয়, check, route, state, viewport, role, প্রমাণ আর জানা সীমাবদ্ধতা জোড়া থাকে। panel-এর উদাহরণে component-এর বদল, সরু স্ক্রিনের interaction, focus-এর আচরণ আর নিচের পেজ সত্যি ব্যবহার করা যাচ্ছে কি না—সব দেখা লাগবে। যে দাবির পক্ষে প্রমাণ, প্রমাণ তার সঙ্গেই থাকে।
যা অটোমেট করি
চাহিদা আর প্রস্তাবিত বদল থেকে ঝুঁকি অনুযায়ী যাচাইয়ের পরিকল্পনা বানানো অটোমেট করি। নির্দিষ্ট test, type check, build, static validation, ব্রাউজারের পথ, viewport, theme আর permission state বেছে নেওয়া যায়। console error, ব্যর্থ request, অপ্রত্যাশিত redirect আর চোখে দেখা ফল দেখা যায়।
যাচাইটা ইমপ্লিমেন্টেশনের পরে বানানো রিপোর্ট হয়ে থাকুক চাই না। একটা চক্র হোক। ব্রাউজারে ভুল ধরা পড়লে ঠিক সেই অবস্থা আর প্রমাণ এজেন্টের কাছে ফিরবে। কাজ বদলাবে, নির্দিষ্ট পরীক্ষা আবার চলবে। ওই দাবি ঠিক হলে দরকারমতো বড় regression check হবে।
কতটা দেখা হয়েছে তা সৎভাবে বলাটাও অটোমেট করি। শেষ সারাংশে থাকুক কী পরীক্ষা হয়েছে, কী পাস করেছে, যাচাই করতে গিয়ে কী বদলাতে হয়েছে, আর কী প্রমাণ করা যায়নি। টেস্টিং সফল হয়েছে এমন অস্পষ্ট কথার চেয়ে ছোট, নির্দিষ্ট প্রমাণের মানচিত্র ভালো।
যে সিদ্ধান্ত মানুষেরই থাকবে
ঝুঁকির জন্য যথেষ্ট প্রমাণ বলতে কী বোঝায়, মানুষ ঠিক করবেন। spacing-এর বদল আর permission-এর সীমানা, মুছে ফেলার action, data migration বা tenant অনুযায়ী সংবেদনশীল route-এর প্রমাণ সমান হবে না। ব্যবস্থা গভীরতা সাজেস্ট করতে পারে। ঝুঁকির দায় দলের।
যা হ্যাঁ-না পরীক্ষায় ধরা কঠিন, মানুষকেই দেখতে হয়। ইন্টারফেসে কোথায় আছি বোঝা যাচ্ছে? ব্যর্থতার অবস্থা সৎ? interaction অনুমান করা যায়? অক্ষরে অক্ষরে চাহিদা মানতে গিয়ে পুরো workflow খারাপ হয়ে গেল কি?
মানুষের কাজ প্রতিটা অটোমেটেড ধাপ আবার হাতে করে করা নয়। জরুরি প্রমাণটা দেখা, বাদ পড়া জায়গা নিয়ে প্রশ্ন করা, আর যে অনিশ্চয়তা রইল তা নিয়ে রিলিজ করা যায় কি না ঠিক করা।
প্রমাণের খরচ ঝুঁকি বুঝে করি
সব ভাবে যাচাই সম্ভব নয়। ডেটা, role, browser, viewport, network আর প্রোডাক্টের ইতিহাসের সব মিশ্রণ দেখতেই ফিচার বানানোর চেয়ে বেশি সময় যাবে। তাই সরাসরি প্রমাণ থেকে শুরু করে বদলের প্রভাব যতটা ছড়ায়, সেই অনুযায়ী যাচাই বাড়ানোর সিঁড়ি দরকার।
তাই কিছু কাজ কোড তৈরি হওয়ার পরেও বেশি সময় নেবে। আমার কাছে সেটা ব্যবস্থার ভালো দিক। দ্রুত ইমপ্লিমেন্টেশনের পরে লুকিয়ে থাকা regression মানে দ্রুত ডেলিভারি নয়। কাজটা পরে, আরও খারাপ সময়ে ফেরত আসা।
আমার কাছে শেষের সংজ্ঞা সোজা: চাহিদা বলা আছে, ইমপ্লিমেন্টেশন আছে, দরকারি দাবির পক্ষে প্রমাণ আছে, আর বাকি সীমাগুলো স্পষ্ট। এজেন্ট সেই প্রমাণ তৈরিতে সাহায্য করতে না পারলে কাজটা এখনও প্রস্তাবই।