কেউ কি অব্যবহৃত কোড মুছে ফেলার (বা রাখার) উপায় সম্পর্কে ব্যাখ্যা করতে পারেন?


102

আমি অনেকবার শুনেছি যে অপ্রয়োজনীয় কোডটি অবশ্যই প্রকল্প থেকে মুছে ফেলা উচিত। তবে এটি "কেন?" আমার পক্ষে পরিষ্কার নয়।

এটি মুছে না দেওয়ার জন্য আমার পয়েন্টগুলি:

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

কেউ কি অব্যবহৃত কোড মুছে ফেলার (বা রাখার) উপায় সম্পর্কে ব্যাখ্যা করতে পারেন?


16
মন্তব্য করা কোড কোনও কোডবেসেও অন্তর্ভুক্ত নয়।
লেপি

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

1
বিটিডব্লিউ, সংস্করণ নিয়ন্ত্রণের বিষয়ে উল্লেখ করা শক্ত হতে পারে, যখন প্রকল্পটি বড় হয় এবং কিছু ফাইলগুলিতে> 200 রিভিশন থাকে
অ্যালেক্স স্ট্যাম্পার

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

1
সফটওয়্যার ইঞ্জিনিয়ারিং একটি খুব অনুরূপ প্রশ্ন আছে
ডেভিডভান্ডেবুন্টে

উত্তর:


180

অব্যবহৃত কোড অপসারণের কয়েকটি কারণ এখানে রয়েছে:

  • যে কোনও প্রকল্পে নতুন কাজ করছেন, তাদের কেবল কাজের কোডটি বুঝতে হবে না, অব্যবহৃত উপাদানও তাদের বুঝতে হবে। এটি সময় নষ্ট এবং বিভ্রান্তি সৃষ্টি করে।

  • এমন একটি আশঙ্কা রয়েছে যে কোনও সময় কোনও ব্যক্তি এমন পরিবর্তন আনতে পারে যা অজান্তে 'সুপ্ত' কোড জড়িত থাকে এবং বাগগুলি প্রবর্তন করতে পারে। আমি জানি যে আমি কাজ করেছি এমন প্রকল্পগুলিতে এটি ঘটেছে।

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

  • সময়ের সাথে কী ঘটে তা হ'ল কোডবেজে আরও বেশি বেশি পুরানো অব্যবহৃত কোড যুক্ত করা হয়। এটি বিভ্রান্তি, সম্ভাব্য ভুল বোঝাবুঝি এবং প্রশাসনিক ওভারহেড বাড়িয়ে তোলে।

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

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


26
অব্যবহৃত কোড দেখার কারণে (এবং এটি অব্যবহৃত হয়েছে তা বুঝতে না পেরে) আমার কাছ থেকে জীবিত ছদ্মবেশটি ভয় পেয়েছিল। অব্যবহৃত কোডটি অস্তিত্ব থেকে শেষ করা উচিত!
লেপি

1
ভাল পয়েন্ট, আপনাকে ধন্যবাদ। আমার সহকর্মীরা তাদের বেশিরভাগেরও জানিয়েছেন
অ্যালেক্স স্ট্যাম্পার

দুর্দান্ত উত্তর। আমি আমার মাস্টার থিসিসে এ জাতীয় যুক্তিগুলি উল্লেখ করতে চাই, তবে উপযুক্ত উত্স (বই, কাগজ, ইত্যাদি) খুঁজে পেতে পারে না। আপনার কি কোনও সীসা আছে?
জোনাস উইঙ্কলার

3
আমি এখনই নিচের ভোটের জন্য আপনার কারণগুলিতে খুব আগ্রহী হব।
সন্দেহভাজন

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

31

@ সুস্পেক্টাস কোড মোছার কারণগুলি উপস্থাপনের জন্য দুর্দান্ত কাজ করেছে; কোড রাখার জন্য আমি আপনার পৃথক বুলেটগুলিকে সম্বোধন করতে চাই।

  • কোড ইতিমধ্যে লিখিত, এবং প্রচেষ্টা ব্যয় করা হয়

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

  • কোড সিন্টেটিক এবং আসল পরিবেশে পরীক্ষা করা যেতে পারে

আমি দুঃখিত, আপনি এর দ্বারা কী বোঝাতে চেয়েছেন তা আমি জানি না।

  • যদি সুসংগঠিত হয় (গোষ্ঠীযুক্ত, পৃথক প্যাকেজ, আলগাভাবে মিলিত ইত্যাদি) এটি সামগ্রিক কোড বিশ্লেষণ বা রিফ্যাক্টরিংয়ের ক্ষেত্রে আপনাকে বিরক্ত করে না

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

  • কোড ভবিষ্যতে ব্যবহার করা যেতে পারে

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

  • মুছে ফেলা হলে, লেখক অস্বস্তি বোধ করতে পারেন

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


17

কিছু কোড বাছাই করা এবং উদ্দেশ্যটি বের করা কি যথেষ্ট কঠিন নয় তবে এখন আপনাকে কোন অংশটি ব্যবহার করা হচ্ছে না তা খুঁজে বের করতে হবে?


14

কোড ইতিমধ্যে লিখিত, এবং প্রচেষ্টা ব্যয় করা হয়

এটিও অপ্রয়োজনীয়। আপনি যদি এটি কোনও কিছুর জন্য ব্যবহার না করেন তবে এটি (সংজ্ঞা অনুসারে) বেহুদা তা বিবেচনা করে না।

কোড সিন্টেটিক এবং আসল পরিবেশে পরীক্ষা করা যেতে পারে

যদি এটি অকেজো হয় তবে এটির পরীক্ষা করা হলেও এটি এখনও অকেজো। কোডটি যদি অকেজো হয় তবে এর জন্য পরীক্ষাগুলিও অকেজো হওয়া উচিত (সুতরাং সেখানে মন্তব্য কোড রাখা, অস্পষ্টতা তৈরি করে - আপনি কি পরীক্ষাগুলি রাখেন? যদি আপনার মন্তব্য করা কোডের ক্লায়েন্ট কোড থাকে, আপনি কি ক্লায়েন্ট কোডটিও মন্তব্য করবেন? )

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

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

কোড না থাকলে সুসংগঠিত হয় তবে এটি স্থির বিশ্লেষণ, রিফ্যাক্টরিং এবং অন্য যে কোনও বিষয়কে বিশৃঙ্খলা করবে।

আপনি আপনার সরঞ্জামগুলির ইনপুটটিতে শব্দ প্রবর্তন করছেন এবং আশা করছেন তারা এটির সাথে সঠিকভাবে মোকাবেলা করছেন।

যদি আপনার স্থিতিশীল বিশ্লেষণ সরঞ্জাম কোনও মন্তব্য / কোড অনুপাত গণনা করে? গতকাল পর্যন্ত (বা যখনই কোড মন্তব্য করা হয়েছিল) প্রাসঙ্গিক এমন কিছু দিয়ে আপনি সবেমাত্র এটিকে গোলমাল করেছিলেন।

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

কোড ভবিষ্যতে ব্যবহার করা যেতে পারে

যদি তা হয় তবে আপনি এটি আপনার পছন্দের এসসিএমে খুঁজে পাবেন।

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

মুছে ফেলা হলে, লেখক অস্বস্তি বোধ করতে পারেন

তাই?

আপনি (আমি ধরে নিচ্ছি) বিকাশকারীদের একটি সম্পূর্ণ দল যা আপনাকে জানবে যে সেরা সফ্টওয়্যার তৈরি করার জন্য অর্থ প্রদান করা হয়, "এক্স এর অনুভূতিতে আঘাত না দিয়ে কীভাবে আপনি জানেন সেরা সফ্টওয়্যার" নয়।

এটি প্রোগ্রামিংয়ের একটি অংশ, বেশিরভাগ লিখিত কোড চূড়ান্তভাবে বাতিল করা হবে; উদাহরণস্বরূপ, জোয়েল স্পলস্কি এক পর্যায়ে বলেছিলেন যে তাঁর সংস্থার জন্য, প্রায় 2% লিখিত কোড উত্পাদন দেখে।

যদি আপনি কোড বেসের মানের তুলনায় বিকাশকারীদের অহংকে অগ্রাধিকার দেন তবে আপনি আপনার পণ্যের মানটি উত্সর্গ করবেন, ঠিক কী জন্য? আপনার সহযোগী বিকাশকারীদের অপরিপক্কতা সংরক্ষণ? আপনার সহকর্মীদের অবাস্তব প্রত্যাশা রক্ষা?

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

// note by <author>: the X parameter here should normally
// be a reference:
// void teleport(dinosaur& X);
// but that would require that we raise another dinosaur and
// kill it every twelve hours
// as such, the parameter is passed by value
void teleport(dinosaur X);

10

ডেড কোডটি আপনার কোডকে দূষিত করছে

ডেড কোড বোধগম্যতা এবং পঠনযোগ্যতা হ্রাস করে।

সেরা কোডগুলি সর্বদা পুনরায় ব্যবহার করা হয় এবং আপনার যদি ডেড কোড থাকে তবে এটি পুনরায় ব্যবহারযোগ্যতা হ্রাস করে

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

মৃত বা মন্তব্য করা কোডটি মিথ্যা ট্রেইল চিহ্নের মতো যা কেবল মানুষকে বিভ্রান্ত করে, তাই এটিকে যেকোন মূল্যে এড়িয়ে চলুন।


10
  • ভয় । এটি দলকে আরও চিন্তিত করে এবং কম উত্পাদন করে। আরও ডেড কোড চালু করা হলে ভয়ের পরিমাণ তীব্রতর হয়। "আমরা জানি না যে এই বিটটি ব্যবহার করা হয়েছে কিনা, তাই আমরা এটিকে সরাতে বা স্পর্শ করার সাহস পাই না don't"
  • সুইপিং পরিবর্তন । সিস্টেমে সর্বত্র যে কোনও কিছুর পরিবর্তন করা দরকার তা যদি ডেড কোডেও থাকে তবে আপনি কি তা পরিবর্তন করেন? এটি অবশ্যই কোথাও ব্যবহার করা হয়নি কিনা তা জানা খুব শক্ত, তাই এটি সর্বদা ঝুঁকিপূর্ণ। এমনকি যদি এটি কিছু নাও ভাঙে, ডেড কোডটি কি আদৌ কাজ করবে যদি এই পরিবর্তনের পরে এটি আবার ব্যবহারের জন্য নেওয়া হয়?

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

  • মানসিক বোঝা । যখনই আপনি কিছু ব্যবহার করা হচ্ছে কিনা বা ডেড কোডটিতে আপনার কিছু করা উচিত কিনা তা চিন্তা করার দরকার পড়লে এটি আপনার মস্তিষ্কের শক্তি নিয়ে যায়।
  • বুনো হংস তাড়া করে । "ফুবার কীভাবে ব্যবহার করতে হয় সে সম্পর্কে আমার একটি উদাহরণ দরকার Oh ওহ, কোডবেজে এই জায়গাগুলি রয়েছে I'll আমি প্রথম হিটটি পরীক্ষা করব এবং এটি ইউআইতে কোথায় আছে তা আবিষ্কার করব H হুম ... কোথাও এটি খুঁজে পাচ্ছি না।"
  • স্ফীত প্রতিবেদনগুলি (উদাহরণস্বরূপ কোডের কতগুলি লাইন, শ্রেণি, রুটিন, পরিবর্তন)। প্রকল্পের দৃশ্যমানতা এবং কোডবেসের কোন অংশগুলিতে কাজ করা উচিত এবং ভবিষ্যতের প্রকল্পগুলির অনুমানের বিষয়ে সিদ্ধান্তগুলি বিকৃত করে।
  • কোডবেসে বিশ্বাসের দুর্বলতা । এটি অনর্থক কাজে বেশি সময় ব্যয় করতে পারে এবং এটি কোডবেস ব্যবহারের প্রবাহকে ভেঙে দেয়। বিকাশকারীদের তাদের চূড়ান্ত যত্ন সহকারে যাচাই করতে হবে যে তারা যা ব্যবহার করে তা তাদের যেভাবে ভাবায় সেভাবে কাজ করবে।

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

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


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

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

আপনার পয়েন্টের জবাবে ...

  • কোড ইতিমধ্যে লিখিত, এবং প্রচেষ্টা ব্যয় করা হয়

তবে এটি প্রায়শই বজায় রাখতে হবে। এটি ফাইলগুলিতে সন্ধানের মতো জিনিসগুলিতে এখনও প্রদর্শিত হবে।

  • কোড সিন্টেটিক এবং আসল পরিবেশে পরীক্ষা করা যেতে পারে

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

  • যদি সুসংগঠিত হয় (গোষ্ঠীযুক্ত, পৃথক প্যাকেজ, আলগাভাবে মিলিত ইত্যাদি) এটি সামগ্রিক কোড বিশ্লেষণ বা রিফ্যাক্টরিংয়ের ক্ষেত্রে আপনাকে বিরক্ত করে না

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

  • কোড ভবিষ্যতে ব্যবহার করা যেতে পারে

মূল্য লিখিত কোডের বেশি লোক। যদি এটি এখন ব্যবহার না করা হয় তবে এটি ডেডওয়েট এবং বাস্তবে আপনি যখন এই পথে নামেন তখন প্রায়শই অব্যবহৃত কোডের একটি ভগ্নাংশ ব্যবহৃত কোড হয়ে যায়। সমস্ত সম্ভাবনায় অব্যবহৃত কোড সম্ভবত ব্যবহারযোগ্য বা ব্যবহৃত কোড হবে না। কোডটির পুনঃব্যবহারের সর্বাধিক সম্ভাব্য কোডটি ইতিমধ্যে কিছু করছে যা কিছু করছে doing

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

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

  • মুছে ফেলা হলে, লেখক অস্বস্তি বোধ করতে পারেন

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

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


3

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


3

এই আলোচনাটি কয়েক বছরের পুরনো, তবে আমি কেবল এটির মধ্যে দৌড়েছি ...

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


2

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


2

আপনি কি নিশ্চিত যে কোডটি অব্যবহৃত হয়েছে?

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

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

আগ্রাসীভাবে অব্যবহৃত কোডটি সরিয়ে দিন

আপনি কোড বজায় রাখার জন্য অর্থ প্রদান করুন:

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

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

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