সফ্টওয়্যার সাফল্য / ব্যর্থতার হারের পুনর্লিখনের ক্ষেত্রে কি কোনও বাস্তব কেস স্টাডি রয়েছে?


36

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

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

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

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

পরিণতি: ঠিক আছে, আরও অনুসন্ধানের পরে, আমি কেস স্টাডিতে তিনটি আকর্ষণীয় নিবন্ধ পেয়েছি:

  1. পুনর্লিখন বা পুনরায় ব্যবহার । তারা একটি কোবোল অ্যাপে একটি গবেষণা করেছিলেন যা জাভাতে রূপান্তরিত হয়েছিল।
  2. অন্যটি ছিল সফ্টওয়্যার পুনঃব্যবহার: বিকাশকারীদের অভিজ্ঞতা এবং উপলব্ধি
  3. পুনরায় ব্যবহার বা পুনর্লিখন পুনর্লিখনের তুলনায় রক্ষণাবেক্ষণের ব্যয় সম্পর্কে আরও একটি গবেষণা।

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


10
আমি কেস স্টাডি সম্পর্কে জানি না, তবে আমি মনে করি কোনও পদ্ধতির জন্য স্ট্যান্ডার্ড উত্তর সম্ভবত "ইউনিট টেস্ট এবং রিফ্যাক্টর যুক্ত করুন"।
জেরি কফিন

2
এটি আমাকে সম্ভবত সর্বনিম্ন ঝুঁকির সহজ পদ্ধতির উপর আঘাত করে। অবশ্যই এটি সঠিক পদ্ধতির সুনিশ্চিত করার জন্য আমি পর্যাপ্ত বিশদ জানি না, তবে আমি এখন পর্যন্ত যা জানি তার ভিত্তিতে আমি আরও কিছু জানি না যা বিশেষত অনেক ভাল হওয়ার সম্ভাবনা রয়েছে।
জেরি কফিন

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

2
অনেকগুলি প্রকল্প ব্যক্তিগত, এটি একটি অধ্যয়নের পক্ষে সত্যই ভাল নমুনা সেট থাকা কঠিন। আপনি উপাখ্যানকৃত প্রমাণের মধ্যে সীমাবদ্ধ থাকতে পারেন।
মাইকে 30

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

উত্তর:


6

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

আমি কেস স্টাডি সম্পর্কে জানি না, তবে আমি মনে করি কোনও পদ্ধতির জন্য স্ট্যান্ডার্ড উত্তর সম্ভবত "ইউনিট টেস্ট এবং রিফ্যাক্টর যুক্ত করুন"।

এটি আমাকে সম্ভবত সর্বনিম্ন ঝুঁকির সহজ পদ্ধতির উপর আঘাত করে। অবশ্যই এটি সঠিক পদ্ধতির সুনিশ্চিত করার জন্য আমি পর্যাপ্ত বিশদ জানি না, তবে আমি এখন পর্যন্ত যা জানি তার ভিত্তিতে আমি আরও কিছু জানি না যা বিশেষত অনেক ভাল হওয়ার সম্ভাবনা রয়েছে।

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

আমি ধরে নেব যে পুনর্লিখন প্রকল্পগুলি সাধারণ প্রকল্পগুলির তুলনায় ব্যর্থতার হারের তুলনায় উল্লেখযোগ্যভাবে আলাদা নয় এবং সেরা তথ্যের জন্য সর্বশেষ CHAOS প্রতিবেদনটি উল্লেখ করবে।


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

হ্যাঁ, এই কারণেই বইটি সম্পর্কে মন্তব্য: "লিগ্যাসি কোডের সাথে কার্যকরভাবে কাজ করা" খুব উপযুক্ত ছিল। আমাকে গত বছরের মতো এইরকম কিছু করতে হয়েছিল এবং সেই বইতে যা ব্যাখ্যা করা হয়েছে তার মতো আরও পদ্ধতিগত পদ্ধতির গ্রহণ করা আমার অনেক সময় বাঁচাতে পারত এবং একটি ডকুমেন্টেশন / টেস্টিং ট্রেইল রেখে যেত দরকারী been আমার মনে হচ্ছে ঠিক এটির কাজটি করা দুর্দান্ত ছিল তবে যথেষ্ট ছিল না। বস্তুর এত বেশি নির্ভরতা ছিল আমি অনুভব করেছি যে আমার পরীক্ষার চেয়ে আরও ভাল কভারেজ থাকতে পারে।

6

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


3

অভিজ্ঞতা থেকে কথা বলা এবং এমন একটি সংস্থার সাথে বসবাস করা যা এন্টারপ্রাইজ আর্কিটেকচারটি শুরু থেকেই খারাপ ধারণা করে নিয়েছে আমি সত্যই বলতে পারি যে বৃহত্তম সমস্যাটি একটি বিস্তৃত বোঝার বিকাশ ঘটানো।

এই ধারণাটি যে কোনও সিস্টেমকে টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো করা যায় এবং স্বতন্ত্রভাবে বোঝা যায় ত্রুটিযুক্ত। এক পর্যায়ে একক ব্যক্তি বা বেশ কয়েকটি ব্যক্তিকে পুরো সমস্যাটি সম্পূর্ণরূপে ধারণা করতে সক্ষম হতে হয়েছিল। যদি সমস্যাটি ব্যবসায়িক সমস্যা এবং তাদের চালিত প্রযুক্তিগুলির একটি সিরিজ হয়; সংস্থার একজন ব্যক্তির সমস্ত সিস্টেমকে এমন স্তরে বুঝতে বেশ কয়েক বছর সময় লাগতে পারে যেখানে কোনও বিপর্যয় বা মিসড প্রয়োজন ছাড়াই তাদের প্রতিস্থাপন করা সম্ভব। আমি যখন প্রযুক্তি পরিচালক হিসাবে দায়িত্ব নিয়েছিলাম তখন আমার সংস্থায় অবশ্যই এটি হয়েছিল। এটি যদি আমি নিজেই একটি কোডার না হয়ে থাকি তবে আমি ধীরে ধীরে সুসংহত, শক্তভাবে মিলিত, শক্তভাবে আবদ্ধ আর্কিটেকচার এবং প্রযুক্তির সংহতকরণের সমস্ত বিবরণ ধীরে ধীরে বুঝতে সক্ষম হত না। যদি ছোট লুকানো থাকে তবে নথিভুক্ত বিবরণগুলি পছন্দ করুন"We put the eBay order number in the "SYSOENT.PO_NUMBER" field in the ERP system because that's what Wendell the VB coder from Florida decided to do" উপেক্ষা করা হয় ফলাফলগুলি বিপর্যয়কর হতে পারে এবং এটি জানার একমাত্র উপায় হ'ল আস্তে আস্তে এটি আবিষ্কার করা।

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

আমার প্রাথমিক ধারণাটি হ'ল, সিস্টেমটি অবশ্যই প্রায় সম্পূর্ণ জটিলতায় বুঝতে হবে এবং নতুন সিস্টেমটি সঠিকভাবে "ইঞ্জিনিয়ারড" হওয়ার জন্য এবং কেবল "তৈরি" না হওয়ার জন্য এটি সম্পূর্ণ সময়ে বুঝতে হবে understood

কুকিজ তৈরি হয়, সফ্টওয়্যার (হওয়া উচিত) ইঞ্জিনিয়ারড।


2
আপ-ফ্রন্টের ব্যবসায়ের সিস্টেম সম্পর্কে এতটা বোঝার প্রয়োজনের জন্য +1। তবে, আপনি কি জানেন যে এখানে চ্যালেঞ্জটি হ'ল সময় এবং সংস্থানসমূহ (ব্যবসায় থেকে) পাশাপাশি পরিবর্তনের কারণগুলি। মাঝারি এবং বড় ব্যবস্থার জন্য, সম্পূর্ণ জটিলতা আপ-ফ্রন্ট বোঝা কখনও কখনও সর্বদা সম্ভব হয় না।
NoChance

2

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

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

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

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


1

আপনি অ-পক্ষপাতদুষ্ট কেস স্টাডিগুলি সন্ধান করতে যাচ্ছেন না যা অ্যাকশন রিপোর্টের পরে অন্য কিছু - বেশিরভাগ লোক একই কাজ কমপক্ষে দু'বার করতে হবে না (একবার পুনর্লিখন হিসাবে, একবার একবার আপগ্রেড হিসাবে, সেরা) কেসটি বিভিন্ন টিমের একাধিক পুনর্লিখন / আপগ্রেড হবে)।

আপনি যে কেস স্টাডিটি দেখেছেন তা ফুজিৎসু প্রযোজনা করেছেন বলে মনে হয়েছে এবং অবাক করার মতো ফলস্বরূপ ফলজিৎসুর সরঞ্জামগুলি ব্যবহার করা ভাল।

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

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

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


1
পুনর্লিখন ব্যর্থতা হতে পারে যখন এটি বাজেটের উপর দিয়ে প্রচুর পরিমাণে চলে এবং সমাপ্তিতে পৌঁছানোর আগে বাতিল হয়ে যায়। ড্রেনের নিচে টাকা। এই ঘটনাটির সম্ভাবনা হ'ল পুনর্লিখনকে রিফ্যাক্টরিংয়ের চেয়ে ঝুঁকিপূর্ণ মনে করা হয়।
MarkJ

@ মারকজে: আমি ভেবেছিলাম যে "কাজ করে না" এর আওতাভুক্ত ছিল তবে আমি এটিকে আরও পরিষ্কার করার জন্য সম্পাদনা করব।
jmoreno
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.