এই সমস্ত কোডিং বিধি সম্পর্কে কী?


10

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

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


3
আপনি যদি ভাষা হিসাবে সি # ব্যবহার করেন তবে স্টাইলকপ ব্যবহার করুন। যদি জাভা ব্যবহার করা হয় ...
চাকরি

@ জোব - হ্যাঁ, আমরা বেশিরভাগ সি # ব্যবহার করি। স্টাইলকপটি আকর্ষণীয় দেখায়।
দ্য বোয়ান

উত্তর:


9

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

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

কখনও কখনও পিয়ার চাপ এটির জন্য সেরা সমাধান।


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

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

6

আমার কাজে আমরা নিম্নলিখিত তিনটি সমাধান ব্যবহার করি:

1) যেমন চমৎকার যেমন একটি কোড শৈলী পরীক্ষক এডপ্ট Checkstyle (জাভা) অথবা StyleCop (গ # জন্য)। এগুলি সহজেই কনফিগার করা সরঞ্জাম যা কোডিং শৈলী / বিধি বিচ্যুতিগুলি স্বয়ংক্রিয়ভাবে হাইলাইট করতে পারে। এটি প্রত্যেকটি একটি নিরপেক্ষ তৃতীয় পক্ষকে এটি নির্ধারণ করার জন্য যেটি গ্রহণযোগ্য এবং কোনটি গ্রহণযোগ্য নয় gives

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

3) কোড পর্যালোচনা। আশা করি আপনি যেভাবেই এইগুলি করছেন, তবে একটি বিষয় হাইলাইট করা উচিত যেখানে কোডিং বিধি / শৈলীগুলি কনভেনশন ভঙ্গ করছে।

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


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

4

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

তারা কি বন্ধনী ব্যবহার না করে "কঠোর নেতৃত্বাধীন" হচ্ছে বা এটি কি "কঠোর নেতৃত্বের" অনুরোধ?

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

ওও 101 : "যখন পণ্যটি যা করানোর দরকার হয় তখন তা সংশোধনকারী"। পূর্বের না.


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

2

বড় দলগুলির প্রতিটি একক বিকাশকারীর কাঁধে বসে থাকা আপনার পক্ষে মনে হয় যে তারা যেখানে যেতে হবে সেগুলি বন্ধনীগুলি রেখেছিলেন - তা নিশ্চিত করুন that তার উপর আমার বিশ্বাস করুন;)।

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

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


2
যদি ব্রেস প্লেসমেন্টটি আপনার বৃহত্তম মানের সমস্যা হয় তবে আমার ধারণা আপনি খুব ভাগ্যবান। এটি কি সঠিক স্তরের দিকে ফোকাস করার জন্য?
বো পারসন

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

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

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

1
"অবশ্যই কিছু সংস্থাগুলি জুনিয়র প্রোগ্রামারদের কাছ থেকে সম্পূর্ণ চেক-ইন সুবিধাদি গ্রহণ করে finally - এটি গুরুত্বপূর্ণ হলে এটি করার একমাত্র উপায়।
ocodo

2

আমি মনে করি আপনি খুব ভিন্ন স্তরের সমস্যার কথা বলছেন:

বিবৃতিতে যদি বন্ধনী ব্যবহার করতে পছন্দ করেন না এমন কঠোর নেতৃত্বদানকারী কীভাবে তৈরি করবেন,

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

অথবা কোডের যে কোনও জায়গায় একই সংযোগের স্ট্রিং ব্যবহার করুন,

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

বা যাই হোক না কেন, কোডিং বিধিগুলি তাদের ধারণার বিরোধিতা না করেই ব্যবহার করবেন?

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

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


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

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

2

বিধি প্রতিষ্ঠায় তাদের জড়িত করুন। এটি সাধারণত লোকদের অনুসরণ করতে উত্সাহিত করতে সহায়তা করে।


1

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


1

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

তবে এখানে আসল সমস্যাটি হ'ল আপনার ক্রিয়া "মেক" । আপনি প্রোগ্রামারদের কিছু করতে এবং আপনি যদি তা করতে না পারেন তবে আপনি তাদের সবচেয়ে মূল্যবান বৈশিষ্ট্যটি নষ্ট করছেন: গভীর বৌদ্ধিক ব্যস্ততা যা আপনার পছন্দের কিছুতে কাজ করার ফলে আসে।

আমি যেভাবে এটি সমাধান করব:

  1. জোর দিয়ে বলুন যে দলের একটি সাধারণ কোডিং স্ট্যান্ডার্ড রয়েছে। এটি 5 লাইন দীর্ঘ হতে পারে, তবে তাদের সবাইকে একমত হতে হবে।
  2. প্রতিবার আপনি যখন কোনও যুক্তি লক্ষ্য করেন তখন তারা জোর করে বলে যে তারা এটিকে একত্রে নিষ্পত্তি করে এবং কোডিং স্ট্যান্ডার্ডে রেখে দেয়। আপনি যদি লোকদের পিছনে পিছনে জিনিস পুনরায় ফর্ম্যাট করতে লক্ষ্য করেন তবে এটিকে একটি যুক্তি হিসাবে বিবেচনা করুন।
  3. যখনই কোনও মানক আইটেমটির সাথে একমত হয়, দেখুন এমন কোনও সরঞ্জাম আছে যা পুরো কোড বেস একবারে পরিষ্কার করে দেবে কিনা if
  4. প্রতি কয়েক মাস, কোডিং স্ট্যান্ডার্ডের মধ্যে যান এবং দেখুন কোনটি এখনও সত্য এবং প্রাসঙ্গিক। মানক লোকেরা কী করছে তা নথিভুক্ত করে। এবং স্ট্যান্ডার্ডে আইটেমগুলি রাখার কোনও অর্থ নেই যা স্পষ্ট হয়ে উঠেছে।

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

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