আমার কোডের একটি বড় অংশের একটি প্রধান ডিজাইনের ত্রুটি রয়েছে। এটি শেষ করুন বা এখনই ঠিক করুন? [বন্ধ]


186

আমি আমার মতো দক্ষতার স্তরের সাথে আমার এক বন্ধুর সাথে সি # প্রকল্পে কাজ করছি এমন একটি উচ্চ বিদ্যালয়ের শিক্ষার্থী। এখন অবধি, আমরা 100 টি কমিটের ব্যবধানে প্রায় 3,000 লাইনের কোড এবং 250 কোড টেস্ট কোড লিখেছি lines বিদ্যালয়ের কারণে, আমি কয়েক মাসের জন্য প্রকল্পটি বন্ধ রেখেছিলাম এবং সম্প্রতি আমি আবার এটি আবার নিতে সক্ষম হয়েছি।

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

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

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

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


13
গুরুতরভাবে: তার পণ্যগুলিতে একটি বড় ডিজাইনের ত্রুটি থাকা কখনও ল্যারি এলিসনকে থামেনি। কেন আপনাকে বিরক্ত করবেন?
পিটার জেরকেনস

54
কাজ নষ্ট হয় নি। এটি আপনাকে আরও উন্নত প্রোগ্রামার করে তুলেছে।
সংপাথ্রিস

10
এই মুহূর্তে এটি আপনার জন্য প্রযোজ্য নাও হতে পারে তবে ভবিষ্যতে আপনি যদি এমন কিছু লিখেন যা আপনি পেশাদারভাবে বজায় রাখতে চান তবে কখনও কখনও বৃহত্তর বিশাল পুনর্লিখন করবেন না
gcampbell

8
@ জোবলো "" 100% সফ্টওয়্যার দ্রুত সম্পূর্ণ অকেজো হয়ে যায় এবং স্ক্র্যাচ থেকে আবার করতে হবে "" এই বিবৃতিটি যৌক্তিক অর্থে বোঝায় না। আপনি আমাকে যে সফ্টওয়্যারটি আমি প্রতিদিন ব্যবহার করি তা বলছেন ... সম্পূর্ণ অকেজো এবং স্ক্র্যাচ থেকে আবার কাজ করতে হবে?
oldmud0

10
"আচ্ছা - হ্যাঁ, অবশ্যই। ওএস 9 বা উইন্ডোজ 3 কেউ ব্যবহার করছে না। সফ্টওয়্যারটি উল্লেখযোগ্যভাবে অস্থায়ী।" আপনি নিজের মত আত্মবিশ্বাস সত্ত্বেও যথারীতি ভুল! উইন্ডোজ এনটি কার্নেল, এনটি ৩.১ এ প্রবর্তিত, এমনকি উইন্ডোজ ১০ এর মূল কেন্দ্রবিন্দুতে রয়েছে উইন্ডোজ প্রায় ২০ বছরে "সম্পূর্ণ পুনর্লিখন" করেনি।
অরবিট

উত্তর:


273

আমি যদি আপনার জুতোতে থাকতাম তবে আমি সম্ভবত এটি চেষ্টা করতাম:

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

  • তারপরে এবং তারপরেই স্ক্র্যাচ থেকে পুনর্লিখন সম্পর্কে চিন্তা করুন (এটি "সংস্করণ 2.0" কল করুন)। হতে পারে আপনি ভি 1.0 থেকে কিছু কোড পুনরায় ব্যবহার করতে পারেন। সম্ভবত পরিস্থিতিটি নিয়ে আবার ঘুমানোর পরে আপনি সিদ্ধান্তে এসেছেন আপনি ভি 1.0 রিফেক্টর করতে পারেন এবং এর বেশিরভাগটি সংরক্ষণ করতে পারেন। আপনার হাতে "ধারণার ভি 1.0 এর প্রমাণ" না পাওয়ার আগে এই সিদ্ধান্ত নেবেন না।

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

অসম্পূর্ণ অবস্থায় প্রকল্পগুলিকে কীভাবে পিছনে ফেলে রাখা যায় তা শেখার সুযোগের পরিবর্তে কীভাবে মধ্যবর্তী লক্ষ্য অর্জন করতে হয় তা শেখার সুযোগ হিসাবে এটিকে নেওয়া ভাল।


71
রিফ্যাক্টরিং প্রক্রিয়াটি সম্পর্কে শেখার সুযোগ হিসাবে কেউ একটি সংস্করণ 1.0 এও দেখতে পারে look
jpmc26

20
এই. আমি প্রায় 1 তম ওয়ার্কিং প্রোটোটাইপে অগ্রসর হওয়ায় আমি প্রায়শই একাধিক ডিজাইনের ত্রুটি / নকশার সীমাবদ্ধতা / প্রয়োজনীয়তা আপডেটগুলি পাই find একটি আসল কার্যকরী রাষ্ট্রের কাছে পৌঁছানো গুরুত্বপূর্ণ।
ইউজিন রায়বতসেভ

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

9
একটি প্রকল্প সমাপ্তি আপনাকে এমন সম্ভাব্য সমস্যাগুলি দেখার সুযোগ দেবে যা আপনি এখনও মুখোমুখি হন নি এবং বাস্তবে আপনাকে দেখাতে পারে যে কিছু বিষয় যা আপনার মনে হয় সমস্যাগুলি ততটুকু বড় নয় যা আপনার মনে হয়। আপনি ১.০ শেষ করার সময় ভাল নোট রাখুন এবং ২.০ এর জন্য একটি পরিকল্পনা নকশা শুরু করুন
ক্যাফিনএডিকশন

9
শেষ বাক্যটি আশ্চর্যজনক:Better take this as an opportunity to learn how to achieve intermediate goals, instead of an opportunity to learn how to leave projects in an unfinished state behind.
ব্র্যান্ডন

119

সমাপ্ত আইটি প্রকল্পগুলি, এমনকি ত্রুটিযুক্তগুলিও অসম্পূর্ণ প্রকল্পগুলির চেয়ে অনেক ভাল।

অসমাপ্তরা আপনাকে অনেক কিছু শেখাতে পারে তবে শেষের মতো নয়।

আপনি এটি এখন দেখতে পাবেন না, তবে আপনি এমনকি ত্রুটিযুক্ত কোডের সাথে প্রচুর পরিমাণে মান কাজ করতে পারেন।

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

একটি কর্মসংস্থান দৃষ্টিকোণ থেকে, বেশিরভাগ ক্ষেত্রে, আপনি একটি সমাপ্ত প্রকল্পের জন্য আরও কুডো পাবেন।


11
সত্যি, অ-তুচ্ছ প্রকল্পগুলিতে সর্বদা কয়েকটি বাগ থাকে। তাদের তালিকাভুক্ত করুন এবং পরবর্তী সংস্করণে এগুলি ঠিক করুন। রিলিজ নোটগুলি এটাই।
রেডসোনজা

56

আমি আনন্দের সাথে প্রকল্পটি শুরু করব।

আপনি একজন শিক্ষার্থী এবং আপনি এখনও শিখছেন। আপনি যে প্রশ্নটির সাথে লিঙ্ক করেছেন তার থেকে এটি আপনাকে খুব আলাদা অবস্থানে ফেলেছে।

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

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

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

  • একটি ভাঙা কোডবেজে কাজ করা আপনার মনোবলের উপরে পুনর্লিখনের চেয়ে অনেক বড় ড্রেন হবে।

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

অবশেষে, কখনও কখনও বড় পদক্ষেপগুলি এগিয়ে নিতে পিছনে পদক্ষেপ গ্রহণ করার প্রজ্ঞা সম্পর্কে এখানে একটি মতামত।


46
স্ক্র্যাচ থেকে পুনর্লিখন খুব কমই ভুল থেকে শিখছে এবং প্রায়শই নতুন করে
তোলে

28
আমার মতে, কোনও প্রকল্প শেষ করা নিখুঁত প্রকল্প হওয়ার পরে আরও গুরুত্বপূর্ণ। চিরস্থায়ী "এটি যথেষ্ট ভাল নয়" লুপের হুমকি আসল।
পিটার বি

9
কখনও কখনও আপনি যখন নিজেকে একটি গর্ত খনন করেন তখন আপনাকে খনন বন্ধ করতে হবে; উপস্থাপিত পাঠটি শিখুন এবং দ্বিতীয় সংস্করণটিকে আরও সহজ করুন । লোকেরা যে দ্বিতীয় সিস্টেমের ভুল করে তা হ'ল এটিকে ফ্যানসিয়ার এবং আরও জটিল।
ডেল জনসন

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

6
@Whatisname তারা একই ভুল করবে না। যেমন আপনি উপরে বলেছেন, তারা নতুন তৈরি করবে, যা তাদের নতুন জিনিস শেখাবে।
কেভিন

34

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

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

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

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


25

সফটওয়্যার বিকাশে আমি "এটি তৈরি করুন, এটি ঠিক করুন, দ্রুত করুন" আদর্শটি অনুসরণ করি ।

  1. এটিকে কাজ করুন : মূল কার্যকারিতা লিখুন, যাতে প্রকল্পটি ব্যবহারযোগ্য able আপনার কাজটি যা করতে হবে তা সব কিছু করার জন্য করুন, এমনকি এটি কুৎসিত কোডের অর্থ হলেও।
  2. এটিকে সঠিক করুন : বাগগুলি ঠিক করুন এবং কোডটি রিফ্যাক্টর করুন যাতে এটি পড়া, বুঝতে এবং বজায় রাখা সহজ হয়।
  3. এটিকে দ্রুত করুন : গতি, সংস্থান ব্যবহার এবং রক্ষণাবেক্ষণের মধ্যে ভাল ভারসাম্য অর্জনের লক্ষ্যে প্রোগ্রামটি অনুকূলিত করুন।

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

মনে রাখবেন: অকালীন অপটিমাইজেশন হ'ল সমস্ত অশুভের মূল ( ভাল আলোচনার জন্য এই দুর্দান্ত প্রোগ্রামারস.এসই প্রশ্নটি দেখুন )। আপনার কোড কীভাবে আরও উন্নত করা যায় সে সম্পর্কে আপনি যদি খুব বেশি সময় ব্যয় করেন তবে বিশ্লেষণ পক্ষাঘাতে আটকে যান । এটি প্রকল্পটিকে হত্যা করে। আপনি প্রকল্পটি অপ্টিমাইজ করার চেষ্টা শুরু করার আগে কেবল প্রকল্পটি সম্পন্ন করা ভাল।

একটি দুর্দান্ত প্রেরণাদায়ী স্পিকারের উদ্ধৃতি দিতে: কেবল এটি করুন

সর্বদা হিসাবে, এখানে একটি প্রাসঙ্গিক xkcd আছে:

এক্সকেসিডি অপ্টিমাইজেশন


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

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

আমি মনে করি না এটি প্রযোজ্য। ওপি স্পষ্টতই মৌলিক নকশা সমস্যার কথা বলছে । এগুলি পরে আপনি নিরাপদে "প্যাচ" করতে পারবেন না।
অরবিট

1
0.5, 1.5, 2.5, এবং 3.5 পদক্ষেপগুলি ভুলে যাবেন না: এটিকে পঠনযোগ্য করে তুলুন।
candied_orange

23

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

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

আপনার পরিস্থিতি সম্পূর্ণ বিপরীত। আপনার কোনও ব্যবহারকারীর সাথে একটি ছোট অ্যাপ্লিকেশন রয়েছে এবং কেবলমাত্র প্রয়োগগুলি আপনি প্রয়োগ করতে বেছে নিয়েছেন। সুতরাং এগিয়ে যান এবং এটি আবার লিখুন।


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

2
কোডের 3k লাইনে কমিটগুলি পরীক্ষা করতে আরও বেশি সময় লাগতে পারে কেবল পুরো জিনিসটি আবার লিখতে।
ম্যাথু হোয়াইট

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

1
@ জো ব্লো: গিট রেপো মোছার কোনও কারণ নেই। শুধু একটি নতুন শাখা তৈরি করুন। আপনি কখনই বলতে পারবেন না যে আপনি কখন পুরানো জিনিসগুলি উল্লেখ করতে চান।
কেভিন cline

19

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

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

সঠিক নকশাটি আপনার মাথায় পরিপক্ক হয়েছে এবং কোডে এটি লিখতে বেশি সময় নেওয়া উচিত নয়।


12

আমি পুনর্লিখনটি একটি খারাপ ধারণা, এমন পরামর্শের সাথে সম্মানের সাথে একমত হব।

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

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


3
"শিল্প গৃহীত" এর অর্থ কী? সংখ্যাটির উত্স কী?
খ্রিস্টান


1
টিডিডি যাওয়ার উপায়!
2rs2ts

10

আপনি এই বাক্যে আমাকে হারিয়েছেন:

সমস্যাটি হ'ল আমি আমার প্রোগ্রামের মূল কার্যকারিতাটিও শেষ করতে পারি নি, সুতরাং আমি সত্যিকার অর্থে রিফ্যাক্টর করতে পারি না এবং আমার কোডটির নকশাটি ত্রুটিযুক্ত বলে আমি পুরোপুরি সচেতন হতে নিরুৎসাহিত বোধ করি।

আমি নীতিতে বিশ্বাস করি ( সিস্টেমেটিক্সে বর্ণিত ) যা

  • একটি জটিল সিস্টেম যা কাজ করে তা কার্যকরভাবে কাজ করে এমন একটি সাধারণ সিস্টেম থেকে বিকশিত হয়।
  • স্ক্র্যাচ থেকে ডিজাইন করা একটি জটিল সিস্টেম কখনই কাজ করে না এবং এটিকে কাজ করতে প্যাচ করা যায় না। একটি কাজ সহজ সিস্টেম দিয়ে আপনি শুরু করতে হবে।

সুতরাং, একটি জটিল পদ্ধতি লেখার অন্তর্ভুক্ত

  • একটি সহজ পদ্ধতি রচনা
  • এটি কার্যকর হয় তা নিশ্চিত করা

... অর্থাৎ নিম্নলিখিত পদক্ষেপগুলি:

  1. কোড একটি বিট লিখুন
  2. এটি কাজ করে তা নিশ্চিত করার জন্য এটি পরীক্ষা করুন
  3. আরও কিছুটা কোড লিখুন
  4. আবার পরীক্ষা
  5. প্রভৃতি

নোট করুন যে পদক্ষেপ 3 জড়িত হতে পারে:

  1. আরও কিছুটা কোড লিখুন
    1. নতুন সংযোজনের জন্য এটি প্রস্তুত করতে রিফ্যাক্টর বিদ্যমান কোড
    2. এটি এখনও কাজ করে তা নিশ্চিত করার জন্য রিফ্যাক্টরিংটি পরীক্ষা করুন
    3. নতুন কার্যকারিতা যুক্ত করুন

এছাড়াও, পদক্ষেপ 2 "এটি কাজ করে তা নিশ্চিত করার জন্য এটি পরীক্ষা করুন" এটি না লিখলে কিছু পুনর্লিখন জড়িত থাকতে পারে।

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

  • উত্স কোড সহজ
  • এবং কোনও নতুন বাগ প্রবর্তিত হয়নি
  • (এবং কিছু পুরানো বাগ মুছে ফেলা হয়েছে)

ঘটনাক্রমে, "এটি পরীক্ষা করে এটি নিশ্চিত করে তোলে" এটি "ইউনিট টেস্টগুলি" বোঝায় না - যখন দলের কাঠামো সহজ হয়, আপনি (সহজ) সিস্টেম পরীক্ষা (পরিবর্তে ইউনিট পরীক্ষা) ব্যবহার করে একটি (সাধারণ) সিস্টেম পরীক্ষা করতে পারেন ।


7

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

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

তিনি হতাশ হয়েছিলেন, তবে 3 দিন পরে তিনি ক্লিনার কোড এবং কম বাগ এবং কোডের কম লাইনের সাথে প্রোগ্রামটি শেষ করেছেন।

প্রকল্পের জন্য উপলভ্য সময়ে কোন বিকল্পটি সবচেয়ে ভাল তা সম্পর্কে একটি নির্ভুল অনুমান করার চেষ্টা করুন।

3 টি পছন্দ

  • এটি মুছুন (পুরোপুরি, কোনও পিছনে ফিরে তাকাবেন না)
  • পুরানো ডিজাইনে কাজ চালিয়ে যান
  • আপনি যাওয়ার সময় রিফ্যাক্টর কোড।

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


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

6

মনে হচ্ছে আপনার সময়কালে আপনার দক্ষতা যথেষ্ট বেড়েছে have সম্ভবত এই প্রকল্পে কাজ করা এতে অবদান রেখেছিল। এটিকে আবার শিখার অভিজ্ঞতা হিসাবে নকশা করা ফলপ্রসূ হবে।

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

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


6

Refactor। Refactor। Refactor! REFACTOR !!!!

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

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

আপনি যখন অ্যাপ্লিকেশনটির একটি বড় অংশে পৌঁছান যার জন্য রিফ্যাক্টর দরকার হয় তখন আপনি এটি গুরুতরভাবে করছেন। ছোট অংশে রিফ্যাক্টরিংটি ভাঙ্গুন। সাত ঘন্টা লেখার কোড এবং এক ঘন্টা রিফ্যাক্টরিং ব্যয় করার চেষ্টা করুন।

আপনি যখন প্রকল্পটি শেষ করেন এবং আপনি বৈশিষ্ট্য হিমায়িত হিট করেন, তারপরে আপনি কিছুটা ব্যয় করতে পারেন রিফ্যাক্টরিংয়ে। আপাতত, গেমটি শেষ করুন, তবে কিছু রিফ্যাক্টর চেষ্টা করুন। এটিই আপনি করতে পারেন সেরা।

রিফ্যাক্টরের জন্য সর্বদা কিছু থাকবে।


4

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

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

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

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


3

আপনি নিজেকে নিয়োগকারীদের জুতা রাখতে হবে।

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

একটি ভাল সংস্করণ প্রক্রিয়া, শাখা এবং ট্যাগ দিয়ে যা কিছু করুন।

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

আপনি অবশ্যই এটি আবার লিখতে পারেন, তবে এটির পরে অন্য একটি প্রকল্প করুন।


কোন নিয়োগকর্তা? ওপি উচ্চ বিদ্যালয়ে রয়েছে, একটি পোষা প্রাণী প্রকল্প করছে।
অরবিট

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

1
"পেশাগতভাবে অভিনয় করা" আপনার রিফ্যাক্টর থাকুক বা না থাকুক এর সাথে একেবারে করার কিছু নেই।
অরবিট

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

এবং এটি সেই সময়ের মধ্যে একটি নয়।
অরবিট

3

শুধু আমার অতীতের কিছু অভিজ্ঞতা মিশ্রণে যুক্ত করতে। আমি এখন এক বছর ধরে একটি পার্শ্ব প্রকল্পে কাজ করে যাচ্ছি, যখনই আমি কয়েক মিনিট অতিরিক্ত রাখি। এই প্রকল্পটি একটি স্ট্যাটিক শ্রেণিতে একটি সাধারণ টেস্টবেড থেকে অবজেক্ট ভিত্তিক স্লিম রেখাযুক্ত নকশায় চলে গেছে এটি এখন।

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

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

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


3

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

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


2

একটিও না? উভয়?

এরপরে চালিয়ে যান, বিদ্যমান নকশাটি সংশোধন করতে এবং কিছু সময় নতুন কার্যকারিতা যুক্ত করতে কিছুটা সময় ব্যয় করুন।

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

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

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


2

যদি আপনার কোডটি মডিউল হয় তবে আপনার কোডটি বাকীভাবে লিখিত উপাদানগুলির চারপাশে শেষ করতে সক্ষম হওয়া উচিত তবে বাকী কোডটি প্রভাবিত না করে খারাপভাবে লেখা উপাদানগুলি পুনরায় লিখুন।

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


2

আপনার নিজের প্রথম প্রশ্নটি জিজ্ঞাসা করা উচিত "ত্রুটিটি কতটা খারাপ?"

আপনি ঠিক কী ভুল করেছেন?

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


প্রোগ্রামাররা তাদের অ্যাপ্লিকেশনগুলি উন্নত করতে পছন্দ করে এবং তাদের "এটি সর্বোত্তম হতে পারে" হতে চেয়েছিল, তবে এটি সঠিক পদ্ধতির নয়।

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

সুতরাং আপনার ক্ষেত্রে, এটি এখান থেকে বেরিয়ে আসুন, কিছু প্রতিক্রিয়া পান এবং তারপরে আপনি সমস্ত পরিবর্তনগুলি সহ 2.0 সংস্করণ গঠন করতে পারেন এবং আপনার নিজের ত্রুটিগুলি ঠিক করতে পারেন।


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


1

এটি আপনার কোডটি কীভাবে গণ্ডগোল করে তা নির্ভর করে।

  • যদি আপনি সত্যিকারের n00b ত্রুটি করে থাকেন যা আপনার কোডটিকে অতিরিক্ত জটিল বা ভার্ভোস করে তোলে, তবে আমি সেই অংশগুলি পুনরায় লেখার পরামর্শ দেব।

  • যদি আপনি ভাবেন যে আপনার যে কোনও গুরুতর ত্রুটি রয়েছে যা আপনাকে যেভাবেই ঠিক করতে হবে, তবে কিছু ইউনিট পরীক্ষা লিখুন যা আপনি বাগটি ঠিক করেছেন কিনা তা পরীক্ষা করতে পারে (... যেহেতু আপনি এখনও প্রোগ্রামটি চালু করতে পারবেন না)। এটির আগে বাগগুলি ঠিক করা আরও ভাল এবং আপনি কোডটি কী করে তা এখনও মনে রাখার পরে বাগগুলি ঠিক করা আরও ভাল।

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

অন্যথায়, এটি কাজ করুন এবং পরের প্রকল্পে আপনার দক্ষতা অর্জন করুন।


1

যেমনটি অন্যরা পরামর্শ দিয়েছেন, যেহেতু এটি একটি ব্যক্তিগত প্রকল্প, (এখনও) কোনও পেশাদার প্রকল্প নয়, আমি পুনর্লিখনটি গুরুত্ব সহকারে বিবেচনা করব।

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

আপনি বিশ্বের সমস্ত পরামর্শ চাইতে পারেন, তবে অনুমানের সাথে অনুমানের পরীক্ষা করার মতো কিছুই নেই।

কোনও পুনর্লিখনকে আপনার পরীক্ষা হিসাবে বেছে নেওয়া বিবেচনা করার কয়েকটি কারণ:

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

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

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