আপনি কীভাবে কোনও প্রোগ্রামকে ইন-ডেভলপমেন্ট থেকে মুক্তির জন্য স্থানান্তর করেন?


67

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

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

স্টাফগুলি একবার পরীক্ষা ও অনুমোদিত হয়ে গেলে তা পুনরায় লেখার কোনও অর্থ হয় না। নিয়মিত ভিত্তিতে আমি সেখানে একটি কার্যকরী 'সমাপ্ত' প্রোটোটাইপ নিয়ে দাঁড়িয়ে আছি এবং পরীক্ষার সময় আমি একটি বাগ পেয়েছি এবং আমি দেখতে পাচ্ছি যে এটি স্মার্ট-কোডিংয়ের ফলাফল যা পুরো উন্নয়ন প্রক্রিয়ার ফলাফল process আমি পরীক্ষার মাঝে আছি এবং বাগফিক্সটি আবার লিখতে হবে ... এটা গোলমাল!

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

তাহলে আমি কীভাবে আমার কার্যকারী প্রোটোটাইপটি স্থিতিশীল কোড বেস সহ একটি প্রকাশ সংস্করণে স্থানান্তর করব? আমার একবার করা উন্নয়ন শেষ হতে পারে না এবং আসলে এটিকে ক্লিন-আপ পর্ব হিসাবে দেখা উচিত ... আমি জানি না, আমার এখানে সহায়তা দরকার।

সম্পাদনা

আমি কয়েকটি বিষয় পরিষ্কার করতে চাই।

  • কোডটি পরিষ্কার এবং পঠনযোগ্য, ঠিক আগে এবং পরে নয় এটি করার পক্ষে আমি 100%। তবে আমাকে কাজগুলিও করতে হবে এবং কোডের সৌন্দর্য সব পরিষ্কার এবং চকচকে করতে পারে না। আমাকে একটি আপস খুঁজতে হবে।

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

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


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

11
@ নিককিডি যদি আপনাকে যথাযথ প্রয়োগের জন্য সময় না দেওয়া হয় তবে আপনার ম্যানেজারের সাথে সফ্টওয়্যারটির গুণমানের প্রভাব সম্পর্কে আপনার কথোপকথন করা উচিত। বুঝুন কি এখানে সবাই তোমাকে বলছি হয়: না সময় বিনিয়োগ সামনে পরে দক্ষতার সঙ্গে কাজ করতে আপনার ক্ষমতা ক্ষতি করে। আরেকটি বিষয় আপনি তাদের সঙ্গে আসা করতে চান: আপনি কোম্পানির ছেড়ে (বা "একটি বাসের উপর চালানো পেতে") ছিল, এটি হবে অত্যন্ত ব্যয়বহুল নতুন ডেভেলপারদের কোড সম্পর্কে ওয়াকিবহাল হতে তারা জন্য। তারা এখন যে অর্থ সঞ্চয় করছে বলে মনে করে তা পরে তাদের ব্যয় করতে হবে।
jpmc26

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

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

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

উত্তর:


98

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

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

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

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

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

আমি পরীক্ষার মাঝে আছি এবং বাগ ফিক্সটি একটি পুনর্লিখন হবে

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

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

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


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

44
@ নিককিডি: এটি সময়সীমাটি ফুলে যায় না। সময়সীমাটি ইতিমধ্যে ফুলে গেছে; আপনি যখন সফ্টওয়্যারটি লিখেছিলেন এবং প্রযুক্তিগত debtণে জমেছিলেন যা আপনি বাজেট করেননি কেবল আপনি ব্লাটের জন্য অ্যাকাউন্ট করেন নি ।
এরিক লিপার্ট

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

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

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

22

আপনার দুটি পৃথক সমস্যা রয়েছে, উভয়ই একই লক্ষণ (স্লোপি কোড) সহ:

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

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

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


21

এটি একটি সাধারণ সমস্যা - বিশেষত কোনও সফ্টওয়্যার ট্রায়াল বেলুনটি তৈরি করার সময় বিশেষত তৈরি করার সময় ।

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

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

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

শুরু থেকে প্রোডাকশন কোডটি কাটা টানা টানা মনে হতে পারে তবে আপনার পরিবেশের উপর নির্ভর করে এমন অনেক সরঞ্জাম রয়েছে যা ঘোস্টডক এবং স্টাইলোকপ হিসাবে বিকাশ করতে পারে ।

এটি শুরু থেকেই সঠিক বিকাশের মানসিকতা অর্জনের পক্ষে মূল্যবান। আপনি অবাক হবেন যে কতগুলি ব্যাক-অফ-এ-ফাগ-প্যাকেট সিস্টেম যা কেবল স্টপ-গ্যাপ সমাধান হিসাবে বিবেচিত হয়েছিল সেগুলি কোণার অ্যাপ্লিকেশন হয়ে যায় become


আপনি বোঝাতে চেয়েছেন যে প্রতিটি স্টপ ফাঁক সমাধান কখনও লেখা হয়েছে, তাই না?
রাবারডাক

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

11

একটানা

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

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


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

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

"আমি কেন তা আমার কাছে অস্বীকার করব এবং কেবল ভবিষ্যতের প্রোগ্রামারের জন্যই তা করব?" প্রকাশিত বাক্য! এবং কি অনুমান? আপনি কখনও কখনও (এবং কখনও কখনও, প্রায়শই) ভবিষ্যতের প্রোগ্রামার হন।
রডারবব

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

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

4

আপনি "কোড এবং" এটি কী পণ্যটির দিকে চলে যায় "কোডটি কীভাবে কাজ করে তা দেখার জন্য আমি এটি চেষ্টা করছি You এটি করার বিভিন্ন উপায় রয়েছে।

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

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

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

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


1

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

সুতরাং উত্তর, হয়

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

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


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

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

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

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

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

0

তুমি লেখ:

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

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

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

আমি মনে করি আপনি অনেকটা "ক্লিনআপ" স্থগিত করছেন।

আমার থাম্বের নিয়মটি হ'ল:

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

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

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