একটি দলে বিভিন্ন প্রোগ্রামিং শৈলী কিভাবে মোকাবেলা করতে?


14

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

আমার প্রশ্ন হ'ল যদি অন্যরাও এর আগে এমন পরিস্থিতি অনুভব করে থাকে এবং কারও সাথে তার সাথে কীভাবে কথা বলতে হয় তার টিপস রয়েছে।


2
ভাণ্ডার হ্যাকগুলি এবং শর্টকাটগুলি সংগ্রহস্থলটিতে পৌঁছানোর আগেই পিয়ার পর্যালোচনা ব্যবহার করে বিবেচনা করা হচ্ছে?

আপনি যখনই পারেন ভাল, নিরপেক্ষ স্বয়ংক্রিয় সরঞ্জামগুলি ব্যবহার করুন।
কাজ

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

উত্তর:


22

আমি এমন একটি দলের সাথে কাজ করি যা এক বছরেরও কম সময়ে 2 বিকাশকারী থেকে 10 এ উন্নীত হয়েছিল। আমি 3 নম্বরে ছিলাম এবং কোডিং মানগুলির ইস্যু উত্থাপনকারী প্রথম। দু'জন মূল বিকাশকারী কয়েক বছর ধরে পাশাপাশি কাজ করছিলেন এবং তারা একটি সাধারণ মান গ্রহণ করেছিলেন যা আমার কাছে পরক বলে মনে হয়েছিল। আপনি বর্ণনা করছেন ঠিক আমাদের একই সমস্যা ছিল।

আমরা যা করেছি তা হ'ল:

কোডিং মানসমূহ গবেষণা

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

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

আমাদের নিজস্ব কোডিং স্ট্যান্ডার্ড তৈরি করা হচ্ছে

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

  • প্রথমে আমরা আমাদের প্রকল্পে প্রযোজ্য না এমন সমস্ত কিছু সরিয়ে দিয়েছি
  • তারপরে আমরা স্টাইলের বিষয় হিসাবে আমাদের উপলব্ধি করা সমস্ত কিছুকে আমাদের শৈলীতে পরিবর্তন করেছি
  • এবং অবশেষে আমরা সবকিছু লিখেছিলাম

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

আমাদের প্রতিশ্রুতি সত্য

আমাদের কোডবেস তখন প্রায় 1 * 10 ^ 6 স্লোক ছিল। আমরা জানতাম যেহেতু আমরা আনুষ্ঠানিক কোডিং মানগুলি অবলম্বন করেছি আমাদের কোডটি রিফ্যাকচারিং শুরু করতে হয়েছিল, কিন্তু সেই সময়ে আমাদের অন্যান্য সমস্যা নিয়ে চাপ দেওয়া হয়েছিল। সুতরাং আমরা কেবলমাত্র আমাদের খুব কোর লাইব্রেরিগুলিকে রিফেক্টর করার সিদ্ধান্ত নিয়েছি, কেবল 5 * 10 ^ 3 স্লোক।

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

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

নতুন লোকটির সাথে ডিল করছে

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

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

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

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

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

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

এবং তারপরে আর এক নতুন লোক এসেছিল। আমরা প্রক্রিয়াটি পুনরাবৃত্তি করেছি (এবার ভিন্ন ভিন্ন মাস্টার) এবং এটি আবার কাজ করেছে। এবং আবার.

উপসংহারে

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

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

কিছু পিএইচপি নির্দিষ্ট, কিন্তু উত্তরগুলি সমস্ত প্ল্যাটফর্মগুলিতে প্রয়োগ হয়।


যদি কেবলমাত্র সমস্ত উন্নয়ন পরিচালনার পদ্ধতিগুলি এত ভাল উত্তর দেওয়া যায় ... ধন্যবাদ!
আনন্দিত

3

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

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

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

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

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

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


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

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

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


1

এখানে কী করা যায় তা এখানে:

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

কী এড়াতে হবে তা এখানে:

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

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

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

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

@ ডিএক্সএম প্রচুর দুর্দান্ত ভাষার বৈশিষ্ট্যগুলিকে আগে দেখা যায় নি বা ব্যবহার করে নি এমন লোকদের দ্বারা 'কুশ্রী হ্যাকস এবং শর্টকাট' বলা হয়। নতুন জিনিসটি হ্যাকার হওয়ার সিদ্ধান্ত নেওয়ার চেয়ে মানদণ্ডের বিষয়ে কথা বলা ভাল Best
কર્ક ব্রডহર્স্ট

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

1

আমাদের বিদ্যমান কোড বেসটিতে বেশিরভাগই পঠনযোগ্য, পরিষ্কার এবং রক্ষণাবেক্ষণযোগ্য কোড রয়েছে

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

এটি বলেছিল, নতুন লোকটিকে আপনার মানদণ্ডের সাথে সামঞ্জস্য করা উচিত, অন্যভাবে নয়।


0

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

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

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


0

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

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

স্পষ্টতই আমি প্রত্যাশা করি যে কোনও শালীন প্রোগ্রামার যে কোনও কোডিং মান অনুসরণ করে কোড লিখতে পারে, তারা সেই নির্দিষ্ট মানটিকে পছন্দ করে কি না।

এবং অন্যদিকে, মানের মান রয়েছে। আপনার মানের মান পূরণ না করে এমন কোড কখনই গ্রহণ করবেন না।

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