কোড রিফ্যাক্টরিং এবং অপ্টিমাইজেশান একটি চতুর এবং জলপ্রপাত প্রক্রিয়া টাইমলাইন উভয় ফিট করা উচিত?


10

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

উত্তর:


13

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

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

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

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

বিকাশকালে, আপনি জানেন যে আপনার একটি সিস্টেম দরকার যা প্রতি সেকেন্ডে 10KB কাঁচা ডেটা প্রক্রিয়া করতে সক্ষম হবে। আপনি একটি লোড পরীক্ষা করেন এবং আপনার প্রাথমিক খসড়া অ্যালগরিদম 8KB / s পরিচালনা করে। আচ্ছা, এটি এএটি পাস করবে না। আপনি একবার দেখুন এবং দেখুন যে আপনার অ্যালগোরিদমে কিছু ও (আমার )শ্বর) - কমপ্লেক্সিটি লুপ কাঠামো রয়েছে; আপনি এটিকে প্রবাহিত করুন এবং 12 কেবি / গুলি পান। "খুব ভাল", আপনি ভাবেন, "তবে কোডটিতে আমার যদি এই দুর্বলতা থাকে তবে আমি আর কী শেভ করতে পারি?"। বাজ আপনি সবেমাত্র "অকাল অপ্টিমাইজেশন" নিয়ম লঙ্ঘন করেছেন। আপনার কোড কাজ করে, এবং সমস্ত প্রয়োজনীয়তা পাস করে। 15KB / s প্রয়োজনের জন্য প্রয়োজনীয়তা আপডেট না হওয়া পর্যন্ত আপনি "সম্পন্ন" হয়ে গেছেন। যদি এবং যখন এটি হয়, তখন আপনি কোডটি ব্যাক আপ করে টানুন এবং উন্নত করার জন্য জিনিসগুলি সন্ধান করুন।

এগিল বা simpleতিহ্যবাহী এসডিএলসি-তে বিকাশের সময় এই সহজ প্রক্রিয়াটি অনুসরণ করুন: "প্রথম পাসে, এটি কাজ করুন the দ্বিতীয় পাসে, এটি সুন্দর করুন the তৃতীয় পাসে, এটি সলিড করুন" " এর অর্থ হ'ল, আপনি যখন প্রথমে কোডের একটি লাইন তৈরি করেন, সেই কোডটি সঠিকভাবে এবং কাজ-ত্রুটিমুক্ত করে তুলুন তবে এই কোডের মধ্যে ডিজাইনের বিধিগুলিতে খুব বেশি মনোযোগ দেবেন না, কারণ এখনই আপনারা সবাই জানেন know এই অঞ্চলটিকে আর কখনও স্পর্শ করব না। পরের বার আপনি সেই কোডের লাইনটি পরিদর্শন করলেন, আপনি কেবল নিজেকে ভুল প্রমাণ করেছেন; এটি এখন আর সিস্টেমের এক-অফ টুকরা নয়। এটি পাঠযোগ্যতা, কোডের সংক্ষিপ্ততা এবং / বা DRY নীতিগুলির জন্য রিফ্যাক্টর (আপনি পাঁচবার কিছু করার জন্য কিছু কোড কপি-পেস্ট করে থাকতে পারেন; রিফ্যাক্টর যা একটি লুপ এবং / অথবা কোনও পদ্ধতির কল)। তৃতীয়বারের মতো আপনি কোডের এই লাইনে বা এর আশেপাশে কাজ করছেন,


3
+1 কারণ O(my God)-complexityআর কিছু না হলে, আমাকে হাসাহাসি করলেন!
জোয়েল সি

এটি প্রথমে কাজ করার জন্য +1 অনেক লোক নিদর্শনগুলি লেখার চেষ্টা করে এবং অকাল আগে ব্যাট বন্ধ করে দেয়।
জাস্টিন শিল্ড

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

আমি প্র্যাকমেটিক অ্যাপ্রোচটি পছন্দ করি তবে আমার "দ্বিতীয় পাসে, এটি সুন্দর করুন" নিয়ে সমস্যা আছে: ২ য় পাসটি যদি এক বছর পরে হয় এবং আপনি শুরুর দিকে না যান যে পরিবর্তনশীল এবং পদ্ধতির নামগুলি অর্থপূর্ণ এবং ম্যাজিক সংখ্যাগুলি প্রতীকী স্থির দ্বারা প্রতিস্থাপন করা হয়েছিল আপনার কোডটি বুঝতে সমস্যা হতে পারে। কিভাবে এটি মোকাবেলা? "এটি তৈরি করুন" এর "1 ঘন্টা পরে" এটি সুন্দর করুন "এক মাস পরে বা এক বছর পরে" এটি সুন্দর করুন "এর চেয়ে অনেক সস্তা। আমি সম্মত হলাম যে "কোডটি এটিকে সুন্দর করুন" যখন পরের কোড পরিবর্তনটি প্রয়োজনীয় হবে যদি "এটি এটিকে সুন্দর করুন" প্রথম স্থানে না করা হয়।
k3b

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

10

যদি এটি কাজ করে, এবং এটি পরীক্ষা করা হয়েছে, তবে কেন এটি ঠিক করুন?

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

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

আপনি যখন টাস্কটিকে "সম্পন্ন" বলছেন তখন এটি আপনার পক্ষ থেকে কমবেশি রায় দেওয়া কল; আপনার কোডটি যে অবস্থায় রয়েছে তার সাথে আপনি যদি স্বাচ্ছন্দ্য বোধ না করেন তবে টাস্কটি সম্পূর্ণ হিসাবে চিহ্নিত করবেন না।


2
আমি এটিকে এই প্রসঙ্গে আনার জন্য, "প্রযুক্তিগত debtণ" ধারণাটির অনুরাগী হয়েছি।
প্যাট্রিক হিউজেস

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

5

এই "আমি আরও ভাল করতে পারি" সময় কি টাইমলাইনের মধ্যে আসলেই ফিট করা উচিত?

হ্যাঁ.

আপনি পরবর্তী প্রকাশের কোডিং শুরু করার ঠিক আগে ।

"স্বজ্ঞাত" উপর ভিত্তি করে রিফ্যাক্টর করবেন না।

পরবর্তী স্প্রিন্টের আসল গল্পের উপর ভিত্তি করে রিফ্যাক্টর।


2

আপনি রিফ্যাক্টরিংয়ের সাথে সন্তুষ্ট না হওয়া পর্যন্ত কোডটিকে 100% সম্পূর্ণ হিসাবে চিহ্নিত করবেন না। কোডটি রিফ্যাক্টর করার জন্য আপনাকে কেবল ক্রমাগত মূল্য / উপকারের মূল্যায়ন করতে হবে কারণ আপনি যদি যথেষ্ট পরিমাণে অধ্যয়ন করেন তবে আপনি সর্বদা কোডটিকে আরও উন্নত করার উপায় দেখতে পাবেন।

আমি টিডিডির লাল সবুজ রঙের চুল্লি পদ্ধতি ব্যবহার করি। সুতরাং আমার রিফ্যাক্টরিংটি আমার বিকাশে তৈরি। অন্তর্নিহিত মডেল বা এর অনুরূপ কিছু পরিবর্তন করার মতো বড় রিফ্যাক্টরিংগুলির জন্য আমি প্রথমে সময় ব্যয় করতে ম্যানেজমেন্টকে কিনতে পারি।


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

2

"পোস্ট লঞ্চ রিফ্যাক্টরিং" -এ রিগ্রেশন টেস্টিং এবং QA সময়টির একটি লুকানো ব্যয় রয়েছে যা আপনি উপেক্ষা করছেন, এবং এটি রিপোর্ট করা বাগ এবং নতুন / অনুরোধ করা বৈশিষ্ট্য এবং পরিবর্তনগুলিতে কাজ না করার সুযোগ ব্যয় বহন করে। TANSTAAFL

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

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


0

যদি আমি কাজ করার জন্য কিছু অংশের জন্য বিকল্প পদ্ধতির চেষ্টা করছি তবে এর অর্থ এই নয় যে আমি সেরা সমাধানটি পেয়েছি,

... যে ক্ষেত্রে আপনি এখনও 100% সম্পন্ন করেননি ...

অথবা এটি অন্যান্য বিকাশকারীদের সাথে পর্যালোচনা করার পরে কিছু পুনর্নির্মাণের প্রয়োজন হবে না।

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

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

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

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

সংক্ষেপে, কারণ কোডটি অনেক স্তরে ভেঙে যেতে পারে।

এটি এখনই এটি কার্যকরভাবে কাজ করে। এটি দীর্ঘকালীন পরিষ্কার, প্রসারযোগ্য এবং রক্ষণাবেক্ষণযোগ্য কিনা তা সম্পূর্ণ আলাদা জিনিস different

আরও বিস্তারিত উত্তরের জন্য এই থ্রেডটি দেখুন


0

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

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

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

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


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

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