জাভা কেন মাল্টিপল ইনহেরিটেন্স (Multiple Inheritance) সাপোর্ট করে না?

এর উত্তর এভাবে দেওয়া যায়। জাভা প্রোগ্রামিং ভাষার ডিজাইনাররা কয়েকটি গুরুত্বপূর্ণ বিষয় মাথায় রেখে এই ভাষাকে ডিজাইন করে। এগুলো হলো, 

1. এটি হতে হবে খুবই সরল, অবজেক্ট ওরিয়েন্টেড এবং পরিচিত, অর্থাৎ যারা তখন সি বা সি++ জানতো তারা যাতে করে সহজেই বুঝতে পারে। 
2. এটিকে অবশ্যই অনেক শক্তসমর্থ এবং নিরাপদ (robust and secure) হতে হবে। 
3. এটি যেকোনো অপারেটিং সিস্টেমে চলবে। 
4. এর পারফরমেন্স অনেক ভালো হতে হবে। 
5. এটি ইন্টারপ্রেটেড (Interpreted), থ্রেডেড (Threaded) এবং ডায়নামিক (Dynamic) হতে হবে। (এখানে বলে রাখি, জাভা যদিও কম্পাইল্ড ভাষা, কিন্তু জাভা ভার্চুয়াল মেশিন মূলত বাইটকোড ইন্টারপ্রেট করে আর জেভিএম একটা ডায়নামিক মেশিন)। 

এই কয়কেটা উদ্দেশ্যের সঙ্গে আরেকটি গুরুত্বপূর্ণ জিনিস হলো, এর ফিচার খুব অল্প হতে হবে যাতে একজন প্রোগ্রামার খুব সহজেই মনে রাখতে পারে। যেসব ফিচার খুব ঝামেলাযুক্ত এবং আসলে তেমন প্রয়োজন নেই খুব একটা সেগুলোকে তারা বাদ দিয়ে ডিজাইন করেছে। যেমন, অপারেটর ওভারলোডিং (Operator Overloading), মাল্টিপল ইনহেরিটেন্স (Multiple Inheritence)। এগুলো সুবিধার চেয়ে প্রোগ্রামারদের অসুবিধার কারণ বেশি তৈরি করে।

মাল্টিপল ইনহেরিটেন্সের ক্ষেত্রে একটি বড় সমস্যা হলো ডায়মন্ড সমস্যা (Diamond Problem)। একটি উদাহরণ দেওয়া যাক,

মনে করা যাক, একটি ক্লাস A, একে B ও C এক্সটেন্ড করে। আবার আরেকটি ক্লাস D যা কিনা B ও C কে এক্সটেন্ড করে। এখন যদি A এর কোনো একটি মেথডকে B ও C দুটিই ওভাররাইড করে এবং D থেকে সেই মেথডটি কল করা হয়, তাহলে সেটি কোন ক্লাসের মেথডকে কল করবে? B না C? সমস্যাটি নিশ্চই বোঝা যাচ্ছে।

জাভা ডিজাইনাররা এরকম সমস্যার মধ্য দিয়ে যেতে চায়নি। তাই জাভাতে মাল্টিপল ইনহেরিটেন্স নেই।

জাভাতে প্রাইভেট ফিল্ড(private field) প্রয়োজন কেনো? এগুলো অ্যাকসেস করার জন্য গেটার সেটার কেনো ব্যবহার করা হয় ?

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

এছাড়ারও আরও বেশ কিছু কারণ রয়েছে, তবে এগুলোকে সঠিক ভাবে ব্যবহার করায় উত্তম, অর্থাৎ যেখানে যেভাবে লাগে। এগুলো হলো -

• ১. আপনি একটি ক্লাসকে রিডওনলি(read only) করতে পারে। অর্থাৎ ক্লাসের ভ্যালুগুলো শুধু পড়া যাবে। এক্ষেত্রে সেই ক্লাসে শুধুমাত্রে গেটার(getter) থাকবে।
• ২. আপনি একটি ক্লাসকে কনফিগারেবল (configurable) করতে চাইতে পারেন। অর্থাৎ ভ্যালু সেট করবে। সেক্ষেত্রে আপনি শুধু সেটার রাখতে পারেন।
• ৩. একটি গেটার যে শুধুমাত্র একটি ভেরিয়েবল থাকে ডাটা পড়ে রিটার্ন করবে এমনটি নাও হতে পারে। অনেকগুলো ভেরিয়েবল থেকে ডেটা কম্পিউট করে রিটার্ন করতে পারে।
• ৪. মনে করুন আপনি ভ্যালু সেট করতে চান যা একটি নির্দিষ্ট রেঞ্জের হবে। এই রেঞ্জের বাইরে কোন ভ্যালু দিলে তা সেটার থেকে একসেপশন থ্রুক করতে পারেন।

একটি উদাহরণ দেওয়া যাক -

    public class Measurement{

    /**
     * The distance in centimeters.
     */
    private double distance;

    /**
     * Gets the distance in inches.
     * @return A distance value.
     */
    public double getDistance()
    {
        return distance / 2.54;
    }

    /**
     * Sets the distance.
     * @param distance The distance, in inches.
     */
    public void setDistance(double distance)
    {
        this.distance = distance * 2.54;
    }
}

এছাড়াও এটি একটি good practice (উত্তম উপায়)। উত্তম উপায় অভ্যাস করায় শ্রেয়।

Java তে String কে immutable বলা হয় কেন?

জাভাতে স্ট্রিং ক্লাস immutable, এর মানে হচ্ছে, একবার কোন স্ট্রিং অবজেক্ট তৈরি করলে তাকে আর পরিবর্তন করা যাবে না। আমরা অনেক ক্লাস লিখি, তারপর এর মাঝে বিভিন্ন ভ্যারিয়েবল রাখি, অবজেক্ট তৈরি করার পর সেই অবজেক্টর এর ভেতরের ভ্যারিয়েবল গুলো বিভিন্ন সময় পরিবতর্তন করতে পারি। কিন্তু স্ট্রিং এর ক্ষেত্রে এটি সম্ভব নয়। অর্থাৎ আমরা যদি কোন একটি ভ্যালু দিয়ে একবার একটি স্ট্রিং অবজেক্ট তৈরি করি তাহলে সেটি আর পরিবর্তন করা যাবে না।

কিন্তু আমরা অনেকসময়ই স্ট্রিং কনকেট করি, সেক্ষেত্রে যা হয়, মনে করি-

String str = "Hello ";
str = str + "world";

এখানে যদিও মনে হচ্ছে আমরা স্ট্রিং এর ভ্যালু পরিবর্তন করে ফেলেছি। কিন্তু আসলে যা হচ্ছে তা হলো, আমরা প্রথমে একটি অবজেক্ট তৈরি করেছি, তারপর সেই অবেজক্টএর ভ্যালু এবং নতুন একটি ভ্যালু নিয়ে নতুন একটি অবজেক্ট তৈরি করেছি, এবং যা str এখন নতুন সেই অবজেক্টকে রেফার করছে। আগের অবজেক্টটিকে গার্বেজ কালেক্টর নিয়ে চলে যাবে।

এখন প্রশ্ন হচ্ছে, কেন এই immutability দরকার হয়।

স্ট্রিং পুল (Stirng Pool) সম্পর্কে হয়তো অনেকেই জানি। এটি একটি জাভা হিপ এর একটি স্পেশাল এরিয়া । আমাদের যদি নতুন একটি স্ট্রিং তৈরি করতে হয়, সেই স্ট্রিং যদি আগে থেকেই স্ট্রিং পুল এ থেকে থাকে, তাহলে নতুন করে আর তৈরি না করে আগের অবজেক্টটির রেফারেন্স দেওয়া হয়। এতে করে আমাদের মেমরি ফ্রুটপ্রিন্ট অনেক কমে যাচ্ছে।

String string1 = "abcd";
String string2 = "abcd";

আমরা যদি এই দুটি লাইন লিখি, তাহলে আসলে জাভা হিপ এ একটি স্ট্রিং অবজেক্ট-ই থাকবে, দুটি তৈরি হবে না। যদি স্ট্রিং immutable না হয়, তাহলে একটি স্ট্রিং যদি পরিবর্তন করি, তাহলে আসলে অন্যান্য রেফারেন্স গুলোও পরিবর্তন হয়ে যাবে।

এছাড়াও, আমরা জানি যে স্ট্রিং এর hashcode খুব বেশি ব্যবহার করা হয়। যেমন HashMap। স্ট্রিং immutable হওয়ায় এটা গ্যারান্টিড যে, সবসময়hashcode এক-ই হবে, সুতরাং আমরা প্রতিবার hashcode ক্যালকুলেট না করে নির্ধিদ্বায় ক্যাশিং করতে পারি।

আমরা স্ট্রিং প্যারামিটার হিসেব অনেক বেশি ব্যবহার করে থাকি, যেমন, নেটওয়ার্ক কানেকশান, ফাইল অপেনিং ইত্যাদির ক্ষে্ত্রে। সুতরাং এটি immutable না হলে পরিবর্তন করে ফেলা সম্ভব যা কিনা একটি সিরিয়াস রকম সিকিউরিটি থ্রেড হতে পারে। কিন্তু যেহেতু স্ট্রিং immutable, সুতরাং সেই সম্ভবনা নেই।

তাছাড়া স্ট্রিং immutable হওয়ায় এটি ন্যাচারালি থ্রেড সেইফ, এবং স্বাধীনভাবে যে কেন থ্রেড একসেস করে পারে আমাদেরকে কষ্ট করে এর থ্রেড সেইফটি নিয়ে চিন্তা করতে হয় না।

কেনো জাভা শেখা উচিত ?

যে যে কারণে জাভা শেখা যেতে পারে তার কারণগুলো নিয়ে আলোচনা করা যাক, 

1. Pay matters. সাম্প্রতিক একটি প্রতিবেদন থেকে দেখা গেছে যে প্রোগ্রামিং ইন্ডাস্ট্রিতে জাভা প্রোগ্রামাররা অন্যান্য প্রোগ্রামারদের চেয়ে অনেক বেশি বেতন পেয়ে থাকে।¹
2. পৃথিবীতে প্রায় ১৫ বিলিয়ন ডিভাইসে জাভা চলে। এছাড়া জাভা দিয়ে স্মার্টফোন থেকে শুরু করে সার্ভার, এটিএম মেশিন (ATM Machine), পয়েন্ট অব সেল (POS) এর টার্মিনাল, ব্লু-রে প্লেয়ার, টেলিভিশন, সেট-টপ বক্স (STB), ইন্টারনেট অব থিং (Internet of thing) এর গেটওয়ে (Gateway), মেডিকেল ডিভাইস (Medical Device), আমাজনের কিন্ডল (Kindle), অটোমোবাইল এবং আরও অনেক কিছুতে প্রোগ্রাম করা যায়। 
3. জাভা সাধরাণত খুব গুরুত্বপূর্ণ এবং রিয়েল ওয়ার্ল্ড অ্যাপ্লিকেশন (Real World Application)² তৈরিতে ব্যবহার করা হয়। যেমন, এন্ড্রয়েড ডেভেলপমেন্টের ক্ষেত্রে জাভা ব্যবহার অপরিহার্য। বিশেষ বিশেষ শক্তিশালী ওয়েব সাইট যেমন, eBay.com, LinkedIn.com, Amazon.com, Facebook.com, ESPNcricinfo.com, Gmail.com, Netflix.com, Alibaba.com ইত্যাদিতে জাভা ব্যবহার করা হয়েছে। এছাড়াও বিভিন্ন এন্টারপ্রাইজ অ্যাপ্লিকেশন যেমন, অর্থনৈতিক সেবাসমূহ, স্বাস্থ্যসেবা, ম্যানুফ্যাকচারিং ইত্যাদির জন্য যেকোনো ইন্ডাস্ট্রিতে জাভার চাহিদা সর্বাগ্রে। 
4. কিছুদিন আগেই জাভার ২১ তম জন্মদিন চলে গেল।³ এ থেকে একটি বিষয় সহজেই অনুমেয় যে জাভা খুব তাড়াতাড়ি পালিয়ে যাওয়ার মতো টেকনোলজি নয়।⁴ আরও দীর্ঘকাল এর চাহিদা অভিন্ন থেকে যাবে। সুতরাং এতে সময় ব্যয় করলে তা নষ্ট হওয়ার সম্ভবনা নেই। 
5. এর সোর্সকোড খুব সহজ ও পাঠযোগ্য (readable)। অন্য যেকোনো প্রোগ্রামিং ভাষা জানে এমন একজন প্রোগ্রামার খুব সহজেই একটি জাভাতে লেখা কোড দেখে বুঝতে পারবে যে কোডে কী লেখা আছে বা কোনো বিশেষ কোড দিয়ে কী কাজ করা হচ্ছে। 
6. সি কিংবা সি++ এ কোড করার সময় আমাদের অনেক সময়ই লিংকিং (Linking)⁵, অপটিমাইজেশন (Optimization)⁶, মেমোরি অ্যালোকেশন (Memory Allocation)⁷, মেমোরি ডি-অ্যালোকেশন (Memory Deallocation)⁸, পয়েন্টার ডিরেফারেন্সিং (Pointer Dereferencing)⁹ ইত্যাদি নানা রকম জিনিস নিয়ে ভাবতে হয়। জাভার ক্ষেত্রে এগুলোর কথা ভাবতেই হয় না। খুব বেশি চিন্তাভাবনা না করেই নিশ্চিন্তভাবে জাভা কম্পাইলারের উপর সব কিছু ছেড়ে দেওয়া যায়। 
7. জাভাতে অসংখ্য এপিআই (API)¹⁰ আছে যেগুলো খুবই স্টেবল (Stable), খুব বেশি চিন্তাভাবনা না করেই এগুলো নিশ্চিন্তমনে ব্যবহার করে খুব সহজেই অনেক বড় বড় প্রোগ্রাম লিখে ফেলা যায়। 
8. এটি একটি ওপেন সোর্স প্রোগ্রামিং ভাষা। এর সোর্সকোড যে কেউ পড়তে পারে। 
9. জাভা ভার্চুয়াল মেশিন সম্ভবত সফটওয়্যার জগতে সবচেয়ে চমৎকার সৃষ্টি। এটি জাভার সঙ্গে আরও অনেকগুলো ল্যাঙ্গুয়েজ¹¹ যেমন, Groovy, Scala, Kotlin, Jython,Jruby, Clojure ইত্যাদি নিয়ে কাজ করা যায়। 
10. গত ১৫ বছরে অনেকগুলো চমৎকার ডেভেলপমেন্ট এনভায়রনমেন্ট (Integrated Development Environment – IDE) তৈরি হয়েছে যেগুলো খুবই স্মার্ট এবং ইন্টেলিজেন্ট। যেমন, Eclipse, IntelliJ IDEA, Netbeans ইত্যাদি। এগুলো ব্যবহার করে খুব আয়েশের সঙ্গেই কোড করা ও ডিবাগ করা যায়। 
11. এটি একটি অবজেক্ট ওরিয়েন্টেড, টাইপ সেইফ প্রোগ্রামিং ভাষা। 
12. এটি পোর্টেবল, যেকোনো প্ল্যাটফর্মে চলে (প্ল্যাটফর্ম ইনডিপেন্ডেন্ট)। একবার কোড লিখে সেটি যেকোনো মেশিনে (উইন্ডোজ, লিনাক্স, ম্যাক অপারেটিং সিস্টেমে) চালানো যায়। 
13. এর অনেক বড় কমিউনিটি সাপোর্ট রয়েছে। সারা পৃথিবীতে প্রায় ১০ মিলিয়ন জাভা প্রোগ্রামার ছড়িয়ে ছিটিয়ে আছে। 
14. এটির পারফরমেন্স নিয়ে বলা চলে কোনো সন্দেহ নেই। 
15. ইন্ডাস্ট্রি গ্রেডেড, বড় বড় এন্টারপ্রাইজ অ্যাপগুলো সাধারণত জাভা দিয়ে লেখা হয়। 
16. এটি পৃথিবীতে সবচেয়ে জনপ্রিয় প্রোগ্রামিং ভাষা।¹²
17. এছাড়াও জাভার একটি শক্তিশালী রোডম্যাপ রয়েছে। ওরাকল এতে প্রতিজ্ঞাবদ্ধ। 

---

পাদটীকা

1https://gooroo.io/GoorooTHINK/Article/16300/Programming-languages--salaries-and-demand-May-2015/18672 

2 Real world application – রিয়েল ওয়ার্ল্ড অ্যাপ্লিকেশন বলতে বোঝায় যেগুলো মানুষের জীবন-যাত্রার সঙ্গে অঙ্গাঅঙ্গিভাবে জড়িত, যেমন, হেল্থকেয়ার সিস্টেম, ব্যাংকিং সিস্টেম, স্টক এক্সচেঞ্জ ইত্যাদি। এগুলো ছাড়া আধুনিক মানুষের জীবনধারণ প্রায় কঠিন হয়ে যাবে। পোকেমন গেমকে রিয়েল ওয়ার্ল্ড অ্যাপ্লিকেশন বলা যাবে না, কারণ এটি না খেললে মানুষের জীবনযাত্রা ব্যহত হবে না। 

3 ২৩, মে ১৯৯৫-তে প্রথম রিলিজ হয়। now you do the math :) 

4 http://turnoff.us/geek/big-numbers/ 

5 সি কিংবা সি++ প্রোগ্রামিং করার সময় সাধারণত স্ট্যান্ডার্ড লাইব্রেরিগুলো দেওয়াই থাকে, কিন্তু আমরা যদি অন্য কোনো লাইব্রেরীর কোনো বিশেষ অংশ যা কিনা আগেই অন্য কেউ তৈরি করে রেখেছে, আমাদের প্রোগ্রামের সঙ্গে যুক্ত করতে চাই তাহলে যে প্রক্রিয়ার মধ্য দিয়ে যেতে হয় তাকে লিংকিং বলা হয়। 

6 একটি প্রোগ্রামকে আরও বেশি কার্যকর করার উদ্দেশ্যে বিশেষ কিছু উপায় ব্যবহার করে কোডকে পরিবর্তন করা। 

7 প্রোগ্রামারের ভ্যারিয়েবলগুলো স্টোর করতে মেমোরির দরকার হয়। মেমোরি অ্যালোকেশন হলো এমন একটি প্রক্রিয়া যাতে করে প্রোগ্রামকে ভার্চুয়াল বা ফিজিক্যাল মেমোরি স্পেস ব্যবহার করতে দেওয়া হয়। 

8 প্রোগ্রাম একটি মেমোরি ব্লক ফ্রি করে দেয় যাতে করে অন্য প্রোগ্রাম সেই মেমোরি ব্লক ব্যবহার করতে পারে। 

9 কোনো পয়েন্টার যে মেমোরি লোকেশনকে পয়েন্ট করে সেখান থেকে ডেটা পড়া। 

10 API (Application Programming Interface) - কতগুলো কোড যেগুলো অন্য কোনো সফটওয়্যারের কম্পোনেন্টের সঙ্গে কাজ করতে পারে এবং এগুলো ব্যবহার করে খুব সহজেই একটি প্রোগ্রাম লিখে ফেলা যায়। উদাহরণ হিসেবে বলা যেতে পারে, যেকোনো স্মার্টফোন স্যাটেলাইট থেকে জিপিএস কোঅর্ডিনেটস পড়তে পারে। এখন কোনো প্রোগ্রাম বা অ্যাপে জিপিএস কোঅর্ডিনেট দরকার হতে পারে। এই জিপিএস কোঅর্ডিনেট পড়ার জন্য APIবা কোড আগে থেকে লেখায় আছে যেগুলো সহজেই সেই অ্যাপ যুক্ত করা যায়, নতুন করে লেখার প্রয়োজন পরে না। 

11 https://en.wikipedia.org/wiki/List_of_JVM_languages 

12 http://www.tiobe.com/tiobe_index?page=index

প্যারামিটার (Parameter) ও আর্গুমেন্ট (Argument) এর পার্থক্য

প্যারামিটার ও আর্গুমেন্ট শব্দ দুটো প্রায়ই একে অপরের স্থলে (Interchangeably) ব্যবহার করা হয়। তবে ব্যবহারের ক্ষেত্র বা প্রসঙ্গ (Context) থেকে এদেরকে আলাদা করা যায়। সাধারণত মেথড ডেফিনেশন লেখার সময় যে ভ্যারিয়েবলগুলো ব্যবহার হয় সেগুলোকে প্যারামিটার বলে। আর যখন সেই মেথডটিকে ব্যবহার করার সময় যে ভ্যালু বা মান পাস (Pass) করা হয় তাকে আর্গুমেন্ট বলা হয়।

চিত্র: প্যারামিটার ও আর্গুমেন্ট

জাভা প্রোগ্রামিং ল্যাংগুয়েজ তৈরির পেছনের গল্প

১৯৯৫ সালের ২৩ মে। ঝলমলে চমৎকার একটি দিন¹। জন গেইজ (John Gage – ডিরেক্টর অব সান-মাইক্রোসিস্টেম) ও মার্ক অ্যান্ডারসেন (Marc Andreesen – নেটস্কেপের ভাইস প্রেসিডেন্ট ও সহপ্রতিষ্ঠাতা) ঘোষণা দেন যে, জাভা টেকনোলজি মোটেই কোনো উপকথা নয়, বরং এটিই বাস্তবতা এবং এটি নেটস্কেপ নেভিগেটর (Netscape Navigator) এর সঙ্গে সংযুক্ত হতে যাচ্ছে।

সে সময় জাভাতে কাজ করে এমন লোকের সংখ্যা ত্রিশেরও কম। তারা কখনোই চিন্তা করেনি তাদের এই টিম ভবিষ্যৎ পৃথিবীর প্রধানতম টেকনোলজি নির্ধারণ করতে যাচ্ছে। ২০০৪ সালের ৩ জানুয়ারি মার্স এক্সপ্লোরেশন রোভার (Mars Exploration Rover)² মঙ্গল গ্রহের মাটিতে পা রাখে যার কন্ট্রোল সিস্টেম থেকে শুরু করে পৃথিবীর অধিকাংশ কনজুমার ইলেকট্রনিক্স, যেমন– কেবল সেট-টপ বক্স (STB), ভিসিআর (VCR), টোস্টার (Toaster), পিডিএ (PDA), স্মার্টফোনসহ প্রায় ১৫ বিলিয়ন ডিভাইস³, ১০০% ব্লু-রে ডিস্ক প্লেয়ার জাভা রান করে।

চলুন একটু পেছনের ইতিহাস জেনে নেই।

তখন সি++ (C++) এর একচ্ছত্রাধিপত্য।

সান মাইক্রোসিস্টেমস (Sun Microsystems, Inc.) মূলত হার্ডওয়্যার কোম্পানি। ১৯৭২ থেকে ১৯৯১ সালের এই সময়টাতে কম্পিউটার হার্ডওয়্যারের এক বিশাল বিপ্লব হয়। দ্রুত এবং উচ্চ ক্ষমতাসম্পন্ন সব হার্ডওয়্যার অল্প দামে পাওয়া যাচ্ছে এবং সেই সঙ্গে জটিল সব সফটওয়্যারের চাহিদা দ্রুতই বেড়ে চলছে। ১৯৭২ সালে ডেনিস রিচি (Dennis Ritchie)⁴ সি প্রোগ্রামিং ভাষা তৈরি করেন। যদিও তখনো প্রোগ্রামারদের মধ্যে এটি সব থেকে জনপ্রিয়, তবে প্রোগ্রামারদের মধ্যে সি-এর স্ট্রাকচার্ড প্রোগ্রামিং কিছুটা ক্লান্তিকর মনে হতে শুরু করেছে। এর ফলশ্রুতিতে বিয়ার্ন স্ট্রাউসট্রাপ (Bjarne Stroustrup)⁵১৯৭৯ সালে ডেভেলপ করেন সি++ (C++) যা কিনা মূলত সি (C) এবং এর সঙ্গে বাড়তি কিছু। এটি অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং ধারণাকে পরিচিত করে তোলে। অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিংয়ের সুবিধা হচ্ছে একজন প্রোগ্রামার পুনর্ব্যবহারযোগ্য (reusable) কোড লিখতে পারে যেটা পরে অন্য কাজে পুনরায় ব্যবহার করা যায়।

১৯৯০ সাল।

সান মাইক্রাসিস্টেমসে সি++ এর আধিপত্যে সি-তে লেখা বিভিন্ন টুল এবং এপিআইগুলো প্রায় অচল হতে শুরু করেছে। প্যাট্রিক নটন (Patrick Naughton) যিনি সান মাইক্রোসিস্টেমের একজন ইঞ্জিনিয়ার, মোটামুটি হতাশ এবং এক ধরনের বিশ্রী পরিস্থিতির সম্মুখীন। ততদিনে স্টিভ জবস (Steve Jobs)⁶ অ্যাপল কম্পিউটার থেকে বিতাড়িত হয়ে নেক্সট কম্পিউটার ইনকরপোরেটেড (NeXT Computer Inc.) প্রতিষ্ঠা করে ফেলেছেন, যা পরবর্তীতে সফটওয়্যার ইন্ডাস্ট্রিতে বৈপ্লবিক পরিবর্তন আনতে যাচ্ছে এবং যার ফলশ্রুতিতে তৈরি হয়েছে আজকের ম্যাক অপারেটিং সিস্টেম (OS X)। তার এই নতুন প্রতিষ্ঠান নেক্সটস্টেপ (NeXTSTEP) নামে একটি অপারেটিং সিস্টেম তৈরি করে। এতে চমৎকার কিছু ব্যাপার ছিল। যার মধ্যে অবজেক্ট ওরিয়েন্টেড অ্যাপ্লিকেশন লেয়ারের ধারণাটি ছিল অসাধারণ। এতে অবজেক্ট ধরে ধরে কাস্টমাইজড সফটওয়্যার তৈরি করে ফেলা যায়। প্যাট্রিক নটন (Patrick Naughton) ইতিমধ্যে NeXT এর দিকে যাওয়ার জন্য মনস্থির করে ফেলেছেন। ঠিক তখনই একবার তাকে শেষ সুযোগ হিসেবে একটি অতি গোপন প্রজেক্টের (Stealth Project) অনুমোদন দেওয়া হয় যার কথা অন্য কেউ জানত না। কিছুদিন পরেই তার সঙ্গে যুক্ত হন জেমস গসলিং (James Gosling)⁷এবং মাইক শেরিডান (Mike Sheridan)। তখন এর নাম দেওয়া হয় গ্রিন প্রজেক্ট (Green Project)। সময়ের সঙ্গে সঙ্গে গ্রিন প্রজেক্টের দন্তোদ্গম হয়। তারা ধীরে ধীরে কম্পিউটার ছাড়াও আরও অন্যান্য ডিভাইস নিয়েও চিন্তাভাবনা শুরু করেন।

এর মধ্যে ১৩ জন কর্মীর এই গ্রিন প্রজেক্টের দল ক্যালিফোর্নিয়ার মেনলো পার্কের সেন্ড হিল রোডের একটি ছোট্ট অফিসে কাজ করতে থাকেন। এই দলকে পরবর্তীতে গ্রিন টিম নাম দেওয়া হয়। তাদের প্রধান উদ্দেশ্য সি++ (C++) এর একটি ভালো ভার্সন তৈরি করা যা হবে অনেক দ্রুতগামী এবং রেসপন্সিভ (responsive)। সেই সময়ে কম্পিউটার ছাড়াও কনজুমার ইলেকট্রনিক্স যেমন – পিডিএ, কেবল সেট-টপ বক্স ইত্যাদির চাহিদা বেশ বেড়ে গেছে। একদল ইঞ্জিনিয়ার এক সঙ্গে থাকলে যা হয়, তারা নানা রকম জিনিস নিয়ে চিন্তা করতে থাকে, নানা রকম আইডিয়া তৈরি হয়, তা থেকে প্রোটোটাইপ (Prototype) তৈরি করতে থাকে। এর মধ্যে জেমস গসলিং সি++ প্রোগ্রামিং ভাষায় বেশ কিছু বাড়তি জিনিস যুক্ত করতে থাকেন এবং কিছু কিছু জিনিস ফেলে দেন। তিনি এর নাম দেন সি++ ++ -- (C++ ++ --)। এখানে বাড়তি ++ মানে হচ্ছে নতুন জিনিস যোগ করা এবং - - মানে হচ্ছে কিছু জিনিস ফেলে দেওয়া।

জেমস গসলিংয়ের জানালা দিয়ে একটি ওক গাছ দেখা যায়। একদিন তিনি অফিস থেকে বের হয়ে ওই গাছটির নিচে দাঁড়ান এবং সঙ্গে সঙ্গে C++ ++ -- নাম পরিবর্তন করার সিন্ধান্ত নেন এবং নতুন নাম দেন ওক (Oak)।

একই সময় সানের ইঞ্জিনিয়াররা মিলে এম্বেডেড সিস্টেম (Embeded System) নিয়েও কাজ করতে থাকেন এবং এসময় তারা নানা রকম সমস্যার সম্মুখীন হন। এম্বেডেড সিস্টেমে মেমোরি কম থাকে, প্রসেসিং ক্ষমতাও কম থাকে। এই সিস্টেমে সি++ (যা কিনা কম্পিউটারের মতো বড় ফুটপ্রিন্টের হার্ডওয়্যারের জন্য ডিজাইন করা) চালাতে গিয়ে তারা অদ্ভুত অদ্ভুত সমস্যার সম্মুখীন হতে থাকেন। এইসব সমস্যার সমাধান করার জন্য গ্রিন টিম নানা রকম চিন্তাভাবনা করতে থাকে। এই সময়েই মানুষ পিডিএ, কেবল সেট-টপ বক্সগুলোর মরণদশা দেখতে শুরু করে। জেমস গসলিং যদিও ওক নিয়ে যথেষ্ট এগিয়েছেন কিন্তু এটি কোনোভাবেই এদেরকে সাহায্য করতে পারছিল না। সবার কাছে মনে হতে থাকে একমাত্র কোনো একটি অলৌকিক ঘটনাই পারে এই প্রজেক্ট সফল করতে। ঠিক তখনই সেই প্রতীক্ষিত প্রত্যাশা আলোর মুখ দেখা যায়। জেমস গসলিং আউট অব দ্য বক্স (out of the box)একটি যুগান্তকারী ধারণা নিয়ে আসেন। সেটি হলো ভার্চুয়াল মেশিন (Virtual Machine)। অর্থাৎ আমরা একটি কাল্পনিক মেশিনের জন্য কোড লিখব যা কম্পাইল হয়ে একটি অন্তর্বর্তীকালীন কোড (Intermediate Code) তৈরি করবে। জাভা ভার্চুয়াল মেশিন সেই অন্তর্বর্তীকালীন কোডকে রানটাইমে আসল ডিভাইসের জন্য প্রয়োজন অনুযায়ী মেশিন কোড তৈরি করবে।

ঠিক একই সময়েই ন্যাশনাল সেন্টার ফর সুপারকম্পিউটিং অ্যাপ্লিকেশনস (National Center for Supercomputing Applications – NCSA) একটি কমার্শিয়াল ওয়েব ব্রাউজার বের করে। তাদের টিম ইন্টারনেটের ভবিষ্যৎ নিয়ে ভাবতে শুরু করে। তারা একটি নতুন ধারণা নিয়ে আসে সেটি হলো, এক ধরনের ছোট ছোট প্রোগ্রাম যা ওয়েব ব্রাউজারের মধ্যে চলবে। তারা এর নাম দেয় অ্যাপলেট (Applet)। তারা অ্যাপলেটের জন্য কিছু মানদণ্ড (standard) ঠিক করে দেয়,

1. এটি হতে হবে খুব ছোট, খুব সহজ ও সাধারণ, 
2. এর স্ট্যান্ডার্ড এপিআই (Standard API) থাকতে হবে, 
3. এটি হবে প্ল্যাটফর্ম ইনডিপেন্ডেন্ট (Platform Independent, অর্থাৎ সব ধরনের অপারেটিং সিস্টেমে চলবে), 
4. একে ওয়েব ব্রাউজারে এম্বেড করা যাবে, 
5. এর মাধ্যমে মাল্টিটাস্কিং (Multitasking) করা যাবে, 
6. এতে হার্ডওয়ারের সরাসরি মেমোরি ম্যানিপুলেশন (Memory Manipulation) করা যাবে না, এবং 
7. আউট-অব-দ্য-বক্স নেটওয়ার্ক প্রোগ্রামিং করা যাবে। 

তারা তখনকার সময়ের ইন্টারনেট বাবলকে (Internet bubble) উদ্দেশ্য করে পরবর্তী প্রজন্মের পণ্য (next generation product) তৈরি করতে চেয়েছিল। এই প্রজেক্টের কার্টুন নাম ছিল Duke (যা এখন আমরা জাভার মাস্কট হিসেবে চিনি)। পরবর্তীতে তারা সিদ্ধান্ত নেয় যে এম্বেডেড সিস্টেমের সমস্যার সমাধানটি তারা ওয়েব ব্রাউজারের ক্ষেত্রেও ব্যবহার করবে।

কিন্তু সমস্যা হচ্ছে এর কোনোকিছুই ঠিকঠাক মতো সি++ দিয়ে করা যাচ্ছিল না। সেই সময়ে ওয়েব ব্রাউজারে শুধুমাত্র স্ট্যাটিক পেইজে (Static Page) লেখা আর ছবি ছাড়া অন্য কিছু দেখাবার ব্যবস্থা ছিল না। এই অ্যাপলেট টেকনোলজি ব্যবহার করায় ব্রাউজার অ্যানিমেশন (Browser Animation) তৈরি করা যাবে। পেইজ হবে ইন্টারঅ্যাকটিভ (Interactive)। অ্যাপলেটের এই বৈশিষ্ট্যগুলো সবার নজর কাড়ে যা কিনা জাভা প্রোগ্রামিং ভাষার সফলতার মূল কারণ।

জেমস গসলিংয়ের এই ভার্চুয়াল মেশিনের সমাধানটি ছিল প্রকৃতপক্ষেই যুগান্তকারী (কেন যুগান্তকারী তা নিয়ে পরবর্তীতে এই বইয়ে আলোচনা করা হবে)। ইতিমধ্যে গ্রিন টিম ওকের প্রথম রিলিজ দেওয়ার প্রস্তুতি নেয়। ঠিক তখনই এক নতুন সমস্যার উদ্ভব হয়। আইনজীবীরা এসে জানায় যে, এর নাম ওক রাখা যাবে না। কারণ ইতিমধ্যেই এই নামটি ওক টেকনোলজিস (Oak Technologies) এর ট্রেডমার্ক। এর অর্থ এই যে, এর নাম পরিবর্তন করে অন্য নাম রাখতে হবে। শুরু হয় নানরকম চিন্তাভাবনার (brainstorming)। কিন্তু কোনোভাবেই একটি ভালো নাম নির্বাচন করা যাচ্ছিল না। অনেকেই অনেক ধরনের নাম উপস্থাপন করেন, যেমন- DNA, Silk, Ruby, yuck, Lyric, Pepper, NetProse, Neon, Java ইত্যাদি। এই সবগুলো নাম লিগ্যাল ডিপার্টমেন্টে সাবমিট করার পর মাত্র Java, DNA ও Silk এই তিনটি নাম ফিরে আসে যেগুলো কিনা ব্যবহার করা যাবে। নাম নিয়ে ঘণ্টার পর ঘণ্টা মিটিং চলতে থাকে। এর মধ্যে ক্রিস ওয়ার্থ (Chris Warth), জাভা (Java) নামটি ব্যবহার করার প্রস্তাব করেন, কারণ তখন তার হাতে ছিল এক কাপ গরম Peet's Java (কফি)⁸। শেষপর্যন্ত অনেক চিন্তাভাবনার পর এর নাম ঠিক করা হয় জাভা। কারণ একমাত্র এই নামেই সব থেকে ইতিবাচক প্রতিক্রিয়া পাওয়া যাচ্ছিল। তাছাড়া কফি পান করার পর সবারই মন চনমনে হয়ে যায়।

জাভা এমন একটি প্রোগ্রামিং ভাষা যা কিনা তখন সবার মনকেই চাঙা করে দিয়েছিল।

১৯৯৫ সালের মে মাসে জাভার প্রথম পাবলিক ভার্সন রিলিজ হয়।

এর পরের ইতিহাস আমরা সবাই জানি। জাভা হচ্ছে পৃথিবী নামক গ্রহের সবচেয়ে সফল এবং জনপ্রিয় প্রোগ্রামিংয়ের ভাষা।

---

পাদটীকা

1 দিনটি চমৎকার ছিল কিনা এ বিষয়ে আমার ধারণা নেই, তবে ধরে নিচ্ছি এটি একটি চমৎকার দিন ছিল।

2 http://soa.sys-con.com/node/39220/mobile

3 https://go.java/index.html

4 Dennis Ritchie (September 9, 1941 – October 12, 2011) আমেরিকান কম্পিউটার বিজ্ঞানী ও সি প্রোগ্রামিং ভাষা এবং Unix অপারেটিং সিস্টেমের প্রণেতা।

5 Bjarne Stroustrup, ডেনমার্কের কম্পিউটার বিজ্ঞানী, সি++ প্রোগ্রামিং ভাষার প্রণেতা।

6 Steven Paul "Steve" Jobs – বিখ্যাত আইফোন প্রস্তুতকারী কোম্পানি অ্যাপলের সহপ্রতিষ্ঠাতা, চেয়ারম্যান এবং প্রধান নির্বাহী কর্মকর্তা (CEO)

7 James Gosling – জাভা প্রোগ্রামিং ভাষার স্রষ্টা (Father)।

8 http://www.javaworld.com/article/2077265/core-java/so-why-did-they-decide-to-call-it-java-.html

প্রোগ্রামিং প্যারাডাইম

সফটওয়্যার মূলত প্রোগ্রাম। একটি প্রোগ্রামে কতগুলো ইনস্ট্রাকশন লেখা থাকে। কম্পিউটার প্রোগ্রামের ইনস্ট্রাকশন অনুযায়ী কাজ করে। এই ইনস্ট্রাকশনগুলো ইচ্ছে মতো দেওয়া যায় না। এগুলো দেওয়ার কতগুলো পদ্ধতি ও স্টাইল রয়েছে। 

এই আলোচনার বিষয়বস্তু হচ্ছে প্রোগ্রামিং স্টাইল। 

উদাহরণসরূপ বলা যেতে পারে যে, আমরা সাবাই পোশাক পড়ি। কিন্তু প্রত্যেকে আলাদা আলাদা পোশাক পড়ে থাকে, বাঙালীদের পোশাকের নিজস্ব স্টাইল রয়েছে। তবে কেউ কেউ ওয়েস্ট্রার্ন ড্রেস পড়তে স্বাচ্ছন্দবোধ করে। আবার কোনো কোনো বিশেষ অনুষ্ঠানে ড্রেস কোড থাকে। তবে আপনি সে রকম পোশাকই পরিধান করুন না কেনো, পোশাক পড়ার মূল কারণ একই।

একইভাবে প্রোগ্রামিং করার ক্ষেত্রেও এরকম অনেকগুলো স্টাইল রয়েছে। তবে যে স্টাইলেই প্রোগ্রাম লিখুন না কেনো, মূল উদ্দ্যেশ্য কম্পিউটারকে ইনস্ট্রাকশন দেওয়া, তাকে দিয়ে কাজ করিয়ে নেওয়া। 

প্রোগ্রামিংয়ের স্টাইলগুলোকে প্রোগ্রামিং প্যারাডাইমও বলা হয়। প্রোগ্রামিংয়ের বেশ কতগুলো প্যারাডাইম রয়েছে -

১. ইম্পারেটিভ (imperative) 

২. ডিক্লেয়ারেটিভ (declarative) 

৩. স্ট্রাকচারড (structured) 

৪. প্রসিডিউরাল (procedural) 

৫. ফাংশনাল (functional) 

৬. অবজেক্ট ওরিয়েন্টেড (object oriented) 

ইত্যাদি। 

দেখা যাচ্ছে প্রোগ্রামিং করার অনেকগুলো প্যারাডাইম রয়েছে, তবে যেকোনো স্টাইল দিয়েই প্রোগ্রাম লেখা যায় এবং কম্পিউটার তা অ্যাকসেপ্ট করবে। তবে কোনো কোনো প্যারাডাইম বিশেষ বিশেষ জায়গায় ভাল কাজ করে। অর্থাৎ সব স্টাইল অ্যাক্সেপ্ট হলেও ক্ষেত্রবিশেষে এদের আলদা গুরুত্ব থাকে। 

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

একটি প্রোগ্রামে নানা রকম এক্সপ্রেশন ও স্টেটমেন্ট থাকে। এক্সপ্রেশন হলো যেখান থেকে কোনো একটি ভ্যালু বা মান বের করা যায়। যেমন- 

এখানে উপরের লাইন থেকে একটা ভ্যালু বের করে আনা যায়। অন্যদিকে স্টেটমেন্ট হলো একটা কোডের লাইন যা কোন একটি কাজ করে। যেমন-

উপরের লাইনটি একটি এক্সপ্রেশন যা প্রোগ্রামকে ১০০ নম্বর লাইনে যেতে বলছে। এটি একটি স্টেটমেন্ট। পাইথনের ক্ষেত্রে নিচের উদাহরণটি দেওয়া যায়

এবার প্রোগ্রামিংয়ের বিভিন্ন প্যারডাইমগুলো নিয়ে হালকা আলোচনা করা যাক -

ইম্পারেটিভ - 

এই স্টাইলের প্রোগ্রামগুলো স্টেপ বাই স্টেপ লেখা হয়। প্রোগ্রামে কতগুলো গ্লোবাল স্টেট থাকে। ফাংশনগুলো এই গ্লোবাল স্টেটকে পরিবর্তন করে। প্রোগ্রামে কোথায় কী করতে হবে তা লিখে দিতে হয়। অনেকটা কতগুলো কমান্ড একের পর এক সাজিয়ে প্রোগ্রাম লেখার মতো। তবে কীভাবে প্রোগ্রামটি এক্সিকিউট হবে, প্রােগ্রাম এক্সিকিউট হলে কী আউটপুট হবে, ভ্যারিয়েবলগুলোর পরিবর্তনগুলো কীভাবে করতে হবে ইত্যাদি প্রোগ্রামারকে বিস্তারিত পুঙ্খানুপুঙ্খভাবে (in detail) বলে দিতে হয়। পুনরাবৃত্তিমূলক কাজগুলো করার জন্যে GoTo ব্যবহার করা হয়। এর এক্সিকিউশন হয় স্টেটমেন্ট বেইজড। কোন একটা ফাইলে উপর থেকে প্রোগ্রাম প্রত্যেকটি স্টেটমেন্ট এক্সিকিউট করে করে কোনো কাজ সম্পাদন করে। 

ডিক্লেয়ারেটিভ -

এই স্টাইলের প্রোগ্রামে প্রোগ্রামার কী চায় তা বলে, কিন্তু কীভাবে তা আসবে বা কিভাবে আউটপুটটি তৈরি হবে তা বলা থাকে না। অর্থাৎ প্রোগ্রামার প্রোগ্রামে কী করতে হবে তা লিখে, কীভাবে করতে হবে তা লিখে না। এটি ইম্পারেটিভ প্রোগ্রামের অনেকটা উল্টো। এতো কোনো অ্যাসাইনমেন্ট থাকে না, লুপ থাকে না। এটি শুধুমাত্র এক্সপ্রেশন বেইজড। এতে শুধু এক্সপ্রেশন লেখা যায় যা থেকে কোনো ভ্যালু deduce বা বের করা আনা যায়। ডাটাবেজের সিকুয়েল প্রোগ্রাম ডিক্লেয়ারেটিভ প্রোগ্রামিংয়ের উদাহরণ বলা যায়। 

স্ট্রাকচারড প্রোগ্রামিং -

এটিও ইম্পারেটিভ প্রোগ্রামিংয়ের একটা আলাদারূপ এবং এতে বাড়তি কিছু বিষয় থাকে। এতে লুপিং, ব্রাঞ্চি করা যায়। প্রোগ্রামের ফ্লো উপর থেকে নিচে না এসে বিভিন্ন দিকে চলে যেতে পারে- এগুলোর জন্য if, switch ইত্যাদি ব্যবহার করা হয়। পুনরাবৃত্তিমূলক কাজ করার জন্য এতে GoTo এর বদলে লুপ ব্যবহার করা হয়। এই প্রোগ্রামিংয়ে কোডগুলো বিভিন্ন স্ট্রাকচারে গুছিয়ে সুন্দর করে উপস্থাপন করা হয়। এতে নানা রকম সাব-রুটিন বা ফাংশন থাকে। কোডগুলোকে বিভিন্ন ব্লকে সাজানো যায়। এতে করে পরিস্কারভাবে কোড লেখা যায় যাতে করে পরবর্তীতে প্রোগ্রামারদের পড়রে সুবিধা হয়।

প্রসিডিউরাল - 

এটিও ইম্পারেটিভ ও স্ট্রাকচারড প্রোগ্রামিং তবে এতে প্রচুর প্রসিডিউর বা সাব-রুটিন ফাংশন কল করা হয়। এতে অনেক রকম প্রসিডিউর বা ফাংশন থাকে। একটি প্রসিডিউরকে একটা ছোট প্রোগ্রাম বলা যেতে পারে। এগুলোকে যেকোনো জায়গা থেকে কল করা যায়। প্রসিডিউরাল প্রোগ্রামে একটার পর একটা প্রসিডিউর কল করা প্রোগ্রাম করা হয়।

ফাংশনাল -

ফাংশনাল প্রোগ্রামিংকে প্রোগাম লেখা হয় কতগুলো ফাংশন সুবিন্যস্ত (compose) করে। তবে ফাংশনাল প্রোগ্রামের বড় বৈশিষ্ট হলো এটি কোনো গ্লোবাল স্টেটকে পরিবর্তন করে না। মনে করুন, একটি ফাংশনের কাজ হলো ১ ইনক্রিমেন্ট করা। এটি যদি ফাংশনাল প্রোগ্রামিংয়ে লেখা হয় তাহলে এই ফাংশন কোনো গ্লোবাল ভ্যারিয়েবলকে পরিবর্তন করবে না। বরং এটি একটি সংখ্যা আর্গুমেন্ট হিসেবে নিয়ে এক ইনক্রিমেন্ট করে রিটার্ন করবে। আরেকটি উদাহরণ দেওয়া যাক -

ধরুন, একটি ক্লাসের সবগুলো ছাত্রছাত্রীর বয়সের গড় নির্ণয় করতে হবে। এর জন্য প্রথমে এদের বয়স যোগ করতে হবে। 

বয়স নির্ণয় করার প্রক্রিয়াটি নিচের মতো হতে পারে- 

বয়স যোগ করার জন্য হুয়াইট বোর্ডে প্রথমে শূণ্য লিখুন। তারপর একজনকে জিজ্ঞাসা করুন, তার বয়স কত? সে উত্তর দিলে, আগের শূণ্য মুছে সেখানে সেই সংখ্যাটা লিখুন। পরের জনকে একই প্রশ্ন করুন, সে উত্তর দিলে বোর্ডের সংখ্যার সঙ্গে তা যোগ করে আগেরটা মুছে দিয়ে সেখানে লিখুন। এই প্রক্রিয়া এভাবে চালিয়ে যান যতক্ষণ পর্যন্ত সবগুলো ছাত্রছাত্রীর বয়স যোগ করা শেষ না হয়। 

তবে এই যোগ করার প্রক্রিয়া এমন হতে পারতো যে, আপনি প্রথম জনকে বললেন, আপনার বয়স পরের জনকে বলেন, পরের জন তার বয়সের সাথে সেই সংখ্যা যোগ করে তা পরের জনকে দিয়ে দেবে। এভাবে একদম শেষ পর্যন্ত হয়ে গেলে আপনাকে সংখ্যা দিয়ে দেবে। এতে করে আপনার বোর্ডে সংখ্যা বার বার লেখা বা মুছার দরকার হলো না। 

ফাংশনাল প্রোগ্রামিং মূলত এভাবেই চিন্তা করা হয়। এর আরও অনেকগুলো বৈশিষ্ট্য রয়েছে। সেগুলো হলো - 

১. একটি ফাংশন আরেকটি ফাংশনে আর্গুমেন্ট হিসেবে পাস করা যায়।

২. একটি ফাংশন অন্য একটি ফাংশন রিটার্ন করতে পারে। 

৩. ফাংশন পিউর (pure) হয়- অর্থাৎ একই ইনপুটের জন্যে সবসময় ফাংশন একই রেজাল্ট রিটার্ন করবে এবং এটি কখনোই গ্লোবাল স্টেটকে পরিবর্তন করবে না। 

৪. সব ফাংশন কল করার সঙ্গে সঙ্গেই এক্সিকিউট হয়ে যায় না। যখন প্রয়োজন পরে শুধুমাত্র তখনই এক্সিকিউট হয়। একে লেজি ইভ্যালিউশন (lazy evaluation) বলে। 

৫. এতে ডিক্লেয়ারেটিভভাবে কোড লেখা যায়। 

ইত্যাদি। এটি নিয়ে পরবর্তী আর্টিক্যালে আরও বিস্তারিত লেখার চেষ্টা করবো। বিশেষ করে এই প্যারাডাইমের কী কী সুবিধা আছে।

অবজেক্ট ওরিয়েন্টেড - 

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

কোড রিইউজ করার জন্য এতে ইনহেরিট্যান্সের সুবিধা সহ, পলিফরফিজম ও এনক্যাপসুলেশন ইত্যাদি বৈশিষ্ট্য থাকে। 

উপরে উল্লেখিত এই কয়েকটি ছাড়াও আরও অনেক রকম প্রোগ্রামিং প্যারাডাইম রয়েছে যেগুলো নিয়ে এখানে আলোচনা করা হলো না।

এখানে মূলত প্রোগ্রামিংয়ের স্টাইল বা প্যারাডাইম নিয়ে আলোচনা করা হলো, প্রোগ্রামিং ল্যাংগুয়েজ নিয়ে নয়। একটি প্রোগ্রামিং ল্যাংগুয়েজ অনেকগুলো প্যারডাইম ইমপ্লিমেন্ট করতে পারে। একজন প্রোগ্রামার তার নিজের পছ্ন্দ ও প্রয়োজন অনুযায়ী স্টাইল বা প্যারাডাইম ঠিক করে নেয় কোনটা সে ব্যবহার করবে।

প্রোগ্রামিং ল্যাংগুয়েজের কত রকম হতে পারে তা নিয়ে পরবর্তী আর্টিক্যাল লেখার ইচ্ছে পোষণ করছি । 

Agile and Scrum

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

Agile এর বাংলা অর্থ হতে পারে কর্মদক্ষ কিংবা চটপটে। অর্থাৎ যা খুব সহজে নিজেকে পরিবর্তন করতে পারে প্রয়োজন অনুসারে। 

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

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

উপরের উপায়টিকে ওয়াটারফল মেথডোলজি(waterfall methodology) বলা হয়। তবে এর একটা সমস্যা হলো, আপনার ডেভেলপমেন্ট করার পর আগেই সবকিছু ঠিকঠাক করে ডিজাইন করতে হবে। একটা স্টেজে থেকে আরেকটি স্টেজে যাওয়ার সময় কোনোরকম ভুল করার উপায় নেই। আপনি যখন রিকোয়ারমেন্ট নিয়ে বিশ্লেষণ বা ডিজাইন করছেন তখন কিন্তু মূল প্রোডাক্ট বা সাইটটি তৈরি হয়নি। আপনি যখন পুরোপুরি তৈরি করে ফেললেন তখন আপনার ক্লায়েন্টকে দেখালেন। কিন্তু ক্লায়েন্ট হয়তো সাইটটি দেখে বললো, না আমিতো এভাবে চাইনি। এটি এভাবে করতে হবে। ইতিমধ্যে আপনি পুরো সফটওয়্যার তৈরি করে ফেলেছেন, এখন আর পরিবর্তন করার কোন উপায় নেই। করতে গেলে পুরো প্রক্রিয়ার মধ্যে দিয়ে আবার যেতে হবে যা কষ্টসাধ্য। 

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

অ্যাজাইলের ১২ টি ম্যানিফেস্টো রয়েছে। 

http://agilemanifesto.org/principles.html

উপরের সাইটিতে গেলে সেগুলো দেখা যাবে।

মূল কথা হচ্ছে, অ্যাজাইলে অনেকগুলো আইটারেশন থাকে। একবারে সবগুলো না করে ছোট ছোট অংশে ভেঙ্গে কাজ করা এবং খুব সহজে পরিবর্তনকে বরণ করা।

হেরাক্লিটাস নামে এক গ্রিক দার্শনিক বলে গেছেন- 

The Only Thing That Is Constant Is Change

সুতরাং পরিবর্তন তো থাকবেই। 

এছাড়াও এটি একটি মানসিকতাও। এতে করে সঠিক কাজটি করা যায়। আপনি একটি ভুল করলে, বুঝতে পারার সঙ্গে সঙ্গে তা শুধরে নেওয়ার মানসিকতা থেকে সঠিকটাকে গ্রহণ করা। 

মানুষ হিসেবেও অ্যাজাইল হওয়া জরুরী।

এই আইডিয়া বেশ কয়েকভাবে ইমপ্লিমেন্ট করা হয়েছে। এগুলো হলো - স্ক্রাম (Scrum), এক্সট্রিম প্রোগ্রামিং (extreme programming), কানবান(Kanban) ইত্যাদি। 

এগুলোর মধ্যে স্ক্রাম অনেক বেশি ব্যবহার হয়। বলা যেতে পারে যেসব ইন্ড্রাস্ট্রি অ্যাজাইল ব্যবহার করে তাদের ৮০-৮৫% শতাংশ স্ক্রাম ব্যবহার করে। 

স্ক্রাম মূলত একটি ফ্রেমওয়ার্ক যা কতগুলো ভ্যালুজ, প্রিন্সিপালস, এন্ড প্র্যাকটিসেস দিয়ে থাকে যা দিয়ে কোনো অর্গানাইজেশনে ইঞ্জিনিয়ারিং প্রজেক্ট বা সমস্যা সমাধানের মৌলিক ভিত্তি তৈরি করে দেয়। 

উপরে বলেছি যে, অ্যাজাইলে একটি প্রজেক্টকে কতগুলো ছোট ছোট অংশে ভাগ করা হয়। এই ছোট অংশগুলোকে আইটারেশন (iteration) বলা হয়। স্ক্রামে এই প্রত্যেকটি আইটারেশনকে স্প্রিন্ট (sprint) বলা হয়।

প্রত্যেকটি স্প্রিন্টের শেষে মূল প্রজেক্টের একটা নিদির্ষ্ট অংশ(end product) তৈরি হয় যা ক্লায়েন্টকে ডেলিভার করা যায়। এটি ক্লায়েন্ট ব্যবহার করে সাথে সাথে ফিডব্যাক দিতে পারে। এতে করে ক্লায়েন্ট-ডেভেলপার সবসময় একটি কনস্ট্যান্ট ফিডব্যক লুপের মধ্যে থাকে এবং এতে ভুল হওয়ার সম্ভবনা কমে যায়। এতে করে ক্লায়েন্টের সম্পূর্ণ ভিজিবিলিটি থাকে। অন্যদিকে ওয়াটারফলে এই ভিজিবিলিটি থাকেই না। 

তাহলে প্রশ্ন হতে পারে একটি প্রজেক্টকে কীভাবে ছোট ছোট অংশে ভাগ করা যায়। স্ক্রামে রিকোয়ারমেন্টগুলোকে ইউজার স্টোরি (user story) আকারে লেখা হয়। 

ইউজার স্টোরি একটি সংক্ষিপ্ত বর্ণনা যেখানে সফটওয়্যারের একটি ফিচার একজন ইউজারের পার্সপেক্টিভ থেকে লেখা হয়। অনেকটা এমন- একজন ব্যবহারকারী (user) যখন কোনো নির্দিষ্ট ফিচার ব্যবহার করবে সে কী প্রত্যাশা করে। উদাহরণ- 

As an I want to do < certain things in the site> so that I can do < this things> 

An a website user, I need a home button, so that I can return back to the homepage with a single click. 

প্রত্যেকটি ইউজার স্টোরিতে তিনটি বিষয় থাকে। 

১. Role বা ক্যারেক্টার অর্থাৎ যে ইউজার স্টোরির নির্দিষ্ট কাজটি করতে যাচ্ছে

২. feature - অর্থাৎ ক্যারেক্টারটি আসলে যে কাজটি করতে যাচ্ছে

৩. benefit - এই কাজটি করে কী লাভ হবে? 

কোনো একটি ইউজার স্টোরিতে যদি এই তিনটি অংশ থাকে, তাহলে এই প্রত্যেকটি স্টোরি হবে একটি অখণ্ড, একটি নির্দিষ্ট ফিচার যা তৈরি করার (কোড লেখার) পর একটি এক্সিকিউটেবলে পরিণত হবে এবং তা ইউজার ব্যবহার করতে পারবে। 

এই ইউজার স্টোরিগুলোকে একটি কালেকশনে রাখা হয় যার নাম ব্যাকলগ (backlog)। এই ব্যাকলগ তিন রকম হতে পারে -

১. প্রোডাক্ট ব্যাকলগ – এখানে একটি প্রজেক্ট বা প্রোডাক্টের (যে সফটওয়্যারটি তৈরি করা হচ্ছে) সবগুলো ব্যাকলগ থাকে।

২. স্প্রিন্ট ব্যাকলগ – একটি নির্দিষ্ট স্প্রিন্টের ব্যাকলগ যা কোন নিদির্ষ্ট স্প্রিন্টে যে ইউজার স্টোরিগুলো নিয়ে কাজ করা হচ্ছে সেগুলো।

৩. রিলিজ ব্যাকলগ – এটি কয়েকটি স্প্রিন্ট মিলে হতে পারে। অনেক সময় স্প্রিন্ট ছোট সময়ে হয়(১ সপ্তাহ বা ২ সপ্তাহ) 

এক্ষেত্রে অনেকগুলো স্প্রিন্টের কাজ নিয়ে একটি রিলিজ দেওয়া হয়, যাতে ক্লায়েন্টের কাছে একটা মিনিংফুল কিছু যায়।

এখন যেহেতু আমাদের কাছে অনেকগুলো ইউজার স্টোরি রয়েছে, তাহলে কোনগুলো আগে করা হবে আর কোনগুলো পরে করা হবে তা নিয়ে প্রশ্ন হতে পারে। এক্ষেত্রে অবশ্যই স্টোরিগুলোকে prioritize করতে হবে। এতে করে যে স্টোরিগুলো সবচেয়ে বেশি প্রাসঙ্গিক সেগুলোকে আগে করা যায়।

এই privatization নানাভাবে করা যায়। প্রথমত এই স্টোরিগুলো যেগুলো আগে দরকার সেগুলোকে টপ অর্ডারে সাজানো যেতে পারে। তারপর কোনটি করতে কেমন সময় লাগবে তার একটি হিসাব করা হয়। এই প্রক্রিয়ায় টিমের সবাই অংশ গ্রহণ করতে পারে। এই সময় নির্ধারণ করার জন্য প্রত্যেকটি স্টোরিকে একটি ফিবোনাচি সংখ্যা দেওয়া যেতে পারে। অনেক ছোট স্টোরিকে ১, এর থেকে একটি বেশি বড়কে ২, এভাবে তিন, মাঝারি স্টোরিকে ৫ এবং এর থেকে একটু বড় স্টোরিকে ৮ তারপর ১৩ এভাবে স্টোরি পয়েন্ট দেওয়া যেতে পারে। এরপর টিমের ক্যাপাসিটি দেখা হয়। 

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

এখন স্প্রিন্ট শুরু হয়ে গেল। কিন্তু এখন প্রশ্ন হচ্ছে, কীভাবে কাজের ট্র্যাক রাখা যায়। খুব সংক্ষিপ্ত সময়ের টাইট টামইলাইনে নানাভাবে deviate হওয়ার সম্ভবনা থাকে। এরজন্য স্ক্রামে প্রতিদিন একটা নির্দিষ্ট সময়ে ১৫ মিনিটের একটি সংক্ষিপ্ত মিটিং হয়। একে daily scrum meeting বা daily scrum বলা হয়। এই মিটিং প্রত্যেকটি টিম মেম্বার উপস্থিত থাকে এবং প্রত্যেকেই তিনটি প্রশ্নের উত্তর দিয়ে থাকে -

১. আপনি গতকাল কী কাজ করেছেন? (status update)

২. আপনি আজ কী করতে যাচ্ছেন ? (planning update)

৩. আপনার কাজে কোনো ব্লকার বা কোনো কিছুতে আটকে আছেন কিনা? (obstacle update) 

এছাড়াও প্রত্যেকটি টিম মেম্বার যে নিদির্ষ্ট স্টোরিতে কাজ করছে, সেগুলোতে কে কতক্ষণ কাজ করেছে তা লগ করে থাকে। এতে করে কোন স্টোরিতে কতক্ষণ কাজ করা হয়েছে বা কতক্ষণ বাকি তা রেকর্ড করা থাকে। এর জন্য একটি স্ক্রাম বোর্ড ব্যবহার করা হয়। 

এতে করে যেকোনো মুহূর্তে টিমের একটি কমপ্লিট পিকচার পাওয়া যায়। এই বোর্ডের অনলাইন সফটওয়্যার রয়েছে। এগুলোর মধ্যে Trello ও JIRA জনপ্রিয়।  

একটি স্ক্রাম টিমে তিনটি ক্যারেক্টার বা এনটিটি থাকে - স্ক্রাম মাস্টার (Scrum Master) , প্রোডাক্ট ওনার (product owner) এবং ডেভেলপমেন্ট টিম (development team)। স্ক্রাম মাস্টারের কাজ হলো সবকিছু ঠিকঠাক মতো চলছে কিনা তা খেয়াল রাখা। সে অনেকটা কোচ (coach) হিসেবে কাজ করে। তার মূল উদ্দেশ্য থাকে কীভাবে একটি হাই পার্মমেন্স টিম তৈরি করা যায়। টিমে কোনো রকম bottleneck বা সমস্যা থাকলে তা স্ক্রাম মাস্টার সমাধান করার চেষ্টা করে।

সহজ বাংলায়, প্রোডাক্ট ওনার হচ্ছে, একজন ব্যক্তি যে পুরো প্রোডাক্টের মালিক। পুরো টিমের সামগ্রিক কিছুর দায়িত্ব তার । তিনি সবার সাথে যোগাযোগ রাখে। প্রোডাক্ট বা প্রজেক্ট নিয়ে তার একটি ক্লিয়ার ভিশন থাকে যা মূলত স্ক্রাম টিম অ্যাচিভ করতে চেষ্টা করে। 

ডেভেলপমেন্ট টিম হলো যারা মূলত সফটওয়্যারটি তৈরি করে- এক্ষেত্রে সফ্টওয়্যার ডেভেলপার, টেস্টার ইত্যাদি।

স্প্রিন্ট শেষে একটি স্প্রিন্ট রিভিও মিটিং হয়। এই মিটিংয়ে মূলত ডেভেলপমেন্ট টিম নির্দিষ্ট স্প্রিন্টে কী কী কাজ হয়েছে তা ডেমোনস্ট্র্যাট করে।

স্প্রিন্ট শেষ হয় আরেকটি মিটিং দিয়ে যার নাম sprint retrospective. 

এই মিটিং স্ক্রাম টিমের প্রসেসগুলো নিয়ে আলোচনা করা হয়। এতে কোথাও কোন সমস্যা থাকলে সেগুলো নিয়ে আলেচনা করা হয় এবং কিভাবে সেগুলো থেকে বের হওয়া যায়। 

অর্থাৎ একটি স্প্রিন্ট শুরু হয় প্ল্যানিং মিটিং দিয়ে, শেষ হয় স্প্রিন্ট রিভিও ও স্প্রিন্ট রেট্রোসপেকটিভ দিয়ে। এভাবে এই সাইক্যাল চলতে থাকে প্রোডাক্ট বা সফওয়্যারটি সম্পূর্ণ শেষ হওয়ার আগ পর্যন্ত।

Act with Prudence

Whatever you undertake, act with prudence and consider the consequences

Kevlin Henney এর একট বই আছে, নাম 97 Things Every Programmer Should Know. 

এই বইয়ের প্রথম চ্যাপ্টারের নাম - Act with prudence.  তারপরেই উপরের লাইনটা আছে। 

Prudence শব্দের অর্থ দূরদর্শিতা বা বিচক্ষণতা। 

লাইনটার মানে দাড়ায় - বিচক্ষণতা সহিত কাজ কর। 

এবার মূল আলোচনায় চলে আসি। আলোচনার বিষয়বস্তু টেকনিক্যাল ডেব্ট(technical debt)

এই জিনিস খায় না মাথায় দেয় তাই বলছি- 

লোন নেওয়ার স্বল্পকালিন কিছু সুবিধা আছে। আমার হয়তো কিছু টাকার দরকার পড়েছে, আমি ব্যাংক থেকে লোন নিয়ে সাময়িক প্রয়োজনটা মেটাতে পারি। যেকোনো লোনের দীর্ঘ মেয়াদী ফলাফল মোটেও ভালো নয় এই জিনিস সবাই জানে। যতই দিন যাবে চক্রবৃদ্ধি হারে সুদ বাড়তে থাকবে এবং কোনো একসময় আমি যে পরিমান লোন নিয়েছিলাম তার থেকে কয়েকগুণ (ক্ষেত্রবিশেষে ৪/৫ গুণ) বেশি টাকা পরিশোধ করতে হয়। 

তবে এই লোন যত তাড়াতাড়ি শোধ করা যায় ততই মঙ্গলজনক (এতে সুদের পরিমান কম থাকে)। মূল বিষয়টা হচ্ছে লোন নেওয়া সাময়িক সুবিধার মনে হলেও এটি মোটেও ভালো কোনো বিষয় নয়। 

টেকনিক্যাল ডেব্‌ট মূলত রুপক অর্থে ব্যবহৃত(metaphorical term) শব্দ। যেকোনো কাজের কিছু নিয়ম কানুন(discipline) থাকে। ধরুণ আপনি একটি ব্রিজ তৈরি করতে চান। কোনোরকম শৃঙ্খলা ছাড়া একটি ব্রিজ ইচ্ছমতো বানানো সম্ভব নয়। সিভিল ইঞ্জিনিয়াররা পুরো প্রক্রিয়ার পরিকল্পনা তৈরি করে, এই পরিকল্পনাতে প্রচুর হিসেব নিকেশ থাকে, কীভাবে কোন রিসোর্স কোথায় ব্যবহার করা হবে তা নির্দিষ্ট করা হয়। 

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

একজন সফটওয়্যার ইঞ্জিনিয়ারিংয়েরও এমন একটি ডিসিপ্লিন রয়েছে। হুটহাট যা ইচ্ছেমতো এই কাজ করা যায় না। একজন ইঞ্জিনিয়ারের অনেকগুলো ডিজাইন ডিসিপ্লিন শিখতে হয়। নানা করম ডেটাস্ট্রাকচার, এলগরিদম এবং ডিজাইন প্যাটার্ন শিখতে হয়। এইগুলোর ভাল মন্দ আছে। অর্থাৎ একটি প্রক্রিয়া খুব ভালোভাবে করা যায় আবার একটু কম ভালোভাবেও করা যায়। ধরুন, আপনাকে একটা ১০ এর নামতা লেখার জন্যে একটি প্রোগ্রাম লিখতে বলা হলো। আপনি ১০ বার প্রিন্ট মেথড লিখে লিখে দিতে পারেন আবার একটা লুপের মধ্যে একটা প্রিন্ট মেথড ব্যবহার করেও লিখতে পারেন। প্রথম প্রক্রিয়াটি যদিও ১০ এর নামতা প্রিন্ট করবে কিন্তু সেটি আসলে মোটেও ভাল ডিজাইন নয়। এটি সাময়িকভাবে কাজ করলেও পরবর্তীতে ভেঙ্গে পরবে। 

আপনি যখন কোনো প্রোগ্রাম লিখেন বা সফটওয়্যার তৈরি করেন, তখন আপনার সবসময় ভালো ডিজাইনগুলো পছন্দ করার উপায় থাকে। এই সিন্ধান্তটি আপনি ডেভেলপার/প্রোগ্রামার হিসেবে নিবেন। তবে এই পছ্ন্দ যে সবসময় করা যায় তা নয়। কখনো কখনো কাস্টোমারকে খুশি করতে খু্ব দ্রুত একটা আউটপুট তৈরি করতে একটা বাঝে সিন্ধান্ত নিতে হয়। এই বাজে সিন্ধান্তের পেছনে একটি ভালো সিন্ধান্ত ছিল যা আপনি নেননি। একে টেকনিক্যাল ডেবট বলা হয়। 

এটি অনেকটা ব্যাংক থেকে লোন নেওয়ার মতো। সাময়িকভাবে সুবিধা দিলেও আপানাকে এর সুদ দিয়ে যেতে হবে যতক্ষণ পর্যন্ত আপনি পুরোপুরি মিটিয়ে না দেন। 

অনেকসময় একজন ডেভেলপার/প্রোগ্রামারকে এমন সিন্ধান্তের মুখোমুখি হতে হয় - 

1. doing it right. 
2. doing it quick 

কখনো কখনো আপানকে দ্বিতীয় সিন্ধান্তটি নিতে হয়। আপনি ধরে রাখেন যে, পরবর্তীতে এসে এটিকে আপনি ঠিক করবেন। কিন্তু বাস্তবতা আসলে এমনটা কখনো হয় না। আপনার কাছে প্রতিনিয়ত নতুন নতুন সমস্যা আসতেই থাকবে। আপনি পরে করবেন বলে যে কাজটি রেখে চলে গেলেন তা হয়তো কখনোই করা হয়ে উঠবে না। আর এদিকে আপনার ঋণ বেড়েই চলবে। এভাবে ঋণ বাড়তে বাড়ে কোনো সময় আপনরা পুরো প্রজেক্ট মুখ থুবড়ে পরতেই পার। এটি খুবই স্বাভাবিক। 

সুতরাং এই আলোচনার মূল বিষয় হচ্ছে, টেকনিক্যাল ডেব্‌ট যত কম রাখা যায় ততই ভালো। যদি কোনো কারণে আপনাকে দ্বিতীয় সিন্ধান্ত নিতে হয়, তাহলে আপনাকে দ্রুত সেই ঋণ শোধ করার ব্যবস্থা করতে হবে। পরবর্তী কাজের আগেই করে ফেলুন। সবচেয়ে ভালো হয় যদি কোন ঋণ না থাকে। 

কিন্তু আমরা জানি যে, বাস্তবে এমনটা সবসময় সম্ভব নয়। তাই সিন্ধান্ত নেওয়ার সময় চিন্তাভাবনা করে বিচক্ষণতার সাথে নেওয়া উচিৎ এবং এর পরিণতি (consequences) সম্পর্কে অবগত থাকা উচিৎ। 

কাজী নজরুল ইসলামের একটা কবিতার লাইন - 

“দিনে দিনে বহু বাড়িয়াছে দেনা শুধিতে হইবে ঋণ”

দেনা না বাড়ানোই উত্তম।