লেখা
প্রোডাক্ট জটিল হলেও কাজে থাকে এমন Angular component
ব্যবহারকারী আর দল যে দায়িত্বগুলো চেনে, component-এর সীমানাও সেগুলোর সঙ্গে মিললে বেশি দিন কাজে লাগে।
প্রথম দিনে যে component দেখে reusable মনে হয়, ছয় মাসে সবাই সেটা এড়াতে চাইতে পারে। সাধারণ কারণ, দেখতে আবার ব্যবহার করা যেত, ধারণার দিক থেকে নয়।
প্রোডাক্টের সব দিক সমানভাবে বাড়ে না। এক দল permission যোগ করে। আর এক দল bulk action। তৃতীয় দলের review state চাই। কারও ঘন টেবিলের জন্য ছোট variant দরকার। প্রথম component শুধু সাজানো বাক্স হলে প্রতিটা নতুন চাহিদায় আচরণ কোথায় থাকবে তা নিয়ে তর্ক লাগে।
প্রোডাক্টের কাজের সঙ্গে মেলা সীমানা পছন্দ করি: একটা item বাছা, record তুলনা করা, recommendation রিভিউ, ঝুঁকির action নিশ্চিত করা, state-এর সারাংশ দেখানো। প্রোডাক্ট বদলালেও ওই দায়িত্ব component-টার থাকার কারণ দেয়।
ডিজাইন সিস্টেম নিয়েও এভাবেই ভাবি। প্রতিটা screen-কে একই generic চেহারায় ঠেলে দেওয়া তার কাজ নয়। মজবুত primitive আর প্রোডাক্ট বোঝে এমন pattern দিক, যাতে দল দ্রুত চলে আর আচরণে মিল থাকে।
Angular-এ এমন template পছন্দ করি যা পড়া সহজ, কারণ component আগেই state-এর নাম দেওয়ার কাজটা করেছে। template boolean-এর ধাঁধা হবে কেন? ইন্টারফেসের মতো পড়া যাক: এটা review-এর অপেক্ষায়, এই action বন্ধ, এই item বাছা, filter-এর ফলে এই empty state।
শুরুতে কখনও একটু বেশি কাঠামো লিখতে হয়। প্রোডাক্টের সত্যি জটিলতার সঙ্গে মিললে তা নিয়ে আপত্তি নেই। শুধু কোনও দিন component আবার লাগতে পারে বলে abstraction বানানোয় আপত্তি আছে।
জটিলতা সামলানো মানে ভবিষ্যতের সব চাহিদা আগে বলা নয়। এমন সীমানা বাছা, যাতে পরের চাহিদায় কম চমক লাগে।