অবনমিত পদ্ধতিটি মোছার আগে আর কতক্ষণ অপেক্ষা করতে হবে? [বন্ধ]


38

আমি একটি সর্বজনীন এপিআই বজায় রাখছি এবং একটি পদ্ধতি অবমূল্যায়ন করতে হবে।

মুছে ফেলার আগে আমার কোনও পদ্ধতি অবমূল্যায়ন করার আগে কত মাস / বছর / সংস্করণ রয়েছে তার কোনও সাধারণ নিয়ম আছে?


27
সাধারণ নিয়মটি হ'ল "যতক্ষণ আপনার এবং / অথবা আপনার গ্রাহকদের এটির প্রয়োজন হয় ততক্ষণ এটিকে ঘিরে রাখুন।"
রবার্ট হার্ভে

15
"পাবলিক" সংজ্ঞা দিন। ফ্রি, ওপেন সোর্স সফ্টওয়্যার, সাধারণ "আপনার নিজের ঝুঁকির সাথে ব্যবহার করুন" অস্বীকার? বা বিক্রয় সফ্টওয়্যার যেখানে একটি চুক্তি বিদ্যমান?
ডক ব্রাউন

11
আপনার ব্যবহারকারীরা কোন বাজারে আসছেন এবং তারা আপনাকে এপিআইয়ের জন্য অর্থ প্রদান করছে কি না তার উপর এটি নির্ভরশীল।
26

10
এটি কেন আপনার অবমূল্যায়ন করতে হবে "তার উপরও নির্ভর করে; পুরানো উপায় কি একটি ঝুঁকি সুরক্ষা? দুর্ভাগ্যজনক ডিজাইনের সিদ্ধান্তের কারণে পুরানো পথটি মৌলিকভাবে এবং অভাবনীয়ভাবে অস্থির হওয়ার কারণ আপনি এখনই খুঁজে পেয়েছেন? পুরানো পথটি এখন আগের চেয়ে অনেক ধীর গতিতে কি? আপনি কি আপনার টার্গেট সিস্টেমে (যেমন, একটি এমবেডেড সিস্টেম) স্মৃতি ছাড়িয়ে চলেছেন এবং আপনি আক্ষরিকভাবে এটিতে উভয় এপিআই ফিট করতে পারবেন না? অথবা আপনি কেবল একটি "আরও ভাল" উপায় খুঁজে পেয়েছেন এবং আপনার রক্ষণাবেক্ষণের ওভারহেড হ্রাস করার জন্য আপনি কেবল পুরাতন কোডটি সাফ করতে চান?
জুন

8
java.io.StringBufferInputStreamজেডিকে ১.১ (১৯৯??) থেকে অবহেলিত। এই প্রশ্নের ভাল বা ভুল উত্তর নেই। এটি আপনার পিছনে সামঞ্জস্যতা সরবরাহের প্রয়োজনীয়তার উপর নির্ভর করে।
লাইভ

উত্তর:


52

সর্বনিম্ন, আপনার মুছে ফেলা পদ্ধতিগুলি মুছে ফেলার আগে একটি সংস্করণে রেখে দেওয়া উচিত যা আমি যখন এটি লিখি তখন এক ধরণের স্পষ্ট বলে মনে হয়। আমি মনে করি না সর্বাধিক সময় রয়েছে তবে আপনি যদি বাস্তবে সেগুলি কখনও না সরিয়ে থাকেন তবে অবমূল্যায়ন কিছুটা অর্থহীন হয়ে যায়।

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


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

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

6
@ সিএইচও আমি বরং কোনও প্রকল্পের তার হ্রাসিত কার্যকারিতা সরিয়ে ফেলতে চাই। কেবলমাত্র ব্যবহারকারীদের সুবিধাটিই স্যুইচ করার জন্য অনুপ্রাণিত হচ্ছে তা নয়, তবে অবহেলিত ইন্টারফেসকে অন্যান্য উন্নতিতে হস্তক্ষেপ থেকে বাধা দেয়।
jpmc26

9
@ সিএইচও এটি একটি প্রসঙ্গে সংবেদনশীল জিনিস। আমার অভিজ্ঞতায় অবজ্ঞার নীতি পরিষ্কার। এটি স্পষ্টভাবে বলেছে যে অবহিত কার্যকারিতা ভবিষ্যতের কোনও সময়ে সরিয়ে দেওয়া হবে। প্রায়শই অবহেলিত কার্যকারিতার ক্ষেত্রে এটি সমস্যার জন্য সমস্যাযুক্ত হয়ে থাকে এবং আপনি পশ্চাদপটে সামঞ্জস্যতাটিকে মূল্য দেন কিনা তা কেবল বিষয় নয়।
জিমি জেমস

6
আমি @ জিমি জেমস এর সাথে একমত হতে চিমিয়ে যাচ্ছি যে অবমূল্যায়ন স্পষ্টতই আসন্ন অপসারণকে বোঝায়। অবচয় সময়কাল অস্থায়ী পিছনের সামঞ্জস্যতা প্রদানের এক উপায় হিসাবে বিদ্যমান যাতে গ্রাহকরা আরও নতুন কার্যকারিতাতে মাইগ্রেট করতে পারেন। অবহেলিত কার্যকারিতা অনির্দিষ্টকালের জন্য থাকবে এমন কোনও প্রত্যাশা থাকা উচিত নয়। যদি পুরানো কার্যকারিতাটি থেকে যায় তবে এটিকে হ্রাস করার কোনও কারণ নেই।
এরিক কিং

17

এটি কেবলমাত্র আপনার ব্যবহারকারীদের কী ধরণের স্থায়িত্বের গ্যারান্টি দেয় এবং আপনার ব্যবহারকারীদের জন্য আপনি কতটা বেদনা দিতে চান তার উপর নির্ভর করে depends

আদর্শভাবে, আপনার এপিআই সেমভার ব্যবহার করে যাতে কোনও ব্রেকিং পরিবর্তনের ফলে মূল সংস্করণ নম্বরটি বাড়ানো যায়। অনুশীলনে, এটি প্রায় কখনওই করা বাঞ্ছনীয়। যদি আপনার এপিআই কিছু প্যাকেজ ম্যানেজারের মাধ্যমে ইনস্টল করা থাকে তবে আপনি ব্রেকিং পরিবর্তনের পরে একটি নতুন প্যাকেজ নাম তৈরি করতে চাইতে পারেন যাতে একটি সাধারণ আপগ্রেড দ্বন্দ্ব সৃষ্টি না করে (যেমন myapi2 v2.123.4বনাম myapi3 v3.2.1)। এটি অপ্রয়োজনীয় হতে পারে যদি আপনার প্যাকেজ পরিচালক কঠোর সংস্করণ নির্ভরতা সমর্থন করে (যেমন একটি নির্ভরতার নির্দিষ্টকরণ যেমন ~v2.120অন্তর্ভুক্ত নয় v3.*) তবে বিভিন্ন প্যাকেজের নামগুলির সুবিধা রয়েছে যে বেমানান সংস্করণগুলি পাশাপাশি খুব সহজে ব্যবহার করা যেতে পারে। এমনকি সেমোভার ব্যবহার করার সময়, অবচয় সময়কাল হওয়াই বুদ্ধিমান হতে পারে।

সেমভার সর্বদা প্রযোজ্য নয়। তারপরে স্পষ্ট স্থিতিশীলতা নীতি যোগাযোগ করা আরও গুরুত্বপূর্ণ। উদাহরণ স্বরূপ:

  • পরীক্ষামূলক বৈশিষ্ট্যগুলি বিজ্ঞপ্তি ছাড়াই সরানো হতে পারে।
  • সুরক্ষা কারণে যে কোনও সময় বৈশিষ্ট্যগুলি মুছে ফেলা হতে পারে।
  • অন্যান্য বৈশিষ্ট্যগুলি কেবল অপসারণ করা হবে
    • … প্রকাশিত সংস্করণে অবমূল্যায়ন করার পরে
    • … যেখানে সেই সংস্করণটি কমপক্ষে তিন মাস পুরানো
    • … এবং প্রধান সংস্করণে একটি দ্বিধা দ্বারা চিহ্নিত করা হবে।

আপনার নিয়মিত প্রকাশ হলে এই জাতীয় নীতিগুলি বিশেষত ভাল কাজ করে যাতে একটি স্পষ্ট অবচয় সময়কাল হয়, যেমন এক বছর।

এপিআইয়ের কোনও অংশকে অবচয় হিসাবে চিহ্নিত করা বাদ দিয়ে আপনার অবচয়কে ব্যাপকভাবে পরিচিত করা উচিত। উদাহরণ স্বরূপ:

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

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


3
এ কারণে Ideally, your API uses semver so that any breaking change causes the major version number to be incremented. In practice, it is desirable to do this almost never.বঞ্চিত: আপনি কখনও নতুন কোনও নতুন সংস্করণ প্রবর্তন করবেন না বলে এই কথাটি অনুসরণ করে যদি ব্রেকিং পরিবর্তনগুলি নির্দেশ করে সেমভার ব্যবহারের কী লাভ?
mrsmn

6
বড় ধরনের পরিবর্তন হলে প্যাকেজটির নতুন নামকরণ করা কি আসলেই ভাল ধারণা? সংস্করণ সংখ্যাগুলি এটাই। আমি ঘৃণা করি যখন তারাও তাদের নাম পরিবর্তন করে, এটি ম্যাভেন নির্ভরতা পরিচালনাকে সত্যিই বিভ্রান্ত করে।
এজেপিরেজ

@ এজেপিরেজ আমি বুঝতে পারি যে এটি আদর্শ নয়, তবে এটি ট্রানসিটিভ নির্ভরশীলতার সাথে বৃহত নির্ভরতা গ্রাফগুলিতে বিরোধগুলি প্রতিরোধ করতে পারে: আমি লাইবফুয়ের উপর নির্ভর করি যা লাইবকনফ্লিক্ট v1.2.3 এর উপর নির্ভর করে, এবং আমি লাইববারের উপরও নির্ভর করি যা লাইবকনফ্লিক্ট v2.3.4 এর উপর নির্ভর করে। তারপরে, আমি কোনও লাইবকনফ্লিক্ট সংস্করণ নির্বাচন করতে পারি না যা সমস্ত নির্ভরতা সন্তুষ্ট করে - যদি না libconflict এবং libconflict2 স্বতন্ত্র প্যাকেজ হয়। বিশেষত জাভার জন্য, এই জাতীয় নামকরণ বিরক্তিকর বি / সি আমাকে সমস্ত আমদানি পরিবর্তন করতে হবে। ভাগ্যক্রমে, জাভা 9 (মডিউল) বিরোধী সংস্করণ ব্যবহার করে সমর্থন করে।
আমন

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

@ এজেপিরেজ হ্যাঁ হ্যা এটি ভাল. লোকেরা সর্বদা সংস্করণটিকে স্ক্রু করে। বাগ ফিক্সগুলি (অনুমিত xxx ++) প্রায়শই ব্রেক হয় (অনুমান করা x ++। Xx)। অ্যামন আপনাকে চিহ্নিত করার সাথে সাথে (এবং আমি বোঝাতে চাইছি আপনি নির্ভরতার ব্যবহারকারী হিসাবে) আপনার সমস্যা সমাধান করতে হবে। আমি জানি আমার কোড foo 3.2.1 এর সাথে কাজ করে, এটি foo 3.3.0 এর সাথে কাজ করতে পারে । আমি জানি যে আমার কোড ফু দিয়ে কাজ করে, এটি ফু -2 দিয়ে কাজ করতে পারে । আমি সেমভার ব্যবহার করি কারণ জনপ্রিয়তা এবং এটি প্রতি হারে ক্ষতি করে না, তবে সত্যিই এটি আমার কাছে স্পষ্ট নয় যে এটি আপনাকে এত বেশি কেনে।
জারেড স্মিথ

14

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

২০১৫ সালে, গুগলের তাদের অ্যান্ড্রয়েড ওএস এ স্টলপোর্টপোর্ট এপিআইয়ের সাথে একই সমস্যা ছিল। তারা এটিকে অবমূল্যায়ন করেছিল এবং এটিকে সরাতে চেয়েছিল, তবে অজস্র অ্যাপ্লিকেশন এটি ব্যবহার করছে। তারা একটি চতুর সমাধান খুঁজে পেয়েছে:

এখানে চিত্র বর্ণনা লিখুন

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

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


5
চতুর। খুব সুন্দর.
ডেভিড হামেন

8

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

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

আমি প্রস্তাব দিচ্ছি যে আপনি অপসারণ থেকে কিছু অর্জন করার সময় অবচিত পদ্ধতিগুলি সরান :

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

কেবলমাত্র এক্স মাস / বছর ধরে অবহেলা করা হয়েছে বা আপনি কোনও নতুন কারণ প্রকাশ করেছেন যেহেতু কোনও উপযুক্ত কারণ ছাড়াই নির্বিচারে সামঞ্জস্যের ক্ষতি করছে to


7

প্রথমে আপনার বিবেচনা করা উচিত যে আপনি অবহেলিত বা অপ্রচলিত চান কিনা।

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

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


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

@ দিমিত্রিগ্রিরিভ: একটি ছোটখাট সংস্করণ অবিলম্বে খুব কাছাকাছি।
জোমরনো

4

উত্তরটি আপনি আপনার গ্রাহকদের কী ধরণের পরিষেবা দিচ্ছেন তার উপর নির্ভর করে।

চূড়ান্ত এক প্রান্তে, উইনস ৩.১ এর যুগ থেকে উইন্ডোজ এইচ-এর ভুল রয়েছে যা দুই দশক ধরে প্রচার করেছিল কারণ মাইক্রোসফ্ট পিছনের সামঞ্জস্যের প্রতি অত্যন্ত দৃ strongly় বিশ্বাস করেছিল।

বর্ণালীটির অন্য প্রান্তে, অনেক ওয়েব-অ্যাপস এমনকি হ্রাসের সতর্কতা না দিয়েও বৈশিষ্ট্যগুলি সরিয়ে দেয়।

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

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


4

আমি একটি সর্বজনীন এপিআই বজায় রাখছি এবং একটি পদ্ধতি অবমূল্যায়ন করতে হবে।

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

  • পুরোনো পদ্ধতিতে কোনো প্রকৃত সমস্যা সৃষ্টি না করে, দয়া এবং করতে ঘুরঘুর, তাহলে এটি হিসাবে ভাল হতে পারে। যদি ভাঙা না থাকে তবে এটি ঠিক করবেন না। আপনার কি সত্যিই এটি অপসারণ করতে হবে? সম্ভবত এটিকে অপ্রচলিত হিসাবে চিহ্নিত করুন এবং ডকুমেন্টেশনে একটি নোট অন্তর্ভুক্ত করুন যাতে অন্য কোনও পদ্ধতি আরও দক্ষ হতে পারে, বা যাই হোক না কেন, তবে এটি সম্ভবত এটি ঠিক রেখে দেওয়া ভাল fine

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

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

(দ্বিতীয় দুটি বুলেট পয়েন্ট অন্যান্য উত্তরে ভালভাবে কভার করা হয়েছে তবে আমি মনে করি প্রথমটি নতুন is


1

একটি সরকারী প্রকল্পের জন্য, কেবল যদি আপনার প্রয়োজন হয় তবেই এটি সরিয়ে দিন ।

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

সংস্থা এবং স্বতন্ত্র প্রোগ্রামাররা কি আপনার প্রকল্পটি ব্যবহার বন্ধ করতে চান? যখন আপনি অপরিহার্য না হন তখন পর্যাপ্ত পরিমাণে তাদের জিনিসগুলি ভাঙ্গুন এবং আপনি কোনও সময়ই সেই নৌকায় থাকবেন।

deprecation != eventual_removal। যদি কোনও এআইপিআই বিপজ্জনক হয় তবে আপনি এটি সরিয়ে ফেলুন। যদি এটি কেবল পুরানো হয় তবে এটি ছেড়ে দিন এবং এর প্রতিস্থাপনটি নথি করুন।

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