পাঠযোগ্য কোডের সাথে অপ্টিমাইজড কোডটি প্রতিস্থাপন করা ঠিক আছে কি?

Question

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

এটি আধুনিক কোড দিয়ে প্রতিস্থাপন করা ভাল ধারণা?

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

কম্পাইলার ভাল ভালো জিনিস তাই পাশাপাশি পেয়ে হবে, মনে struct abc = {}চুপটি মধ্যে প্রমাণিত হয় memsetএস, shared_ptrগুলি কাছাকাছি একই কোড কাঁচা পয়েন্টার twiddling যেমন, টেমপ্লেট সুপার ভাল কাজ করছে, কারণ তারা সুপার চর্বিহীন কোড উত্পাদন, ইত্যাদি উৎপাদন করছে।

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

আপনি যদি কোনওভাবেই এর কোনও ছোট্ট অংশটি স্পর্শ করতে চান তবে কি এই জাতীয় কোডটি পরিবর্তন করা ভাল ধারণা?

Comments

পাঠযোগ্যতা এবং অপ্টিমাইজেশনের বেশিরভাগ সময় বিরোধিতা করা হয় না।

— ডেডালনিক্স

কিছু মন্তব্য দিয়ে পাঠযোগ্যতা উন্নতি করতে পারেন?

— তথাপি অন্য ইউজার

এটি উদ্বেগজনক যে ওওপি-ইফিশনটিকে 'আধুনিক কোড' হিসাবে বিবেচনা করা হয়

— জেমস

স্ল্যাকওয়্যার দর্শনের মতো: এটি যদি না ভাঙা হয় তবে এটি ঠিক করবেন না, কমপক্ষে আপনার এটি করার খুব যুক্তিসঙ্গত কারণ আছে

— ওসাদমভ

অপ্টিমাইজড কোড দ্বারা, আপনি কি আসল অপ্টিমাইজড কোড বা তথাকথিত অপ্টিমাইজড কোডটি বোঝাচ্ছেন ?

— dan04

Answer 1

কোথায়?

• গুগল-স্কেল ওয়েবসাইটের হোম পেজে এটি গ্রহণযোগ্য নয়। জিনিসগুলি যত তাড়াতাড়ি সম্ভব রাখুন।

• কোনও আবেদনের অংশে যা একবারে একবারে একজন ব্যক্তি ব্যবহার করেন, কোড পাঠযোগ্যতা অর্জনের জন্য পারফরম্যান্স ত্যাগ করতে এটি পুরোপুরি গ্রহণযোগ্য।

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

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

Comments

+1 টি! আপনার যদি নম্বর না থাকে তবে কিছু নম্বর পান। আপনার কাছে নম্বর পাওয়ার সময় না থাকলে এটি পরিবর্তন করার আপনার কাছে সময় নেই।

— ট্যাক্রয়

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

— স্টিভেন বার্নাপ

অন্য উত্তর যুক্ত করার পরিবর্তে, আমি এই উত্তরটি +1 করতাম। কোড টুকরা বুঝতে যদি গুরুত্বপূর্ণ হয়, তাদের ভাল মন্তব্য করুন। আমি কয়েক দশক অবদানকারী সহ এক দশক পুরানো লিগ্যাসি কোড সহ সি / সি ++ / অ্যাসেম্বলির পরিবেশে কাজ করেছি। কোডটি যদি কাজ করে তবে এটিকে একা রেখে কাজে ফিরে যান।

— ক্রিস কে

সে কারণেই আমি কেবল পঠনযোগ্য কোড লেখার প্রবণতা রাখি। কয়েকটি হট স্পট কাটতে পারফরম্যান্সে পৌঁছানো যায়।

— লুকা

Answer 2

সাধারণত, না ।

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

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

অবশ্যই, প্রোফাইল, প্রোফাইল, প্রোফাইল , বিশেষত যদি এটি একটি সমালোচনামূলক পথের অঞ্চল।

Comments

হ্যাঁ, তবে আপনি ধরে নিই যে অপ্টিমাইজেশনটি প্রয়োজন ছিল। আমরা সবসময় জানি না এটি ছিল কিনা এবং আমরা সম্ভবত এটি নির্ধারণ করতে চাই।

— হাইলেম

@ হাইলেম: না, আমি ধরে নিই যে কোডটি ঠিক তেমন কাজ করে । আমি এটাও ধরে নিয়েছি যে কোডটি রিফ্যাক্টর করার ফলে সিস্টেমের অন্য কোথাও কোনও সমস্যা হবে না (যদি না আপনি যদি কোনও বাহ্যিক নির্ভরতা না করে এমন কোডের একটি তুচ্ছ বিষয় নিয়ে কাজ না করেন)।

— ডেমিয়ান ব্রেচট

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

— রওয়ং

Answer 3

সংক্ষেপে: এটি নির্ভর করে

• আপনি কি আপনার রিফ্যাক্টরড / বর্ধিত সংস্করণটি সত্যই প্রয়োজন বা ব্যবহার করতে যাচ্ছেন?

  • তাত্ক্ষণিক বা দীর্ঘমেয়াদী কোন কংক্রিট লাভ আছে?
  • এই লাভটি কি কেবল রক্ষণাবেক্ষণের জন্য, না সত্যই স্থাপত্যের জন্য?

• এটি কি সত্যিকারের অনুকূলিত হওয়া দরকার?

  • কেন?
  • কোন লক্ষ্য অর্জনের জন্য আপনার প্রয়োজন?

---

বিস্তারিত

আপনি কি পরিষ্কার, চকচকে জিনিস প্রয়োজন?

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

আরও নির্দিষ্টভাবে, এটি জানুন:

ওভার ইঞ্জিনিয়ারিংয়ের মতো জিনিস রয়েছে

এটি একটি বিরোধী-নিদর্শন, এবং এটি অন্তর্নির্মিত সমস্যাগুলির সাথে আসে:

• এটি আরও বর্ধনযোগ্য হতে পারে তবে প্রসারিত করা সহজ নয় ,
• এটি বুঝতে সহজ হতে পারে না ,
• শেষ, তবে অবশ্যই এখানে নয়: আপনি পুরো কোডটি ধীর করতে পারেন।

কেউ কেউ KISS নীতিটিকে রেফারেন্স হিসাবে উল্লেখও করতে পারে , তবে এখানে এটি পাল্টা স্বজ্ঞাত: অনুকূলিত উপায়টি কি সহজ উপায় বা ক্লিন আর্কিটেকচারিং উপায়? উত্তরটি নিখুঁতভাবে নিখুঁত নয়, যেমন নীচের বাকীটিতে ব্যাখ্যা করা হয়েছে।

তোমার দরকার নেই

YAGNI নীতি অন্যান্য সমস্যার সাথে সম্পূর্ণরূপে লম্ব নয়, কিন্তু এটি নিজে প্রশ্ন জিজ্ঞাসা করতে সাহায্য করে: আপনি এটি প্রয়োজন করতে যাচ্ছি?

আরও জটিল আর্কিটেকচারটি কি আরও রক্ষণাবেক্ষণের চেহারার পরিবর্তে সত্যই আপনার জন্য উপকার উপস্থাপন করে?

যদি এটি ভেঙে না যায় তবে এটি ঠিক করবেন না

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

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

• আসলে,
• আসলে করা দরকার,
• শেষ পর্যন্ত করার প্রয়োজন হবে,
• এবং এটি কত ভাল করে।

এটি কি সত্যিকারের অনুকূলিত হওয়া দরকার?

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

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

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

পরিমাপ, পরিমাপ, পরিমাপ

গুগল এখন যেমন ভাবেন, এগুলি সবই ডেটা সম্পর্কে! আপনি যদি ডেটা দিয়ে এটি ব্যাক আপ করতে পারেন, তবে এটি প্রয়োজনীয়।

এই না, তাই পুরাতন কাহিনী যে প্রতি $ 1 উন্নয়নে ব্যয় জন্য এটি দ্বারা অনুসরণ করা হবে অন্তত পরীক্ষার মধ্যে $ 1 এবং অন্তত সমর্থনে $ 1 (কিন্তু সত্যিই, এটা একটা অনেক কিছু)।

পরিবর্তনগুলি অনেক কিছুই প্রভাবিত করে:

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

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

এবং আপনার পরিচালক হিসাবে, এর অর্থ এটি বর্তমান বিকাশ পরিকল্পনায় ফিট করে, তাই এটি সম্পর্কে কথা বলুন এবং উগ্র গরু-বালক / সাবমেরিন / ব্ল্যাক-ওপ্স কোডিংয়ে প্রবেশ করবেন না।

---

সাধারণভাবে ...

হ্যাঁ কিন্তু...

আমাকে ভুল করবেন না, সাধারণভাবে, আমি আপনাকে পরামর্শ দিই কেন তাই করার পক্ষে হয়ে থাকি এবং আমি প্রায়শই এটির পক্ষে পরামর্শ করি। তবে আপনাকে দীর্ঘমেয়াদী ব্যয় সম্পর্কে সচেতন হওয়া দরকার।

নিখুঁত বিশ্বে এটি সঠিক সমাধান:

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

প্রস্তুতিতে:

• আপনি এটি আরও খারাপ করতে পারে

  এটি দেখার জন্য আপনার আরও চোখের বলের প্রয়োজন এবং যত বেশি আপনি এটিকে জটিল করবেন আপনার তত বেশি চোখের বলটি দরকার।

• আপনি ভবিষ্যতের ভবিষ্যদ্বাণী করতে পারবেন না

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

• এটি পরিচালনার দৃষ্টিকোণ থেকে, সরাসরি লাভের জন্য একটি বিশাল ব্যয় উপস্থাপন করে।

এটি প্রক্রিয়া অংশ করুন

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

আপনার যদি এই জাতীয় সিদ্ধান্তগুলি পরিচালনা করার প্রক্রিয়া থাকে তবে আপনি সেগুলি থেকে ব্যক্তিগত প্রান্তটি সরিয়ে ফেলুন:

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

পরীক্ষা কভারেজ, প্রোফাইলিং এবং ডেটা-সংগ্রহ জটিল rick

তবে অবশ্যই আপনার টেস্টিং কোড এবং মেট্রিকগুলি একই সমস্যা থেকে ভুগতে পারে যা আপনি আপনার আসল কোডটির জন্য এড়াতে চাইছেন: আপনি কি সঠিক জিনিসগুলি পরীক্ষা করেন এবং সেগুলি কি ভবিষ্যতের জন্য সঠিক জিনিস এবং আপনি কি সঠিকটি পরিমাপ করেন? কথা বলছ? '

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

কোড পর্যালোচনাগুলি হ'ল ডেভলপমেন্ট টিমের হলওয়ে পরীক্ষা

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

বন্ধ শব্দ হিসাবে, মনে রাখবেন:

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

Comments

"যদি এটি ভেঙে না যায় তবে এটি ঠিক করবেন না" রিফ্যাক্টরিংয়ের বিরুদ্ধে। কিছু কাজ করে না তা বিবেচনা করে না, যদি চিন্তাভাবনা না করে তবে পরিবর্তন করা দরকার।

— মিয়ামোটো আকিরা

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

— হাইলেম

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

— মিয়ামোটো আকিরা

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

— হাইলেম

Answer 4

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

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

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

একবারে কোডের কেবল একটি অংশ পরিবর্তন করুন এবং দেখুন প্রতিটি রাউন্ড রিফ্যাক্টরিংয়ের পরে এটি কার্য সম্পাদনকে কীভাবে প্রভাবিত করে।

Answer 5

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

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

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

অপ্টিমাইজেশনটি যদি পুরানো হয় তবে নতুন পদ্ধতিগুলি আরও তত দ্রুত এবং আরও পঠনযোগ্যও হতে পারে।

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

Answer 6

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

উপযুক্ত টেস্টগুলির সাথেও কোডটি একই আচরণ করে তা নিশ্চিত করুন

Answer 7

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

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

Answer 8

মূলত, আপনি জিজ্ঞাসা করছেন যে রিফ্যাক্টরিং একটি উপযুক্ত উদ্যোগ। এর উত্তর অবশ্যই হ্যাঁ।

কিন্তু ...

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

মার্টিন ফওলার এ নিয়ে বইটি লিখেছিলেন ।

Answer 9

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

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

Answer 10

যদি এটি কেবল একটি সংক্ষিপ্ত অংশের কোড যা হার্ড-টু-বোধগম্য উপায়ে তুলনামূলক সহজ কিছু করে, আমি একটি বর্ধিত মন্তব্যে এবং / অথবা অব্যবহৃত বিকল্প বাস্তবায়নে "দ্রুত বোঝাপড়া" স্থানান্তরিত করব, যেমন

#ifdef READABLE_ALT_IMPLEMENTATION

   double x=0;
   for(double n: summands)
     x += n;
   return x;

#else

   auto subsum = [&](int lb, int rb){
          double x=0;
          while(lb<rb)
            x += summands[lb++];
          return x;
        };
   double x_fin=0;
   for(double nsm: par_eval( subsum
                           , partitions(n_threads, 0, summands.size()) ) )
     x_fin += nsm;
   return x_fin;

#endif

Answer 11

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

1. কর্মক্ষমতা পরীক্ষা এবং সমর্থনমূলক প্রোফাইল তথ্য সন্ধান করুন। যদি কোনও পারফরম্যান্স পরীক্ষা না হয় তবে প্রমাণ ছাড়া যা বলা যায় তা প্রমাণ ছাড়াই খারিজ করা যায়। আপনার আধুনিক কোডটি দ্রুত এবং পুরানো কোডটি সরিয়ে ফেলুন। যদি কেউ তর্ক করে (এমনকি নিজেও) তাদের কাছে কোনটি দ্রুত তা প্রমাণ করার জন্য প্রোফাইলিং কোডটি লিখতে বলে ask
2. যদি প্রোফাইলিং কোড বিদ্যমান থাকে তবে যাইহোক আধুনিক কোডটি লিখুন। এর মতো কিছু নাম দিন <function>_clean()। তারপরে, আপনার কোডটি খারাপ কোডের বিরুদ্ধে "রেস" করুন। যদি আপনার কোডটি আরও ভাল হয় তবে পুরানো কোডটি সরিয়ে দিন।
3. যদি পুরানো কোডটি দ্রুত হয় তবে আপনার আধুনিক কোডটিকে যাইহোক সেখানে রেখে দিন। এটি অন্যান্য কোডটি কী বোঝাতে চেয়েছিল তার জন্য এটি খুব ভাল ডকুমেন্টেশন হিসাবে কাজ করে এবং "রেস" কোডটি যেহেতু আপনি দুটি পাথের মধ্যে পারফরম্যান্স বৈশিষ্ট্য এবং পার্থক্য ডকুমেন্ট করার জন্য এটি চালিয়ে যেতে পারেন can কোড আচরণের পার্থক্যের জন্য আপনি পরীক্ষা ইউনিটও করতে পারেন। গুরুত্বপূর্ণভাবে, আধুনিক কোড একদিন "অপ্টিমাইজড" কোডটি গ্যারান্টিযুক্ত করে ফেলবে। তারপরে আপনি বাজে কোডটি মুছে ফেলতে পারেন।

Qed।

Answer 12

আমি যদি আমার মৃত্যুর আগে বিশ্বকে একটি জিনিস (সফ্টওয়্যার সম্পর্কে) শেখাতে পারি, তবে আমি এটি শিখিয়েছি যে "পারফরম্যান্স বনাম এক্স" একটি মিথ্যা দ্বিধা।

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

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

এইভাবে বগিযুক্ত, আপনি যেমন চান তেমন এই পদ্ধতির প্রয়োগ পরিবর্তন করতে পারবেন। প্রকৃতপক্ষে, সম্ভবত এটি আমি শুরু করার জন্য পাগল সংস্করণটি লিখেছিলাম। আপনি চেষ্টা করতে স্বাগত, বা কমপক্ষে বিকল্প সম্পর্কে জিজ্ঞাসা করুন। বেশিরভাগ সময় আপনি খুঁজে পাবেন যে নিষ্পাপ বাস্তবায়নটি লক্ষণীয়ভাবে খারাপ হয় (সাধারণত আমি কেবল 2-10x উন্নতির জন্য বিরক্ত করি), তবে সংকলক এবং গ্রন্থাগারগুলি সর্বদা পরিবর্তিত হয় এবং আপনি কি জানেন যে আজ আপনি কী খুঁজে পেতে পারেন যা উপলভ্য ছিল না যখন ফাংশনটি কি লেখা ছিল?

Comments

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

— সুপারক্যাট

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

— সুপারক্যাট

Answer 13

এটি স্পর্শ করা সম্ভবত কোনও ভাল ধারণা নয় - পারফরম্যান্সের কারণে কোডটি যদি সেভাবে লেখা হয় তবে এর অর্থ এটি পরিবর্তন করা পারফরম্যান্সের সমস্যাগুলি ফিরিয়ে আনতে পারে যা আগে সমাধান করা হয়েছিল।

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

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

Comments

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

— ডেভ ই

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

— হতাশ

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

— ডেভ

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

— জ্যান লিংস

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

— ডেভ

Answer 14

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

এবং "দুর্বল," অপঠনযোগ্য কোড সর্বদা অনুকূলিত হয় না।

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

Answer 15

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

অতএব, কোডটি অনুকূলিত করা হবে + যথাযথ মন্তব্য করা এটিকে পাঠযোগ্যও করে তুলবে।

দ্রষ্টব্য: আপনি যথাযথ মন্তব্যের সাহায্যে একটি অনুকূলিত কোডটি পঠনযোগ্য করতে পারেন তবে আপনি পঠনযোগ্য কোডকে অনুকূলিতকরণ করতে পারবেন না।

Comments

আমি এই পদ্ধতির থেকে ক্লান্ত হয়ে পড়ব কারণ মন্তব্যটি সিঙ্কে রাখতে ভুলবেন না এমন একজন ব্যক্তি কোড সম্পাদনা করে। হঠাৎ করে পরবর্তী প্রতিটি পর্যালোচনা আসলে ওয়াই করার সময় এটি এক্স সম্পাদন করে ভেবে চলে যাবে

— জন ডি

Answer 16

সাধারণ কোড এবং অপ্টিমাইজড কোডের মধ্যে পার্থক্যটি দেখতে এখানে একটি উদাহরণ রয়েছে: https://stackoverflow.com/a/11227902/1396264

উত্তরের শেষে তিনি কেবল প্রতিস্থাপন করেছেন:

if (data[c] >= 128)
    sum += data[c];

সঙ্গে:

int t = (data[c] - 128) >> 31;
sum += ~t & data[c];

ন্যায্য বলতে আমার এই ধারণাটি কী প্রতিস্থাপনের সাথে প্রতিস্থাপন করা হয়েছে তা সম্পর্কে কোনও ধারণা নেই তবে উত্তরদাতা যেমনটি বলেছিলেন যে এটি কিছুটা বিপরীত ক্রিয়াকলাপ একই ফল দিচ্ছে (আমি কেবল তার কথাটি গ্রহণ করছি) ।

এটি মূল সময়ের এক চতুর্থাংশেরও কম সময়ে কার্যকর করে (১১.৫৪ সেকস বনাম 2.5 সেকস)

Answer 17

এখানে মূল প্রশ্নটি হল: অপটিমাইজেশনটি প্রয়োজনীয়?

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

কোডটি যদি অপ্টিমাইজ করতে না হয় তবে তা (পঠনযোগ্যতাকে প্রভাবিত করার দিকের) হওয়া উচিত নয় এবং আপনি এটিকে আরও পঠনযোগ্য করার জন্য এটি পুনরায় ফ্যাক্টর করতে পারেন।

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

Answer 18

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

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

Answer 19

আইএমএইচও-র পাঠযোগ্যতা অপ্টিমাইজড কোডের চেয়ে বেশি গুরুত্বপূর্ণ কারণ বেশিরভাগ ক্ষেত্রে মাইক্রো-অপ্টিমাইজেশনের পক্ষে এটির মূল্য হয় না।

জ্ঞানহীন অণু-অপ্টিমাইজেশান সম্পর্কিত নিবন্ধ :

আমাদের বেশিরভাগ হিসাবে, আমি ইকো দ্বারা মুদ্রণ প্রতিস্থাপন, ++ $ i দ্বারা $ i ++, বা একক উদ্ধৃতি দ্বারা ডাবল উদ্ধৃতি যেমন অজ্ঞান মাইক্রো-অপ্টিমাইজেশন সম্পর্কে ব্লগ পোস্ট পড়তে ক্লান্ত হয়ে পড়েছি। কেন? কারণ 99.999999% সময় এটি অপ্রাসঙ্গিক।

"প্রিন্ট" "ইকো" এর চেয়ে আরও একটি অপকোড ব্যবহার করে কারণ এটি আসলে কিছু দেয়। আমরা সিদ্ধান্তে পৌঁছাতে পারি যে প্রতিধ্বনি প্রিন্টের চেয়ে দ্রুত faster তবে একটি অপকোডের জন্য কিছুই হয় না, আসলে কিছুই হয় না।

আমি একটি নতুন ওয়ার্ডপ্রেস ইনস্টলেশন চেষ্টা করেছি। আমার ল্যাপটপে একটি "বাস ত্রুটি" শেষ হওয়ার আগে স্ক্রিপ্টটি থেমে গেছে, তবে ইতিমধ্যে অপকডের সংখ্যা ছিল ২.৩ মিলিয়নেরও বেশি। যথেষ্ট বলেছ.

Answer 20

অপটিমাইজেশন আপেক্ষিক is উদাহরণ স্বরূপ:

বিওওএল সদস্যদের একগুচ্ছ সহ একটি শ্রেণি বিবেচনা করুন:

// no nitpicking over BOOL vs bool allowed
class Pear {
 ...
 BOOL m_peeled;
 BOOL m_sliced;
 BOOL m_pitted;
 BOOL m_rotten;
 ...
};

আপনি BOOL ক্ষেত্রগুলিকে বিটফিল্ডে রূপান্তর করতে প্ররোচিত হতে পারেন:

class Pear {
 ...
 BOOL m_peeled:1;
 BOOL m_sliced:1;
 BOOL m_pitted:1;
 BOOL m_rotten:1;
 ...
};

যেহেতু একটি বিওএল INT (যা উইন্ডোজ প্ল্যাটফর্মে স্বাক্ষরিত 32-বিট পূর্ণসংখ্যার) হিসাবে টাইপডেফড হয়, তাই এটি ষোলটি বাইট নেয় এবং সেগুলিকে একটিতে প্যাক করে। এটি একটি 93% সঞ্চয়! কে এই সম্পর্কে অভিযোগ করতে পারে?

এই অনুমান:

যেহেতু একটি বিওএল INT (যা উইন্ডোজ প্ল্যাটফর্মে স্বাক্ষরিত 32-বিট পূর্ণসংখ্যার) হিসাবে টাইপডেফড হয়, তাই এটি ষোলটি বাইট নেয় এবং সেগুলিকে একটিতে প্যাক করে। এটি একটি 93% সঞ্চয়! কে এই সম্পর্কে অভিযোগ করতে পারে?

দিকে:

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

যেটা আগে থাকত

 push [ebx+01Ch]      ; m_sliced
 call _Something@4    ; Something(m_sliced);

হয়ে

 mov  ecx, [ebx+01Ch] ; load bitfield value
 shl  ecx, 30         ; put bit at top
 sar  ecx, 31         ; move down and sign extend
 push ecx
 call _Something@4    ; Something(m_sliced);

বিটফিল্ড সংস্করণটি নয়টি বাইট দ্বারা বড়।

আসুন বসে কিছু গাণিতিক করি। মনে করুন এই বিটফিল্ড ক্ষেত্রগুলির প্রত্যেকটি আপনার কোডে ছয়বার, লেখার জন্য তিনবার এবং পড়ার জন্য তিনবার অ্যাক্সেস করেছে। কোড বৃদ্ধিতে ব্যয় প্রায় 100 বাইট। এটি ঠিক ১০২ বাইট হবে না কারণ অপ্টিমাইজারটি কিছু ক্রিয়াকলাপের জন্য রেজিস্টারগুলিতে ইতিমধ্যে মানগুলির সুবিধা নিতে সক্ষম হতে পারে এবং অতিরিক্ত নির্দেশাবলীতে নিবন্ধক নমনীয়তার স্বল্পতার ক্ষেত্রে লুকানো ব্যয় থাকতে পারে। আসল পার্থক্যটি আরও বেশি হতে পারে, এটি কমও হতে পারে, তবে একটি খামের গণনার জন্য আসুন এটি ১০০ বলুন Meanwhileদিকে, মেমরির সঞ্চয় প্রতি ক্লাসে 15 বাইট ছিল। সুতরাং, ব্রেকভেনভিয়েন্টটি সাতটি is যদি আপনার প্রোগ্রামটি এই শ্রেণীর সাতটিরও কম উদাহরণ তৈরি করে, তবে কোড ব্যয় ডেটা সঞ্চয়কে ছাড়িয়ে যায়: আপনার মেমরি অপটিমাইজেশন একটি মেমরি ডি-অপ্টিমাইজেশন ছিল।

তথ্যসূত্র

• বুলিয়ান সংগ্রহের জন্য বিটফিল্ডের ব্যয়-বেনিফিট বিশ্লেষণ - ওল্ড নিউ থিং

• বিট-ফিল্ড বেদনারতা - হার্ডওয়্যারবাগ

• সিতে পঠনযোগ্য এবং রক্ষণাবেক্ষণযোগ্য বিটফিল্ডগুলি pagetable.com