কোন জনপ্রিয় "সেরা অনুশীলন" সর্বদা সেরা হয় না এবং কেন? [বন্ধ]


100

"সেরা অনুশীলন" আমাদের শিল্পের সর্বত্র রয়েছে। "কোডিং সেরা অনুশীলনগুলি" সম্পর্কে একটি গুগল অনুসন্ধান প্রায় 1.5 মিলিয়ন ফলাফলকে সরিয়ে নিয়েছে। ধারণাটি অনেকের কাছে স্বস্তি বয়ে নিয়েছে; কেবল নির্দেশাবলী অনুসরণ করুন, এবং সবকিছু ঠিকঠাক হয়ে উঠবে।

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

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

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

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

আমি নির্দিষ্ট উদাহরণ এবং অভিজ্ঞতা সম্পর্কে শুনতে পছন্দ করব।


8
কোনটি অনুশীলনের সাথে আপনি একমত নন ?, কেবল কৌতূহলী।
সেরজিও আকোস্টা

যে কেউ একটি বই লিখতে পারে, এবং আমার এটির সাথে একমত হতে হবে না - এটি এতটা সহজ।
চাকরী

স্টিভ ম্যাককনেলের "কোড কমপ্লিট" বইটি সম্পর্কে আমি একটি জিনিস পছন্দ করি তা হ'ল তিনি দৃ evidence় প্রমাণ এবং গবেষণা দিয়ে তার সমস্ত টিপসকে ব্যাক আপ করেন। শুধু বলুন '
JW01

5
@ ওয়াল্টার: এটি কয়েক মাস ধরে খোলা ছিল, এটি অবশ্যই গঠনমূলক, কেন এটি বন্ধ করুন?
2-28 এ Orbling

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

উত্তর:


125

আমি মনে করি আপনি এই বিবৃতি দিয়ে মাথায় পেরেকটি আঘাত করেছেন

আমি জিনিসগুলিকে গুরুত্বের সাথে বিবেচনা করতে এবং সমালোচনা করে সেগুলি সম্পর্কে ভাবি না hate

কেন এটি বিদ্যমান তা নিয়ে যখন ব্যাখ্যা আসে না তখন আমি প্রায় সমস্ত সেরা অভ্যাসগুলিকে উপেক্ষা করি

রেমন্ড চেন তিনি যখন বলেন তখন এই নিবন্ধে এটি সর্বোত্তমভাবে রাখে

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


4
অপূর্ব উক্তি।
ডেভিড থর্নলি

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

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

3
যুক্তি ভালো। গবেষণা আরও ভাল।
জন পুরি

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

95

এটিকেও রিংয়ের মধ্যে ফেলে দিতে পারে:

Premature optimization is the root of all evil.

না এইটা না.

সম্পূর্ণ উদ্ধৃতি:

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

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

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

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


4
শক্তিশালী না,
স্টিফেন

21
তবে আপনি যদি ইতিমধ্যে স্বীকৃত হয়ে থাকেন যে একটি নির্দিষ্ট অপ্টিমাইজেশন সেই সমালোচনামূলক 3% এর মধ্যে রয়েছে, তবে আপনি কি এটি অনুকূলিতকরণে অকাল?
জন

7
@ রবার্ট: তারপরে "" অকালীন অপটিমাইজেশন সমস্ত মন্দের মূল "এই বক্তব্যটির সাথে মতবিরোধের কী আছে?
জন

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

8
@ রবার্ট, নথের উদ্ধৃতিটি অকালে অপ্টিমাইজ করা হয়েছিল ...

94

ফাংশন / পদ্ধতিতে এক রিটার্ন।


7
আমি এই করা যাচ্ছে। আমি কিছু তাড়াতাড়ি রিটার্ন বিবৃতি আমাকে ভালবাসি।
কারসন মায়ার্স

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

4
আপনার যদি কোনও ফাংশনে একাধিক রিটার্নের প্রয়োজন হয় (প্রহরীকে বাদ দিয়ে) আপনার ফাংশনটি সম্ভবত খুব দীর্ঘ।
এরিকশাফার

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

7
আমি মনে করি এটি একটি অত্যন্ত পুরানো সেরা অনুশীলন। আমি মনে করি না এটি একটি আধুনিক সেরা অনুশীলন।
স্কিলড্রিক

87

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

সমস্যাটি হ'ল একটি 100% উপযুক্ত সমাধান খুব কমই বিদ্যমান। একটি 80% উপযুক্ত সমাধান উপস্থিত থাকতে পারে এবং এটি ব্যবহার করা সম্ভবত ভাল। তবে কীভাবে প্রায় 60% উপযুক্ত? 40%? আপনি কোথায় রেখা আঁকেন? আপনি যদি লাইনটি আঁকেন না, তবে আপনি আপনার প্রকল্পে একটি পুষ্পিত গ্রন্থাগার অন্তর্ভুক্ত করতে পারেন কারণ আপনি এর বৈশিষ্ট্যগুলির 10% ব্যবহার করছেন - কেবলমাত্র আপনি "চাকা পুনরুদ্ধার" এড়াতে চান বলে।

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


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

20
একমত। যদি কেউ এই চক্রটিকে পুনরায় উদ্ভাবন না করে, তবে আমরা সবাই কাঠের টায়ারে গাড়ি চালাচ্ছি।
ডঃ উইলির অ্যাপ্রেন্টিস

6
আমি যখন C ++ প্রকল্পে বুস্ট যুক্ত করি তখন আমি সর্বদা আপনার 10% উদাহরণের মতো বোধ করি। আমার সর্বদা এটির 10% এরও কম প্রয়োজন, তবে অবশ্যই যে ক্রিয়াকলাপগুলির জন্য আমার অন্যান্য মডিউলগুলি আমদানি করা দরকার যা অন্যান্য মডিউলগুলি আমদানি করে ...
রোমান স্টারকভ

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

2
@ডাঃ. উইলি, whe চাকাগুলি নতুনভাবে তৈরি করা হয়নি, সেগুলি রিফ্যাক্টর করা হয়েছিল!

78

"ইউনিট টেস্ট সবকিছু।"

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

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


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

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

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

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

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

57

সবসময় ইন্টারফেস প্রোগ্রাম।

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


4
সম্মতি জানানো হয়েছে, যখন আপনার কোনও ইন্টারফেসের প্রয়োজন হয় তখন আপনি একটি ইন্টারফেসে প্রোগ্রাম করেন (যেমন কাজ করার জন্য একটি স্থিতিশীল এপিআই)।
রবার্ট হার্ভে

45
আমার পড়ার ক্ষেত্রে এই নিয়মটি ভাষা গঠন হিসাবে ইন্টারফেস সম্পর্কে নয়। এর অর্থ হ'ল কোনও শ্রেণীর অভ্যন্তরীণ কাজগুলি সম্পর্কে পদ্ধতিগুলি কল করার সময় আপনার কোনও অনুমান করা উচিত নয় এবং কেবলমাত্র এপিআই চুক্তিতে নির্ভর করা উচিত।
Zsolt Török

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

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

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

46

কোনও ওপেন সোর্স (বা আপনার জন্য নন-মাইক্রোসফ্ট। নেট বিকাশকারী) ব্যবহার করবেন না

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

  • মনে রাখবেন এটি আপনার সেরা অনুশীলন নাও হতে পারে , তবে আমি যেখানে কাজ করেছি প্রায় সর্বত্র এটি একটি সাধারণ common

13
ভয়াবহ শোনায় ... = (আমি সম্ভবত অন্যদিকে খুব বেশি, যদিও আমি এম-কে যথাসম্ভব এড়িয়ে
চলেছি

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

4
আপনি আইবিএম ^ ডব্লিউমাইক্রোসফ্ট কেনার জন্য বরখাস্ত হবেন না
ক্রিস্টোফার মাহান

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

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

40

অবজেক্ট ওরিয়েন্টেশন

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


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

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

7
আমি যা বোঝাতে চেয়েছি তা হ'ল আমার মনে হয় আমাদের সবচেয়ে উপযুক্ত পদ্ধতিটি ব্যবহার করা উচিত। আমি লোককে এমন পদ্ধতি এবং ক্লাস ব্যবহার করতে দেখেছি যেখানে এটি জটিল এবং এগুলি বোঝায় না, কেবল "এটি বস্তু-ভিত্তিক" বলে because এটাই কার্গো কাল্ট।
লেনি প্রোগ্রামার্স

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

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

35

সমস্ত কোড মন্তব্য করা উচিত।

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

/** hey you, if didn't get, it's logger. */
private static Logger logger = LoggerFactory.getLogger(MyClass.class);

13
সমস্ত কোড বোধগম্য হওয়া উচিত । মন্তব্যগুলি এতে একটি প্রধান সরঞ্জাম, তবে এটি কেবলমাত্র একটি থেকে অনেক দূরে।
ট্র্যাভেল

নিখুঁতভাবে, কোডটি বোধগম্য হওয়া উচিত। তবে কোনও মন্তব্য লেখার কোনও একক কারণ নেই যা কিছু যোগ করবে না, উদাহরণস্বরূপ, পদ্ধতির নাম। আপনি যদি লিখেন /** sets rank. */ void setRank(int rank) { this.rank = rank; }আমি মন্তব্যটি বোকা হিসাবে ধরে নিই। কেন লেখা হচ্ছে?
ভ্লাদিমির ইভানভ 17'11

2
তৈরি ডকুমেন্টেশন। যে কি /** */বিন্যাসের পরিবর্তে জন্য /* */বিন্যাস মন্তব্য নেই। বা। নেট এর জন্য এটি হবে///
বারিন লরিটস

10
ব্যবহার }//end if, }//end for, }//end whileমন্তব্য আমি কখনো সম্মুখীন হয়েছি অযথা শ্রেষ্ঠ উদাহরণ। আমি এটি বহুবার দেখেছি যেখানে উদ্বোধনী ব্রেস উপরে 2 লাইনের বেশি নয়। আপনি এই প্রোগ্রামটিতে যদি প্রয়োজন এসব মন্তব্য তারপর আপনার কোড চাহিদা পুনরায় ফ্যাক্টরিং ... অথবা আপনি $ 20 পর্যন্ত টাট্টু এবং আইডিই / টেক্সট এডিটর হাইলাইট যে ধনুর্বন্ধনী মিলে কিনতে হবে।
স্ক্যানলিফ

7
কোড "কীভাবে" বলে। মন্তব্যে "কেন" বলা দরকার।

32

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

চতুর পদ্ধতিতে জ্ঞানের নাগেট রয়েছে --- সেগুলির অনেকগুলি --- তবে তারা প্রায়শই এত বেশি সারে বসে থাকে যে আমি আমার ঠাট্টা প্রতিবিম্বের সাথে লড়াই করতে পারি না। উইকিপিডিয়া এর স্ক্র্যাম পৃষ্ঠা থেকে এই বিট নিন :

বেশ কয়েকটি ভূমিকা স্ক্রমে সংজ্ঞায়িত করা হয়। সমস্ত ভূমিকা দুটি পৃথক গোষ্ঠী — শূকর এবং মুরগির মধ্যে পড়ে the উন্নয়ন প্রক্রিয়াতে তাদের জড়িত থাকার প্রকৃতির উপর ভিত্তি করে।

সত্যি? শূকর ও মুরগি, আপনি বলছেন? আকর্ষনীয়! আমার মনিবকে এটি পিচ করার জন্য অপেক্ষা করতে পারি না ...


মজাদার. আমি কিছুটা হলেও একমত যদিও শেষ অংশটির সাথে: আপনি যা চান তাদের কল করুন, তারা স্মৃতিবিদ, এগুলিই।
স্টিভেন এভার্স

12
+1 ... আপনি ঠিক বলেছেন, এটিকে গুরুত্ব সহকারে নেওয়া শক্ত। <বিগমিং ভয়েস> * আমি স্ক্রিমমাস্টার * </ পছন্দ>
গ্র্যান্ড

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

2
স্ক্রাম নিনজাস সম্পর্কে কী?
বেরিন লরিটশ

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

25

বিষয় সম্পর্কিত ম্যাপিং ... http://en.wikedia.org/wiki/Object- সম্পর্কিত সম্পর্কিত_ মানচিত্র

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


19
অকালীন অপটিমাইজেশন হ'ল সমস্ত অশুভের মূল। অবিশ্বাস্য কোডের সাথে তুলনা করলে স্লো কোডটি আসল জীবনে কেবল অবিশ্বাস্যভাবে বিরল সমস্যা। একটি ORM ব্যবহার করুন, তারপরে কেবল যেখানে আপনার প্রয়োজন সেখানে বিমূর্ততাটি কেটে নিন।
ফিশটোস্টার

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

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

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

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

22

ফাংশন নাম লিখলে যেন তারা ইংরেজী বাক্য:

Draw_Foo()
Write_Foo()
Create_Foo()

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

Foo_Draw()
Foo_Write()
Foo_Create()

প্রভৃতি


2
সম্ভবত টিএম এর ফাংশন তালিকায় ফু টাইপ করার মতো সহজ।
জোশ কে

68
মনে হচ্ছে আপনি আসলে এটি হতে চান Foo.Draw(), Foo.Write()এবং Foo.Create(), যাতে আপনি করতে পারেন Foo.methods.sortবাFoo.methods.grep([what I seek]).sort
ইনাইমথি

7
'গেট' দিয়ে শুরু করা অন্য উদাহরণ।
জেফো

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

2
@ স্কট হুইটলক: কিছু। নেট বিকাশকারী, আইরিচ, ভিএস ২০০৮ এর ক্ষেত্রে এটি পুরানো নয় । ২০১০ যদিও করে এবং এটি দুর্দান্ত।
স্টিভেন এভার্স 21

22

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

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


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

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

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

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

1
আমি ব্যক্তিগতভাবে আকৃতির-> আয়তক্ষেত্র-> বর্গক্ষেত্রের উদাহরণটি ওওপের বিরুদ্ধে সর্বাধিক মার্জিত যুক্তি হিসাবে বিবেচনা করি । উদাহরণস্বরূপ, Square(10).Draw()এটি যথেষ্ট Rectangle(10, 10).Draw()। সুতরাং আমি অনুমান করি যে বর্গ মানে আয়তক্ষেত্রের একটি উপক্লাস। তবে mySquare.setWidthHeight(5,10)বাজে কথা (IE, এটি লিসকোভ প্রতিস্থাপনের নীতি ব্যর্থ করে), একটি বর্গক্ষেত্রের উচ্চতা এবং প্রস্থ থাকতে পারে না, যদিও একটি আয়তক্ষেত্র পারে, যাতে বোঝা যায় যে আয়তক্ষেত্রটি একটি বর্গের উপক্লাস। এটি অন্যান্য প্রসঙ্গে "চেনাশোনা, উপবৃত্ত সমস্যা" হিসাবে পরিচিত
সিঙ্গেল নেজেশন ইলিমিনেশন

22

YAGNI

( আপনার দরকার নেই )

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

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

(অবশ্যই যে কেউ যুক্তি দিতে পারেন যে একটি সু-নকশাকৃত কোডবেস এছাড়াও পরে বৈশিষ্ট্যগুলি যুক্ত করার অনুমতি দেয় তবে বাস্তবতা ভিন্ন)


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

12
পি.ফ্লয়েড, @ জেসন বেকার: +1 একেবারে ঠিক। পুরানো প্রবাদটি এখানে প্রয়োগ করা হয়েছে "কয়েক মাস ল্যাবরেটরে লাইব্রেরিতে ঘন্টা বাঁচাতে পারে"
স্টিভেন ইভার্স

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

1
@ টোকেনম্যাকগুয়াই গুরুত্বপূর্ণ দিকটি অনুচ্ছেদে অংশ দ্বারা বোঝানো হয়েছে । মতামত অনেক পৃথক যেখানে।
শন প্যাট্রিক ফ্লয়েড

20

এসকিউএল জন্য

  1. ট্রিগার ব্যবহার করবেন না
  2. সবসময় দর্শনের পিছনে সারণীগুলি আড়াল করুন

ক্রমানুসারে:

  1. এগুলি একটি বৈশিষ্ট্য যার এটির স্থান রয়েছে। আপনার একটি টেবিলের একাধিক আপডেট পাথ রয়েছে, বা 100% অডিটিং প্রয়োজন?

  2. শুধু কেন? আমি যদি আমি চুক্তিটি বজায় রাখার জন্য পুনঃপ্রেরণ করছিলাম তবে আমি যখন পড়েছি যে কোনও লোকের টেবিলের পরিবর্তনের সাথে মেলে লোকেরা দৃষ্টিভঙ্গি পরিবর্তন করে

সম্পাদনা:

সংখ্যা 3: বিদ্যমান * সহ এড়ানো। 1/0 চেষ্টা করুন। এটা কাজ করে। এসকিউএল স্ট্যান্ডার্ড অনুযায়ী কলামের তালিকাটি মূল্যায়ন করা হয় না। পৃষ্ঠা 191


3
# 2 একটি সেরা অনুশীলন?
হোগান

2
@ হোগান: হ্যাঁ, এটি অনেক জায়গায় vyaskn.tripod.com/sql_server_security_best_practices.htm এবং flylib.com/books/en/3.404.1.34/1 এবং এর চেয়ে কম এখানে ডকুমেন্টেড রয়েছে
2009/08/06

1
@ হোগান: এমন একটি দৃশ্য যা কেবল বেস টেবিলটি আয়না করে সরাসরি বেস টেবিলটি সরাসরি ব্যবহার করার ক্ষেত্রে কোনও সুরক্ষা যোগ করে না। আপনি যদি কোনও সুরক্ষাকারী টেবিলের সাথে যোগ দেন, বা কিছু কলামগুলি মাস্ক করেন তবে যথেষ্ট fair তবে টেবিল থেকে প্রতিটি কলাম নির্বাচন করুন বা দেখুন: কোনও পার্থক্য নেই। ব্যক্তিগতভাবে, আমি যাইহোক স্টোরড প্রক্স ব্যবহার করি।
gbn

3
@Hogan: আমি SQL সার্ভার সম্পর্কে কিছু :-) জানেন stackoverflow.com/users/27535/gbn কি আমি বলতে চাচ্ছি GRANT নির্বাচন টেবিল নির্বাচন মানচিত্র দর্শনে মঞ্জুর করতে যদি ভিউ নির্বাচন করুন নেই কোন পার্থক্য নাই হবে * টেবিল থেকে
gbn

1
@ জিবিএন: আমি সম্মত সেখানে কোনও পার্থক্য নেই। আমি মনে করি আমরাও একই কথা বলছি। আমার অনুমান আমার মূল মন্তব্য ("# 2 একটি সেরা অনুশীলন?") আমার ব্যক্তিগত অভিজ্ঞতার উপর ভিত্তি করে তৈরি হয়েছিল যে ভিউগুলি (ট্রিগারগুলির মতো) সঠিকভাবে ব্যবহারের চেয়ে প্রায়শই মিস-ব্যবহৃত হয়। সুতরাং এই জাতীয় সেরা অনুশীলন কেবল অপব্যবহারের দিকে না বাড়িয়ে দেয়। যদি এটি একটি সেরা অনুশীলন হিসাবে বিবেচিত হয় তবে আপনি 100% ঠিক আছেন এটি খারাপ।
হোগান

20

বেশিরভাগ ডিজাইনের প্যাটার্নস। তারা বেশি ব্যবহৃত হয় এবং এর অধীনে ব্যবহার হয়।


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

2
কেবল এটিকে ভাষা ব্যবহার করে ভাষার গন্ধ নির্মূল করার প্রচেষ্টা হিসাবে দেখুন।
ফিলিপ দুপানোভিć

15

একক দায়িত্বের নীতি

("প্রত্যেক শ্রেণীর কেবলমাত্র একটি একক দায়িত্ব থাকতে হবে; অন্য কথায়, প্রতিটি শ্রেণীর একটি, এবং শুধুমাত্র একটি, পরিবর্তনের কারণ থাকতে হবে")

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

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

কল্পনা করুন যে। নেট এপিআই-র নির্মাতাদের যদি এই ধরণের মানসিকতা থাকে: তালিকা.সোর্ট (), তালিকা.বিপরীত (), তালিকা.ফিন্ড () ইত্যাদি এর চেয়ে আমাদের লিস্টসোর্টার, তালিকা-রিভার্সার এবং তালিকা অনুসন্ধানকারী শ্রেণি থাকে!

এসআরপি-র বিরুদ্ধে আর তর্ক করার পরিবর্তে (যা তাত্ত্বিকভাবে নিজেই ভয়ানক নয়) , আমি আমার দীর্ঘ-ঘূর্ণিত কাহিনীভিত্তিক কয়েকটি অভিজ্ঞতা শেয়ার করব:


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


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


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

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

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


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

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

3
2 য় মন্তব্য এখানে। প্রচুর "নীতিগুলি" অতিরিক্ত প্রয়োগ করা হয়। অনেকগুলি জিনিস রয়েছে যা ভাল ধারণা, যেখানে সঠিক বিপরীতে কাজ করা কখনও কখনও উপযুক্ত। ভাল প্রোগ্রামাররা যখন বিধিগুলি বিরতি জানেন। যেহেতু নিয়মগুলি "বিধি" নয়, তারা "বেশিরভাগ সময় ভাল অনুশীলন করার সত্যিকারের বোবা ধারণা ব্যতীত" এর বিবৃতি।
দ্রুত_ফেব্রুয়ারী

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

14

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

এছাড়াও, সাধারণ প্রাথমিক জিনিসগুলি প্রতিস্থাপন করা

0 == memberArray.length

শ্রেণীর মধ্যে যেমন ক্লাসের নিজস্ব পদ্ধতিতে কল রয়েছে

isEmpty()

প্রশ্নবিদ্ধ "উন্নতি" আইএমএইচও। সংযোজন: পার্থক্যটি হ'ল প্রথম চেকটি যা বলেছে ঠিক তা করে: অ্যারের দৈর্ঘ্য 0 হয় কিনা তা যাচাই করে, ঠিক আছে, অ্যারের দৈর্ঘ্যও চেক করতে isEmpty()পারে। তবে এটিও এভাবে প্রয়োগ করা যেতে পারে:

return null != memberArray ? 0 == memberArray.length : true;

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


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

এমনকি আমি আরও বলতে চাই যে কোনও কোনও ক্ষেত্রে 1-লাইন পদ্ধতি খুব কম হলেও একটি পদ্ধতি হওয়ার যোগ্য।


6
আমি ইস্যু হিসাবে খুব কমই এটি দেখতে। বেশিরভাগ ক্ষেত্রেই কারণ আমি সাধারণত একটি পদ্ধতিতে খুব বেশি দেখি, খুব কম নয়। যাইহোক, কিছু গবেষণা অনুসারে পদ্ধতিগুলিতে খুব কম জটিলতার মধ্যেও মাঝারিভাবে কম জটিলতার তুলনায় কিছুটা বাগের হার রয়েছে। enerjy.com/blog/?p=198
এমআইএ

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

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

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

@ জুনাস: যথেষ্ট ফর্সা
রবার্ট হার্ভে 21

13

"মন্তব্যে উদার হন"

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


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

6
সোভা যেভাবে এটি রেখেছিল তাতে আমার একমত হতে হবে। ক্লিন কোড মন্তব্য করার চেয়ে পছন্দনীয়।
রিওয়ালক

4
আপনার এখনও সেখানে "কেন" দরকার!

আমি বরং কারণ ব্যাখ্যা করে মন্তব্য করব। এর অর্থ কোডটি যখন লক্ষ্য করা যায় তখন আমার বিপরীত প্রকৌশলটিতে কম ভাবতে হবে।
দ্রুত_

12

GoTo ক্ষতিকারক হিসাবে বিবেচিত

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

যে কোনও "সেরা অনুশীলন" যা এর বিধিগুলিতে বুদ্ধিমান এবং ডকুমেন্টেড ব্যতিক্রমগুলির জন্য মঞ্জুরি দেয় না এটি কেবল সাধারণ ভয়ঙ্কর।


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

3
@ ম্যাথিউ এম। - সম্মত হয়েছেন - কাঠামোগত নিয়ন্ত্রণের বিবৃতিতে GOTO মেশানো বুদ্ধিমানের নয়। (এটি খাঁটি সি ছিল এবং এটি কোনও সমস্যা ছিল না
এমজেডবি

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

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

3
সরাসরি একটি স্টেটম্যাচিন বাস্তবায়ন সম্ভবত একটি অ্যান্টিপ্যাটার্ন। আক্ষরিক অর্থে রাজ্যগুলি এবং রূপান্তরগুলি প্রকাশ না করেই একটি রাষ্ট্র মেশিন রাখার প্রচুর উপায় রয়েছে। উদাহরণস্বরূপ,import re
সিঙ্গেলাইজেশন ইলিমিনেশন

12

কোডকে পরীক্ষামূলক করে তোলার জন্য আমরা যে ত্যাগ স্বীকার করি

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

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

সুতরাং আমরা এটি ঠিক করতে কি করতে পারি? আমাদের ভাষা আর্কিটেকচারে একটি গুরুতর পরিবর্তন প্রয়োজন:

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

সংক্ষেপে, আমাদের পরীক্ষা -নিরীক্ষার বিষয়টি মাথায় রেখে গ্রাউন্ড-আপ থেকে ডিজাইন করা একটি ভাষা প্রয়োজন ।


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

@ অ্যালন: আমার কাছে আছে, তবে এটি বিনামূল্যে থেকে দূরে , এটি বেশিরভাগ মানুষের পক্ষে বিকল্প নয়।
ব্লুরাজা - ড্যানি পিফ্লুঘুফুট

যদি আপনাকে প্রচুর কারখানার ক্লাস লিখতে হয় তবে আপনি কিছু ভুল করছেন। স্মার্ট ডিআই লাইব্রেরি (যেমন সি # এর জন্য অটোফ্যাক) নিজেকে কোনও বয়লারপ্লেট না লিখে ফ্যাক্টরিগুলির জন্য ফানক <টি>, অলস <টি>, ডেলিগেটস ইত্যাদি ব্যবহার করতে পারে।
gix

10

অ্যাপ্লিকেশন স্তরগুলিতে পৃথক করা; ডেটা লেয়ার, বিজনেস লেয়ার, ইউআই লেয়ার

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

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

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

"স্তরগুলি" পাশাপাশি ফাঁস হতে থাকে; যদি কোনও স্তর প্রক্রিয়া / মেশিনের সীমানা (IE ওয়েব ইউআই এবং ব্যবসায় ব্যাকএন্ড যুক্তি) দ্বারা শারীরিকভাবে পৃথক করা হয় তবে নিয়মগুলি যথাযথভাবে ভালভাবে কাজ করার জন্য নকল হয়ে যায় get যেমন কিছু ব্যবসায়ের যুক্তি ইউআইতে শেষ হয় যদিও এটি একটি "ব্যবসায়িক নিয়ম", যদিও ব্যবহারকারীর সাড়া জাগাতে ইউআই দরকার।

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

আমি সম্ভবত এটির জন্য নিন্দা করব, তবে এটি এখানে আছে :)


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

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


7

ব্যবহারকারীর গল্প / ব্যবহারের কেস / পার্সোনাস

 

আপনি যখন এমন কোনও শিল্পের জন্য প্রোগ্রামিং করছেন যার সাথে আপনি পরিচিত নন তবে আমি এগুলির প্রয়োজনীয়তা বুঝতে পারি তবে আমি মনে করি যে তারা যখন পুরোপুরি প্রয়োগ করা হয় তখন তারা খুব কর্পোরেট হয় এবং সময়ের অপচয় হয় waste


7

80 চর / রেখার সীমা বোবা

আমি বুঝতে পারি যে জিইউআই পার্শ্বের সবচেয়ে ধীরতম রানার (স্ক্রিন রেজোলিউশন সীমাবদ্ধতা ইত্যাদি) গতির সাথে মেলে কিছু আপস করা দরকার তবে কেন এই নিয়ম কোড ফর্ম্যাটিংয়ের ক্ষেত্রে প্রযোজ্য?

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

অবশ্যই, সেখানে সিআইএল সম্পাদকগুলি ধর্মীয়ভাবে * নিক্স ডাইনোসর দ্বারা ব্যবহার করা হয় যা তাদের ভিটি 220 টার্মিনালের ক্লান্ত পুরানো সীমাবদ্ধতাগুলি অনুসরণ করে তবে আমাদের বাকিরা কেন একই স্ট্যান্ডার্ডের সাথে আবদ্ধ?

আমি বলি, 80 চর সীমাটি স্ক্রু করুন। যদি ডায়নোসরগুলি পুরো দিন ইম্যাক্স / ভিআইএম হ্যাক করার পক্ষে যথেষ্ট মহাকাব্যীয় হয় তবে কেন এমন একটি এক্সটেনশন তৈরি করতে সক্ষম হতে পারে না যা স্বয়ংক্রিয়ভাবে লাইনগুলি মোড়ানো বা তাদের সিএলআই আইডিগুলিতে অনুভূমিক স্ক্রোলিং ক্ষমতা দেয়?

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

80 গৃহস্থালির কাজ সীমা আছে না একটি সেরা অনুশীলন কিন্তু প্রোগ্রামারদের খুবই সংখ্যালঘু একটি কুলুঙ্গি অনুশীলন এবং যেমন চিকিত্সা করা উচিত।

সম্পাদনা:

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

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


1
@ অরব্লিং নিস জিডাব্লুবি যুক্তি ___ এর সাথে দুষ্ট কোণ। সুতরাং আপনি এইচস্ক্রোলকে ঘৃণা করছেন, আপনার কি কোনও বৈধ কারণ আছে যে কারণে করল-প্রস্থটি 80 টি অক্ষরে সীমাবদ্ধ করা উচিত? 160 বা 256 কেন নয়? আমি মনে করি আমরা সকলেই ধরে নিতে পারি যে বেশিরভাগ বিকাশকারীরা তাদের ভিটি 220 টার্মিনালগুলি অবসর নিয়েছে এবং কুকুরছানা দিয়ে তাদের প্রতিস্থাপন করেছে যাতে তারা যে কোনওভাবে প্রস্থের প্রস্থকে প্রসারিত করতে সক্ষম হয়'re
ইভান প্লেইস

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

2
আপনি এটি কীভাবে মুদ্রণ করবেন?

5
দুঃখিত - এটির সাথে একমত হতে হবে। আমি লম্বা লম্বা রেখাগুলি সত্যিই ঘৃণা করি - এর জন্য আরও চোখের চলাচল দরকার, এর জন্য মাউস অঙ্গভঙ্গিগুলি স্ক্রোল করার জন্য প্রয়োজন, একটি লাইনের শেষে নীচে সূক্ষ্মভাবে ছোট ছোট জঞ্জাল জিনিসগুলি দেখতে আরও শক্ত। প্রায় 99% ক্ষেত্রে বেশ কয়েকটি (খাটো) লাইনের উপর স্টাফ তৈরির পরিষ্কার উপায় রয়েছে যা পরিষ্কার করা এবং সহজেই পড়া সহজ। ৮০ অক্ষর নির্বিচারে হতে পারে এবং "কারণ এটি ছিল পাঞ্চ কার্ডের দিনগুলিতে" তবে এটি এখনও অভ্যন্তরে কাজ করার জন্য একটি যুক্তিসঙ্গত কাঠামো - বেশিরভাগ সময় উপরের কারণে for
দ্রুত_

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

5

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

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

আমি পরিমাপ-পরিমাপ "জ্ঞান" এর উত্সটি সন্ধান করার চেষ্টা করছি। যথেষ্ট লম্বা সাবানবক্স সহ কেউ এটি বলেছে এবং এখন এটি ভ্রমণ করে।


5

আমার শিক্ষকের দাবি আমি আমার সমস্ত সনাক্তকারী (ধ্রুবক সহ) ছোট হাতের অক্ষর দিয়ে শুরু করি না, যেমন myVariable

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


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

@ এক্সনাইন আপনার মন্তব্যটি রেট দেওয়ার জন্য আমার কাছে এখনও এই সাইটে যথেষ্ট প্রতিবেদন নেই, তাই আমি অনুমোদনের
ম্যাক্সপাম

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

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

1
ইন যান , পাবলিক পদ্ধতি এবং ক্লাস সদস্যদের একটি ঊর্ধ্ব অক্ষর দিয়ে শুরু; লোয়ার-কেস চিঠিযুক্ত ব্যক্তিগত চিঠিগুলি।
জোনাথন লেফলার

5

সিলেটলেটস ব্যবহার করুন

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


2
এটি সম্পূর্ণ নেতিবাচক thatণ যা আমাকে সিলেটলেটের বিষয়ে আপনার আসল অবস্থান হিসাবে বিভ্রান্ত করেছে।
পল কসাই

1
@ পল বাচার: আমি সিলেটলেটকে ঘৃণা করি এবং এটি কখনই ব্যবহার করা উচিত নয়

1
@ রুং: ব্যক্তিগতভাবে আমি মনে করি না যে কোনও কারণ বৈধ কারণ। এটি কেবল একটি সাধারণ শ্রেণি হিসাবে লিখুন। সত্যিই, অলসতার পরে অন্য কোনও সিঙ্গলটোন ব্যবহার করার এবং খারাপ অভ্যাস বা নকশার প্রচার করার কোনও কারণ নেই।

6
কে বলে যে সিঙ্গেলটন ব্যবহার করা সবচেয়ে ভাল অনুশীলন?
ফিল ম্যান্ডার

2
সিঙ্গেলটনের তাদের জায়গা রয়েছে, বিশেষত এমন একটি ক্ষেত্রে যেখানে একটি অপারেশনাল কাঠামো বরাদ্দ করা হয় এবং শুরুতে পূরণ করা হয়, তারপরে মূলত কেবল প্রোগ্রামের রান সময় জুড়েই পঠিত হয়ে যায়। সেক্ষেত্রে এটি কেবল পয়েন্টারের অন্যদিকে ক্যাশে পরিণত হয়।
টিম পোস্ট

5

স্বাক্ষরবিহীন int ব্যবহার করে পুনরুক্তি হিসাবে

কখন তারা জানতে পারবেন যে সাইন ইনড ব্যবহার করা অনেক বেশি নিরাপদ এবং কম বাগ প্রবণ। অ্যারে সূচকটি কেবল ইতিবাচক সংখ্যা হতে পারে কেন এটি খুব গুরুত্বপূর্ণ, যে 4 - 5 হল 4294967295 এর সত্যটি উপেক্ষা করে সকলেই খুশি?


ঠিক আছে, এখন আমি কৌতূহলী- কেন আপনি এটি বলেন? আমি একটু বোবা অনুভব করছি - আপনি কি আপনার বিবৃতি ব্যাক আপ করার জন্য কিছু কোড উদাহরণ সরবরাহ করতে পারেন?
পল নাথান

4
@ পল নাথান: বগিটি এখানে যেমন একটি উদাহরণ রয়েছে: (স্বাক্ষরযুক্ত স্বাক্ষরিত আই = 0; আই <10; আই ++) cra ইন ক্র্যাশ_এইয়ার = আমার_আরে [সর্বাধিক (আই -1,0)];}
আরেপ

@আরএপ: নিশ্চিত হওয়ার জন্য - আমি অনুমান করি আপনি এই সত্যটি উল্লেখ করছেন যে যখন একটি স্বাক্ষরবিহীন অন্তর্গঠকটি 0হ্রাস পাবে 1, আপনি আসলে সাইন ইন না থাকা কোনটি ইতিবাচক মানটি সঞ্চিত করতে পারেন?
অ্যাডাম পেইন্টার

1
@ অ্যাডাম পেইন্টার: হ্যাঁ এটি সি ++ প্রোগ্রামারদের পক্ষে সাধারণ বলে মনে হতে পারে তবে আসুন এটির মুখোমুখি হোন, "স্বাক্ষরযুক্ত স্বাক্ষর" হ'ল ইতিবাচক-কেবল সংখ্যাগুলির একটি খারাপ "বাস্তবায়ন"।
আরেপ

ছোট এম্বেড থাকা মেশিনে একটি ভাল ধারণা নয় - প্রায়শই স্বাক্ষরযুক্ত ইনটগুলি আরও ছোট, দ্রুত কোড উত্পন্ন করবে। সংকলক এবং প্রসেসরের উপর নির্ভর করে।
দ্রুত_

4

পদ্ধতিগুলি একটি একক স্ক্রিনের চেয়ে বেশি হওয়া উচিত নয়

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

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

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

এখানে আমার নিয়ম ...

কিছু অর্জনের জন্য ফাংশন / পদ্ধতি লিখুন

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

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

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

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

অপ্রয়োজনীয় বিমূর্ততা সীমাবদ্ধ করুন এবং স্বতঃপূরণকে দূষিত করবেন না।


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

3
আমি মনে করি এটির একটি পাল্টা যুক্তি হ'ল একটি বৃহত পদ্ধতির অংশগুলি পৃথক কলগুলিতে রিফ্যাকচারিংগুলি বৃহত্তর পদ্ধতিটি পড়া সহজ করে তুলতে পারে। এমনকি যদি পদ্ধতিটি কেবল একবার বলা হয়।
জেরেমি হিলার

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

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

1
+1 এবং আমি যদি দিতে পারতাম তবে আরও দিতাম। সি কোডের একগুণে একক ফাংশনে 1000 লাইন ঠেলাঠেলি করে কিছুই নেই (উদাহরণস্বরূপ একটি বিশাল স্যুইচযুক্ত পার্সার ()) উদ্দেশ্যটি পরিষ্কার এবং সহজ। সমস্ত ছোট টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো কথা বলা বোঝার জন্য আরও শক্ত করে তোলে। অবশ্যই এটিরও সীমাবদ্ধতা রয়েছে .... বুদ্ধিমান রায়ই সব কিছু।
দ্রুত_
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.