কোড ভাগ করে নেওয়ার জন্য সেরা / খারাপ অভ্যাসগুলি? [বন্ধ]


9

আমি গিথুবকে যত বেশি ঘুরে দেখি ততই আমার পছন্দ হয়। কোডিং কীভাবে আরও সামাজিক হয়ে উঠছে তা আমি সত্যিই উপভোগ করি।

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

উদাহরণ স্বরূপ:

একক রেপোর জন্য 'মিসকপ্রজেক্টস' নামে একাধিক স্ক্রিপ্ট / প্রকল্প রাখা কি খারাপ অভ্যাস ? নাম অনুসারে এই রেপোটি হ'ল বিবিধ ছোট স্ক্রিপ্ট এবং প্রকল্পগুলির সংকলন। এটির অনুরূপ হতে পারে যে কোনও প্রোগ্রামার তার / তার স্থানীয় স্টোরেজে প্রকল্পগুলি সংগঠিত করে তবে কোড ভাগ করে নেওয়ার জন্য এটি সম্ভবত সর্বোত্তম নয়?

একটি ভাল README / ডকুমেন্টেশন যদি করা হয়, এটি আরও ভাল হবে? বা যতক্ষণ না এটি ভালভাবে নথিভুক্ত করা হয়, কিছু যায়?

উত্তর:


9

যদিও কোন 'খারাপ চর্চা' পাথর সেট, একইভাবে অন্যান্য সংস্করণ কন্ট্রোল সিস্টেম সঙ্গে, আছে নিয়মাবলী

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

  • গিট ছোট রেপোসের জন্য দ্রুত
  • এর নকশার কারণে, প্রতিটি ক্রিয়াকলাপ পুরো রেপোকে প্রভাবিত করে । আপনি যদি কেবলমাত্র তাদের একটিতে কাজ করছেন তবে প্রয়োজনীয় প্রকল্পগুলির উপর গিট অপারেশন করা অদক্ষ।

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

গিটহাবের বেশিরভাগ প্রকল্প কনভেনশনগুলিতে মেনে চলে। আপনার ভবিষ্যতের প্রকল্পগুলি কীভাবে গঠন করবেন তার উদাহরণ হিসাবে সেগুলি ব্যবহার করুন।

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