"অকালীন অপটিমাইজেশন সমস্ত মন্দের মূল" সম্পর্কে ভুল ধারণা নিয়ে কীভাবে মোকাবিলা করবেন?


26

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

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

পূর্ববর্তী প্রচেষ্টা

কয়েক বার, আমি সরবরাহের চেষ্টা করেছি ডোনাল্ড Knuth থেকে সম্পূর্ণ উদ্ধৃতি অর্ডার ব্যাখ্যা করার যে "অকাল অপ্টিমাইজেশান খারাপ" ↛ "সব অপ্টিমাইজেশান খারাপ" এ:

আমাদের ছোট কার্যকারিতা সম্পর্কে ভুলে যাওয়া উচিত, সময়ের প্রায় 97% বলুন: অকালীন অপটিমাইজেশন হ'ল সমস্ত মন্দের মূল। তবুও আমাদের সেই সমালোচনামূলক 3% তে আমাদের সুযোগগুলি অতিক্রম করা উচিত নয়।

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


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

12
@ ইরান্টলিংয়েস্ট: যদি প্রোগ্রামটি "গুড়ের মতো ধীর" হয় তবে স্পষ্টতই আপনাকে নুথের "সেই সমালোচনামূলক 3%" সহজেই সনাক্ত করতে সক্ষম হওয়া উচিত এবং সুতরাং এটির অনুকূলিতকরণের বিরুদ্ধে কোনও যুক্তি প্রকাশ করা উচিত। এবং যদি আপনি এটি সনাক্ত করতে না পারেন ... তবে আপনি এখনও নিজের হোমওয়ার্ক করেননি এবং আপনি এখনও অনুকূলিত করতে প্রস্তুত নন। সুতরাং সমস্যাটি কোথায় তা পরিষ্কার নয়।
নিকল বোলাস

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

6
@ ইরান্টলিংয়েস্ট: মূল প্রশ্ন: গ্রাহকরা কি অভিযোগ করছেন যে ওই অঞ্চলে অ্যাপ্লিকেশনটি ধীর ছিল?
রোবট

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

উত্তর:


35

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

আমার অভিজ্ঞতায়, আপনাকে হয় বুলেটটি কামড়তে হবে এবং প্রথমে "নিষ্পাপ বাস্তবায়ন" চেষ্টা করতে হবে (এবং সম্ভবত এটি কতটা দ্রুত হয় তা অবাক করে দেবেন), অথবা চলমান সময় সম্পর্কে আপনি কমপক্ষে একটি মোটামুটি অনুমান করবেন, যেমন:

"নিষ্পাপ বাস্তবায়নটি ও (n³) হবে, এবং n 100.000 এর চেয়ে বড় হবে; এটি কয়েক দিন চলবে, যখন না-অত্যাবশ্যক বাস্তবায়ন ও (এন) এ চলবে, এতে কয়েক মিনিট সময় লাগবে"

কেবল হাতে যেমন যুক্তি দিয়ে আপনি নিশ্চিত হতে পারেন যে আপনার অপ্টিমাইজেশন অকাল নয়।

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

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

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


15
@ ইরান্টলিংয়েস্ট: সম্ভবত আমি কি নিজেকে পরিষ্কার করে দেখিনি, বা এটি শুনতে চেয়েছিল তা নয়? আমার পরামর্শটি হ'ল: "3%" বা "97%" সম্পর্কে নথের * দার্শনিক যুক্তিগুলি ব্যবহার করার চেষ্টা করবেন না it এটি সত্যবাদী রাখুন, অন্যথায় আপনার সহকর্মীরা সম্ভবত আপনার পারফরম্যান্স যুক্তিগুলি অনুপযুক্ত বলে ঠিক বলেছেন
ডক ব্রাউন

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

2
@ ইরান্টলিংয়েস্ট: এটি কবর দেবেন না - এই দিকগুলিকে ফোকাসে রাখুন, যখন এই বিষয়গুলি সঠিকভাবে ফোকাস করা উচিত, এবং যখন আপনি এটি প্রমাণ করতে না পারেন যে এটি শেষ ব্যবহারকারীর জন্য একটি গুরুত্বপূর্ণ পার্থক্য করে makes
ডক ব্রাউন

2
@ ইরান্টলিংয়েস্ট: আপনি কীভাবে এই সিদ্ধান্তে পৌঁছেছেন তা আমি নিশ্চিত নই। ডক ব্রাউন এর উত্তর পুরোপুরি স্পষ্ট বলে মনে হচ্ছে: আপনি গ্রহণযোগ্য পারফরম্যান্স কী এবং না তা সম্পর্কে সত্যবাদী বক্তব্যকে আঁকড়ে ধরে আপনি আপনার সহকর্মীদের সাথে যে অনুচ্চারিত যুক্তি দিয়েছিলেন তা কাটাচ্ছেন।
jl6

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

18

নিজেকে জিজ্ঞাসা করুন:

  • সফ্টওয়্যারটি পারফরম্যান্সের বিশদটি পূরণ করে না?
  • সফ্টওয়্যারটি কি পারফরম্যান্সের সমস্যা রয়েছে?

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

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

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

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


4
ভাল তথ্য দেওয়ার সময়, এটি আসলে এমন লোকদের সাথে কীভাবে কাজ করবেন সে সম্পর্কে আমার প্রশ্নের উত্তর দেয় না যাঁরা পারফরম্যান্সের সাথে এই মুহূর্তে কোনও আলোচনার প্রস্তুতি নিতে পারেন discussion
ভ্রান্তলিঙ্গবাদী

7
"শুধুমাত্র কয়েকটি বিশেষায়িত শিল্পের গতিটিই গতিময় গুরুত্বপূর্ণ important" ব্যতীত আমি এগুলির সাথে একমত। আমি মনে করি আপনি যে পরিমাণ সফ্টওয়্যারটির গ্রাহকের দৃষ্টিকোণ থেকে পারফরম্যান্স সংক্রান্ত সমস্যা রয়েছে সেটিকে আপনি কম মূল্যায়ন করবেন।
রোবট

@ স্টিভেন বার্নাপ: হ্যাঁ - বন্যে এমন কি ওয়েব অ্যাপ্লিকেশন রয়েছে যা আসলে ধীর নয় ? - আমি বিজ্ঞানের একই সাথে একটি দেখতে চাই।
ভুল হয়েছে 17

1
google.com বেশ দ্রুত pretty :
রোবট

একটি এজ মোবাইল মোবাইল সংযোগে google.com ব্যবহার করার চেষ্টা করুন। হ্যাঁ, এটি একটি হাস্যকর প্রান্তের মামলা তবে এটি অবশ্যই খুব দ্রুত হবে না । ;) (পুন প্রকৃত উদ্দেশ্য নয়
ভুল হয়েছে

7

পারফরম্যান্সের সাথে এই মুহুর্তে যে আলোচনার আলোচনার দরকার আছে তাদের সাথে কীভাবে কাজ করবেন?

আপনার গ্রুপের কৌশলগত দিকের ভিত্তিতে ভাগ করা নীতিগুলি দিয়ে শুরু করুন।

আমার নীতিগুলি:

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

আপনার গ্রাহকরা যদি গ্রাহক হন তবে আপনার গ্রাহকরা আপনাকে দ্রুত কোডের প্রয়োজন কিনা তা আপনাকে জানিয়ে দেবে।

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

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

অপ্টিমাইজেশনের প্রয়োজনীয়তা সঠিক বলে ধরে নিচ্ছি

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

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

অতিরিক্ত জটিলতার ব্যয় ওজন করুন

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

নেতৃত্ব

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

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


6

এগিয়ে যাওয়ার উপায়টি প্রকৃত উদ্ধৃতি এবং বিভিন্ন ব্যাখ্যাগুলি ভুলে যাওয়া - এটি কোনও গুরুর দ্বারা নির্দিষ্ট কোনও উদ্ধৃতিতে এত বেশি কেন্দ্রীভূত করার মতবাদ dog কে বলেছেন নথ সর্বদাই ঠিক আছে?

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

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

আরও সাধারণভাবে, অপটিমাইজেশন সংক্রান্ত দুটি সম্ভাবনা রয়েছে:

  1. অপ্টিমাইজড কোডটি আরও খাটো, বোঝা সহজ এবং বজায় রাখা সহজ।

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

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


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

@ ডকব্রাউন: অবশ্যই, তবে এটি কোনও গ্রাহকই সিদ্ধান্ত নেন যে এটি খুব ধীর বা না, বিকাশকারী নয়।
জ্যাকবিবি

আমি কখনই ব্যবসায়ের প্রয়োজনীয়তাগুলিতে আসিনি যা স্পষ্টভাবে পারফরম্যান্সের প্রয়োজনীয়তার বিবরণ দেয়।
ভুল সন্ধানকারী

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

4

আমি মনে করি প্রসঙ্গে সম্পূর্ণ উক্তিটি শিক্ষণীয়। আমি এই বিষয়টিতে রেডডিতে তৈরি একটি পোস্ট থেকে অনুলিপি করব:

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

তবুও আমাদের সেই সমালোচনামূলক 3% তে আমাদের সুযোগগুলি অতিক্রম করা উচিত নয়। একজন ভাল প্রোগ্রামারকে এ জাতীয় যুক্তি দিয়ে আত্মতৃপ্তিতে জাগানো হবে না, তিনি সমালোচনামূলক কোডটি মনোযোগ সহকারে দেখার পক্ষে হবে; তবে কেবলমাত্র সেই কোডটি সনাক্ত করার পরে।

- ডোনাল্ড নুথ, স্ট্রাকচার্ড প্রোগ্রামিং উইথ গো স্টেটমেন্টস , এসিএম কম্পিউটিং সার্ভেস, Vol ষ্ঠ নং, ৪ ডিসেম্বর, ১৯4৪, পৃষ্ঠা ২6868

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

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


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

3

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

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


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

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

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

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

2

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

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

এটি "অকাল অপটিমাইজেশন" এর "অকাল"। কখন এটি "অকাল" হয় না? গ্রাহকরা যখন আপনাকে বলেন "এটি খুব জঘন্য ধীর, ঠিক করুন!" আপনি যখন কোডটি খনন করেন এবং এটিকে আরও দ্রুত করার চেষ্টা করেন That's

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


এর অর্থ এই নয় যে আপনার মস্তিষ্ক বন্ধ করা উচিত। এর অর্থ এই নয় যে আপনার 10,000 গ্রাহকের রেকর্ড এককভাবে সংযুক্ত তালিকায় রাখা উচিত। > যদিও আমি এটির সাথে আপনার 100% একমত, আমি আসলে সেভাবে ব্যবহৃত লিঙ্কযুক্ত তালিকা দেখেছি এবং "এটি স্পর্শ না করতে" বলা হয়েছিল।
ভ্রান্তিমূলকবাদক

ভাল তথ্য দেওয়ার সময়, এটি আসলে এমন লোকদের সাথে কীভাবে কাজ করবেন সে সম্পর্কে আমার প্রশ্নের উত্তর দেয় না যাঁরা পারফরম্যান্সের সাথে এই মুহূর্তে কোনও আলোচনার প্রস্তুতি নিতে পারেন discussion
ভুল সন্ধানকারী

3
দুঃখের বিষয়, "এককভাবে সংযুক্ত তালিকা" জিনিসটি এলোমেলো উদাহরণ নয় বরং এমন কিছু যা আমি ব্যক্তিগতভাবে ছুঁড়েছি।
রোবট

1

আপনি হয় ভুল উপায়ে জিনিসগুলি করতে পারেন, বা জিনিসগুলি সঠিক উপায়ে করতে পারেন।

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

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

আমি মনে করি যে লোকেরা অন্যায় করার চেয়ে তাদের জিনিসগুলি সঠিকভাবে করতে চাইবে। আপনি যখন আপনার সমবয়সীদের সাথে বিকল্প কৌশলগুলি নিয়ে আলোচনা করেন তখন এটি ব্যবহার করুন।


5
"ভুল উপায়" বা "সঠিক উপায়ে" কখনও হয় না। "মাই গড, এটি কীভাবে চলবে !?" "জো কারম্যাক এবং ডোনাল্ড নুথ জুটি প্রোগ্রামিংয়ের সময় এটি আরও ভাল করতে পারেনি"।
রোবট

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

" আমি মনে করি যে লোকেরা তাদের ভুল করার পরিবর্তে জিনিসগুলি সঠিক করতে চায় tend " - সমস্যাটি হ'ল, সঠিক বা অন্যায় সম্পর্কে খুব আলাদা মতামত রয়েছে। এমনকি কেউ কেউ এ সম্পর্কে পবিত্র যুদ্ধ শুরু করেন (আক্ষরিক অর্থে)।
JensG

1

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

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

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


আমি উত্তরটি সম্পাদনা করব এবং কিছুটা আরও ছড়িয়ে দেব, ডাউনভোটার কি কিছু প্রতিক্রিয়া যোগ করতে পারে? :)
সারা

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

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