প্রতিটি নতুন প্রজেক্ট একই প্রলোভন দেয়: এডিটর খুলুন, একটি ফ্রেমওয়ার্ক বেছে নিন এবং টাইপ করা শুরু করুন। MaxOS-এর ক্ষেত্রে, নির্মাতা Max Paardekam সেই টান তীব্রভাবে অনুভব করেছিলেন। কয়েক সপ্তাহ আগে, প্রজেক্টটি কেবল তার নোটের বিক্ষিপ্ত ধারণা হিসেবে ছিল। তার তাৎক্ষণিক প্রবৃত্তি ছিল Cursor-এর ভেতরে ঘণ্টার পর ঘণ্টা TypeScript লেখা, যাতে মাসল মেমরি এবং অটো-কমপ্লিট গতি তৈরি করতে পারে। তিনি তা প্রতিরোধ করেছিলেন। অ্যাপ্লিকেশন কোডের পরিবর্তে, তিনি আরও বিরল এবং ভঙ্গুর কিছু তৈরি করেছিলেন: একটি সম্পূর্ণ আর্কিটেকচার।

সেই সিদ্ধান্তটি প্রথমে স্থবিরতার মতো মনে হয়েছিল। যখন সরঞ্জামগুলো প্রস্তুত থাকে এবং বয়েলারপ্লেট কয়েক সেকেন্ডের মধ্যে ইনস্টল হয়ে যায়, তখন বক্স এবং অ্যারো আঁকার জন্য বিরতি নেওয়াটা অদ্ভুত মনে হতে পারে। কিন্তু MaxOS কেবল একটি ওয়েব ভিউ-এর চারপাশে আরেকটি সাধারণ Electron র‍্যাপার হিসেবে গড়ে উঠছে না। লক্ষ্য হলো এমন কিছু তৈরি করা যা বছরের পর বছর ব্যবহার, রিফ্যাক্টরিং এবং সম্প্রসারণের মাধ্যমে টিকে থাকবে। এই ধরণের দীর্ঘায়ু সম্পন্ন সিস্টেমগুলোর জন্য দ্রুত শুরুর চেয়ে আরও গভীর কিছুর প্রয়োজন। প্রথম import স্টেটমেন্টের আগেই তাদের একটি সুসংগত চিন্তাভাবনার প্রয়োজন।

কেন IDE অপেক্ষা করতে পারে

আধুনিক ডেভেলপমেন্ট এনভায়রনমেন্টগুলো পরিকল্পনা এবং বাস্তবায়নের মধ্যকার সীমারেখা অস্পষ্ট করে দেয়। Cursor এবং অনুরূপ AI-সহায়তা সম্পন্ন এডিটরগুলো একটি কমেন্ট থেকে সম্পূর্ণ কম্পোনেন্ট তৈরি করা সম্ভব করে তোলে। ফিডব্যাক লুপটি তাৎক্ষণিক, এবং একটি UI materialize হতে দেখা ডোপামিন হিতের কাছে হার মানানো কঠিন। Paardekam ঠিক সেই ধারণা নিয়েই শুরু করেছিলেন: তার প্রাথমিক শক্তির বেশিরভাগই সরাসরি TypeScript ফাইলগুলোতে ব্যয় হবে। তবুও তিনি ধীরে ধীরে সেই দিনগুলোকে বিশুদ্ধ ডিজাইন কাজের দিকে পরিচালিত করেছিলেন।

যেকোনো একক নির্মাতার (solo builder) জন্য এটি একটি কঠিন মোড়। যখন আপনি নিজেই আপনার পুরো ইঞ্জিনিয়ারিং টিম, তখন ডায়াগ্রাম টুল বা টেক্সট ডকুমেন্টে কাটানো প্রতিটি ঘণ্টা শিপিং থেকে চুরি করা ঘণ্টার মতো মনে হয়। কিন্তু প্রাথমিক কোড প্রায়শই অগ্রগতির ছদ্মবেশে একটি ঝুঁকি হয়ে দাঁড়ায়। একটি চলমান প্রোটোটাইপের নতুনত্ব দ্রুত হারিয়ে যায় যখন প্রতিটি নতুন ফিচারের জন্য প্রথম দিনেই তৈরি করা অনুমানগুলোর (assumptions) আশেপাশে হ্যাকিং করতে হয়। নিজেকে এডিটর থেকে দূরে সরিয়ে রেখে, Paardekam সেই একটি সম্পদ অর্জন করেছিলেন যা সময়ের সাথে সাথে বৃদ্ধি পায়: স্বচ্ছতা।

ফিচারের পরিবর্তে সিস্টেম হিসেবে চিন্তা করা

এই সপ্তাহগুলোতে সবচেয়ে উল্লেখযোগ্য পরিবর্তনটি প্রযুক্তিগত ছিল না। এটি ছিল জ্ঞানীয় (cognitive)। সফটওয়্যার আর্কিটেকচারকে যখন গুরুত্ব সহকারে নেওয়া হয়, তখন এটি আপনার করা প্রশ্নগুলোকে নতুনভাবে সাজায়। Paardekam ফিচার-কেন্দ্রিক মানসিকতা দিয়ে প্রজেক্টটিকে দেখা বন্ধ করেছিলেন। তিনি আর জিজ্ঞাসা করছিলেন না কীভাবে একটি নির্দিষ্ট সক্ষমতা যুক্ত করা যায়। পরিবর্তে, তিনি একটি কঠিন প্রশ্নের মুখোমুখি হলেন: কোন অন্তর্নিহিত কাঠামো প্রতিটি ভবিষ্যৎ সক্ষমতা যোগ করা সহজ করে তুলবে?

এই পার্থক্যটি গুরুত্বপূর্ণ। ফিচার-কেন্দ্রিক মানসিকতা সফটওয়্যারকে একটি to-do list-এর মতো বিবেচনা করে। আপনি প্রথমে সার্চ, তারপর নোটিফিকেশন, তারপর একটি এক্সপোর্ট বাটন ইমপ্লিমেন্ট করেন। সিস্টেম-কেন্দ্রিক মানসিকতা জিজ্ঞাসা করে কীভাবে সার্চ, নোটিফিকেশন এবং এক্সপোর্ট একই ডেটা মডেল, একই ইভেন্ট বাস এবং একই পারমিশন লেয়ার ব্যবহার করতে পারে। এর মানে হলো অ্যাপ্লিকেশনের বাক্যগুলো লেখার আগে তার ব্যাকরণ ডিজাইন করা। প্রাথমিক খরচ বেশি। তবে পুরস্কার হলো, ভবিষ্যৎ কাজগুলো আর অ্যাসেম্বলি বা জোড়াতালি দেওয়ার মতো মনে হবে না, বরং কম্পোজিশন বা সৃজনশীল গঠনের মতো মনে হবে।

এটি MaxOS-এর মতো প্রজেক্টের জন্য বিশেষভাবে গুরুত্বপূর্ণ, যার লক্ষ্য হলো এমন সব ফাংশনগুলোকে একত্রিত করা যা সাধারণত দশটি ভিন্ন ভিন্ন অ্যাপ্লিকেশনের মধ্যে থাকে। সিস্টেমিক চিন্তাভাবনা ছাড়া নিবিড় ইন্টিগ্রেশন ভঙ্গুর ব্রিজ এবং অসংলগ্ন স্টেটের (inconsistent state) দুঃস্বপ্নে পরিণত হয়। সিস্টেমিক চিন্তাভাবনা থাকলে, ওয়ার্কস্পেসটি জোড়াতালি দেওয়া টুলের সমষ্টির পরিবর্তে একটি একক সত্তার মতো আচরণ করে।

অপারেটিং সিস্টেম নয়, বরং ওয়ার্কস্পেস

Paardekam তার উচ্চাকাঙ্ক্ষার সীমানা সম্পর্কে স্পষ্ট ছিলেন। MaxOS Windows বা macOS-কে প্রতিস্থাপন করবে না। এটি ড্রাইভার, মেমরি অ্যালোকেশন বা হার্ডওয়্যার অ্যাবস্ট্রাকশন লেয়ার পরিচালনা করার আকাঙ্ক্ষা করে না। এর লক্ষ্য হলো আরও ঘনিষ্ঠ কিছু: ওয়ার্কস্পেস।

বেশিরভাগ নলেজ ওয়ার্কার একটি খণ্ডিত পরিবেশে কাজ করেন। আপনি ইমেল ক্লায়েন্ট থেকে ক্যালেন্ডারে, নোটস অ্যাপ থেকে টার্মিনালে, ডিজাইন টুল থেকে মেসেজিং প্ল্যাটফর্মে লাফিয়ে যান। প্রতিটি পরিবর্তনের সাথে বাধা (friction) তৈরি হয়। প্রেক্ষাপট (context) হারিয়ে যায়। মনোযোগ খণ্ডিত হয়। অপারেটিং সিস্টেম মঞ্চ প্রদান করে, কিন্তু এটি নাটক পরিচালনা করে না।

MaxOS সেই অভিজ্ঞতাকে একটি একক পরিবেশে ঐক্যবদ্ধ করতে চায় যা আপনার কাজের ধারা বুঝতে পারে এবং আপনাকে দ্রুত কাজ করতে সক্রিয়ভাবে সাহায্য করে। এটি একটি প্রথাগত OS তৈরির চেয়ে ভিন্ন একটি ইঞ্জিনিয়ারিং চ্যালেঞ্জ। এর জন্য ওয়ার্কফ্লোর প্রতি গভীর সহানুভূতি, স্কোপের কঠোর সম্পাদনা এবং এমন ইন্টারফেস প্রয়োজন যা ব্যবহারকারীকে টুলের সাথে খাপ খাইয়ে নিতে বাধ্য না করে বরং ব্যবহারকারীর উদ্দেশ্যের সাথে খাপ খাইয়ে নেয়। একটি ওয়ার্কস্পেস পরিবর্তন করার অর্থ হলো অভ্যাস পরিবর্তন করা, আর অভ্যাস তখনই পরিবর্তিত হয় যখন বিকল্পটি শেখার চাপের পরিবর্তে একটি স্বস্তি হিসেবে অনুভূত হয়।

শান্ত সপ্তাহগুলোতে যা নির্মিত হয়েছে

Paardekam-এর আর্কিটেকচার পর্যায় দুটি সুনির্দিষ্ট ফলাফল প্রদান করেছে। প্রথমত, একটি স্পষ্ট ভিশন এবং মিশন সংজ্ঞায়িত করা। এটি কোনো মার্কেটিংয়ের ফাঁকা কথা নয়। একজন একক টেকনিক্যাল ফাউন্ডারের জন্য, এটি একটি চূড়ান্ত 'স্কেপ গার্ড' (scope guard) হিসেবে কাজ করে। যখন আপনি একটি চ্যাট সাইডবার বা একটি প্লাগইন মার্কেটপ্লেস যোগ করার সিদ্ধান্ত নেওয়ার মুখোমুখি হন, তখন মিশন স্টেটমেন্টটি হয় এটিকে স্বাগত জানায় অথবা বাতিল করে দেয়। দ্বিতীয়ত, তিনি একটি পূর্ণাঙ্গ প্রজেক্ট ব্লুপ্রিন্ট সম্পন্ন করেছেন।

পুরো পরিকল্পনাটি শুরু থেকে শেষ পর্যন্ত সাজানো দেখে প্রজেক্টের মানসিকতা বদলে গেছে। নোটবুকে থাকা আইডিয়াগুলো কাল্পনিক মনে হয়। কিন্তু একটি ব্লুপ্রিন্ট অনিবার্য মনে হয়। এটি ত্রুটি বা গ্যাপগুলোকে এমন সময়ে সামনে নিয়ে আসে যখন সেগুলো সংশোধন করা সাশ্রয়ী। এটি প্রকাশ করে দেয় কোথায় সবচেয়ে কঠিন ঝুঁকিগুলো লুকিয়ে আছে। এই পর্যায়ে, কোডের লাইনের চেয়ে একটি সুনির্দিষ্ট ডকুমেন্ট সত্যিই বেশি গুরুত্বপূর্ণ। কোড রিফ্যাক্টর (refactor) করা সম্ভব; কিন্তু একটি অস্পষ্ট ধারণা টেকনিক্যাল ডেট (technical debt) হিসেবে জমে যায়, যা গভীর রাতে ডিবাগিং করেও দূর করা সম্ভব নয়।

কাগজ থেকে মনোরিপো (Monorepo)

আর্কিটেকচার শেষ হওয়ার সাথে সাথে পরবর্তী পর্যায় শুরু হয়েছে। Paardekam এখন ডকুমেন্ট থেকে কোডের দিকে এগোচ্ছে, যার শুরু হচ্ছে মনোরিপো (monorepo) ইনিশিয়ালাইজেশনের মাধ্যমে। এই পরিবর্তনের সাথে নিজস্ব উদ্বেগও জড়িয়ে আছে। একটি ব্লুপ্রিন্ট হলো একটি প্রতিশ্রুতি। একটি কোডবেস হলো তার প্রমাণ। তিনি স্বীকার করেছেন যে, ইমপ্লিমেন্টেশনের সময় ডিজাইনটি টিকে থাকবে কি না, তা নিয়ে তিনি কিছুটা নার্ভাস। এই সততা সেই অজানা বিষয়গুলোর প্রতি একটি সুস্থ শ্রদ্ধাবোধ প্রকাশ করে, যা কেবল তখনই সামনে আসে যখন থিওরি বা তত্ত্বের সাথে লাইব্রেরি ভার্সন, এজ কেস (edge cases) এবং ক্রস-প্ল্যাটফর্ম আচরণের বাস্তবতার দেখা মেলে।

মনোরিপো ইনিশিয়ালাইজ করা কেবল একটি আনুষ্ঠানিক git init-এর চেয়ে বেশি কিছু। এটি সেই ভৌত কাঠামো তৈরি করে যা লজিক্যাল আর্কিটেকচারকে প্রতিফলিত করবে। প্যাকেজগুলো কোথায় থাকবে, তারা একে অপরের ওপর কীভাবে নির্ভর করবে এবং লেয়ারগুলোর মধ্যে সীমানা কোথায় হবে—তা কয়েক সপ্তাহের পরিকল্পনার প্রতিফলন ঘটাবে। যদি এটি সঠিকভাবে করা হয়, তবে প্রথম ফোল্ডার স্ট্রাকচার এবং বিল্ড পাইপলাইন ভবিষ্যতের অবদানকারীদের পথ দেখাবে। আর যদি এটি ভুলভাবে করা হয়, তবে এটি বছরের পর বছর ধরে প্রজেক্টে কাজ করা প্রতিটি ডেভেলপারকে নীরবে শাস্তি দেবে।

আসল শিক্ষা

Paardekam-এর অভিজ্ঞতা আধুনিক সফটওয়্যার সংস্কৃতির সেই 'ভেলোসিটি' বা দ্রুততা প্রদর্শনের প্রবণতার বিপরীতে যায়। দ্রুত শিপ (ship) করা, প্রবৃদ্ধি দেখানো এবং আলোচনার পরিবর্তে কোড দিয়ে কাজ চালিয়ে যাওয়ার জন্য প্রচণ্ড চাপ থাকে। কিন্তু কিছু প্রজেক্ট, বিশেষ করে যেগুলো দীর্ঘস্থায়ী হওয়ার কথা, সেগুলো ধৈর্যের প্রতিদান দেয়। ভেরিয়েবল ডিক্লেয়ার করার আগেই আপনার ভিশন সংজ্ঞায়িত করা, ব্লুপ্রিন্ট তৈরি করা এবং সিস্টেম ডিজাইন করার শৃঙ্খলা হলো একটি পুরনো উপদেশ যা আজও সমানভাবে সত্য।

আপনি যদি এখন কোনো আইডিয়া নিয়ে বসে থাকেন এবং এডিটর খোলার জন্য উন্মুখ হয়ে থাকেন, তবে ভেবে দেখুন কয়েক দিনের সুপরিকল্পিত ডিজাইন আপনাকে মাসের পর মাস অগোছালো রিওয়ার্ক (rework) থেকে বাঁচাতে পারে কি না। একটি অ্যাপ চলার যে ডোপামিন দেয় তা সময়ের সাথে ফিকে হয়ে যায়। কিন্তু একটি ভালো আর্কিটেকচারের স্বচ্ছতা ক্রমাগত বৃদ্ধি পায়। আপনি ঠিক কী তৈরি করছেন এবং কেন তৈরি করছেন তা নিশ্চিতভাবে জানার মাধ্যমে শুরু করুন। টাইপিংয়ের কাজ পরে করা যাবে।