আরও ভাল উত্পাদনশীলতা পেতে বোকা হচ্ছে?


112

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

if(xxx) {
    doSomething();
}

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

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

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

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

আমি প্রায়শই আমার ফলাফলগুলির সাথে খুব সন্তুষ্ট বোধ করি - ভাল কোড যা কেবলমাত্র A করতে পারে তা খারাপ কোডের চেয়ে খারাপ যা এ, বি, সি এবং ডি করতে পারে worse

এই পদ্ধতির ফলে কোনও সফ্টওয়্যার প্রকল্পের জন্য ইতিবাচক নেট লাভের সম্ভাবনা রয়েছে, বা এটি সময় নষ্ট করে?


141
আমি আপনার সলিডটি দেখতে পাচ্ছি এবং আপনাকে ইয়াগনি এবং কেআইএসএস
জে কে

16
বুম, হেডশট
রবার্ট এস

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

4
হতে পারে এটি কেবলমাত্র আমি তবে আমি আমার মক্কেল / নিয়োগকর্তাকে এমন কিছু দেওয়ার জন্য অর্থ ব্যয় করা "বোকামি" হিসাবে বিবেচনা করব যা তারা অনুরোধ / চায় নি: এস
টমাস বনিনি

2
ভবিষ্যতে কোনও বৈশিষ্ট্য যখন এটির প্রয়োজন হয় তখন এটি যোগ করা প্রায় কখনই শক্ত হয় না। আপনি এখন এটি করে কিছুই অর্জন করবেন না।
হার্ডওয়্যারগুই

উত্তর:


153

ভাল কোড যা কেবল এ করতে পারে তা খারাপ কোডের চেয়ে খারাপ যা এ, বি, সি, ডি করতে পারে

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

তাই:

ভাল কোড যা কেবল এ করতে পারে (তবে এটি সহজ এবং পরিষ্কারভাবে একটি জিনিস করছে) খারাপ কোডের চেয়ে ভাল যা এ, বি, সি, ডি করতে পারে (যার মধ্যে কিছু ভবিষ্যতে কখনও কখনও প্রয়োজন হতে পারে)।


87
"ভবিষ্যতের ভবিষ্যদ্বাণী করার ক্ষেত্রে আমরা সাধারণত খুব খারাপ" ব্যবহারকারীরা সম্ভবত ই :) এর জন্য জিজ্ঞাসা করবেন
মাইচা পিয়াসকোভস্কি

1
+1 আরও সম্মত হতে পারে না। আমি সম্প্রতি একটি সংস্থায় একটি কাজের মেয়াদ শেষ করেছি এবং আমি এটি শিখেছি সবচেয়ে গুরুত্বপূর্ণ পাঠ বিবেচনা করব।
উইপকজন

4
@ মাইচা, এটি কি ভবিষ্যদ্বাণী? ;-)
পিটার টারিক

10
এমনকি তারা আপনাকে ডি-র জন্য জিজ্ঞাসা করলেও তাদের সম্ভবত এটির ভিন্ন মানসিক মডেল থাকবে এবং আপনার বিমূর্ততা সমর্থন করে না এমন কিছুটা ভিন্ন ধরণের ডি চাইবে ...
ক্রিস বার্ট-ব্রাউন

"যদি সমস্যাটি পুরোপুরি বোঝা না যায় তবে সম্ভবত কোনও সমাধান না দেওয়া সবচেয়ে ভাল" বা "যদি কোনও বাস্তবায়নকারী এটি ব্যতীত সত্যিকারের অ্যাপ্লিকেশনটি সম্পূর্ণ না করতে পারে তবে নতুন কার্যকারিতা যুক্ত করবেন না।" এখানে প্রযোজ্য। এর মাধ্যমে en.wikipedia.org/wiki/X_Window_System#Principles
nwahmaet

87

উপাখ্যানের সময়:

আমার পক্ষে দু'জন বিকাশকারী কাজ করেছেন যারা এই পদ্ধতিতে ওভার ইঞ্জিনিয়ারিংয়ের দিকে ঝুঁকছেন।

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

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

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

তাই না।

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


10
সম্ভব হিসাবে সহজ হিসাবে সহজ +1 কিন্তু।
জুলিয়ান

33
"একজন ডিজাইনার জানেন যে যখন যোগ করার মতো কিছুই অবশিষ্ট থাকে না তখন যখন তিনি সিদ্ধি অর্জন করেছিলেন তবে যখন যখন কিছুই নিতে হবে না"।
আন্টোইন

প্লেগের মতো সদৃশতা এড়িয়ে চলুন এবং আপনি কোনও ভুল হতে পারবেন না।
কেভিন 15

@ আরখ ... আমি একই উক্তিটি ব্যবহার করতে যাচ্ছিলাম: পি
মাইকেল ব্রাউন

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

26

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

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

আমি এই সহজ তিন-পদক্ষেপ পদ্ধতি অনুসরণ করতে চাই।

  • প্রথম পাসে, এটি কাজ করুন।
  • দ্বিতীয় পাসে এটি পরিষ্কার করুন।
  • তৃতীয় পাসে এটি সলিড করুন।

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

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


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

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

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

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

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

17

ভাল কোড যা কেবল এ করতে পারে তা খারাপ কোডের চেয়ে খারাপ যা এ, বি, সি, ডি করতে পারে

1) একটি কোড আছে যা কেবল যা করার কথা তা করে।

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

2) আপনি যদি আপনার কোড এ, বি, সি এবং ডি করার পরিকল্পনা করেন তবে গ্রাহক শেষ পর্যন্ত আপনাকে E এর জন্য জিজ্ঞাসা করবেন

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

আমি আপনাকে একটি ভাল বই পড়ার পরামর্শ দিচ্ছি: প্র্যাকমেটিক প্রোগ্রামার । এটি আপনার মন খুলবে এবং আপনাকে কী করা উচিত এবং কী করা উচিত নয় তা শিখিয়ে দেবে।

এছাড়াও কোড কমপ্লিট হ'ল দরকারী তথ্য পূর্ণ পূর্ণ সংস্থান যা প্রতিটি বিকাশকারী (কেবল প্রোগ্রামার নয়) পড়া উচিত।


12

খুব সহজেই আমাকে কোডের একটি সহজ টুকরো লিখতে হবে, আমি ভবিষ্যতের কথা চিন্তা করি

এখানেই সমস্যা।

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

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

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

মনে রাখবেন: বৃহত্তর কোডবেস মানে আরও রক্ষণাবেক্ষণ। আপনি যখন এড়াতে পারেন তখন আরও কোড লিখবেন না।

আপনার দৃষ্টিভঙ্গি অন্যদিকেও ক্ষতিকারক:

  • আপনার যদি কোনও বৈশিষ্ট্য অপসারণের প্রয়োজন হয়, তবে কয়েক ডজন শ্রেণীর মধ্যে নির্ভরতা বোঝার জন্য আপনার সময় নষ্ট করার চেয়ে নির্দিষ্ট বিশ লাইন পদ্ধতিটি কোথায় ব্যবহৃত হয়েছে তা নির্ধারণ করা কি সহজ নয়?

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

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


"কয়েক ডজন আধা-খালি ক্লাস" এর অতিরিক্ত অসুবিধাগুলি রয়েছে যে এই ক্লাসগুলির জন্য কী ভাল তা বোঝার জন্য পর্যাপ্ত উপাদান নেই।
gnasher729

5

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


3

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


3

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

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

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


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

@ কোডার অনুমান করার চেষ্টা করবেন না যে কোনও সময়ে আর্কিটেকচারটি পরিবর্তন হতে পারে না। এটা করতে পারে এবং করতে পারে।
রিকি ক্লার্কসন

1
ওয়েইন এম, আমি আপনার কাজের পরিস্থিতিতে সহানুভূতি জানাতে পারি। বাহিনীর সাথে থাকুন। :)
জেনিফার এস

3

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

আমি আপনার পরিস্থিতি দেখে এই প্রশ্নগুলি জিজ্ঞাসা করব:

  1. এই কোড স্টাফ যা মিশন সমালোচনামূলক এবং আমি পুনরায় কোড দিলে তা কি আরও বেশি স্থিতিশীল হবে? শল্য চিকিত্সা বলতে, এই রিফ্যাক্টরিং জীবন রক্ষাকারী, বা এটি নিছক বৈকল্পিক এবং প্রসাধনী?

  2. আমি কি রিফ্যাকচারিং কোডটি বিবেচনা করছি যা আমরা 6 মাসের মধ্যে প্রতিস্থাপন করব?

  3. আমি রিফ্যাক্টরিংয়ের জন্য ব্যয় করতে আমি কি ভবিষ্যতের বিকাশকারীদের জন্য নকশাটি এবং আমার যুক্তিটি নথিতে ডকুমেন্ট করতে যতটা সময় নিতে চাই?

  4. ভবিষ্যতের বৈশিষ্ট্যগুলি যুক্ত করার জন্য আমার মার্জিত ডিজাইনের বিষয়ে, ব্যবহারকারীরা প্রতি সপ্তাহে পরিবর্তনের জন্য অনুরোধ করার কোডটিতেই কি এই বছর প্রথমবারের মতো স্পর্শ করা যায়?

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


3

স্ট্রোস্পেস্পস 'দ্য সি ++ প্রোগ্রামিং ল্যাঙ্গুয়েজ' এর দ্বিতীয় সংস্করণে (আমি পৃষ্ঠাটি উপলভ্য নেই) আমি পড়েছি

জায়গায় স্বতঃস্ফূর্ত কোড যোগ করবেন না।

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

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

তবে তারপরে আপনাকে YAGNI প্রশ্নটি জিজ্ঞাসা করতে হবে: এটির কি মূল্য? এটি কি সত্যিই কার্যকর হবে? অভিজ্ঞ হওয়ার অর্থ হ'ল, আপনি খুব কমই ভুল হতে পারেন, এবং একজন শিক্ষানবিস হিসাবে প্রায়শই ভুল।

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

সমাধানটি এই বা এটি নয়, এটি সম্পর্কে চিন্তা করা। :)


2

"ভাল কোড যা কেবলমাত্র এ করতে পারে তা খারাপ কোডের চেয়ে খারাপ যা এ, বি, সি এবং ডি করতে পারে" "

এটি পণ্য বিকাশে কিছুটা অর্থ বোধ করতে পারে; তবে বেশিরভাগ তথ্যপ্রযুক্তি পেশাদার পণ্য বিকাশকারী না হয়ে 'প্রকল্পগুলিতে' কাজ করেন।

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

অনেকেই 'উইন্ডোজ সিটিএল + আল্ট + ডেল' প্রোগ্রাম করার সুযোগ পান না এবং যারা এই সুযোগটি পান তারা তাদের কোডের ভবিষ্যতের সম্ভাব্যতা বুঝতে পারে না!


1

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


1

এটি মজাদার যে কীভাবে লোকেরা সঠিকভাবে / ভুল কাজের উপায় সম্পর্কে কথা বলে। একই সময়ে প্রোগ্রামিংয়ের কাজটি এখনও বেদনাদায়ক কঠিন এবং বড় জটিল সিস্টেমগুলি লেখার জন্য কোনও ভাল সমাধান দেয় না।

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


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

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

1

এমন প্রাককালীন সাধারণ নকশাগুলি দেখেছি যা পরে এসেছিল আসল প্রয়োজনীয়তার সাথে পুরোপুরি খাপ খায় না, আমি আমার জন্য একটি নিয়ম তৈরি করেছি:

অনুমানের প্রয়োজনীয়তার জন্য কেবল অনুমানের কোড লিখুন।

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


0

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

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


0

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

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

বাকিগুলি ইতিমধ্যে কিথস বলেছে


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

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

0

নিজেকে জিজ্ঞাসা করুন একটি ভাল ডিজাইনের সুবিধা কী:

  • বোঝা সহজ
  • সহজ রক্ষণাবেক্ষণ
  • সুবহ
  • দীর্ঘ সময় ধরে দরকারী
  • নতুন বৈশিষ্ট্য যুক্ত করা সহজ

এখন, নিজেকে জিজ্ঞাসা করুন যে বিমূর্ততার সমস্ত স্তরগুলি যুক্ত করে উপরে উল্লিখিত পয়েন্টগুলির মধ্যে সত্যিই যুক্ত হয় কিনা। যদি এটি না হয় তবে আপনি এটি ভুল করছেন ।

যদি আপনি এই জাতীয় 3 টি লাইনের কোড যুক্ত করে একটি নতুন বৈশিষ্ট্য যুক্ত করতে সক্ষম হন:

if (condition()) {
  doSomething()
}

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

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

আপনি যদি এটির মতো কাজ করেন তবে আপনি কখনই কোনও কিছুর অতিরিক্ত নকশা করবেন না। আপনি যখন নতুন কিছু যুক্ত করতে চান বা নতুন কোডটি কিছুটা কুরুচিপূর্ণভাবে ছেড়ে যেতে চান তখন আপনার পুরানো কোডটিতে ফিরে যেতে কিছুটা শৃঙ্খলা লাগতে পারে তবে আপনি ওভার ইঞ্জিনিয়ারের পরিবর্তে উত্পাদনশীল কোনও দিকে কাজ করবেন।

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