কোড রিভিউ সহ বয় স্কাউট নিয়ম এবং সুযোগসত্তা রিফ্যাক্টরিং পুনর্বিবেচনা করা


55

আমি বয় স্কাউট নিয়মে একটি দুর্দান্ত বিশ্বাসী :

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

আমি অপারচুনিস্টিক রিফ্যাক্টরিং সম্পর্কিত ধারণা সম্পর্কেও দুর্দান্ত বিশ্বাসী :

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

বিশেষ করে রিফ্যাক্টরিং নিবন্ধের নীচের অংশটি নোট করুন:

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

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

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

(1) বেশিরভাগ সময় আপনি যখন বুঝতে পারেন যে আপনি যখন নিজের অ্যাসাইনমেন্টের মাঝে রয়েছেন তখন আপনি কী এবং কীভাবে রিফ্যাক্টর করতে চান। মার্টিন ফোলার যেমন লিখেছেন:

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

(২) আপনার "রিফ্যাক্টরিং" সিআরগুলি প্রকাশের বিষয়ে আপনার পক্ষে কেউ অনুকূলভাবে তাকাবে না you একটি সিআর এর একটি নির্দিষ্ট ওভারহেড থাকে এবং আপনার ব্যবস্থাপক চান না যে আপনি রিফ্যাক্টরিংয়ে "আপনার সময় নষ্ট করবেন"। আপনার যে পরিবর্তনটি করা উচিত তা যখন এটি বান্ডিল হয়ে থাকে তখন এই সমস্যাটি হ্রাস করা হয়।

সমস্যাটি রেশার্পার দ্বারা তীব্রতর করা হয়েছে, আমি যে প্রতিটি নতুন ফাইল পরিবর্তনের সাথে যুক্ত করেছি (এবং আমি আগে জানতাম না যে কোন ফাইলগুলি পরিবর্তিত হবে ঠিক তেমনভাবে) সাধারণত ত্রুটি এবং পরামর্শ দিয়ে লিখিত হয় - যার বেশিরভাগ স্পট এবং সম্পূর্ণ প্রাপ্য স্থাপন করা.

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

আমি কীভাবে এই পরিস্থিতির প্রতিকার করতে পারি সে সম্পর্কে কোনও চিন্তাভাবনা?


40
আমি এমন জায়গায় কাজ করতে অস্বস্তি বোধ করবyour manager doesn't want you to "waste your time" on refactoring
দেনিথ

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

2
@ t0x1n আমি এর চেয়ে আলাদা হিসাবে দেখতে পাচ্ছি না
দেনিথ

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

6
বুলেট 1 দাবি করে না যে কমিটগুলি পৃথক করা অসম্ভব। এটি কেবল বোঝায় যে আপনি এটি কীভাবে করবেন তা জানেন না বা আপনার ভিসিএস এটি শক্ত করে তোলে। আমি এটি সর্বদা করি, এমনকি একটি একক প্রতিশ্রুতি গ্রহণ করে এবং সত্যের পরে এটি বিভাজন করে।
অকেজো

উত্তর:


18

ঠিক আছে, সুতরাং এখানে মন্তব্যের উপযুক্ত হওয়ার চেয়ে আরও বেশি জিনিস রয়েছে।

TL; ড

আপনার যা করা উচিত তা সম্পর্কে আপনার স্বজ্ঞাততা (আপনি যেমন চলেছেন তেমন রিফ্যাক্টরিং) সঠিক।

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

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


কর্মপ্রবাহ / অফিস রাজনীতির বিষয়

আমি মূলত গ্লেনএইচ as এর মতো একই সুপারিশ করব যা আপনি দুটি কমিট তৈরি করেছেন - একটিতে কেবল রিফ্যাক্টরিং এবং (প্রদর্শিত বা স্পষ্টত) কোনও কার্যকরী পরিবর্তন নেই, এবং একটি প্রশ্নে কার্যকরী পরিবর্তন রয়েছে।

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


ভিসিএস ইস্যু

আপনার কার্যক্ষম উত্সে করা পরিবর্তনগুলি একাধিক কমিটে বিভক্ত করা চ্যালেঞ্জ হওয়া উচিত নয়। আপনি যা ব্যবহার করছেন তা আপনি বলেননি, তবে সম্ভাব্য ওয়ার্কফ্লোগুলি হ'ল:

  1. আপনি যদি গিট ব্যবহার করছেন তবে আপনার কাছে দুর্দান্ত সরঞ্জাম রয়েছে

    • আপনি git add -iকমান্ড লাইন থেকে ইন্টারেক্টিভ মঞ্চের জন্য ব্যবহার করতে পারেন
    • আপনি git guiপৃথক কুনি এবং পংক্তিগুলি পর্যায়ক্রমে ব্যবহার করতে এবং নির্বাচন করতে পারেন (এটি কয়েকটি ভিসিএস সম্পর্কিত জিইআইআই সম্পর্কিত যে আমি আসলে কমান্ড লাইনের চেয়ে বেশি পছন্দ করি, অন্যটি ভাল 3-উপায় সংহত সম্পাদক হ'ল)
    • আপনি প্রচুর ছোট ছোট কমিট করতে পারেন (স্বতন্ত্র পরিবর্তনগুলি বা একাধিক জায়গায় একই শ্রেণীর বাগটি ফিক্সিং) এবং তারপরে পুনরায় অর্ডার করতে, সেগুলিকে মার্জ করে বা এটিকে বিভক্ত করতে পারেন rebase -i
  2. আপনি যদি গিট ব্যবহার না করে থাকেন তবে আপনার ভিসিএসে এখনও এই ধরণের জিনিসটির জন্য সরঞ্জাম তৈরি থাকতে পারে তবে আপনি কোন সিস্টেমটি ব্যবহার করছেন তা না জেনে আমি পরামর্শ দিতে পারি না

    আপনি উল্লেখ করেছেন যে আপনি টিএফএস ব্যবহার করছেন - যা আমার বিশ্বাস টিএফএস ২০১৩ সাল থেকে গিটের সাথে সামঞ্জস্যপূর্ণ। এটিতে কাজ করতে রেপোর স্থানীয় গিট ক্লোন ব্যবহার করে পরীক্ষা করা উপযুক্ত। আপনার চূড়ান্ত কমিট রফতানি করুন।

  3. আপনি আপনার মত মৌলিক সরঞ্জাম এক্সেস আছে যদি থাকে VCS মধ্যে নিজে এটা করতে পারেন diffএবং patch। এটি আরও বেদনাদায়ক, তবে অবশ্যই সম্ভব। মূল কর্মপ্রবাহটি হ'ল:

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

আপনার পরিবর্তনগুলি যথাযথভাবে বিভাজন সহ এখন আপনার দুটি কমিট রয়েছে।

দ্রষ্টব্য এই প্যাচ পরিচালনাকে আরও সহজ করার জন্য সম্ভবত সরঞ্জামগুলি রয়েছে - আমি কেবল সেগুলি ব্যবহার করি না কারণ গিট এটি আমার জন্য করে।


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

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

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

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

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

29

আমি ধরে নিচ্ছি যে পরিবর্তনগুলির অনুরোধগুলি আপনার সংস্থায় বড় এবং আনুষ্ঠানিক। যদি তা না হয় তবে কেবলমাত্র ছোট ছোট কমিটে (যেমন আপনার অনুমিত হওয়ার কথা) পরিবর্তন করুন।

আমি কীভাবে এই পরিস্থিতির প্রতিকার করতে পারি সে সম্পর্কে কোনও চিন্তাভাবনা?

আপনি যা করছেন তা চালিয়ে যেতে চান?

মানে, আপনার সমস্ত চিন্তাভাবনা এবং কর্তন সম্পূর্ণরূপে সঠিক। আপনার দেখা জিনিসগুলি ঠিক করা উচিত। লোকেরা পর্যাপ্ত পরিকল্পিত রিফ্যাক্টরিং করে না। এবং পুরো গ্রুপের জন্য সেই সুবিধাটি কয়েকটি অসুবিধার চেয়ে বেশি গুরুত্বপূর্ণ।

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

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


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

13
@ t0x1n - আমার দিকে তাকাবেন না। আমি এমন লোকদের মুখে সঠিক জিনিস করার কেরিয়ার তৈরি করেছি যারা চুষে অনড় হয়ে দেখেন behold মানুষকে খুশি করতে পারলে আমার থেকে যতটা লাভজনক হতে পারে তা না হতে পারে তবে আমি ভাল ঘুমাই।
তেলস্তিন

সৎ হওয়ার জন্য ধন্যবাদ। এটা সত্যিই মনন কিছু।
t0x1n

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

1
@ স্যানপেরি আগ্রাহিত হয়েছিল - তবে আমি সাধারণ পরিস্থিতি সম্পর্কে বলছি যেখানে পরীক্ষা রয়েছে, বাগ
বাসগুলি করা

14

আপনার পরিস্থিতির প্রতি আমার অনেক সহানুভূতি রয়েছে, তবে কয়েকটি কংক্রিট পরামর্শ রয়েছে। আর কিছু না হলে, আমি আপনাকে বোঝাতে পারি যে পরিস্থিতি যত খারাপ, তত খারাপ হতে পারে। এটি সবসময় আরও খারাপ হতে পারে। :-)

প্রথমত, আমি মনে করি আপনার সংস্কৃতি নিয়ে আপনার দুটি সমস্যা রয়েছে (কমপক্ষে), কেবল একটি নয়। একটি সমস্যা হ'ল রিফ্যাক্টরিংয়ের পদ্ধতি, তবে কোড পর্যালোচনাগুলি একটি পৃথক সমস্যা বলে মনে হয়। আমি আমার চিন্তা আলাদা করার চেষ্টা করব।

কোড পর্যালোচনা

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

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

ম্যানেজমেন্ট সম্মত হয়েছিল যে মান অগ্রহণযোগ্যভাবে কম হওয়ার আগে আমাদের "কিছু করা" দরকার। :-) তাদের উত্তর ছিল কোড পর্যালোচনা। কোড পর্যালোচনাগুলি প্রতিটি চেক-ইন করার আগে, অফিসিয়াল "তুই শাল্ট" আইটেমে পরিণত হয়েছিল। আমরা যে সরঞ্জামটি ব্যবহার করেছি তা ছিল রিভিউ বোর্ড।

আমি বর্ণিত সংস্কৃতিতে এটি কীভাবে কাজ করবে? কিছুই না চেয়ে ভাল, কিন্তু এটি বেদনাদায়ক ছিল এবং কমপাল ন্যূনতম স্তরের সম্মতিতে পৌঁছতে এক বছরেরও বেশি সময় নিয়েছিল। কিছু বিষয় আমরা পর্যবেক্ষণ করেছি:

  1. আপনি যে সরঞ্জামটি ব্যবহার করছেন তা নির্দিষ্ট উপায়ে কোড পর্যালোচনাগুলিকে ফোকাস করে। এটি একটি সমস্যা হতে পারে। পর্যালোচনা বোর্ড আপনাকে সুন্দর, রঙিন লাইন বাই লাইন আলাদা করে দেয় এবং আপনাকে একটি লাইনে মন্তব্যগুলি সংযুক্ত করতে দেয়। এটি বেশিরভাগ বিকাশকারী পরিবর্তন করে না এমন সমস্ত লাইন উপেক্ষা করে। এটি ছোট, বিচ্ছিন্ন পরিবর্তনের জন্য দুর্দান্ত। এটি বড় পরিবর্তন, নতুন কোডের বৃহত হানস, বা কোডটির জন্য এতটা ভাল নয় যে নতুন কার্যকারিতার 10 টি লাইনের সাথে একটি নতুন নামকরণের ফাংশনের 500 টি উদাহরণ রয়েছে।
  2. যদিও আমরা একটি পুরানো, অসুস্থ কোড বেসে ছিলাম যা বেশিরভাগ আগে কখনও পর্যালোচনা করা হয়নি, তবুও কোনও পর্যালোচককে কোনও পরিবর্তন লাইন নয় এমন কোনও মন্তব্য করার জন্য এমনকি "স্পষ্টতই" পরিণত হয়েছিল, এমনকি একটি স্পষ্ট ত্রুটি চিহ্নিত করতে পারে। "আমাকে বিরক্ত করবেন না, এটি একটি গুরুত্বপূর্ণ চেক-ইন এবং আমার কাছে বাগগুলি ঠিক করার সময় নেই।"
  3. একটি "সহজ" পর্যালোচক জন্য কেনাকাটা করুন। কিছু লোকেরা 3 মিনিটের জন্য 2000 পরিবর্তিত লাইনগুলির সাথে একটি 10-ফাইল পর্যালোচনা দেখবে এবং "শিপ ইট!" ক্লিক করবে। প্রত্যেকেই তাড়াতাড়ি জানতে পারে যে এই লোকগুলি কে। যদি আপনি সত্যিই আপনার কোডটি প্রথম স্থানে পর্যালোচনা করতে না চান তবে এটি একটি "সহজ" পর্যালোচককে প্রেরণ করুন। আপনার চেক ইন ধীর করা হবে না। আপনি তার কোডের জন্য "সহজ" পর্যালোচক হয়ে অনুগ্রহটি ফিরিয়ে দিতে পারেন।
  4. আপনি যদি কোড পর্যালোচনাগুলি ঘৃণা করেন তবে পর্যালোচনা বোর্ডের কাছ থেকে পাওয়া ইমেলগুলি উপেক্ষা করুন। আপনার দলের সদস্যদের ফলো-আপগুলি উপেক্ষা করুন। সপ্তাহের জন্য. আপনার কাতারে 3 ডজন খোলা পর্যালোচনা না হওয়া পর্যন্ত এবং কয়েকবার গ্রুপ মিটিংয়ে আপনার নাম উঠে আসে। তারপরে একজন "সহজ" পর্যালোচক হয়ে উঠুন এবং মধ্যাহ্নভোজনের আগে আপনার সমস্ত পর্যালোচনা সাফ করুন।
  5. আপনার কোডটিকে "শক্ত" পর্যালোচককে প্রেরণ এড়িয়ে চলুন। (এই ধরণের বিকাশকারী যিনি এর মতো কোনও প্রশ্ন জিজ্ঞাসা বা উত্তর দিতেন)) সহজেই শিখলে "হার্ড" পর্যালোচক কারা, তা প্রত্যেকেই দ্রুত শিখে যায়। কোড পর্যালোচনাগুলি যদি সময়ের অপচয় (™) হয় তবে আপনার OWN কোড সম্পর্কিত বিশদ প্রতিক্রিয়া পড়া হ'ল সময় নষ্ট (™) এবং অপমান is
  6. কোড পর্যালোচনাগুলি বেদনাদায়ক হয়ে থাকে, লোকেরা এগুলি বন্ধ করে দেয় এবং আরও কোড লিখতে থাকে। আপনি কম কোড রিভিউ পাবেন, তবে প্রত্যেকটিই বড়। আপনার আরও, আরও ছোট কোড পর্যালোচনা প্রয়োজন, যার অর্থ দলের কীভাবে সম্ভব হিসাবে বেদনাদায়ক করা যায় তা কী তা নির্ধারণ করা দরকার।

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

refactoring

কোডটি পর্যালোচনাগুলি ঘৃণার চেয়েও কি আমার গ্রুপটি রিফ্যাক্টরিংকে তুচ্ছ করেছে? অবশ্যই! ইতিমধ্যে উল্লিখিত সমস্ত সুস্পষ্ট কারণগুলির জন্য। আপনি একটি আইকি কোড পর্যালোচনা দিয়ে আমার সময় নষ্ট করছেন, এবং আপনি এমনকি কোনও বৈশিষ্ট্য যুক্ত বা বাগ সংশোধন করছেন না!

তবে কোডটি এখনও পুনরায় সংশোধন করার মরিয়া ছিল। কীভাবে এগিয়ে যাব?

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

1
এটি একটি অত্যন্ত চিন্তাশীল উত্তর, ধন্যবাদ! আমি সিআর সরঞ্জামটি পর্যালোচনাটির ফোকাসকে কীভাবে প্রভাবিত করতে পারে তার সাথে আমি বিশেষত একমত ... লাইন বাই লাইনটি সহজ উপায়, এটি আসলে কী ঘটেছিল এবং এখন কী ঘটেছিল তা বোঝার সাথে জড়িত নয়। এবং অবশ্যই যে কোডটি পরিবর্তন হয়নি তা নিখুঁত,
এটির

1
" খারাপ হতে গেল rainin করা যায়নি '।। " যখন আমি পড়তে আপনার শেষ অনুচ্ছেদ (দ্বিতীয় দফা # 4) আমি ভাবছিলাম: তারা আরো পর্যালোচনা প্রয়োজন, সংকেতপদ্ধতিরচয়িতা পর্যালোচনা। এবং কিছু রিফ্যাক্টরিং, যেমন রয়েছে: "আপনার স্যালারি = 0"

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

13

কেন আপনি উভয় না, কিন্তু পৃথক কমিট দিয়ে?

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

তবে আপনি যদি বেশ কয়েকটি চমকপ্রদ সমস্যা দেখতে পান তবে দুটি বিকল্প রয়েছে যা আপনি অনুসরণ করতে পারেন।

  1. কোড পর্যালোচনা অন্যথায় ভাল থাকলে, আপনি যা অংশ পর্যালোচনা করেছেন তা প্রতিশ্রুতিবদ্ধ হওয়ার অনুমতি দিন এবং তারপরে দ্বিতীয় চেক-ইনের অধীনে কোডটিকে রিফ্যাক্টর করুন act

  2. কোড পর্যালোচনায় যদি সংশোধন দরকার হয় এমন সমস্যা থাকে তবে বিকাশকারীকে পুনঃ-সুপারিশের ভিত্তিতে রিফ্যাক্টরের অনুরোধ করুন।


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

8
@ t0x1n: যদি আপনার পরিচালকরা রিফ্যাক্টরিংয়ের বিষয়ে চিন্তা না করে এবং আপনার সহযোগী বিকাশকারীরা রিফ্যাক্টরিংয়ের বিষয়ে চিন্তা করেন না ... তবে সেই সংস্থাটি ধীরে ধীরে ডুবে যাচ্ছে। পলায়ন! :)
লগ করুন

8
@ t0x1n মাত্র কারণ আপনার একসাথে সংশোধন করুন মানে এই নয় আপনি করতে হবে কমিট তাদের একসঙ্গে। তদতিরিক্ত, এটি প্রায়শই দরকারী আপনার রিফ্যাক্টরিং আপনার কার্যকরী পরিবর্তনটি যাচাই করা থেকে প্রত্যাশিত প্রভাব ছিল পৃথক থেকে পৃথক কোন অপ্রত্যাশিত পার্শ্ব প্রতিক্রিয়া। অবশ্যই এটি সমস্ত রিফ্যাক্টরিংগুলিতে প্রযোজ্য না, তবে এটি সাধারণত খারাপ পরামর্শ নয়।
অকেজো

2
@ t0x1n - দৃ strong় কোডের মালিকানা সম্পর্কে কিছু বলতে আমার মনে নেই। আমার উত্তরটি ছিল একটি পর্যালোচক হিসাবে আপনার ভূমিকা খাঁটি রাখা। যদি কোনও পর্যালোচক পরিবর্তনগুলির সাথে পরিচয় করিয়ে দেয় তবে তারা আর কেবল পর্যালোচক নয়।

3
@ গ্লেনএইচ 7 সম্ভবত এখানে কিছু ভুল বুঝাবুঝি হয়েছিল - আমি পর্যালোচক নই। আমি কেবল আমার যা প্রয়োজন তা কোডিং করছি এবং কোডটি চালিয়ে আমি প্রক্রিয়াটি উন্নত করতে পারি। আমার পর্যালোচকরা তখন আমি যখন অভিযোগ করি।
t0x1n

7

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

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

অবশ্যই এটি রিফ্যাক্টরিংগুলির পরিবর্তনের ক্ষেত্রের বাইরে থাকা সমস্যার সমস্যার সরাসরি উত্তর নয় তবে আমি আশা করব যে আপনার বন্ধুবান্ধবরা পরিবর্তনগুলি যখন সেখানে পরিবর্তন করার সময় সেখানে রয়েছে তবে তারা পরিবর্তনের পিছনে যুক্তিটি আরও ভালভাবে বুঝতে পারবেন।

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


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

6

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

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

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


1
আপনি একবার মূল্যায়ন গেমটি জিততে চান যখন আপনি বুঝতে পারেন যে এটি আপনাকে বেতন বৃদ্ধি, বোনাস এবং স্টক বিকল্পের সাথে পুরষ্কার দেয় :)
t0x1n

2
না। আপনি নীতিগুলি @ t0x1n এর জন্য অর্থ লেনদেন করছেন। যে হিসাবে সহজ। আপনার তিনটি পছন্দ রয়েছে: সিস্টেমটি ঠিক করার, সিস্টেমকে গ্রহণ করার, সিস্টেম ত্যাগ করার জন্য কাজ করুন। বিকল্প 1 এবং 3 আত্মার পক্ষে ভাল।
সান পেরি

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

1
মেহ, আত্মারা
ছেয়ে গেছে

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

5

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

1. স্বয়ংক্রিয় পরীক্ষাগুলি দিয়ে আপনি যে পরিবর্তনগুলি করেছেন তা পরীক্ষা করতে পারবেন না যখন রিফ্যাক্টরটি করবেন না।

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

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

কোডের টুকরোগুলি ব্যবহার করবেন না যাতে আপনার ডোমেন-নির্দিষ্ট জ্ঞানের প্রয়োজন নেই।

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

আইডোমেটিক ভেরিয়েবলের নাম পরিবর্তনের পরিবর্তে তারা কী তা ব্যাখ্যা করে কেবল মন্তব্য করুন। যদি তারা মূ .় না হয় , দয়া করে তাদের নাম পরিবর্তন করুন। ছেড়ে না i, j, k, x, y, ইত্যাদি প্রায় ফ্লোটিং যখন ভাল নাম কাজ করবে।

সংক্ষিপ্তসারগুলির জন্য থাম্বের বিধি: লোকেরা যখন কথা বলছে, তারা একটি সংক্ষেপণ ব্যবহার করে, কোডটিতে সংক্ষেপটি ব্যবহার করা ঠিক আছে। কর্মক্ষেত্রে কোড বেস থেকে উদাহরণ:

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


এটি আপনার পরিস্থিতিতে বাস্তবে প্রযোজ্য নাও হতে পারে তবে এই বিষয়ে আমার মতামত রয়েছে।


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

2

এই প্রশ্নের এখন দুটি স্বতন্ত্র সমস্যা রয়েছে - কোড পর্যালোচনাগুলির পরিবর্তনের পর্যালোচনা করা সহজতরকরণ এবং পুনর্দক্ষতার উপর ব্যয় করা সময়।

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

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

(২) আপনার "রিফ্যাক্টরিং" সিআরগুলি প্রকাশের বিষয়ে আপনার পক্ষে কেউ অনুকূলভাবে তাকাবে না you একটি সিআর এর একটি নির্দিষ্ট ওভারহেড থাকে এবং আপনার ব্যবস্থাপক চান না যে আপনি রিফ্যাক্টরিংয়ে "আপনার সময় নষ্ট করবেন"। আপনার যে পরিবর্তনটি করা উচিত তা যখন এটি বান্ডিল হয়ে থাকে তখন এই সমস্যাটি হ্রাস করা হয়।

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

সমস্যাটি রেশার্পার দ্বারা তীব্রতর করা হয়েছে, আমি যে প্রতিটি নতুন ফাইল পরিবর্তনের সাথে যুক্ত করেছি (এবং আমি আগে জানতাম না যে কোন ফাইলগুলি পরিবর্তিত হবে ঠিক তেমনভাবে) সাধারণত ত্রুটি এবং পরামর্শ দিয়ে লিখিত হয় - যার বেশিরভাগ স্পট এবং সম্পূর্ণ প্রাপ্য স্থাপন করা.

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


সিআর পৃথকীকরণ সম্পর্কে, আমি আমার পোস্ট এবং অন্যান্য বেশ কয়েকটি মন্তব্যে কেন এটিকে অসম্ভব বলে মনে করি তা উল্লেখ করেছি।
t0x1n

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

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

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

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

2

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

গল্পটির সারাংশ হলো? আমি জানিনা. আমার ধারণা এটি কখনও কখনও নিজেকে বাদ দিয়ে কাউকে খুশি করতে পারে না। আমি সময় নষ্ট করছিলাম না (আমার চোখে) - ক্লিন আপ কোডটি পড়া এবং বোঝা সহজ ছিল । এটি ঠিক যে অন্যরা ব্যবহৃত আদিম পরিবর্তন নিয়ন্ত্রণ সরঞ্জামগুলি তাদের উপর কিছু অতিরিক্ত এক-শট কাজ রেখেছিল। স্পেস / ট্যাবিং এবং প্রত্যাবর্তিত মন্তব্যগুলিকে উপেক্ষা করার জন্য সরঞ্জামগুলি খুব আদিম ছিল।


হ্যাঁ, আমি ব্যবধানের জন্যও হোসড হয়েছি, তেমনি তুচ্ছ জিনিস যেমন অনর্থক ingালাই ইত্যাদি my
t0x1n

2

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

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

আচ্ছাদিত বিষয়গুলির মধ্যে রয়েছে:

  • সফ্টওয়্যার পরিবর্তনের মেকানিকগুলি বোঝা: বৈশিষ্ট্য যুক্ত করা, বাগ সংশোধন করা, নকশা উন্নতি করা, কর্মক্ষমতা অনুকূলকরণ optim
  • উত্তরাধিকারের কোডটি একটি পরীক্ষার জোয়ারে প্রবেশ করা
  • পরীক্ষাগুলি রচনা করা যা আপনাকে নতুন সমস্যার প্রবর্তন থেকে রক্ষা করে
  • যে ভাষাগুলি যে কোনও ভাষা বা প্ল্যাটফর্মের সাথে ব্যবহার করা যেতে পারে Java জাভা, সি ++, সি এবং সি # এর উদাহরণ সহ #
  • কোড পরিবর্তনগুলি কোথায় করা দরকার তা সঠিকভাবে সনাক্ত করে
  • বস্তু-ভিত্তিক নয় এমন উত্তরাধিকার ব্যবস্থাগুলির সাথে মোকাবিলা করা
  • অ্যাপ্লিকেশনগুলি হ্যান্ডলিং যা কোনও কাঠামো বলে মনে হয় না

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


2

আমিও বয়স্কাউট রুল এবং অ্যাফোরচুনিস্টিক রিফ্যাক্টরিংয়ের একজন দুর্দান্ত বিশ্বাসী। সমস্যাটি প্রায়শই ব্যবস্থাপনা কেনার ক্ষেত্রে হয় Ref রিফ্যাক্টরিংটি ঝুঁকি এবং ব্যয় উভয়ই নিয়ে আসে। ম্যানেজমেন্ট যা প্রায়শই পর্যবেক্ষণ করে তা হ'ল প্রযুক্তিগত .ণও।

এটি মানুষের স্বভাব। আমরা প্রকৃত সমস্যাগুলি মোকাবেলায় অভ্যস্ত, তাদের প্রতিরোধের চেষ্টা না করে। আমরা প্রতিক্রিয়াশীল, সক্রিয় না।

সফ্টওয়্যার অদম্য এবং তাই এটি বোঝা শক্ত যে একটি গাড়ির মতো এটিরও সার্ভিসিং করা দরকার। কোনও যুক্তিসঙ্গত ব্যক্তি গাড়ি কিনে আনতেন না এবং সেবার কোনও দিনই পরিষেবা দেবেন না। আমরা স্বীকার করি যে এই ধরনের অবহেলা তার দীর্ঘায়ু হ্রাস করবে এবং দীর্ঘমেয়াদে আরও ব্যয়বহুল হবে।

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

সত্যি কথা বলতে কি, আপনার ব্যবস্থাপক সর্বদা নিশ্চিত হন না যে আপনার প্রতিকারটি বাস্তবে যতটা দুর্দান্ত আপনি মনে করেন তত দুর্দান্ত। (সাপের তেল?) বিক্রয় বিক্রয় আছে। তাকে সুবিধাটি দেখতে সহায়তা করা আপনার কাজ।

পরিচালন আপনার অগ্রাধিকার ভাগ করে না। আপনার পরিচালনা টুপি এবং পরিচালনা চোখ দিয়ে দেখুন। আপনি সম্ভবত সঠিক কোণ খুঁজে পাবেন। ধৈর্য ধারণ কর. আপনাকে বিরক্ত করার জন্য প্রথম নেতিবাচক প্রতিক্রিয়া না দিয়ে আপনি আরও পরিবর্তনকে প্রভাবিত করবেন।


1

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

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

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


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

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

1
হতাশার অংশ! আমি কেবল আমার কাজের অংশ হিসাবে যে কোনও উপায়ে স্পর্শ করতে চাইতাম সেই ফাইলগুলিকেই আমি স্পর্শ করি, তবে আমি কেবল অভিযোগগুলিই পাই! আমি যে সতর্কতাগুলির কথা বলছি তা
হ'ল

@ t0x1n: এটি সত্যিই খুব হতাশাবোধ বলে মনে হচ্ছে। দয়া করে মনে রাখবেন যে আমি কেবল "স্থির কোড বিশ্লেষণ" নয় বরং অন্যান্য প্রস্তাবনাগুলিও নেক্সাসের সমতুল্য কিছু বোঝাতে চাইছিলাম। অবশ্যই, কোনও সরঞ্জাম 100% শব্দার্থক শব্দগুলি ধরে না; এটি কেবল একটি প্রতিকারের কৌশল।
লগ্যাক
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.