পুনর্নির্মাণ এবং সংস্করণ নিয়ন্ত্রণ


23

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

SELECT id, name, address
FROM persons JOIN addresses ON persons.id = addresses.person_id;

লেখার চেয়ে ভাল / আরও ভাল লেখা যেতে পারে

SELECT persons.id,
       persons.name,
       addresses.address
  FROM persons
  JOIN addresses ON persons.id = addresses.person_id;

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

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

  • সমস্ত কমিট একই স্টাইল
  • ন্যূনতম সংযুক্তির কাজ

?

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


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

5
আমি কমিটিকে মন্তব্য করতে চাই যে আমি "রিফর্ম্যাট। কোনও কার্যকরী পরিবর্তন নেই"
রিগ

3
কোনও সম্পর্কযুক্ত বিষয়ে, মনে হচ্ছে আপনি সমস্ত কোডটি পুনরায় ফর্ম্যাট করে গিট ইতিহাস পুনরায় লেখার পরামর্শ দিচ্ছেন। লোকদের ধারণা দেবেন না, গিট ইতিহাসের পুনর্লিখন 99.9% ক্ষেত্রে খারাপ। পুনরায় ফর্ম্যাট করা .1% প্রান্তের কেস নয়।
অ্যান্ড্রু টি ফিনেল

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

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

উত্তর:


26

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


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

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

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

প্রোগ্রামিংয়ে, কিছুই যেমন শোনা যায় তত সহজ নয় :)
হেরাল্ড

13

ভিসিএস ইতিহাস পুনরায় লিখবেন না: এটি ভিসিএস নীতিগুলির বিরুদ্ধে।

ফর্ম্যাটিং ফিক্সিং স্বয়ংক্রিয় করার চেষ্টা করবেন না: এটি লক্ষণগুলি চিকিত্সা করছে, আসল সমস্যা নয় (= বিকাশকারী কোডিং মান অনুসরণ করছেন না)।

একটি সাধারণ দস্তাবেজে কোডিং স্ট্যান্ডার্ড এবং ফর্ম্যাট করার সেরা অনুশীলনগুলি সংজ্ঞায়িত করুন এবং সমস্ত বিকাশকারীকে সম্মত করুন।

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

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

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


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

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

9

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

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

অতএব, এটি পুনরায় ফর্ম্যাট করার জন্য প্রতিষ্ঠিত কোডটি কঠোরভাবে পরিবর্তন করা উপযুক্ত নয়। ভেরিয়েবলের নাম পরিবর্তন করা, দীর্ঘ ক্রিয়াকলাপ ভাঙা, এত ভাল রিফ্যাক্টরিং স্টাফ যা সামগ্রীতে পরিবর্তন করে, হ্যাঁ, তবে কেবল পুনর্নির্মাণ নয়।

1) - আমি একবারের জন্য উইন্ডোজ ক্লিপবোর্ড দর্শকের মালিকানা পেয়েছিলাম। পুরো জিনিসটি এক, 150 কে, সি মডিউল ছিল। আমি এমন একটি জায়গা পেয়েছি যেখানে বিভিন্ন লোকেরা ব্যবহার করেছিল, আমি মনে করি, একে অপরের তিরিশ লাইনের মধ্যে পাঁচটি বিভিন্ন ব্রেস শৈলী les কিন্তু জিনিসগুলির সেই বিভাগটি কাজ করেছে। আমি দশ বছর ধরে কোডটির একটি অংশের একটি মুদ্রণ বহন করেছিলাম, তবে আমি তা পোঁকতে পারি নি কারণ ইতিহাসটি গুরুত্বপূর্ণ, এবং সেই কোডটি কমপক্ষে তিনটি উত্স গাছের মধ্যে ছিল (উইন্ডোজ 3.x, এনটি, ভবিষ্যতে 95) যা সমস্ত জীবিত ছিল বিভিন্ন বিল্ডিংয়ে।


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

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

4

তবে আপনি কীভাবে বড় আকারের পরিবর্তনগুলি জুড়ে কোড পরিবর্তনগুলি ট্র্যাক করবেন?

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

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

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


1

এখানে আমি কার্যকর দুটি পন্থা দেখেছি।

1. কমিট-হুকের পুনরায় ফর্ম্যাট কোড

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

২. সমস্ত কোডের এককালীন পুনরায় ফর্ম্যাট করা

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


1
কোড ফাইলের বেশিরভাগ অংশ জুড়ে দ্রুত রিপল চালু করার সাথে সাথে কী বিকল্পগুলির বিকল্প হবে না, যার ফলে প্রতিটি ফাইল পরিবর্তন হওয়ার একই বৃহত ঠুং শব্দ ঘটে?
সাইন ইন করুন

@ সাইন: হুবহু আমার বক্তব্য - যখন কমিট হুক পরিবর্তন হয়, আপনার ইতিহাস প্রায় অকেজো কিছুতে অবনতি হতে পারে। ফর্ম্যাটিং যা কার্যকারিতা পরিবর্তন করে না প্রতিশ্রুতিবদ্ধ হওয়া উচিত নয়, এটি কোডের ইতিহাস জুড়ে প্রতিস্থাপন করা উচিত।
l0b0

1
যদি আইডিই এর সমর্থন করে তবে 3 টিও থাকে) সংরক্ষণের সময় আইডিই অটোফর্ম্যাট থাকে। তারপরে সর্বদা একই সেটিংস ব্যবহার করুন - আপনি আইডিই দিয়ে ডিফল্ট ব্যবহার করেন তবে এটি সবচেয়ে সহজ।

আমি এই উভয় পন্থা সম্পন্ন করেছি। প্রথম পদ্ধতিরটি খুব বাধাজনক কারণ প্রতিবার নতুন ফাইল প্রথমবারের জন্য প্রতিশ্রুতিবদ্ধ হওয়ার সাথে সাথে এক টন পরিবর্তন হবে। দ্বিতীয় পন্থাটি দলের পক্ষে আরও ভাল, যেমন একটি বান্দাইদকে দ্রুত ছিঁড়ে ফেলার মতো।
দ্রুষ্কা
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.