আপনি কী করতে পারবেন না তা জানতে না পারলে আমরা কী করতাম। 3 অংশবিশিষ্ট একটি সিস্টেমটি কল্পনা করুন। একটি ইউআই রয়েছে যা ডেটা সংগ্রহ করে এবং এটি ডাটাবেসে রাখে। একটি রিপোর্টিং সিস্টেম রয়েছে যা ডাটাবেস থেকে রিপোর্ট করে। এবং এমন কিছু সার্ভার রয়েছে যা ডাটাবেস পর্যবেক্ষণ করে এবং নির্দিষ্ট মানদণ্ড পূরণ করা হলে ইমেল সতর্কতা প্রেরণ করে।
অনেক আগে এই লিখিত হবে:
- ডাটাবেস এবং প্রয়োজনীয়তার জন্য স্কিমার সাথে সম্মত হন - এটি কয়েক সপ্তাহ সময় নেয় কারণ এটি শীঘ্রই দেখতে পাবেন কেন এটি নিখুঁত হতে হয়েছিল
- 3 টি টুকরা 3 টি দেব বা 3 টি স্বতন্ত্র দলকে অর্পণ করুন
- প্রতিটি দেব তাদের টুকরোয় কাজ করবে এবং সপ্তাহে বা মাস ধরে তাদের নিজস্ব ডাটাবেস অনুলিপি ব্যবহার করে তাদের টুকরো পরীক্ষা করবে।
এই সময়ের মধ্যে ডেভসগুলি একে অপরের কোড চালায় না, বা অন্য কারও কোড দ্বারা তৈরি করা ডাটাবেসের কোনও সংস্করণ ব্যবহার করার চেষ্টা করবে না। রিপোর্ট লেখক কেবলমাত্র একগুচ্ছ নমুনা ডেটা যুক্ত করবেন। সতর্কতা লেখক রেকর্ডগুলি যুক্ত করে যা প্রতিবেদনের ইভেন্টগুলির অনুকরণ করে। এবং জিইউআই লেখক জিইউআই কী যুক্ত করেছে তা দেখার জন্য ডাটাবেসের দিকে নজর রাখবে। সময়ের সাথে সাথে, ডেভসরা বুঝতে পারে যে অনুমানটি কোনওভাবে ভুল ছিল, যেমন একটি সূচি নির্দিষ্ট না করা বা ক্ষেত্রের দৈর্ঘ্য খুব কম হওয়া এবং তাদের সংস্করণে এটি "ফিক্স" করা। তারা অন্যকে বলতে পারে, যারা এতে অভিনয় করতে পারে, তবে সাধারণত এই জিনিসগুলি পরবর্তীকালে একটি তালিকায় যাবে।
যখন তিনটি অংশই সম্পূর্ণরূপে কোডড হয়ে গিয়েছিল, এবং তাদের ডেভগুলি দ্বারা পরীক্ষা করা হয়েছিল এবং কখনও কখনও এটি ব্যবহারকারীদের দ্বারাও পরীক্ষিত হয় (তাদের একটি প্রতিবেদন, স্ক্রিন বা ইমেল সতর্কতা দেখায়) তখন "সংহতকরণ" পর্যায়ে চলে আসত। এটি প্রায়শই বেশ কয়েকমাসে বাজেট করা হলেও এখনও শেষ হবে। ডিভ 1 দ্বারা এই ক্ষেত্রের দৈর্ঘ্যের পরিবর্তনটি এখানে সন্ধান করা হবে এবং বিপুল কোড পরিবর্তন করতে এবং সম্ভবত ইউআই পরিবর্তনগুলি করার জন্য ডিভস 2 এবং 3 প্রয়োজন হবে। এই অতিরিক্ত সূচকটি তার নিজের সর্বনাশ ডেকে আনবে। ইত্যাদি। যদি ডেভসগুলির মধ্যে একটির দ্বারা কোনও ব্যবহারকারী কোনও ক্ষেত্র যোগ করার কথা বলেছিল, এবং করেছে, এখন অন্য দু'জনকেও এটি যুক্ত করার সময় হবে।
এই পর্যায়টি নির্মমভাবে বেদনাদায়ক এবং অনুমান করা বেশ অসম্ভব ছিল। সুতরাং লোকেরা বলতে শুরু করল "আমাদের আরও প্রায়ই সংহত করতে হবে"। "শুরু থেকেই আমাদের একসাথে কাজ করতে হবে।" "যখন আমাদের মধ্যে কেউ একটি পরিবর্তনের অনুরোধ উত্থাপন করে [সেভাবে আমরা কীভাবে কথা বললাম] অন্যরাও এটি সম্পর্কে জানতে হবে।" কিছু দল পৃথকভাবে কাজ চালিয়ে যাওয়ার আগে ইন্টিগ্রেশন টেস্টগুলি শুরু করেছিল। এবং কিছু দল একেবারে একে অপরের কোড এবং আউটপুট সর্বদা ব্যবহার শুরু করে। এবং এটি হয়ে উঠল অবিচ্ছিন্ন একীকরণ।
আপনি ভাবতে পারেন আমি প্রথম গল্পটি অত্যুক্তি করছি। আমি এমন একটি সংস্থার জন্য একবার কিছু কাজ করেছি যেখানে আমার যোগাযোগটি নীচের ত্রুটিগুলি ভুগছে এমন কিছু কোড পরীক্ষা করার জন্য আমাকে চিবিয়েছিল:
- তিনি যে স্ক্রিনটিতে কাজ করছেন না তার একটি বোতাম ছিল যা এখনও কিছুই করেনি
- কোনও ব্যবহারকারী স্ক্রিন ডিজাইনে সাইন আপ করেন নি (সুনির্দিষ্ট রঙ এবং ফন্ট; পর্দার অস্তিত্ব, এর ক্ষমতা এবং এটিতে কী বোতাম রয়েছে 300 পৃষ্ঠাগুলিতে।)
এটি তার মতামত ছিল যে আপনি কাজ শেষ না হওয়া পর্যন্ত উত্স নিয়ন্ত্রণে রাখবেন না। তিনি সাধারণত এক বছর দুটি বা দুটি চেকইন করেছিলেন। আমাদের কিছুটা দর্শনের পার্থক্য ছিল :-)
এছাড়াও, যদি আপনার বিশ্বাস করা খুব কঠিন হয় যে দলগুলি একটি ডেটাবেসের মতো ভাগ করা সংস্থার কাছাকাছি সংযোগ বিচ্ছিন্ন হয়ে যায়, আপনি সত্যই বিশ্বাস করবেন না (তবে এটি সত্য) যে একই পদ্ধতির কোডে নেওয়া হয়েছিল। আপনি কল করতে পারেন একটি ফাংশন লিখতে যাচ্ছেন? এটি দুর্দান্ত, এগিয়ে যান এবং এটি করুন, এর মধ্যে আমার যা দরকার তা কেবল হার্ডকোড করব। কয়েক মাস পরে আমি আমার কোডটি "সংহত" করব যাতে এটি আপনার এপিআইকে কল করে এবং আমরা আবিষ্কার করব যে আমি নাল পাস করলে এটি ফুঁড়ে উঠবে, যদি এটি নাল ফেরায় তবে আমি ফুঁক দেব (এবং এটি অনেক কিছু করে) এটি এমন জিনিসগুলি ফেরত দেয় যা খুব বড় আমার জন্য, এটি লিপ বছর এবং আরও হাজার হাজার জিনিস পরিচালনা করতে পারে না। স্বতন্ত্রভাবে কাজ করা এবং তারপরে একটি সংহতকরণের পর্ব হওয়া স্বাভাবিক ছিল। এখন তা পাগলের মতো শোনাচ্ছে।
