গুণমানের উন্নতির আশায় মিনি-রিফ্যাক্টর কোডটি কী কার্যকর, বা এটি খুব বেশি সুবিধা ছাড়াই কেবল "চলাচল কোড"?


12

উদাহরণ

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

রিফ্যাক্টর কেন? উদ্দেশ্য কি? এটা কি অকেজো? লাভ কী? মনে রাখবেন যে আমি বেশিরভাগ ক্ষেত্রে একচেটিয়া ফাইলটি রেখে দিয়েছি, তবে কেবলমাত্র সেই ছোট অংশটিই রিফ্যাক্ট করেছিলাম যেখানে আমার কিছু কাজ করার প্রয়োজন ছিল to

আসল কোড:

একটি কংক্রিট উদাহরণ দেওয়ার জন্য, আমি এই কোড স্নিপেট জুড়ে এসেছি - এটি পরিচিত পণ্য আইডি দ্বারা বা কোনও ব্যবহারকারী-নির্বাচিত সংস্করণ আইডি দ্বারা পণ্য স্পেসিফিকেশন লোড করে:

if ($verid)
    $sql1 = "SELECT * FROM product_spec WHERE id = " . clean_input($verid);
else
    $sql1 = "SELECT * FROM product_spec WHERE product_id = " . clean_input($productid) ;
$result1 = query($sql1);
$row1 = fetch_array($result1);
/* html markup follows */

refactoring:

যেহেতু আমি কোডের এই নির্দিষ্ট অংশে আমাকে জিনিসগুলি পরিবর্তন করার জন্য কিছু কাজ করছি, তাই আমি এটি সংগ্রহস্থল প্যাটার্ন ব্যবহার করতে পরিবর্তন করেছি এবং এটি অবজেক্ট-ভিত্তিক মাইএসকিউএল সুবিধাদি ব্যবহার করতে আপগ্রেড করেছি:

//some implementation details omitted 
$this->repository = new SpecRepository($mysql);
if ($verid)
    $row1 = $this->repository->getSpecByVersion($verid);
else 
    $row1 = $this->repository->getSpecByProductId($productid);
/* html markup follows to be refactored or left alone till another time*/

//added new class:
class SpecRepository extends MySqlRepository
{

    function getSpecByVersion(int $verid)
    {
        return $this->getMySql()->paramQuery("
            SELECT * FROM product_spec WHERE id = ?
        ", $verid)->getSingleArray();
    }

    function getSpecByProductId(int $productid)
    {
        return $this->getMySql()->paramQuery("
            SELECT * FROM product_spec WHERE product_id = ?
        ", $productid)->getSingleArray();
    }
}

আমার এই করা উচিত?

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

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

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

আমি কেন প্রথম জায়গায় রিফ্যাক্টর করলাম?

আমার ক্ষেত্রে আমি একটি নতুন পণ্য লাইনের জন্য নতুন কার্যকারিতা যুক্ত করছি, সুতরাং আমাকে হয় অনুরূপ পণ্য লাইনের জন্য বিদ্যমান কোড কাঠামো অনুসরণ করতে হবে, বা আমার নিজের লিখতে হবে।


ওটি তবে বিবেচনা করার মতো কিছু এটি Select * from ..এন্টি-প্যাটার্ন হিসাবে বিবেচনা করা যেতে পারে। দেখুন stackoverflow.com/q/3639861/31326
পিটার এম

1
@ পিটারএম: আপনি যদি ওআরএম না লিখে থাকেন তবে এই ক্ষেত্রে select *একটি "সেরা অনুশীলন" হয়ে যায়।
রবার্ট হার্ভে

@RobertHarvey সালে যে ক্ষেত্রে আমি জিজ্ঞাসাবাদ করছি কেন আপনি আপনার নিজের ORM লিখছেন: ডি
পিটার এম

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

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

উত্তর:


13

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

আমি এও বলব যে আপনি যে সুবিধাটি এখানে পেয়েছিলেন তা হ'ল কোড যা সহজেই আমার দৃষ্টিকোণ থেকে বোঝা যায় যে কেউ আপনার কোড বেসটি জানেন না।


সাধারণভাবে:

রিফ্যাক্টরিংটি কি অন্য বিকাশকারীদের আপনার কোড বুঝতে সহজ করে তোলে?

রিফ্যাক্টরিং কি কোডটি বাড়ানো সহজ করে?

রিফ্যাক্টরিং কি কোড বজায় রাখা সহজ করে তোলে?

রিফ্যাক্টরিং কি ডিবাগ করা সহজ করে?

যদি এগুলির কোনওটির উত্তর "হ্যাঁ" হয়, তবে এটির মূল্য ছিল, এবং এটি কেবল "চলাফেরার কোড" এর চেয়ে বেশি ছিল?

যদি এই সমস্তটির উত্তরটি "না" হয়, তবে সম্ভবত এটি পুনরায় সঞ্চার করার প্রয়োজন ছিল না।

কোড বেসের চূড়ান্ত আকারটি এলওসি-র ক্ষেত্রে বৃহত্তর হতে পারে (যদিও কিছু রিফ্যাক্টরিজগুলি রিডানড্যান্ট কোডটি সুবিন্যস্ত করে কোড বেসকে সঙ্কুচিত করতে পারে), তবে অন্য লাভগুলি থাকলে এটি কোনও কারণ নয়।


9

আপনি যদি কোনও একপাল বিছিন্ন করে থাকেন তবে রিফ্যাক্টরিং ফুলে যায়।

তবে আপনি ইতিমধ্যে সুবিধাটি খুঁজে পেয়েছেন।

"আমার ক্ষেত্রে আমি একটি নতুন পণ্য লাইনের জন্য নতুন কার্যকারিতা যুক্ত করছি" "

জিনিসগুলি না ভেঙে আপনি খুব সহজেই এক একপথে কার্যকারিতা যুক্ত করতে পারবেন না।

আপনি বলেছিলেন যে একই কোডটি ডেটা পাচ্ছে এবং মার্কআপ করছে। দুর্দান্ত, যতক্ষণ না আপনি নির্দিষ্ট কন্ডিশনে কোন কলামগুলি নির্বাচন করছেন এবং ম্যানিপুলেট করছেন তা পরিবর্তন করতে চান। হঠাৎ, আপনার মার্কআপ কোড একটি নির্দিষ্ট ক্ষেত্রে কাজ স্টপ এবং আপনি আছে refactor।


হ্যাঁ, তবে আমি এমনকি নতুন কার্যকারিতার জন্য একচেটিয়াতে যুক্ত করে রাখতে পারি :) আমি একটি নতুন if/elseব্লক যুক্ত করব এবং এসকিউএল স্টেটমেন্ট যুক্ত করার জন্য কোডের মূল স্টাইলটি অনুসরণ করব এবং তারপরে আমি একই মনোলিথ ফাইলে নতুন এইচটিএমএল চিহ্নিত করব would এবং কলামগুলি পরিবর্তন করতে আমি যদি / অন্যটি এসকিউএল লাইনগুলি আবাসন করার জন্য দায়বদ্ধ করে এবং সেই ফাইলটি না ভাঙিয়ে কলামগুলিতে পরিবর্তন করতে সেই এসকিউএল সম্পাদনা করি।
ডেনিস

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

2

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

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

আমি নিম্নলিখিত কারণে রিফ্যাক্টরিংকে গুরুত্ব দিই:

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

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

আমি বাগ প্রবর্তন। আমি দেখতে পাচ্ছি কিছু প্রশ্নোত্তর কেন জিজ্ঞাসা করছে are you guys doing refactoring? because everything stopped working!এটি এই ঝুঁকি টিমকে গ্রহণ করা উচিত এবং আমাদের সর্বদা এটি সম্পর্কে স্বচ্ছ হতে হবে।

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


এটি একটি ডাউন ভোটের খুব কাছাকাছি - 'কম্পিউটার প্রোগ্রামার'-এ' আমি 'নেই। 'আমি' দ্বারা আপনি কি আমাকে 'আমি' (ভোট দিয়েছিলেন) বা আপনার অর্থ কি ডেভলপাররা এখন এবং ভবিষ্যতে কোডে কাজ করছেন?
mattnz

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

1

আমার মনে হয় আপনার নিজের কাছে যে প্রশ্নটি জিজ্ঞাসা করতে হবে তা এতটা নয় "কোনও লাভ আছে কি?" তবে "এই কাজের জন্য কে দেবে?"

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

কোডটি দেখার জন্য আপনি কোনও কোথাও কোনও দেব দলে থাকলে এবং এটিকে আরও ভাল করার জন্য এটিকে রিফ্যাক্টর করতে চাইলে এটি খুব সহজ। যখন পণ্যটি ইতিমধ্যে কাজ করে তখন 'আরও ভাল কোড'-এ একটি মান রাখা।

'নতুন বৈশিষ্ট্যগুলির দ্রুত বিকাশ' এর মতো জিনিসগুলি এটি কাটবে না কারণ এগুলি কেবল ব্যয় হ্রাস পেয়েছে। আপনার বিক্রয় উত্পাদন করা দরকার।


1

আমার মতে রিফ্যাক্টরিং একটি ভাল বিনিয়োগ।

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

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

যদি আপনাকে আপনার বস বা সহকর্মীদের বোঝাতে হয় তবে আপনার চতুর পদ্ধতি সম্পর্কে (যেমন SCRUM) কয়েকটি বই পড়তে হবে এবং পরীক্ষা চালিত বিকাশ করতে হবে।

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