আপনি যখন বাগ ফিক্সিং করতে যান, দ্রুত, সুস্পষ্ট পরিবর্তন সবসময় সেরা হয় না। এবং আপনার সামনে কোডটি কখনই পুরো গল্প নয়। সহজ সমাধানের বাইরে যেতে, আপনাকে কেন জানতে হবে কিছু সিদ্ধান্ত নেওয়া হয়েছে। আপনাকে কোডের পিছনের ইতিহাস বুঝতে হবে। এবং আত্মবিশ্বাসের সাথে কোড পরিবর্তন করতে আপনার যা জানা দরকার তা শেখার তিনটি দুর্দান্ত উপায় রয়েছে৷
গিট ব্লেম
git blame
এর সাহায্যে , আপনি একটি প্রজেক্টে কোডের প্রতিটি লাইনের প্রতিটি সংস্করণের মাধ্যমে ট্রেস করতে পারেন, এটি লেখার সময় পর্যন্ত।
উদাহরণস্বরূপ, বলুন আপনি ActiveJob-এর queue_name.rb
দেখছেন ফাইল, এবং আপনি জানতে চেয়েছিলেন এই queue_name_delimiter
কি বৈশিষ্ট্য সব সম্পর্কে ছিল:
included do
class_attribute :queue_name, instance_accessor: false
class_attribute :queue_name_delimiter, instance_accessor: false
self.queue_name = default_queue_name
self.queue_name_delimiter = '_' # set default delimiter to '_'
end
আপনি git blame
চালাতে পারেন এটিতে:
$ git blame queue_name.rb
...
da6a86f8 lib/active_job/queue_name.rb (Douwe Maan 2014-06-09 18:49:14 +0200 34) included do
1e237b4e activejob/lib/active_job/queue_name.rb (Cristian Bica 2014-08-25 17:34:50 +0300 35) class_attribute :queue_name, instance_accessor: false
11ab04b1 activejob/lib/active_job/queue_name.rb (Terry Meacham 2014-09-23 15:51:44 -0500 36) class_attribute :queue_name_delimiter, instance_accessor: false
11ab04b1 activejob/lib/active_job/queue_name.rb (Terry Meacham 2014-09-23 15:51:44 -0500 37)
...
এবং প্রতিটি লাইনের জন্য, ক্রমানুসারে, আপনি দেখতে পাবেন:
- সংশোধন যা সেই লাইনটিকে সম্প্রতি পরিবর্তন করেছে (
11ab04b1
, উদাহরণস্বরূপ), - সেই কমিটের লেখকের নাম,
- এবং পরিবর্তনের তারিখ।
কোডের সেই লাইন সম্পর্কে আরও জানতে, আপনার সংশোধন নম্বরের প্রয়োজন হবে। আইডি পাস করুন (যে 11ab04b1
অংশ) git show
করতে অথবা git log
:
$ git show 11ab04b1
commit 11ab04b11170253e96515c3ada6f2566b092533a
Author: Terry Meacham <[email protected]>
Date: Tue Sep 23 15:51:44 2014 -0500
Added queue_name_delimiter attribute.
- Added ActiveJob::Base#queue_name_delimiter to allow for
developers using ActiveJob to change the delimiter from the default
('_') to whatever else they may be using (e.g., '.', '-', ...).
- Updated source guide to include a blurb about the delimiter.
diff --git a/activejob/lib/active_job/queue_name.rb b/activejob/lib/active_job/queue_name.rb
index d167617..6ee7142 100644
...
শান্ত! আপনি পরিবর্তনটি সম্পর্কে আরও কিছু জানতে পারবেন, কেন এটি দরকারী, এবং এটি সম্পর্কে রেল গাইডের অংশটি দেখুন যা আপনি আগে মিস করেছেন।
এখানে, আমরা বেশ ভাগ্যবান পেয়েছিলাম। আমরা এখনই যে তথ্য খুঁজছিলাম তা আমরা পেয়েছি। কিন্তু git blame
শুধুমাত্র আপনাকে দেখায় সবচেয়ে সাম্প্রতিক সময় যে লাইন পরিবর্তন. এবং কখনও কখনও, আপনি যা খুঁজছেন তা খুঁজে পাবেন না যতক্ষণ না আপনি দুই বা তিনটি প্রতিশ্রুতি ফিরে যান।
আগের কমিট দেখতে, আপনি git blame
কল করতে পারেন আবার কিন্তু এইবার, আগে সংশোধন পাস করুন প্রতিশ্রুতি git blame
পাওয়া গেছে। (গিটে, আপনি ^
বসিয়ে "এই অন্য কমিটের আগে কমিট" বলতে পারেন পুনর্বিবেচনার পরে, যেমন 11ab04b1^
):
$ git blame 11ab04b1^ queue_name.rb
...
da6a86f8 lib/active_job/queue_name.rb (Douwe Maan 2014-06-09 18:49:14 +0200 33) included do
1e237b4e activejob/lib/active_job/queue_name.rb (Cristian Bica 2014-08-25 17:34:50 +0300 34) class_attribute :queue_name, instance_accessor: false
94ae25ec activejob/lib/active_job/queue_name.rb (Cristian Bica 2014-08-15 23:32:08 +0300 35) self.queue_name = default_queue_name
...
$ git blame 1e237b4e^ queue_name.rb
... and so on ...
যদিও এটি বেশ মনকে অসাড় করে দেয়।
পরিবর্তে, আপনার পাঠ্য সম্পাদক অন্বেষণ করুন. বেশিরভাগ সম্পাদকই git blame
দিয়ে ইতিহাসের মাধ্যমে ট্রেসিং করেন সহজ। উদাহরণস্বরূপ, Emacs-এ, git blame
এর পরে - আপনার কোডে, একটি লাইনে আপনার কার্সার রাখুন। তারপর, আপনি a
চাপতে পারেন সেই লাইনটিকে প্রভাবিত করে এমন প্রতিটি পরিবর্তনের মাধ্যমে ফিরে যেতে এবং l
ব্যবহার করুন এবং D
একটি প্রতিশ্রুতি সম্পর্কে আরও বিস্তারিত দেখতে৷
আপনার দল কি আপনার প্রতিশ্রুতি বার্তাগুলিতে ইস্যু নম্বর এবং অনুরোধগুলিকে উল্লেখ করে? যদি তাই হয়, git blame
আপনাকে সহজেই কোডের একটি লাইন থেকে, একটি প্রতিশ্রুতিতে, সেই প্রতিশ্রুতি সম্পর্কে আলোচনায় নিয়ে যেতে পারে৷৷ এবং সেই আলোচনাটি হল যেখানে আপনি সমস্ত সত্যি পাবেন৷ ভালো জিনিস।
Github সমস্যা
কিছুক্ষণ আগে, আমি লক্ষ্য করেছি যে Rails 4.2 সরিয়ে দিয়েছে respond_with
. ডক্সে, এটা পরিষ্কার যে এটি সরানো হয়েছে, কিন্তু আমি বুঝতে পারিনি কেন।
GitHub-এর ইস্যু সার্চ বক্সের পিছনে লুকিয়ে আছে প্রচুর জ্ঞান। আপনি যদি জানতে চান কেন একটি বৈশিষ্ট্য সরানো হয়েছে, টিমটি সরানোর সিদ্ধান্ত নেওয়ার সময় আলোচনার চেয়ে শেখার জন্য আর কোন ভাল জায়গা নেই।
সুতরাং, আপনি যদি respond_with
এর জন্য Rails' GitHub রেপো অনুসন্ধান করেন , আপনি respond_with
সম্পর্কে কিছু আকর্ষণীয় থ্রেড পাবেন . আপনি যদি খুঁজে বের করার চেষ্টা করছেন কেন এটি সরানো হয়েছে, আপনি সম্ভবত এই থ্রেডে অবতরণ করবেন। দুর্ভাগ্যবশত, এটি কীভাবে বর্ণনা করে এটি সরানো হয়েছে, কিন্তু কেন নয় .
পরে সেই থ্রেডে, যদিও, আপনি এমন একটি মন্তব্য পাবেন যা respond_with
সরানোর বিষয়ে প্রকৃত আলোচনার দিকে নির্দেশ করে . এখানেই ভালো জিনিস!
যেমন git blame
, আপনি ঠিক যা খুঁজছেন তা এখনই খুঁজে নাও পেতে পারেন৷৷ আপনাকে রেফারেন্সগুলি অনুসরণ করতে হবে, মন্তব্যগুলি পড়তে হবে এবং লিঙ্কগুলিতে ক্লিক করতে হবে। কিন্তু গিটহাবের সমস্যা অনুসন্ধান আপনাকে সঠিক জায়গায় শুরু করবে। এবং একটু কৌতূহল এবং অন্বেষণের অনুভূতির সাথে, আপনি কী জন্য এসেছেন তা শিখবেন।
প্রশ্ন জিজ্ঞাসা করুন
দুর্ভাগ্যবশত, একটি প্রকল্প সম্পর্কে সমস্ত জ্ঞান তার ইতিহাস, সমস্যা এবং অনুরোধের মধ্যে পাওয়া যায় না। সবকিছু লিখে রাখা হয় না।
সুতরাং আপনি যদি সেই ব্যক্তিকে খুঁজে পান যে মূলত কোডটি লিখেছিল, সে সম্পর্কে জিজ্ঞাসা করুন৷৷ আপনি দেব সংস্কৃতি এবং ধারণাগুলি আবিষ্কার করবেন যা একটি সিদ্ধান্তের দিকে পরিচালিত করে। আপনি এই প্রকল্প সম্পর্কে কিছু ইতিহাস শিখবেন যা কখনও রেকর্ড করা হয়নি। এবং আপনি এমন পথগুলি সম্পর্কে শুনতে পাবেন যেগুলি কখনও নেওয়া হয়নি, যা আসলে এখন চেষ্টা করার অর্থ হতে পারে৷
৷সহজ উপায় বিপজ্জনক হতে পারে
কখনও কখনও, একটি সমাধান মনে হয় এত সহজ৷ . আপনাকে যা করতে হবে তা হল এই একটি জায়গায় এই একটি ব্যতিক্রমকে উদ্ধার করুন, এবং তারপর আপনি বাড়িতে যেতে পারেন!
কিন্তু আপনি বোঝেন না এমন কোড পরিবর্তন করা বিপজ্জনক৷৷
সুতরাং যখন কোডের একটি লাইন বন্ধ বলে মনে হয়, বা একটি সিদ্ধান্ত অদ্ভুত বলে মনে হয়, বা একটি কল অকেজো বলে মনে হয়, তখন আপনার প্রত্নতাত্ত্বিকের টুপি পরুন। সেই কোডটি সম্পর্কে আপনি যতটা পারেন, যাইহোক আপনি শিখুন। এভাবেই আপনি ইচ্ছাকৃতভাবে আপনার কোড পরিবর্তন করবেন এবং সমস্যাটির মূলে সমাধান করবেন।