কর্মহীন কোড করা কি কখনও ঠিক আছে?


40

এটি কি কেবলমাত্র কার্যকরী কোড করা দরকার?

এই প্রতিশ্রুতিবদ্ধ হিসাবে কার্যকারী অবস্থায় os

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

    1. স্থানীয় ফাইল
    2. উপস্থাপনকারী এলাকা
    3. স্থানীয় শাখায় প্রতিশ্রুতিবদ্ধ
    4. দূরবর্তী ব্যক্তিগত বৈশিষ্ট্য শাখায় কমিট করে
    5. দূরবর্তী developশাখার সাথে একীভূত করুন
    6. দূরবর্তী masterশাখার সাথে একীভূত করুন
    7. দূরবর্তী releaseশাখার সাথে একীভূত করুন
  • ... তাড়াতাড়ি কমিট, প্রায়শই কমিট।

সুতরাং উপরের লিঙ্কযুক্ত প্রশ্নে, বেশিরভাগ উত্তর বলে যে সংকলনযোগ্য কোড না করা স্থানীয় এবং বৈশিষ্ট্যযুক্ত শাখায় কোনও সমস্যা নয় is কেন? একটি ভাঙ্গা প্রতিশ্রুতি মূল্য কি?


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


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


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

@ জোছিম সাউর, ভাল অভ্যাস গড়ে তুলতে আমি তাদের সর্বোত্তম অনুশীলন এবং তাদের পিছনে যুক্তি সম্পর্কে জিজ্ঞাসা করছি । বর্তমানে আমি প্রায়শই ভাঙা কোডটি করি। বিগত কয়েকদিন ধরে দশকের মতো কমিটের মধ্য দিয়ে ফিরে যাওয়া একটি দুঃস্বপ্ন।
ভোরাক

9
আপনি যদি প্রতিটি বৈশিষ্ট্যকে তার নিজস্ব শাখায় বিকাশ করেন, তবে সেই সিদ্ধান্তটি তুচ্ছ: শাখাটি বাতিল করুন, বর্তমান মাস্টারের উপর নির্মিত একটি নতুন শাখা থেকে চালিয়ে যান
জোছিম সাউর

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

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

উত্তর:


20

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

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

(পারফোর্স সেরা অভ্যাস থেকে)

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

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

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

(পারফোর্স সেরা অভ্যাস থেকে)

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

সুতরাং শাখা, বলুন যে এই শাখায় কোডটি ভঙ্গ হতে পারে এবং দূরে থাকতে পারে।


40

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


2
এটা সত্যিই একটি সুন্দর জিনিস। আমি মনে করি না যে সম্প্রদায়টি সাধারণভাবে গিট এবং ডিভিসিএসের প্রশংসা করতে শিখেছে।
কেওসপ্যান্ডিয়ন

5
যতক্ষণ না লোকে এই ফিলোসোহিকে ট্রায়াল এবং ত্রুটি প্রোগ্রামিংয়ের সাথে বিভ্রান্ত না করে, যা এড়ানো উচিত।
পিটার বি

10

হ্যাঁ, যতক্ষণ না এটি রিলিজ শাখা নয়।

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

ভাঙা কোড প্রতিশ্রুত করার মান ?: সহযোগিতা এবং পরীক্ষামূলক


অপ্রাপ্তবয়স্ক টুইট: হ্যাঁ, যতক্ষণ না এটি প্রযোজনায় চালিত হবে না। উদাহরণস্বরূপ, কোনও বৈশিষ্ট্য টগল দ্বারা লুকানো কোড।
রব ক্রফোর্ড

5

হ্যাঁ এটি ঠিক আছে এবং এর কিছু আমি অনেক কিছু করি।

সংকলনবিহীন কোড (কমপক্ষে শাখাগুলিতে) করার অঙ্গীকারটি হ'ল কখনও কখনও আপনার কোডটি একটি কার্য-অগ্রগতি হয় তবে এখন পর্যন্ত করা কাজটি সংরক্ষণ এবং / অথবা অন্যের সাথে ভাগ করে নেওয়ার পক্ষে মূল্যবান

আমার অনুশীলনগুলি হ'ল:

  • প্রথম পরীক্ষা লিখুন
  • wip (ওয়ার্ক-ইন-প্রগ্রেস) কমিটগুলি ভাল
  • প্রায়শই কমিট (এক দিনের মধ্যে একাধিক) এবং তাড়াতাড়ি ('ওয়ার্কিং' পদক্ষেপগুলি সংরক্ষণ করুন)
  • প্রতি প্রতিশ্রুতিবদ্ধতার পরে চাপ দিন (আপনার হার্ড ড্রাইভ ক্র্যাশ হলে / বাস আপনাকে আঘাত করবে))
  • সর্বদা শাখা কাজ
  • যখন সম্ভব তখন কেবলমাত্র ওয়ার্কিং কোডকে মাস্টার হিসাবে মার্জ করুন
  • মাস্টার মার্জ হওয়ার আগে স্কোয়াশ ওয়াইপে গিটের মধ্যে ইন্টারেক্টিভ রিবেস ase

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

আরেকটি বিকল্প হ'ল শাখাটি সাময়িকভাবে ব্যবহার করা এবং মোতায়েন করা। এটি নির্দিষ্ট পরিস্থিতিতে সহায়তা করতে পারে তবে সাধারণত প্রস্তাবিত হয় না এবং টেকসই হয় না।

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

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


3

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


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

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

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

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

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

3

এই ভাবে চিন্তা করুন। একজন বিকাশকারী হিসাবে আপনার করা সবচেয়ে বিরক্তিকর জিনিসগুলির মধ্যে একটি হ'ল আপনার দলের অন্য বিকাশকারীদের তাদের কাজগুলিতে কাজ করা থেকে বিরত রাখা।

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

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

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


3

আপনি কীভাবে আপনার সংস্করণ নিয়ন্ত্রণের সাথে কাজ করবেন তা সম্পর্কে কৌতূহল বোধ করার আগে, আপনি সংস্করণ নিয়ন্ত্রণের সাথে কেন কাজ করছেন তা ভেবে দেখার বিষয় ।

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

আপনি কখন প্রতিশ্রুতিবদ্ধ করা উচিত? যখন যুক্তিসঙ্গত সুযোগ থাকে আপনি ভবিষ্যতে আপনার কোডের অবস্থার (বা প্রতিশ্রুতি দেওয়ার বার্তাটি) দেখতে পাবেন look

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

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


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

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

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

2

শাখাগুলি তৈরি / প্রকাশ করুন

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

অন্যান্য শাখা: প্রায়শই রাজ্য সংরক্ষণ করুন

ব্যক্তিগত বা বৈশিষ্ট্যযুক্ত শাখার জন্য, লক্ষ্যগুলি প্রায়শই আলাদা। কোডের ঘন ঘন চেক-ইন (কাজ করা হোক বা না হোক) কাঙ্ক্ষিত হতে পারে। সাধারণত, আপনি বর্তমান অবস্থায় ফিরে যেতে প্রয়োজন হতে পারে যে কোনও সময় প্রতিশ্রুতিবদ্ধ করতে চাইবেন।

এই উদাহরণগুলি বিবেচনা করুন যেখানে সংরক্ষিত রাষ্ট্র একটি উল্লেখযোগ্য সুবিধা দেয়:

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

0

কিছু ভাঙা কোড-বেস করা যতক্ষণ না স্থানীয় হয় ততক্ষণ ঠিক।

কেন?

  • আপনার বিকাশে সেভ পয়েন্ট হিসাবে প্রতিশ্রুতিবদ্ধ ব্যবহার করা অপরিহার্য
  • পণ্যটি বিকাশের সময় এটি আপনাকে চিন্তার একটি প্যাটার্ন দেখায়।
  • এটি সহযোগিতা ভঙ্গ করে না

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

  1. আরও বৈশিষ্ট্যগুলির জন্য ব্যবহৃত সময় এখন ত্রুটিগুলি ঠিক করতে ব্যয় করা হয় ...
  2. উন্নয়ন কাটা পূরণ হয় না ...
  3. পণ্য সময়মতো প্রেরণ করা হয় না

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


0

আমি ভাবি না যে ভাঙা কোড করা ঠিক আছে।

যদি হয় কি

  • একটি জরুরি হট ফিক্স প্রয়োজন। কোড বেসটি একটি ভাঙ্গা অবস্থায় রয়েছে। আপনি পিছনে রোল করতে, ঠিক করতে এবং মোতায়েন করতে বাধ্য হন are

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

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

  • কেউ আপনার 'ভাঙা কোড' মোতায়েন করেন? আপনি ব্যক্তিগত ডেটা নিয়ে বা কোনও প্রদানের সরবরাহকারীর সাথে কাজ করে থাকলে এটি 'গেম ওভার' হতে পারে।

@ ওয়ারেনটি উত্তর

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


Downvote। আপনি যদি কোনও স্ট্যান্ডার্ড ডিভিসিএস ওয়ার্কফ্লো ব্যবহার করছেন তবে এই পরিস্থিতিতে কোনওটিই সম্ভবত নেই।
ব্যবহারকারী16764

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

আমি মনে করি "অ-কার্যকারী কোড" (ওপি কী জিজ্ঞাসা করেছিল) এবং "ভাঙা কোড" যার মধ্যে আপনি উল্লেখ করেছেন তার মধ্যে পার্থক্য রয়েছে।
সাইমন

@ ওয়ারেনটি দয়া করে উত্তর দেখুন।
কোডার্ট

-1

অ-কার্যকারী কোড করা ঠিক আছে কিনা তা নির্ধারণ করতে আপনাকে সহায়তা করার জন্য কয়েকটি প্রশ্ন:

  1. আপনি কি অতিরিক্ত কাজ করছেন?
  2. আপনার দলের সঙ্গী কি ক্রমাগত বিল্ডটি ভাঙেন?
  3. আপনার কোড বেসটি কি কোনও জগাখিচুড়ি এবং সম্ভবত আরও খারাপ হতে পারে না?

যদি আপনি উপরের যে কোনওটিকে হ্যাঁ বলে থাকেন তবে হ্যাঁ এটি অ-কার্যকারী কোড করা ঠিক আছে।

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

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