"পরিবর্তিত হয় না" হিসাবে চিহ্নিত কোডটি কি আমার রিফ্যাক্টর করা উচিত?


148

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

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

মডিউল এটিকে স্টাফ করার জন্য কিছু সময় দেওয়ার সময় নির্ধারিত। এটি যদি এর মতো সময়োপযোগী না হয় তবে এটি ভেঙে যাবে।

অথবা

এটি পরিবর্তন করবেন না। আমার উপর বিশ্বাস রাখো, তুমি জিনিস ভেঙে দেবে

অথবা

আমি জানি সেটটাইমআউট ব্যবহার করা ভাল অভ্যাস নয়, তবে এই ক্ষেত্রে আমাকে এটি ব্যবহার করতে হয়েছিল

আমার প্রশ্নটি হ'ল: যখন আমি লেখকদের কাছ থেকে এই ধরনের সতর্কতার মুখোমুখি হই তখন কি কোডটি রিফ্যাক্ট করা উচিত (না, আমি লেখকদের সাথে যোগাযোগ করতে পারি না)?


157
অভিনন্দন! আপনি এখন কোড লেখক।

12
আপনি এটি স্থির করতে পারবেন না যতক্ষণ না আপনি এটি করা উচিত এবং এটি আসলে কী করে উভয়ই জানেন (আপনার পরিবর্তনের সম্পূর্ণ পরিণতি বোঝার জন্য আপনাকে পরবর্তীটি জানা উচিত)) সমস্যাটি সংলগ্নকরণ হিসাবে দেখা যায় এবং এই জাতীয় সমস্যাগুলি সরিয়ে ফেলা হয় # 1 কাজটি রিফ্যাক্টর করা উচিত, অন্যথায় প্রতিটি পরিবর্তনগুলির সাথে জিনিসগুলি আরও খারাপ হতে চলেছে। আপনার যে প্রশ্নটি করা উচিত তা হ'ল এটি কীভাবে করা যায়। এই প্রশ্নে ভাষা এবং প্ল্যাটফর্ম-নির্ভরতা একটি পর্যাপ্ত পরিমাণ আছে। উদাহরণ: stackoverflow.com/questions/3099794/finding-threading-bugs
sdenham

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

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

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

উত্তর:


225

দেখে মনে হচ্ছে আপনি "কেবলমাত্র ক্ষেত্রে" রিফ্যাক্ট করছেন, সঠিকভাবে কোডবেজের কোন অংশগুলি পরিবর্তন করা হবে যখন নতুন বৈশিষ্ট্য বিকাশ ঘটবে তা সঠিকভাবে না জেনে । অন্যথায়, আপনি জানতেন যে ভঙ্গুর মডিউলগুলির রিফ্যাক্টর করার প্রকৃত প্রয়োজন আছে, বা যদি আপনি সেগুলি যেমন রেখে দিতে পারেন তবে।

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

এখানে একটি আরও ভাল কৌশল: আপনার সময় ব্যবহার করুন

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

  • রিফ্যাক্টর কেবলমাত্র বিটগুলি আপনার জায়গায় পরীক্ষাগুলি আনতে হবে। প্রয়োজনীয় যে কোনও পরিবর্তনকে হ্রাস করার চেষ্টা করুন। একমাত্র ব্যতিক্রম হ'ল যখন আপনার পরীক্ষাগুলি বাগগুলি প্রকাশ করে - তারপরে তাৎক্ষণিকভাবে ঠিক করুন (এবং আপনাকে নিরাপদে এমনভাবে ডিগ্রি দেওয়ার জন্য রিফ্যাক্টর)।

  • আপনার সহকর্মীদের "বয় স্কাউট নীতি" (এ কেএ "সুবিধাবাদী রিফ্যাক্টরিং" ) শিখুন , সুতরাং যখন দলটি নতুন বৈশিষ্ট্যগুলি (বা বাগগুলি ঠিক করতে) যুক্ত করতে শুরু করবে তখন তাদের কোড বেসের ঠিক কিছু অংশগুলি পরিবর্তন করতে হবে এবং তাদের পুনরুদ্ধার করা উচিত, কম নয়, বেশি নয়।

  • দলের জন্য ফেদার বই "উত্তরাধিকারের কোডের সাথে কার্যকরভাবে কাজ করা" বইয়ের একটি অনুলিপি পান।

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

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


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

98
আমি তর্ক করবে একটি মন্তব্য দিয়ে চিহ্নিত করা কোন কোড "টাইম আউট মডিউল একটি কিছু সময় উপাদান কি দিতে সেট। তার ভালো সময় শেষ না হলে, তা ভঙ্গ হবে" ইতিমধ্যে একটি বাগ আছে। এটি কেবল ড্রয়ের ভাগ্য যে বাগটি আঘাত হানে না।
26

10
@ 17of26: একটি বাগ অবশ্যই প্রয়োজন নেই। কখনও কখনও আপনি যখন তৃতীয় পক্ষের গ্রন্থাগারগুলির সাথে কাজ করছেন তখন আপনাকে কাজ করতে এটির লক্ষ্যে সমস্ত ধরণের "কমনীয়তা" ছাড় দিতে বাধ্য করা হয়।
হোসাইজ করুন

30
@ 17of26: যদি কোনও স্টাফের মডিউলটিতে বাগ রয়েছে বলে সন্দেহ করা হয় তবে কোনও ধরণের রিফ্যাক্টরিংয়ের আগে পরীক্ষা যুক্ত করা আরও গুরুত্বপূর্ণ is এবং যখন এই পরীক্ষাগুলি বাগটি প্রকাশ করে, তখন আপনাকে সেই মডিউলটি পরিবর্তন করতে হবে এবং অবিলম্বে এটিকে রিফেক্টর করার জন্য একটি আইনীকরণ। যদি পরীক্ষাগুলি কোনও বাগ প্রকাশ না করে তবে কোডটি যেমন হয় তেমনি রেখে দিন।
ডক ব্রাউন

17
@ অ্যারন: আপনি কেন পরীক্ষাগুলি যুক্ত করার বা বাল্য স্কাউটের নীতি অনুসরণ করার ফলে পণ্যের গুণমান হ্রাস করবেন তা আমি বুঝতে পারি না।
ডক ব্রাউন

142

হ্যাঁ, অন্যান্য বৈশিষ্ট্যগুলি যুক্ত করার আগে আপনার কোডটি রিফেক্টর করা উচিত।

এই জাতীয় মন্তব্যে সমস্যাটি হ'ল তারা কোড পরিবেশের যে পরিবেশে চলছে তার নির্দিষ্ট পরিস্থিতির উপর নির্ভর করে। একটি নির্দিষ্ট সময়ে প্রোগ্রাম করা সময়সীমাটি প্রোগ্রাম করার সময় সত্যই প্রয়োজনীয় হতে পারে।

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

আপনার ক্ষেত্রে, আপনি মূল পরিস্থিতিগুলি জানেন না এবং আপনি মূল লেখককেও জিজ্ঞাসা করতে পারবেন না। (সম্ভবত আপনারও যথাযথ রিগ্রেশন / ইন্টিগ্রেশন টেস্টিং নেই, অথবা আপনি কেবল এগিয়ে যেতে পারেন এবং আপনার পরীক্ষাগুলি আপনাকে কিছু ভঙ্গ করেছে কিনা তা জানাতে পারে))

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


46
এখানে সেরা উত্তর; খুব খারাপ এটি একটি আন্ডারডগ উপরে গৃহীত উত্তরটি ভাল পরামর্শ নয়, বিশেষত "ডুমুড" এর উপর জোর দেওয়া। আমি সর্বশেষ বৃহত্তম বছরে কাজ করেছি (এটির আমার বিভাগের জন্য ~ 10 ^ 6LOC ), উত্তরাধিকারের-পূর্ববর্তী, আমি কখনও দেখেছি এমন ভীষণ কোড এবং আমি যখন ট্রেনটি নষ্ট করেছি তখন ঠিক করার অভ্যাসটি করেছি সময়, এমনকি আমি যে উপাদানটির সাথে কাজ করছি তার অংশ না হলেও। এটি করতে গিয়ে আমি খুঁজে পেয়েছি এবং বাগগুলি স্থির করেছি যে দেব দলটি এমনকি সচেতন ছিল না (যদিও আমাদের শেষ ব্যবহারকারীরা সম্ভবত ছিলেন)। আসলে, আমি নির্দেশিত হয়। ফলস্বরূপ পণ্যটির উন্নতি হয়েছে।
অ্যারন

10
যদিও আমি সেই রিফ্যাক্টরিংকে কল করব না, তবে বাগ-ফিক্সিং করব।
পাওলো ইবারম্যান 18

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

10
অ্যারন আপনি এটি করতে পরিচালনা / বিকাশকারী সমর্থন পাওয়ার জন্য ভাগ্যবান। বেশিরভাগ পরিবেশে দুর্বল নকশা এবং কোডের কারণে জ্ঞাত এবং অজানা বাগগুলি প্রাকৃতিক ক্রম হিসাবে গ্রহণযোগ্য accepted
রুডলফ ওলা

5
@ নোকমপ্রেডে আমি যুক্তি দিয়ে বলব যে আপনি যদি সিস্টেমটি এর জন্য কিছু পরীক্ষা লেখার পক্ষে যথেষ্ট পরিমাণে বুঝতে না পারেন তবে এটি কীভাবে কাজ করে তা আপনার কোনও ব্যবসায়িক পরিবর্তন নেই।
প্যাট্রিক এম

61

আমার প্রশ্নটি হ'ল: যখন আমি লেখকদের কাছ থেকে এই ধরনের সতর্কতাগুলির মুখোমুখি হই তখন কি আমি কোডটি রিফ্যাক্ট করব?

না, বা কমপক্ষে এখনও না। আপনি বোঝাচ্ছেন যে স্বয়ংক্রিয় পরীক্ষার স্তরটি খুব কম। আত্মবিশ্বাসের সাথে রিফ্যাক্টর করার আগে আপনার পরীক্ষা করা দরকার।

আপাতত আমরা আর কিছু ভেঙে ফেলা ছাড়া আর কোনও বৈশিষ্ট্য যুক্ত করতে পারছি না

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

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

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

প্রতিবার আপনি যখন কোনও ত্রুটি ঠিক করেন, তখন একটি পরীক্ষার কেস যুক্ত করুন যা প্রমাণ করে যে বাগটি ঠিক হয়ে গেছে। এটি সরাসরি প্রতিরোধগুলি প্রতিরোধ করে।

আপনি যখন কোনও নতুন বৈশিষ্ট্য যুক্ত করেন, কমপক্ষে কিছু বেসিক পরীক্ষা যোগ করুন যা নতুন বৈশিষ্ট্যটি ইচ্ছাকৃতভাবে কাজ করে।

সম্ভবত "লিগ্যাসি কোডের সাথে কার্যকরভাবে কাজ করা" এর একটি অনুলিপি পাবেন?

বিদ্যমান কোডটি রিফ্যাক্টর করার জন্য আমাকে কয়েক মাস সময় দেওয়া হয়েছিল।

পরীক্ষার কভারেজ পেয়ে শুরু করুন। যে অঞ্চলগুলি সবচেয়ে বেশি ভেঙে যায় সেগুলি দিয়ে শুরু করুন। সর্বাধিক পরিবর্তন হওয়া অঞ্চলগুলি দিয়ে শুরু করুন। তারপরে আপনি একবার খারাপ ডিজাইনগুলি সনাক্ত করে ফেললে একে একে একে প্রতিস্থাপন করুন।

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


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

2
ঠিক। বা যদি ব্যবহারযোগ্য স্পেক পরীক্ষা না হয় তবে পূর্ববর্তী আচরণটি আসলে লোকেদের সফ্টওয়্যারটির জন্য অর্থ প্রদান বা আগ্রহী হওয়ার জন্য পছন্দ করেছে কিনা।
বিডিএসএল

সম্ভবত "লিগ্যাসি কোডের সাথে কার্যকরভাবে কাজ করা" এর একটি অনুলিপি পাবেন? এই বইটি পড়তে তাকে কত সপ্তাহ লাগবে? এবং কখন: কর্মক্ষেত্রে কাজের সময়, রাতে যখন সবাই ঘুমায়?
বিল্লাল বেগেরাদজ

23

জে কে চেস্টারটনের বেড়া মনে রাখবেন : কোনও রাস্তা কেন তৈরি হয়েছে তা বুঝতে না পারলে কোনও রাস্তা বাধাগ্রস্ত করতে কোনও বেড়া নামাবেন না।

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

আপনার উদ্দেশ্যটি কোডটি কী করে এবং কেন এটি তখন একটি সতর্কতার সাথে চিহ্নিত করা হয়েছিল এবং সেই সতর্কতাটিকে অগ্রাহ্য করা হলে কী হবে তা বোঝার জন্য পৌঁছানো।

তার আগে, আমি যে কোডটি "স্পর্শ করি না" চিহ্নিত আছে তা স্পর্শ করব না।


4
ওপি বলেছেন "না, আমি লেখকদের সংস্পর্শে আসতে পারি না"।
FrustratedWithFormsDesigner

5
আমি লেখকদের সাথে যোগাযোগ করতে পারি না বা কোনও ডকুমেন্টেশনও নেই।
কুকিস

21
@ কুকিস: আপনি লেখক, কোনও ডোমেন বিশেষজ্ঞের সাথে যোগাযোগ করতে পারবেন না, এবং প্রশ্নযুক্ত কোড সম্পর্কিত কোনও ইমেল / উইকি / ডকস / পরীক্ষার মামলা খুঁজে পাবেন না? ঠিক আছে, তবে এটি সফ্টওয়্যার প্রত্নতত্ত্বের একটি সম্পূর্ণ বিকাশ গবেষণা প্রকল্প, কোনও সাধারণ রিফ্যাক্টরিংয়ের কাজ নয়।
9000

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

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

6

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

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

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

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

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


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

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

5

যদি জিনিসগুলি ঠিক যেমন কাজ করে ঠিক তেমন কাজ করে তবে সম্ভবত এই ধরনের সতর্কতাগুলির সাথে রিফ্যাক্টর কোডের পক্ষে ভাল ধারণা নয়।

তবে আপনি যদি অবশ্যই চুল্লী ...

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


5

আমি বলি এগিয়ে যাও এবং এটি পরিবর্তন করুন। বিশ্বাস করুন বা না করুন, প্রতিটি কোডার একটি প্রতিভা নয় এবং এর মতো একটি সতর্কতা এর অর্থ এটি উন্নতির স্থান হতে পারে। আপনি যদি লেখককে ঠিক বলে মনে করেন তবে আপনি ডকুমেন্টটি (হাঁপাতে) বা সতর্কতার কারণ ব্যাখ্যা করতে পারেন।


4

আমি আমার মন্তব্যগুলিকে উত্তরে প্রসারিত করছি কারণ আমি মনে করি যে নির্দিষ্ট সমস্যার কিছু দিক হয় উপেক্ষা করা হচ্ছে, বা ভুল উপসংহার টানতে ব্যবহৃত হয়েছিল।

এই মুহুর্তে, রিফ্যাক্টরটি করা উচিত কিনা তা অকালিক (যদিও এটি সম্ভবত 'হ্যাঁ'র একটি নির্দিষ্ট ফর্মের দ্বারা উত্তর দেওয়া হবে)।

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

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

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

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


1
মন্তব্যগুলিতে আপনি কোথায় "রেসের অবস্থা" দেখছেন? এমনকি এটি নিহিত কোথায়? আপনি কোডটিতে দেখার সুবিধা ছাড়াই এখানে একটি ভয়ঙ্কর প্রযুক্তিগত অনুমান তৈরি করছেন।
রবার্ট হার্ভে

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

3

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

রিফ্যাক্টরিংয়ের সময় সময়ে সময়ে আমার ক্লাস, পদ্ধতি বা কোডের লাইনগুলির মুখোমুখি হয় যার মতামত রয়েছে ["এটিকে স্পর্শ করবেন না!"]

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

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


2

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

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

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

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

তবে তবুও, আপনার ব্যবস্থাপনায় আপনি যা করছেন তার মধ্যে অন্তর্ভুক্ত ঝুঁকিটি বোঝার দরকার এবং আপনি সম্মত হন যে আপনি যা করছেন তার একটি ব্যবসায়িক মূল্য রয়েছে যা ঝুঁকিকে ছাড়িয়ে যায় এবং সেই ঝুঁকি হ্রাস করার জন্য আপনি যা করেছেন তা করেছেন।

এখন, আসুন আমরা সবাই আমাদের নিজস্ব টডোতে ফিরে যাই এবং আমরা যদি জানি যে জিনিসগুলি যদি আরও বেশি সময় থাকে তবে আমাদের নিজস্ব কোড তৈরিতে উন্নত করা যায়।


1

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

তবে এটি একটি সতর্কবার্তা যে এগুলি সংশোধন করার জন্য প্রচুর পরিশ্রমের প্রয়োজন হবে এবং এই ধরনের সংশোধনগুলির সাথে তাদের ঝুঁকি রয়েছে।

আদর্শভাবে, আপনি সমস্যাটি কী তা নির্ধারণ করতে এবং এটি সঠিকভাবে সমাধান করতে সক্ষম হবেন। উদাহরণ স্বরূপ:

মডিউল এটিকে স্টাফ করার জন্য কিছু সময় দেওয়ার সময় নির্ধারিত। এটি যদি এর মতো সময়োপযোগী না হয় তবে এটি ভেঙে যাবে।

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

এটি পরিবর্তন করবেন না। আমার উপর বিশ্বাস রাখো, তুমি জিনিস ভেঙে দেবে

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

আমি জানি সেটটাইমআউট ব্যবহার করা ভাল অভ্যাস নয়, তবে এই ক্ষেত্রে আমাকে এটি ব্যবহার করতে হয়েছিল।

এটি দেখতে অনেক সহজ। আপনি কী setTimeoutকরছেন তা দেখতে সক্ষম হওয়া এবং সম্ভবত এটি করার আরও ভাল উপায় খুঁজে পাওয়া উচিত।

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

সর্বনিম্ন, প্রভাবিত কোডটি ঘনিষ্ঠভাবে দেখুন এবং দেখুন আপনি কমপক্ষে এই মন্তব্যটি উন্নত করতে পারেন কিনা তা এটি আরও স্পষ্টভাবে ব্যাখ্যা করে যে সমস্যাটি কী। এটি পরবর্তী ব্যক্তিকে আপনার একই রহস্যের মুখোমুখি হতে বাঁচাতে পারে।


2
এটা সম্ভব যে শর্তগুলি সেই স্থানে পরিবর্তিত হয়েছে যেখানে পুরানো সমস্যাগুলি একেবারেই নেই and ডুব দিন এবং পরিস্থিতিটি কী তা শিখুন বা দেখুন যে এটি ইতিহাসে চলে গেছে।

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

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

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

1

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

কোডটি অনুমান করা এবং ট্রায়াল-অ্যান্ড-ত্রুটির মাধ্যমে বাস্তবে কী ঘটে থাকে তার সম্পূর্ণ ধারণা ছাড়াই বিকাশ করা হয়।

এর অর্থ:

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

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

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

এর অর্থ কাজটি কেবলমাত্র রুটিন রিফ্যাক্টরিংয়ের চেয়ে অনেক বেশি চাহিদাযুক্ত demanding আপনাকে এটি একটি বাস্তব বিকাশের কাজ হিসাবে নির্ধারণ করতে হবে।

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


-1

আমি যে প্রশ্নটি জিজ্ঞাসা করব তা হ'ল কেন কেউ লিখেছেন, প্রথমে সম্পাদনা করবেন না।

আমি প্রচুর কোডে কাজ করেছি এবং এর কয়েকটি কুৎসিত এবং সময় প্রদত্ত সীমাবদ্ধতার মধ্যে কাজ করার জন্য অনেক সময় এবং প্রচেষ্টা নিয়েছি।

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

অন্য কথায়, আমার জীবনের সাথে আরও ভাল জিনিস করার কারণে আমি এটি আবার ঠিক করতে চাই না।

ডোন এডিট না করে, এটি বলার একটি উপায় যা আমরা এখনই জানব যা আমরা এখনই জানতে পারি এবং তাই ভবিষ্যতে আমরা কখনই নতুন কিছু শিখব না।

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

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

আমি মনে করি শেষ পর্যন্ত, পণ্যটিকে প্রাকৃতিক এবং জৈব উপায়ে বিকশিত করার এবং প্রতিরোধের উপর বিধিনিষেধ আরোপ করার জন্য এটি ছোট করে দেওয়া হয়েছে।


2
এটি 9 টি পূর্ব উত্তরগুলিতে তৈরি এবং ব্যাখ্যা করা পয়েন্টগুলির চেয়ে বেশি কিছু দেওয়ার প্রস্তাব দিচ্ছে না
জিনাত
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.