দুঃখিত, এটি দীর্ঘ হতে চলেছে তবে একাধিক পুনর্লিখন প্রকল্পের স্থপতি এবং বিকাশকারী উভয়ই এটি ব্যক্তিগত অভিজ্ঞতার ভিত্তিতে।
নিম্নলিখিত শর্তগুলির কারণে আপনাকে কিছু প্রকার পুনর্লিখন বিবেচনা করতে হবে। এর পরে কোনটি করা উচিত তা কীভাবে সিদ্ধান্ত নেবেন সে সম্পর্কে আমি কথা বলব।
- বিকাশকারী র্যাম্প আপ সময় খুব বেশি। যদি কোনও নতুন বিকাশকারীকে র্যাম্প আপ করতে নীচের (অভিজ্ঞতার স্তরের) চেয়ে বেশি বেশি সময় লাগে তবে সিস্টেমটি নতুন করে ডিজাইন করা দরকার। র্যাম্প আপের অর্থ, নতুন বিকাশকারী তাদের প্রথম প্রতিশ্রুতি (প্রস্তুত করার জন্য একটি ছোট বৈশিষ্ট্যে) প্রস্তুত হওয়ার আগে সময়ের পরিমাণ বোঝায়
- কলেজ থেকে সতেজ - 1.5 মাস
- এখনও সবুজ, তবে 1 মাস - আগে অন্যান্য প্রকল্পে কাজ করেছেন
- মাঝের স্তর - 2 সপ্তাহ
- অভিজ্ঞ - 1 সপ্তাহ
- সিনিয়র স্তর - 1 দিন
- স্থাপনা স্বয়ংক্রিয় করা যায় না, কারণ বিদ্যমান স্থাপত্যের জটিলতার কারণে
- এমনকি সরল বাগ ফিক্সগুলি বিদ্যমান কোডের জটিলতার কারণে খুব বেশি সময় নেয়
- নতুন বৈশিষ্ট্যগুলি অনেক দীর্ঘ সময় নেয় এবং কোডবেসের আন্তঃনির্ভরতার কারণে অনেক বেশি ব্যয় হয় (নতুন বৈশিষ্ট্যগুলি পৃথক করা যায় না, এবং তাই বিদ্যমান বৈশিষ্ট্যগুলিকে প্রভাবিত করে)
- বিদ্যমান কোডবেসের আন্তঃনির্ভরতার কারণে আনুষ্ঠানিক পরীক্ষার চক্রটি অনেক বেশি সময় নেয়।
- অনেকগুলি ব্যবহারের কেস খুব কম স্ক্রিনে কার্যকর করা হয়। এটি ব্যবহারকারী এবং বিকাশকারীদের প্রশিক্ষণের সমস্যাগুলির কারণ করে।
- বর্তমান ব্যবস্থায় যে প্রযুক্তি রয়েছে তার দাবি এটি
- প্রযুক্তির অভিজ্ঞতার সাথে গুণমান বিকাশকারীদের খুঁজে পাওয়া খুব কঠিন
- এটি অবচয় করা হয়েছে (নতুন প্ল্যাটফর্ম / বৈশিষ্ট্যগুলি সমর্থন করার জন্য এটি আপগ্রেড করা যাবে না)
- এখানে কেবলমাত্র আরও অনেকগুলি উচ্চতর স্তরের প্রযুক্তি উপলব্ধ রয়েছে
- পুরানো প্রযুক্তির অবকাঠামো রক্ষণাবেক্ষণের ব্যয় খুব বেশি
এই জিনিসগুলি বেশ স্ব-স্পষ্ট। যখন একটি ক্রমবর্ধমান পুনর্নির্মাণ বনাম সম্পূর্ণ পুনর্লিখনের বিষয়ে সিদ্ধান্ত নেওয়া হয় তখন আরও বিষয়ভিত্তিক হয়, এবং তাই আরও রাজনৈতিকভাবে চার্জ করা হয়। আমি দৃ conv়তার সাথে যা বলতে পারি তা হল স্পষ্টভাবে বলতে গেলে এটি কখনই একটি ভাল ধারণা ভুল নয়।
যদি কোনও সিস্টেমকে ক্রমবর্ধমানভাবে নতুনভাবে ডিজাইন করা যায় এবং আপনার এ জাতীয় কোনও প্রকল্পের স্পনসরশিপের সম্পূর্ণ সমর্থন রয়েছে, তবে আপনার এটি করা উচিত। যদিও সমস্যাটি এখানে। অনেকগুলি সিস্টেম ক্রমবর্ধমানভাবে নতুনভাবে নকশা করা যায় না। এটির (প্রযুক্তিগত এবং রাজনৈতিক উভয়) প্রতিরোধ করার জন্য আমি যে কয়েকটি কারণের মুখোমুখি হয়েছি তা এখানে রয়েছে।
- কারিগরী
- উপাদানগুলির সংমিশ্রণটি এত বেশি যে একক উপাদানগুলিতে পরিবর্তনগুলি অন্য উপাদানগুলি থেকে পৃথক করা যায় না। একটি একক উপাদানটির পুনরায় নকশা কেবল সংলগ্ন উপাদানগুলিতেই নয়, পরোক্ষভাবে সমস্ত উপাদানগুলিতে পরিবর্তনের ক্যাসকেডের ফলাফল করে।
- প্রযুক্তি স্ট্যাক এত জটিল যে ভবিষ্যতের রাষ্ট্র নকশা একাধিক অবকাঠামোগত পরিবর্তন প্রয়োজন। এটি একটি সম্পূর্ণ পুনর্লিখনের ক্ষেত্রেও প্রয়োজনীয় হবে, তবে যদি এটি একটি ইনক্রিমেন্টাল পুনরায় ডিজাইনের ক্ষেত্রে প্রয়োজন হয়, তবে আপনি সেই সুবিধাটি হারাবেন।
- কোনও উপাদান পুনরায় নকশার ফলে সেই উপাদানটির সম্পূর্ণ পুনর্লিখনের ফলাফল হয়, কারণ বিদ্যমান নকশাটি এতই নিখরচায় যে সংরক্ষণ করার মতো কিছুই নেই। আবার, আপনি যদি সুবিধাটি হারাতে চান তবে এই ঘটনাটি ঘটে।
- রাজনৈতিক
- স্পনসরদের বোঝার জন্য এটি তৈরি করা যায় না যে একটি ইনক্রিমেন্টাল ডিজাইন প্রকল্পের জন্য দীর্ঘমেয়াদী প্রতিশ্রুতি প্রয়োজন requires অনিবার্যভাবে, বেশিরভাগ সংস্থাগুলি একটি ক্রমবর্ধমান পুনরায় নকশা তৈরি করে চলমান বাজেট ড্রেনের ক্ষুধা হারাবে। পুনর্লিখনের জন্য এই ক্ষুধা হ্রাস অনিবার্য, তবে স্পনসররা আরও চালিয়ে যাওয়ার দিকে ঝুঁকবেন, কারণ তারা আংশিকভাবে সম্পূর্ণ নতুন সিস্টেম এবং একটি আংশিকভাবে অপ্রচলিত পুরানো সিস্টেমের মধ্যে বিভক্ত হতে চান না।
- সিস্টেমের ব্যবহারকারীরা তাদের "বর্তমান স্ক্রিনগুলি" এর সাথে খুব বেশি সংযুক্ত আছেন। যদি এটি হয় তবে আপনার কাছে সিস্টেমের একটি গুরুত্বপূর্ণ অংশ (সম্মুখ প্রান্ত) উন্নত করার লাইসেন্স থাকবে না। একটি নতুন ডিজাইন আপনাকে নতুন কিছু দিয়ে শুরু করার কারণে এই সমস্যাটি থেকে বাঁচাতে দেয়। তারা এখনও "একই পর্দা" পাওয়ার জন্য জোর দিবে তবে পিছনে পিছনে আপনার কাছে আরও কিছু গোলাবারুদ রয়েছে।
মনে রাখবেন যে সম্পূর্ণ পুনর্লিখনের তুলনায় বর্ধিতভাবে পুনঃনির্মাণের মোট ব্যয় সর্বদা বেশি , তবে সংস্থায় প্রভাব সাধারণত কম থাকে। আমার মতে, আপনি যদি পুনর্লিখনকে ন্যায়সঙ্গত করতে পারেন এবং আপনার কাছে সুপারস্টার বিকাশকারীরা থাকে তবে এটি করুন।
কেবলমাত্র এটি করুন যদি আপনি নিশ্চিত হন যে এটির সমাপ্তির মধ্যে দিয়ে দেখার রাজনৈতিক ইচ্ছা আছে। এর অর্থ নির্বাহী এবং শেষ ব্যবহারকারী উভয়ই ইন-ইন। এটি ছাড়া, আপনি ব্যর্থ হবে। আমি ধরে নিচ্ছি যে এই কারণেই জোয়েল বলেছেন এটি একটি খারাপ ধারণা। এক্সিকিউটিভ এবং শেষ ব্যবহারকারীর ব-ইন অনেক স্থপতিদের কাছে দ্বি-মাথাযুক্ত ইউনিকর্নের মতো দেখায়। আপনাকে আক্রমণাত্মকভাবে এটি বিক্রি করতে হবে এবং এটি সম্পূর্ণ না হওয়া অবধি ধারাবাহিকতার জন্য প্রচার চালিয়ে যেতে হবে। এটি কঠিন, এবং আপনি এমন কিছুতে নিজের খ্যাতি স্থাপনের কথা বলছেন যা কেউ কেউ সফল হতে চাইবে না।
সাফল্যের জন্য কিছু কৌশল:
- আপনি যদি তা করেন তবে বিদ্যমান কোডটি রূপান্তর করার চেষ্টা করবেন না। স্ক্র্যাচ থেকে সিস্টেমটি ডিজাইন করুন। অন্যথায় আপনি আপনার সময় নষ্ট করছেন। "রূপান্তর" প্রকল্পটি আমি কখনও দেখিনি বা শুনিনি যা খারাপভাবে শেষ হয় নি।
- ব্যবহারকারীদের একবারে নতুন সিস্টেমে স্থানান্তর করুন। বিদ্যমান সিস্টেমে সবচেয়ে বেশি বেদনা থাকা দলগুলি শনাক্ত করুন এবং তাদের প্রথমে মাইগ্রেশন করুন। তাদের মুখের কথায় সুসংবাদ ছড়িয়ে দিন। এইভাবে আপনার নতুন সিস্টেমটি ভিতরে থেকে বিক্রি হবে।
- আপনার কাঠামোগুলি যেমন প্রয়োজন তেমন ডিজাইন করুন। কিছু আই-ব্যয়-6-মাস-বিল্ডিং-এই ফ্রেমওয়ার্কটি দিয়ে শুরু করবেন না যা আসল কোডটি কখনও দেখেনি।
- আপনার প্রযুক্তির স্ট্যাকটি যতটা সম্ভব ছোট রাখুন। ওভার ডিজাইন করবেন না। আপনি প্রয়োজন অনুযায়ী প্রযুক্তি যুক্ত করতে পারেন, তবে এগুলি আনা কঠিন। অতিরিক্তভাবে, আপনার যত স্তর রয়েছে তত বেশি কাজ বিকাশকারীদের কাজ করা। যেতে-যেতে অসুবিধা করবেন না।
- সরাসরি ডিজাইন প্রক্রিয়াতে ব্যবহারকারীদের জড়িত করুন, তবে কীভাবে এটি করবেন তা নির্ধারিত করতে দেবেন না। আপনি যদি ভাল ডিজাইনের নীতিমালা অনুসরণ করেন তবে তারা যা চান তার চেয়ে আরও ভাল তারা দিতে পারেন তা দেখিয়ে তাদের বিশ্বাস অর্জন করুন।
