আমাদের সফটওয়্যার ডেভেলপারদের অনেকেই আফসোস করেন যে,
'সব কাজ মুখে মুখে হয়, কোনো কিছুর কোনো ডকুমেন্টেশন নাই। একেকবার একেক রিকোয়ারমেন্ট আসে, একেক সময় একেক ডিসিশন চেঞ্জ হয়। কাজ করে শান্তি নাই।'

এই রকম সিচুয়েশনে কাজ করা আসলেই বেশ দুরূহ। সবচাইতে বড় সমস্যা হয় আপনি যদি এই রকম কোনো টীমে বা কোম্পানিতে 'নতুন ডেভেলপার' হিসেবে জয়েন করেন। কোনো ডকুমেন্টেশন নাই, কিন্তু আপনাকে নিজের মত করে সব খুঁজে নিয়ে কাজ করতে হবে। অনেক সময় ব্যাপারটা এমন দাঁড়ায় যে এটা করতে পারা দিয়েই প্রমাণ হবে আপনি এই টীমে কাজ করার জন্য উপযুক্ত কিনা। এই রকম পরিস্থিতির জন্যই নীচের meme টা জনপ্রিয়তা পেয়েছে। 😅

যাই হোক, একটা সফটওয়্যার ডেভেলপমেন্ট টীমে কিছু টেকনিক্যাল ডকুমেন্টেশন মেইণ্টেইন করা টীমের প্রোডাক্টিভিটি এবং কোলাবোরেশনের জন্য বেশ জরুরী। এই পরামর্শটা দিলেই অনেকে জিজ্ঞেস করেন কি কি টেকনিক্যাল ডকুমেন্টেশন রাখা উচিত? তাঁদের জন্যই এই লেখা।

Onboarding and Project setup guide:

আমি একটা কোম্পানিতে কিছুদিন কাজ করেছিলাম যেখানে জয়েন করার পরে আমাকে গিটহাবের কোডবেইজে এক্সেস দিয়ে বলা হয় সেটআপ করে নিতে এবং কোড বুঝে নিতে। আমার মাথা খারাপ হয়ে গেছিল এই কাজ করতে গিয়ে। কারণ তাঁদের কোনো প্রজেক্ট সেটআপ গাইড ছিল না। কোডবেইজ ছিল খুবই অগোছালো এবং তাঁরা কি আর্কিটেকচার বা টেক স্ট্যাক ফলো করেছে সেগুলোরও কোনো ডকুমেন্টেশন ছিল না। আমি একে ওকে জিজ্ঞেস করে করে পুরো কাজ করতে করতেই সেটার ডকুমেন্টেশন করে ফেলি এবং টীমে সেটাই ছিল আমার ফার্স্ট কন্ট্রিবিউশন। এটার জন্য আমাকে এপ্রেশিয়েটও করা হয়।
এর আগে আরেক কোম্পানিতে আমি ছিলাম যেখানে আমি প্রজেক্টের শুরু থেকে কাজ করেছিলাম এবং পুরো প্রজেক্ট সেটআপ গাইড এবং অনবোর্ডিং ইন্সট্রাকশন আমি রেডি করে রেখেছিলাম। এছাড়াও কোম্পানির নিয়ম ছিল একজন Onboarding buddy এসাইন করে দেয়া প্রথম সপ্তাহের জন্য, যে হেল্প করবে প্রজেক্ট রিলেটেড যে কোনো সমস্যায়। সেখানে নতুন যারাই জয়েন করতো তাঁরা খুব স্মুথলি এবং খুব অল্প সময়ে প্রজেক্টে কোড করা শুরু করতে পারতো।
দুইটা সিচুয়েশনের পার্থক্য আপনারা নিজেরাই বুঝতে পারছেন আশা করি। এ কারণে আপনার টীমে যদি প্রজেক্ট সেটআপ এবং অনবোর্ডিং এর কোনো ডকুমেন্ট না থাকে আজই এটা করে ফেলুন। এটা করতে যে খুব আহামরি সময় লাগবে এমন না। কিন্তু এটা নতুন ডেভেলপারদের সময় যেমন বাঁচাবে তেমনি নিজেরাও কখনো নতুন ডিভাইসে প্রজেক্ট সেটআপ করে কাজ শুরু করতে হেল্প করবে। নাহলে শুরু থেকেই নতুন ডেভেলপাররা ফ্রাস্টেশন নিয়ে টীমে জার্নি শুরু করে যেটা মোটেও সুখকর না।

Design diagrams:

এর মধ্যে আর্কিটেকচার ডায়াগ্রাম, সিস্টেম ডিজাইন ডায়গ্রাম, ER ডায়াগ্রামসহ অনেককিছুই অন্তর্ভূক্ত। তবে এর সবকিছুই থাকতে হবে এমন না। তবে এগুলো থাকলে যে কারো পুরো সিস্টেম সম্পর্কে আইডিয়া পাওয়াটা সহজ হবে। এটাও নতুন কারো টীমে জয়েন করে কাজ শুরু করতে অনেক হেল্প করে।

ADR (Architectural Decision Records):

আমরা অনেক সময় প্রোডাক্টের বিভিন্ন রকম আর্কিটেকচারাল ডিসিশন নিয়ে থাকি। যেমন হয়তো আমরা ডিসিশন নিলাম এখন থেকে আমাদের সব API অবশ্যই OpenAPI Spec ফলো করতে হবে। এখন এই ব্যাপারটা টীমের শুধু লিড আর সিনিয়র দুই একজন জানলেই কি হবে? হবে না। বরং টীমের সবার এটা জানতে হবে, এমনকি পরে নতুন কেউ জয়েন করলে তাকেও। এ কারণে এই ধরনের মেজর যেই আর্কিটেকচারাল ডিসিশন সেগুলো ডকুমেণ্টেড থাকা উচিত। ADR এ সাধারণত শুধু ডিসিশন না, বরং কবে ডিসিশন হয়েছে, কোন কন্টেক্সটে এই সিদ্ধান্ত নেয়া হয়েছে সেগুলোও থাকে।

Incident reports:

সিস্টেম থাকলে সেটা গ্যাড়াবেই। মানে সেখানে বড়সড় বাগ, ভাল্লুক, ইস্যু হবেই। প্রোডাকশনে এরকম মেজর ইস্যু হলে সাধারণত সেটার জন্য Incident reports লিখে রাখা উচিত। কেন ইস্যুটা হয়েছিল, সেটার ইমপ্যাক্ট সিস্টেমে কোথায় কোথায় পড়েছিল, ইউজাররা কতটুকু ইম্প্যাক্টেড হয়েছিল, রিজলভ করার জন্য কি করা হয়েছে, সামনে যেন আর না হয় তাঁর জন্য কি স্টেপ নেয়া হয়েছে- এগুলো এখানে ইনক্লুড থাকা উচিত।

উপরের এগুলো ছাড়াও প্রজেক্টের রিকোয়ারমেন্ট, API ডকুমেন্টেশন, Knowledge base টাইপের ডকুমেন্টেশনও মেইন্টেইন করা যায় যতটুকু প্রয়োজন।

মনে হতে পারে যে এত এত ডকুমেন্টেশন মেইন্টেইন করার টাইম কই?
আসলে দেখবেন যে এগুলো মেইন্টেইন করতে খুব বেশী সময় লাগে না। বরং এগুলো লং টার্মে পুরো টীমের যেই পরিমাণ সময় বাঁচায় এবং Guess work এভয়েড করে প্রপারলি ডিসিশন নিতে হেল্প করে, সেটার মূল্য অনেক বেশী।