আপনি পরিষ্কার কোড অনুশীলন অনুসরণ করে আরও কোড কীভাবে ন্যায্যতা প্রমাণ করবেন?


106

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

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

এর একটি পার্শ্ব প্রতিক্রিয়া আমি লক্ষ্য করেছি, তবে, আমি যে "ক্লিন" কোডটি লিখি তা হ'ল আমি যদি কিছু অনুশীলন অনুসরণ না করি তবে তার চেয়ে বেশি কোড। নির্দিষ্ট অনুশীলনগুলি যা এর দিকে পরিচালিত করে:

  • শর্তসাপেক্ষে encapsulating

পরিবর্তে তাই

if(contact.email != null && contact.emails.contains('@')

আমি এই মত একটি ছোট পদ্ধতি লিখতে পারে

private Boolean isEmailValid(String email){...}
  • অন্য একটি ব্যক্তিগত পদ্ধতির সাথে একটি ইনলাইন মন্তব্য প্রতিস্থাপন করা, যাতে পদ্ধতির নামটি তার উপরে একটি ইনলাইন মন্তব্য না করে নিজেকে বর্ণনা করে
  • একটি শ্রেণীর পরিবর্তনের কেবল একটি কারণ থাকতে হবে

এবং কয়েক অন্যান্য। বিন্দুটি হ'ল, 30 লাইনের একটি পদ্ধতি কী হতে পারে তা ক্লাস হিসাবে শেষ হয়, কারণ ক্ষুদ্র পদ্ধতিগুলি মন্তব্যগুলি প্রতিস্থাপন করে এবং শর্তসাপেক্ষে আবশ্যক ইত্যাদি etc. সমস্ত কার্যকারিতা একটি শ্রেণিতে রাখুন, যখন সত্যিই এটি কোনও পদ্ধতি হওয়া উচিত।

আমি জানি যে চরম গ্রহণের যে কোনও অনুশীলন ক্ষতিকারক হতে পারে।

আমি যে সুনির্দিষ্ট প্রশ্নের উত্তর খুঁজছি তা হ'ল:

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

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

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

এটি নির্দিষ্ট উদ্বেগ ... এই ক্লাসগুলি এমন একক শ্রেণি হতে পারে যা এখনও অনেকগুলি ছোট পদ্ধতির সহায়তা ছাড়াই "একটি জিনিস" অর্জন করে। এটি 3 বা 4 পদ্ধতি এবং কিছু মন্তব্য সহ একক শ্রেণী হতে পারে।


98
যদি আপনার সংস্থাটি আপনার কোড বেসগুলির জন্য কেবলমাত্র এলওসি ব্যবহার করে তবে ক্লিন কোডকে ন্যায্যতা দিয়ে শুরু করার আশা নেই।
কিলিয়ান ফট 12

24
রক্ষণাবেক্ষণ যদি আপনার লক্ষ্য হয় তবে এলওসি বিচারের পক্ষে সেরা মেট্রিক নয় - এটি তাদের মধ্যে একটি, তবে কেবল এটি সংক্ষিপ্ত রাখার চেয়ে আরও অনেক বিষয় বিবেচনা করার দরকার রয়েছে।
জিব্বোবজ

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

14
শুধু নিজের নিয়ম না করে প্রতিটি সেরা অনুশীলনের পিছনে কারণগুলি শিখুন। কারণ ছাড়াই নিয়মাবলী অনুসরণ করা কার্গো কাল্ট। প্রতিটি একক নিয়মের নিজস্ব কারণ রয়েছে।
গেরম্যান

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

উত্তর:


130

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

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

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

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


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

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

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

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

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

155

হ্যাঁ, এটি একটি গ্রহণযোগ্য বাই-প্রোডাক্ট, এবং ন্যায়সঙ্গততা হ'ল এটি এখন এমনভাবে কাঠামোযুক্ত করা হয়েছে যে বেশিরভাগ সময় আপনাকে বেশিরভাগ কোড পড়তে হবে না। প্রতিবার আপনি পরিবর্তন করার সময় 30-লাইনের ফাংশনটি পড়ার পরিবর্তে সামগ্রিক প্রবাহ পেতে আপনি একটি 5-লাইন ফাংশন পড়ছেন এবং আপনার পরিবর্তন যদি সেই অঞ্চলটিকে স্পর্শ করে তবে সম্ভবত কয়েকজন সহায়ক কাজ করবে। যদি আপনার নতুন "অতিরিক্ত" শ্রেণি কল করা হয় EmailValidatorএবং আপনি জানেন যে আপনার সমস্যা ইমেল বৈধকরণের সাথে নয় তবে আপনি এটি পুরোপুরি পড়া বাদ দিতে পারেন।

ছোট ছোট টুকরো পুনরায় ব্যবহার করাও সহজ, যা আপনার সামগ্রিক প্রোগ্রামের জন্য আপনার লাইন গণনা হ্রাস করে। একটি EmailValidatorপুরো জায়গা জুড়ে ব্যবহার করা যেতে পারে। কোডের কয়েকটি লাইন যা ইমেল বৈধতা দেয় তবে ডেটাবেস অ্যাক্সেস কোডের সাথে একসাথে স্ক্র্যাঞ্চ হয় তা পুনরায় ব্যবহার করা যাবে না।

এবং তারপরে ইমেল বৈধকরণের নিয়মগুলি পরিবর্তন করার প্রয়োজন হলে কী করা দরকার তা বিবেচনা করুন — যা আপনি বরং চান: একটি পরিচিত অবস্থান; বা অনেক লোকেশন, সম্ভবত কিছু মিস করছেন?


10
এর থেকে আরও উত্তম উত্তর তারপর ক্লান্তিকর "ইউনিট পরীক্ষা আপনার সমস্ত সমস্যার সমাধান করে"
ডার্ক বোয়ার

13
এই উত্তরটি একটি মূল পয়েন্টে আঘাত করে যা চাচা বব এবং বন্ধুরা সবসময় মিস করে বলে মনে হয় - ছোট পদ্ধতিতে রিফ্যাক্টরিং কেবল তখনই সহায়তা করে যদি আপনার কোডটি কী করছে তা নির্ধারণ করার জন্য আপনাকে সমস্ত ছোট পদ্ধতি পড়তে হবে না। ইমেল ঠিকানাগুলি বৈধ করার জন্য একটি পৃথক শ্রেণি তৈরি করা বুদ্ধিমানের কাজ। কোড টানা iterations < _maxIterationsএকটি পদ্ধতি নামক ShouldContinueToIterateহয় মূঢ়
বিজে মায়ার্স

4
@ ডেভিড আর্নো: "দরকারী হতে"! = "আপনার সমস্ত সমস্যার সমাধান করে"
খ্রিস্টান হ্যাকেল

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

2
হাই @ ডেভিড আর্নো, আমার মন্তব্য স্পষ্টতই হাইপারবোল ছিল স্ট্রোম্যান নয়;) আমার কাছে এটি এরকম: আমি কীভাবে আমার গাড়ি স্থির করব এবং ধর্মীয় লোকেরা এসে আমাকে বলবেন যে আমার কম পাপী জীবনযাপন করা উচিত। তাত্ত্বিকভাবে আলোচনার জন্য মূল্যবান কিছু, তবে গাড়ি ঠিক করার ক্ষেত্রে এটি আমাকে সত্যিই সহায়তা করছে না।
ডার্ক বোয়ার

34

বিল গেটস বিখ্যাত হয়ে বলেছিলেন, "কোডের লাইনে প্রোগ্রামিংয়ের অগ্রগতি পরিমাপ করা ওজন দ্বারা বিমান তৈরির অগ্রগতি পরিমাপ করার মতো।"

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

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

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

যদিও স্পষ্টত আপনি এই ক্ষেত্রে এটি করছেন না, তাই আমি আপনাকে যেমন করছিলাম তেমন চালিয়ে যেতে উত্সাহিত করব। আপনার সর্বদা নিজেকে জিজ্ঞাসা করা উচিত যদি পরিবর্তন করে, পড়া সহজ হয় এবং যদি এটি আপনার ক্ষেত্রে হয় তবে তা করুন!


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

21
নির্দিষ্ট দলের ওপিতে @Jos যারা কাজ করছেন, এটি কম এলওসি'কে আরও ভাল 'বলে মনে করা হচ্ছে appears বিল গেটস যে বিষয়টি তৈরি করছিলেন তা হ'ল যে এলওসি কোনও অর্থবহ উপায়ে অগ্রগতির সাথে সম্পর্কিত নয় , ঠিক তেমনই বিমানের নির্মাণের ওজনও অর্থবহ উপায়ে অগ্রগতির সাথে সম্পর্কিত নয়। নির্মাণাধীন একটি বিমানের চূড়ান্ত ওজনের 95% তুলনামূলকভাবে দ্রুত থাকতে পারে, তবে এটি কেবল একটি খালি শেল হবে যার কোনও নিয়ন্ত্রণ ব্যবস্থা নেই, এটি 95% সম্পূর্ণ নয়। সফ্টওয়্যার একই, যদি একটি প্রোগ্রামে কোডের 100k লাইন থাকে তবে এর অর্থ এই নয় যে প্রতিটি 1000 লাইন কার্যকারিতার 1% সরবরাহ করে।
মিঃমিন্দর

7
অগ্রগতি পর্যবেক্ষণ একটি কঠিন কাজ, তাই না? দরিদ্র পরিচালকরা।
জোস

@ জোস: কোডেও একই কার্যকারিতাটির জন্য কম লাইন থাকা ভাল, যদি সমস্ত কিছু সমান হয়।
রিমকো গ্রিলিচ

@ জোস সাবধানে পড়ুন। গেটস কোনও বিমানের জন্যই ওজন একটি গুরুত্বপূর্ণ পরিমাপ কিনা সে সম্পর্কে কিছুই বলেন না। তিনি বলেছেন যে ওজন একটি বিমান তৈরির অগ্রগতির জন্য এক ভয়াবহ পরিমাপ । সর্বোপরি, সেই পরিমাপের সাথে সাথে আপনি পুরো হুলটি মাটিতে ফেলে দিলে আপনি মূলত সম্পন্ন হয়ে গেছেন যেহেতু সম্ভবত পুরো বিমানের ওজনের 9x% পরিমাণে।
ভু

23

সুতরাং কিছু বিকাশকারী / পরিচালকগণ কাজ সম্পন্ন করার জন্য কম কোড লেখার মান দেখতে পান যাতে আমাদের বজায় রাখার জন্য কম কোড থাকে

এটি আসল লক্ষের দিকে দৃষ্টি হারিয়ে যাওয়ার বিষয়।

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

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


লগিং

একটি অ্যাপ্লিকেশন নিন (এ) যার কোনও লগিং নেই। এখন অ্যাপ্লিকেশন বি তৈরি করুন যা একই অ্যাপ্লিকেশন এ তবে লগিং সহ। বি এর সর্বদা কোডের আরও লাইন থাকবে এবং সুতরাং আপনাকে আরও কোড লিখতে হবে।

তবে অনেক সময় সমস্যা এবং ত্রুটিগুলি তদন্ত করতে এবং কী ভুল হয়েছে তা নির্ধারণের জন্য ডুবে যাবে।

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

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

এটি মিনিট, ঘন্টা বা দিন সংরক্ষণের বিষয় হতে পারে; কোডবেজের আকার এবং জটিলতার উপর নির্ভর করে।


রিগ্রেশন

অ্যাপ্লিকেশন এ নিন, যা মোটেও DRY- বান্ধব নয়।
অ্যাপ্লিকেশন বি নিন, যা শুকনো, তবে অতিরিক্ত বিমূর্ততার কারণে আরও লাইনের প্রয়োজন শেষ হয়েছে।

একটি পরিবর্তন অনুরোধ দায়ের করা হয়েছে, যার জন্য যুক্তিতে পরিবর্তন দরকার।

বি অ্যাপ্লিকেশনটির জন্য, বিকাশকারী পরিবর্তন অনুরোধ অনুযায়ী (অনন্য, ভাগ করা) যুক্তি পরিবর্তন করে।

অ্যাপ্লিকেশন এ এর ​​জন্য, বিকাশকারীকে এই যুক্তির সমস্ত দৃষ্টান্ত পরিবর্তন করতে হবে যেখানে তিনি মনে করছেন এটি ব্যবহার হচ্ছে।

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

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


বিকাশকারী বিনিময়যোগ্যতা

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

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

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

একই সময়ে, অ্যাপ্লিকেশন বি (যা দেব বি তৈরি করেছে) এর একটি জরুরি অবস্থা রয়েছে। দেব বি দখল করা হয়েছে, তবে কোড সিটি না জানলেও দেব সি উপলব্ধ is আমরা কি করি?

  • আমরা যদি খ-কে A তে কাজ করে রাখি এবং বি তে কাজ করি, তবে আমাদের দু'জন বিকাশকারী আছেন যারা জানেন না তারা কী করছেন, এবং কাজটি suboptimally সম্পাদিত হচ্ছে।
  • আমরা যদি এটিকে বি থেকে দূরে সরিয়ে নিয়ে তাকে বি করি, এবং আমরা এখন সি এ এ রাখি, তবে বিকাশকারী বি এর সমস্ত কাজ (বা এর উল্লেখযোগ্য অংশ) ফেলে দেওয়া হতে পারে। এটি সম্ভাব্য দিন / সপ্তাহের প্রচেষ্টা নষ্ট হয়।

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


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

ম্যানেজমেন্টকে বুঝতে হবে যে এখন একটি সংক্ষিপ্ত কাজ আপনাকে ভবিষ্যতে বেশ কয়েকটি দীর্ঘ কাজ সাশ্রয় করবে। পরিকল্পনা ব্যর্থ ব্যর্থ করার পরিকল্পনা করা হয়।

যদি তা হয়, তবে আরও এলওসি রচিত হয়েছে তা প্রমাণ করতে আমি কোন যুক্তিগুলি ব্যবহার করতে পারি?

আমার গোপনীয় বিবরণী তারা কী পছন্দ করবে সে সম্পর্কে ম্যানেজমেন্টকে জিজ্ঞাসা করছে: 100KLOC কোডবেস সহ একটি অ্যাপ্লিকেশন যা তিন মাসের মধ্যে বিকাশ করা যায়, বা 50 কেএলপি কোডবেস যা ছয় মাসে উন্নত করা যায়।

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


23

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

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

আমি বলছি না যে আপনার শর্তসাপেক্ষে উত্তোলন করা উচিত নয় , আপনার যদি প্রয়োজন হয় তবে আপনার যত্ন সহকারে বিবেচনা করা উচিত।

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

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

আমি বলব, যদি সন্দেহ হয় তবে সর্বদা সহজ এবং সর্বাধিক সরল কোড নির্বাচন করুন।


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

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

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

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

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

9

আমি উল্লেখ করতে চাই যে এগুলির সাথে অন্তর্নিহিত কোনও ভুল নেই:

if(contact.email != null && contact.email.contains('@')

কমপক্ষে ধরে নিলাম এটি একবার ব্যবহার হয়েছে।

আমার খুব সহজেই এটির সাথে সমস্যা হতে পারে:

private Boolean isEmailValid(String email){
   return email != null && email.contains('@');
}

কয়েকটি বিষয় যা আমি লক্ষ্য করি:

  1. এটা ব্যক্তিগত কেন? এটি একটি সম্ভাব্য দরকারী স্টাবের মতো দেখাচ্ছে। এটি কি কোনও ব্যক্তিগত পদ্ধতি হতে যথেষ্ট কার্যকর এবং এর বেশি বিস্তৃত ব্যবহারের সম্ভাবনা নেই?
  2. আমি পদ্ধতি IsValidEmail ব্যক্তিগতভাবে, সম্ভবত নাম না ContainsAtSign বা LooksVaguelyLikeEmailAddress কারণ এটি প্রায় কোনো বাস্তব বৈধতা, যা হয়তো ভালো, হয়তো কি exected হয় না।
  3. এটি কি একাধিকবার ব্যবহৃত হচ্ছে?

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

অন্যদিকে আমি দেখেছি পদ্ধতিগুলি এরকম কিছু করে:

if (contact.email != null && contact.email.contains('@')) { ... }
else if (contact.email != null && contact.email.contains('@') && contact.email.contains("@mydomain.com")) { //headquarters email }
else if (contact.email != null && contact.email.contains('@') && (contact.email.contains("@news.mydomain.com") || contact.email.contains("@design.mydomain.com") ) { //internal contract teams }

উদাহরণটি স্পষ্টতই DRY নয়।

বা এমনকি ঠিক যে শেষ বিবৃতি অন্য উদাহরণ দিতে পারে:

if (contact.email != null && contact.email.contains('@') && (contact.email.contains("@news.mydomain.com") || contact.email.contains("@design.mydomain.com") )

লক্ষ্যটি কোডটি আরও পঠনযোগ্য করে তোলা উচিত:

if (LooksSortaLikeAnEmail(contact.Email)) { ... }
else if (LooksLikeFromHeadquarters(contact.Email)) { ... }
else if (LooksLikeInternalEmail(contact.Email)) { ... }

আর একটি দৃশ্য:

আপনার মতো পদ্ধতি থাকতে পারে:

public void SaveContact(Contact contact){
   if (contact.email != null && contact.email.contains('@'))
   {
       contacts.Add(contact);
       contacts.Save();
   }
}

এটি যদি আপনার ব্যবসায়ের যুক্তি অনুসারে ফিট করে এবং পুনরায় ব্যবহার না করা হয় তবে এখানে কোনও সমস্যা নেই।

কিন্তু যখন কেউ জিজ্ঞাসা করে "কেন '@' সংরক্ষণ করা হয়েছে, কারণ এটি সঠিক নয়!" এবং আপনি কোনও প্রকারের আসল বৈধতা যুক্ত করার সিদ্ধান্ত নিয়েছেন, তারপরে এটি নিষ্কাশন করুন!

আপনি যখন খুশি হবেন যে আপনি যখন রাষ্ট্রপতিদের দ্বিতীয় ইমেল অ্যাকাউন্ট Pr3 $ sid3nt @ h0m3! @ Mydomain.com এর জন্য অ্যাকাউন্টও প্রয়োজন তখন আপনি ঠিক করবেন এবং আরএফসি 2822 কে সমর্থন করার চেষ্টা করবেন এবং সমর্থন করবেন।

পাঠযোগ্যতার উপর:

// If there is an email property and it contains an @ sign then process
if (contact.email != null && contact.email.contains('@'))

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

// The UI passes '@' by default, the DBA's made this column non-nullable but 
// marketing is currently more concerned with other fields and '@' default is OK
if (contact.email != null && contact.email.contains('@'))

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

সংক্ষেপে: এই জিনিসগুলি পরিমাপ করবেন না; (DRY, SOLID, KISS) পাঠ্যটি যে নীতিগুলি থেকে তৈরি হয়েছিল সেদিকে মনোনিবেশ করুন।

// A valid class that does nothing
public class Nothing 
{

}

3
Whether the comments above an if statement or inside a tiny method is to me, pedantic.এটি একটি "খড় যা উটের পিঠে ভেঙে দেয়" সমস্যা। আপনি ঠিক বলেছেন যে এই একটি জিনিস সরাসরি পড়তে খুব কঠিন নয়। কিন্তু যদি আপনি একটি বড় পদ্ধতি (যেমন একটি বৃহৎ আমদানি) যা এই ছোট মূল্যায়ন কয়েক ডজন আছে, এই পাঠযোগ্য পদ্ধতি নামে encapsulated থাকার আছে ( IsUserActive, GetAverageIncome, MustBeDeleted, ...) কোড পড়া একটি লক্ষণীয় উন্নতি হয়ে যাবে। উদাহরণ সহ সমস্যাটি হ'ল এটি কেবল একটি খড় পর্যবেক্ষণ করে, পুরো বান্ডিলটি যা উটের পিছন ভাঙে না।
ফ্লাটার

@ ফ্লাটার এবং আমি আশা করি এটি পাঠক যে আত্মা থেকে গ্রহণ করবে this
অ্যাথমসফার্ট

1
এই "এনক্যাপসুলেশন" একটি অ্যান্টি-প্যাটার্ন এবং উত্তরটি প্রকৃতপক্ষে এটি প্রদর্শন করে। আমরা ডিবাগিংয়ের উদ্দেশ্যে এবং কোডটি প্রসারিত করার উদ্দেশ্যে কোডটি পড়তে ফিরে আসি। উভয় ক্ষেত্রে কোডটি আসলে কী তা বোঝা সমালোচনা করে। কোড ব্লক if (contact.email != null && contact.email.contains('@'))শুরুটি বগি। যদি মানটি মিথ্যা হয় তবে লাইনগুলি সত্য হতে পারে না অন্য কোনওটি। এটি LooksSortaLikeAnEmailব্লকটিতে দৃশ্যমান নয় । কোডের একক লাইন সমন্বিত একটি ক্রিয়াকলাপ লাইনটি কীভাবে কাজ করে তা ব্যাখ্যা করার চেয়ে বেশি ভাল নয়।
Quirk

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

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

6

ক্লিন কোড একটি দুর্দান্ত বই, এবং পড়ার পক্ষে উপযুক্ত তবে এটি এই জাতীয় বিষয়ে চূড়ান্ত কর্তৃপক্ষ নয়।

যৌক্তিক ফাংশনগুলিতে কোড ভাঙা সাধারণত একটি ভাল ধারণা, তবে মার্টিনের মতো কিছু প্রোগ্রামারই এটি করেন - কিছু সময় আপনি সমস্ত কিছুকে ফাংশনে রূপান্তর থেকে কমিয়ে ফিরতে পারেন এবং যখন সমস্ত কোড ক্ষুদ্রতর হয় তখন তা অনুসরণ করা শক্ত হতে পারে টুকরা.

একটি সম্পূর্ণ নতুন ফাংশন তৈরি করার উপযুক্ত না হলে একটি বিকল্প হ'ল কেবল একটি মধ্যবর্তী ভেরিয়েবল ব্যবহার করা:

boolean isEmailValid = (contact.email != null && contact.emails.contains('@');

if (isEmailValid) {
...

এটি প্রচুর পরিমাণে ফাইলের চারপাশে ঝাঁপ না দিয়ে কোডটি অনুসরণ করা সহজ রাখতে সহায়তা করে।

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


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

5

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

একটি মেট্রিক হিসাবে কোডের লাইনগুলি অর্থহীন। সফটওয়্যার ইঞ্জিনিয়ারিংয়ের গুরুত্বপূর্ণ প্রশ্নগুলি হ'ল:

  • আপনার কি খুব বেশি কোড আছে?
  • আপনার কি খুব কম কোড আছে?

গুরুত্বপূর্ণ প্রশ্নগুলি হ'ল:

  • পুরো অ্যাপ্লিকেশনটি কি সঠিকভাবে ডিজাইন করা হয়েছে?
  • কোডটি কি সঠিকভাবে প্রয়োগ করা হয়েছে?
  • কোডটি কি রক্ষণাবেক্ষণযোগ্য?
  • কোডটি পরীক্ষাযোগ্য?
  • কোডটি কি পর্যাপ্তভাবে পরীক্ষিত হয়?

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

অবশ্যই, আমি কোনও ইউটিলিটি পদ্ধতির পরিবর্তে বুলিয়ান ক্রিয়াকলাপগুলির একটি দীর্ঘ চেইন ব্যবহার করতে পারি, তবে আমার কি করা উচিত?

আপনার প্রশ্নটি আসলে আমাকে যে বুলিয়ানগুলি লিখেছিল তার কয়েকটি দীর্ঘ শৃঙ্খলে ফিরে যেতে ভাবতে বাধ্য করে এবং বুঝতে পারে তার পরিবর্তে আমার সম্ভবত এক বা একাধিক ইউটিলিটি পদ্ধতি (গুলি) লেখা উচিত ছিল।


3

এক স্তরে, তারা ঠিক - কম কোড ভাল। আর একটি উত্তর গেটের উদ্ধৃত, আমি পছন্দ করি:

"যদি ডিবাগিং হ'ল সফ্টওয়্যার বাগগুলি অপসারণের প্রক্রিয়া হয় তবে প্রোগ্রামিং এগুলি অবশ্যই এগুলি রাখার প্রক্রিয়া হতে হবে” "- এডসগার ডিজকস্ট্রা

“ডিবাগিং করার সময়, নতুনরা সংশোধন কোড প্রবেশ করান; বিশেষজ্ঞরা ত্রুটিযুক্ত কোড অপসারণ করে। ”- রিচার্ড প্যাটিস

সস্তার, দ্রুততম এবং সবচেয়ে নির্ভরযোগ্য উপাদানগুলি সেগুলি নেই যা সেখানে নেই। - গর্ডন বেল

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

এখানে যা গুরুত্বপূর্ণ তা হল এই সমস্তগুলি কার্যকারিতা বোঝায় এবং এটি করার জন্য কেবল সর্বনিম্ন প্রয়োজনীয়তা রয়েছে। এটি কীভাবে প্রকাশ করা হয় সে সম্পর্কে এটি কিছু বলে না ।

পরিষ্কার কোড দেওয়ার চেষ্টা করে আপনি যা করছেন তা উপরের বিপরীতে নয়। আপনি আপনার এলওসি-তে যোগ করছেন কিন্তু অব্যবহৃত কার্যকারিতা যোগ করছেন না।

শেষ লক্ষ্যটি হ'ল পাঠযোগ্য কোড রয়েছে তবে অতিরিক্ত অতিরিক্ত কোনও অতিরিক্ত নেই। দুটি নীতি একে অপরের বিরুদ্ধে কাজ করা উচিত নয়।

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


2

বিদ্যমান উত্তরের মধ্যে প্রচুর জ্ঞান রয়েছে, তবে আমি আরও একটি কারণে যুক্ত করতে চাই: ভাষা

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

উদাহরণস্বরূপ, জাভাতে সহজেই তিনটি বৈশিষ্ট্য সহ একটি নতুন শ্রেণি লিখতে 50 টি লাইন লাগতে পারে, প্রতিটি গেটর এবং সেটার এবং এক বা একাধিক কনস্ট্রাক্টর - আপনি কোটলিন * বা স্কালার একক লাইনে ঠিক একই অর্জন করতে পারবেন। (এমনকি বৃহত্তর সংরক্ষণ করেন তাহলে আপনি উপযুক্ত চেয়েছিলেন equals(), hashCode()এবং toString()পদ্ধতি।)

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

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

সুতরাং জিনিসগুলি সঠিকভাবে করার 'ব্যয়' ভাষার উপর নির্ভর করে। সম্ভবত কোনও ভাল ভাষার একটি চিহ্ন হ'ল এটি আপনাকে ভাল করে কাজ করার এবং সহজভাবে সম্পাদন করার মধ্য দিয়ে পছন্দ করে না !

(* এটি কোনও প্লাগের জন্য সত্যিই জায়গা নয়, তবে কোটলিন আইএমএইচও-র প্রতি মূল্যবান)


1

ধরে নেওয়া যাক আপনি Contactবর্তমানে ক্লাসের সাথে কাজ করছেন। আপনি যে ইমেল ঠিকানার বৈধতার জন্য অন্য পদ্ধতি লিখছেন তা ক্লাসটি Contactকোনও একক দায়িত্ব পরিচালনা করছে না তার প্রমাণ is

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


আপনার কোডটি একটি কোড Contactএবং Emailক্লাসের একটি ফিউশন যা এর আরও প্রমাণ হ'ল আপনি ইমেল বৈধকরণ কোডটি সহজেই পরীক্ষা করতে পারবেন না। সঠিক মান সহ একটি বড় পদ্ধতিতে ইমেল বৈধকরণ কোডটিতে পৌঁছানোর জন্য এটি প্রচুর কসরত করতে হবে। নীচের পদ্ধতিটি দেখুন।

private void LargeMethod() {
    //A lot of code which modifies a lot of values. You do all sorts of tricks here.
    //Code.
    //Code..
    //Code...

    //Email validation code becoming very difficult to test as it will be difficult to ensure 
    //that you have the right data till you reach here in the method
    ValidateEmail();

    //Another whole lot of code that modifies all sorts of values.
    //Extra work to preserve the result of ValidateEmail() for your asserts later.
}

অন্যদিকে, আপনার যদি ইমেল বৈধতার জন্য একটি পৃথক ইমেল শ্রেণি থাকে, তবে আপনার বৈধতা কোডটি পরীক্ষা করার জন্য আপনি কেবল Email.Validation()নিজের পরীক্ষার ডেটা দিয়ে একটি সাধারণ কল করতে পারবেন ।


বোনাস সামগ্রী: পরীক্ষারযোগ্যতা এবং ভাল ডিজাইনের মধ্যে গভীর সহমর্মিতা সম্পর্কে এমফিডারের আলোচনা talk


1

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

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

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

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


1

আপনি একটি বৈধ বাণিজ্য বন্ধ চিহ্নিত করেছেন

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

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

লোভী অ্যালগরিদম এই ক্ষেত্রে ব্যর্থ হতে পারে

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

আমার মনে হয় আমি যখন এই যাত্রাটি ছেড়েছিলাম, তখন এই সাধারণ সিআরইউডি এপিআই এমন পর্যায়ে ছিল যেখানে আপনি প্রতি পৃষ্ঠায় 30 লাইনে এটি মুদ্রণ করলে এটি একটি বালুচরে 10-20 পাঁচশো পৃষ্ঠার পাঠ্যপুস্তক গ্রহণ করবে: এটি পুনরাবৃত্তির একটি সম্পূর্ণ এনসাইক্লোপিডিয়া ছিল কোড। প্রয়োজনীয় জটিলতার ক্ষেত্রে, আমি নিশ্চিত নই যে সেখানে প্রয়োজনীয় জটিলতার একটি পাঠ্যপুস্তকের অর্ধেকও ছিল; এটি হ্যান্ডেল করার জন্য আমাদের কাছে কেবল 5-6 ডাটাবেস ডায়াগ্রাম ছিল। এটিতে সামান্য পরিবর্তন করা একটি বিশাল উদ্যোগ ছিল, এটি শেখার একটি বিশাল উদ্যোগ ছিল, নতুন কার্যকারিতা যুক্ত করা এত বেদনাদায়ক হয়েছিল যে আমাদের কাছে বয়লারপ্লেট টেম্পলেট ফাইল রয়েছে যা আমরা নতুন কার্যকারিতা যুক্ত করতে ব্যবহার করব।

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

সেরা অনুশীলন: কল করার জন্য ডিআরওয়াই এবং দৈর্ঘ্য ব্যবহার করুন

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

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

এবং তার তীব্র প্রতিক্রিয়া সহজভাবে ছিল, "আমাদের প্রয়োজন হলে আমরা পরে সবসময় এটি করতে পারি" "

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

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

  1. আপনি যখন এটি অনুলিপি-আটকাতে চান তখন কোনও ফাংশন / পদ্ধতিতে একটি পরীক্ষা করে রিফ্যাক্টর করুন। কপিরাইট-পেস্ট করার মাঝে মাঝে বৈধ কারণ রয়েছে তবে আপনার এটি সম্পর্কে সর্বদা নোংরা হওয়া উচিত। সত্যিকারের লেখকরা আখ্যায়িতভাবে 50 বার একটি বড় দীর্ঘ বাক্যটি পুনরায় পাঠাতে পারবেন না যতক্ষণ না তারা সত্যই কোনও থিম হাইলাইট করার চেষ্টা করছেন।
  2. কোনও ফাংশন / পদ্ধতিটি আদর্শভাবে একটি "অনুচ্ছেদ" হওয়া উচিত। বেশিরভাগ ফাংশনগুলি প্রায় অর্ধেক পৃষ্ঠা দীর্ঘ বা কোডের 1-15 লাইন হওয়া উচিত এবং কেবলমাত্র আপনার 10% ফাংশন একটি পৃষ্ঠায় এবং অর্ধ, 45 টি লাইন বা তার বেশি রেঞ্জের মঞ্জুরি দেওয়া উচিত। আপনি একবার 120+ কোডের কোড এবং মন্তব্যে থাকলে সেই জিনিসটিকে কিছু অংশে ভাঙতে হবে।
  3. একটি ফাইল আদর্শভাবে একটি "অধ্যায়" হওয়া উচিত। বেশিরভাগ ফাইল 12 পৃষ্ঠার দীর্ঘ বা তার কম হওয়া উচিত, তাই কোড এবং মন্তব্যের 360 লাইন। কেবলমাত্র আপনার 10% ফাইলকে 50 পৃষ্ঠার দীর্ঘ বা কোড এবং মন্তব্যের 1500 লাইনের মধ্যে থাকতে দেওয়া উচিত।
  4. আদর্শভাবে, আপনার বেশিরভাগ কোডটি ফাংশনের বেসলাইন বা এক স্তর গভীর দিয়ে ইন্টেন্ট করা উচিত। লিনাক্স উত্স বৃক্ষ সম্পর্কে কিছু তাত্পর্যপূর্ণ ভিত্তিতে, যদি আপনি এটি সম্পর্কে ধর্মীয় হন তবে কেবল আপনার কোডের 10% বেসডলাইনের মধ্যে 2 স্তরের বা আরও বেশি, 5% এর চেয়ে কম ইন্ডেন্টড 3 স্তর বা তারও বেশি হওয়া উচিত more এর অর্থ হল বিশেষত যে জিনিসগুলিকে অন্য কিছু উদ্বেগের "মোড়ক" লাগানো দরকার, তেমনি একটি বড় চেষ্টা / ধরার ক্ষেত্রে ত্রুটি পরিচালনা করার মতো বিষয়গুলিকে প্রকৃত যুক্তি থেকে টেনে আনা উচিত।

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

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