কর্মক্ষেত্রে কোডিং স্ট্যান্ডার্ডগুলি পরিচালনা করা (আমি বস না)


40

আমি একটি ছোট দলে কাজ করি, প্রায় 10 দেব! আমাদের মোটেই কোডিং মান নেই। কিছু নির্দিষ্ট জিনিস রয়েছে যা আদর্শ হয়ে উঠেছে তবে কিছু করার কিছু উপায় সম্পূর্ণ ভিন্ন are আমার বড়টি হ'ল ইনডেন্টেশন। কেউ ট্যাব ব্যবহার করেন, কেউ ফাঁকা জায়গা ব্যবহার করেন, কেউ কেউ বিভিন্ন সংখ্যক স্পেস ব্যবহার করেন যা একটি বিশাল সমস্যা তৈরি করে। আমি যখন মার্জ হয়ে যাই তখন প্রায়শই আমি দ্বন্দ্বের সাথে শেষ করি কারণ কেউ তাদের আইডিই স্বতঃরূপে ব্যবহার করেছে এবং তারা আমার চেয়ে ইনডেন্ট করার জন্য একটি ভিন্ন চরিত্র ব্যবহার করে। আমরা কোনটি ব্যবহার করি সেদিকে খেয়াল নেই আমি কেবল আমাদের সকলকে একই ব্যবহার করতে চাই।

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

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

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

আপনার সময় জন্য সবাইকে ধন্যবাদ।

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

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


3
কিছু মার্জ সরঞ্জাম হোয়াইটস্পেসের ভিন্নতা উপেক্ষা করার বিকল্প দেয়। এটি মূল কারণটিকে সমাধান করতে পারে না, তবে মধ্যবর্তী ব্যথা প্রশমিত করতে পারে ...
হতাশ

5
কোডটি উত্স নিয়ন্ত্রণে চলে যাওয়ার পরে আপনি কেন আপনার ম্যানেজারের কোডটি ফর্ম্যাট করার সমাধানটি পছন্দ করেন না?
ল্যারি কোলেম্যান

5
আমি মনে করি এটি একটি সামাজিক সমস্যা, প্রযুক্তিগত সমস্যা নয়। যদি টিম স্ট্যান্ডার্ডগুলিতে একমত হতে না পারে তবে আইএমও কোনও পরিমাণ প্রযুক্তির সহায়তা করবে না।
ব্রায়ান ওকলে

11
প্রত্যেকেরই একই সেটিংস সহ আইডিই অটোফর্ম্যাট ব্যবহার করা উচিত। সপ্তাহের দিন.

1
@ থরবজর্ন - সম্মত। আমরা গতকাল সবেমাত্র গ্লোবাল আইডিই সেটিংস জারি করেছি।
অ্যাড্রিয়ান জে মোরেনো

উত্তর:


73

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

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

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


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

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

2
+1 ঠিক একইভাবে আমরা একই পরিস্থিতি পরিচালনা করেছি। আমি খুঁজে পেয়েছি যে উদাহরণস্বরূপ নেতৃত্ব করা প্রায়শই একটি বিকাশের দোকানে অনেকগুলি সমস্যা সমাধান করে - তবে আপনার অন্যের কাছ থেকে জিততে হবে। যদি আপনি একমাত্র পথটি জ্বলজ্বলে করেন তবে আপনার সম্ভবত প্রথম স্থানে পুনরায় মূল্যায়ন করা উচিত।
জুলু

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

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

6

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

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

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


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

3
ওয়েল টেকনিক্যালি সেখানে হয় : একটি ওয়ান মুক্ত বন্ধনী স্টাইল en.wikipedia.org/wiki/Indent_style#Variant:_1TBS
পুনর্বহাল মনিকা

@ সেমজ: আমি আন্তরিকভাবে একমত নই। এটি মোটামুটি পরিচালকের উপর নির্ভর করা উচিত নয়। সামান্যও নয়।
ব্রায়ান ওকলি

অন্যদিকে, আপনি একটি প্রোগ্রামিং দল, কারও কর্মচারী, হিপ্পি কমুন নয়। প্রকল্প ব্যর্থ হলে কার মাথার রোল? আমি কারওর গ্যারান্টি দিচ্ছি। প্রত্যেকে যদি দায়ী হয় তবে কেউ নেই। দেখুন এই , এই , এই , ইত্যাদি
ক্রেগ

"কার মাথা ঘুরছে," আমি বলতে চাইছি। অবশ্যই ...
ক্রেগ

5

যে সমস্যার সৃষ্টি হচ্ছে তার কারণে আপনি যে সময় নষ্ট করেছেন তার কিছু প্রমাণ আপনি দেখাতে পারেন?

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

সুতরাং আপনি যে সমস্যার মুখোমুখি হন এবং তার সমাধানের জন্য সময় লাগে তার একটি লগ রাখুন - আপনার এবং আপনার সহকর্মীদের জন্য উভয়ই।

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


3

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

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


3
আমি যাই হোক না কেন লাইনে বন্ধনী সঙ্গে ভাল। উভয় শৈলী একই ফাইলে থাকা অবস্থায় আমি ছুঁড়ে ফেলি । এটি স্ক্যান করা আরও শক্ত করে তোলে।
জোশ জনসন

এটি আমাকে পাগল করে তোলে তবে যেহেতু আমি পুরো কোড বেসটি ঠিক পুনরায় ফর্ম্যাট করতে পারি না, তাই আমি কেবল এটির সাথে চেষ্টা করার চেষ্টা করি যতক্ষণ না আমি একটি স্বয়ংক্রিয় সমাধানের জন্য চাপ দিতে পারি।
jprete

2

কোডিং মান সম্পর্কে: আমি কোডিং স্ট্যান্ডার্ড একটি "ভাল জিনিস" (বনাম কোনও মান) না বলে প্রায় প্রত্যেকের সাথে বোর্ডে উঠব।

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

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

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

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


3
অথবা আপনি কেবল ট্যাব ব্যবহার করতে পারেন এবং স্বতন্ত্র ডিভগুলি তাদের যে কোনও আকারের আকার তৈরি করতে পারে ..
মনিকা

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

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

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

1

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

এখন, কোড পর্যালোচনাগুলি একটি সাধারণ কোডিং স্ট্যান্ডার্ড থেকে উপকৃত হয়, কারণ এটি অন্যান্য লোকের কোডগুলি পড়া সহজ করে তোলে easier কোডিং স্ট্যান্ডার্ডগুলি প্রবর্তন করার জন্য এটি আপনাকে একটি দ্বি-পদক্ষেপ যুক্তি সরবরাহ করে: শেষ পর্যন্ত, এটি ভাল কোড তৈরি করা সস্তা করে তোলে।


1

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

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

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

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


1

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

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

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

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


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

0

আপনার দেওয়া সমস্ত উদাহরণ মূলত সাদা স্থান এবং বিন্যাস সম্পর্কে। যদি এটি সবচেয়ে বড় সমস্যা হয় তবে আমি আপনার ম্যানেজারের সাথে একরকম একমত হই: এটি কোনও চুক্তির মধ্যে এত বড় নয়।

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

যদি আপনার দলের কোনও নির্দিষ্ট বিকাশকারী কোড লিখেন যা বোঝা / ডিবাগ করা শক্ত কারণ এটিতে একক বর্ণের পরিবর্তনশীল নাম সহ কোডের অনেকগুলি দীর্ঘ অংশ রয়েছে, এটি কিছু মান অবলম্বন করার একটি ভাল কারণ, এবং এমন কোনও কিছু নয় যা ঠিক করে দেওয়া যেতে পারে একটি পান্ডুলিপি. মানক উন্নতি করতে পারে এমন জিনিস হিসাবে (কৌশলগতভাবে) উল্লেখ করা ভাল জিনিস।

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


0

সংঘর্ষগুলি যখন আমি মার্জ করি কারণ কেউ নিজের আইডিই অটো ফর্ম্যাট করতে ব্যবহার করেছে এবং তারা আমার চেয়ে ইনডেন্ট করার জন্য একটি আলাদা অক্ষর ব্যবহার করে

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

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


0

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


0

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

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


0

এটি চেষ্টা করবেন না!

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

আপনি যদি আপনার সহকর্মীদের দ্বারা লঞ্চ না পান (!!), আপনি কোডিং মান সহ শেষ করতে পারেন।

স্পষ্টতই, এটি একটি উচ্চ ঝুঁকির কৌশল ... :-)


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

@ জোশ জনসন - তারা সম্ভবত যথেষ্ট চেষ্টা করেন নি tried সমস্ত সনাক্তকারীগুলিতে ROT-13 ব্যবহার করে বিবেচনা করুন :-)
স্টিফেন সি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.