আপনি যে কুৎসিত কোডটি লিখেছেন তা কীভাবে মোকাবেলা করবেন? [বন্ধ]

Question

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

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

Comments

এটি একটি দুর্দান্ত প্রশ্ন।

— ওয়াল্টার

আমি মনে করি এটি 80/20 নিয়ম প্রয়োগ করার জন্য ভাল জায়গা ।

— সি সি

umm .. প্রথমে কুৎসিত কোড লিখবেন না ?!

— রূপেশ শেনয়

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

— এমপেন

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

— এমপেন

Answer 1

অন্য একটি চাকরি পান এবং অন্যান্য লোকেদের এটির মোকাবেলা করতে দিন। Muahahahhahahaa।

.....

ঠাট্টা করছি. :)

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

অন্য একটি (সম্পর্কিত) টিপ: সর্বদা আপাতদৃষ্টিতে ক্ষুদ্রতর অনুমান করুন, কোনও শালীন আকারের ব্লকের কোনও মস্তিষ্কের কাজ নয়। উদাহরণস্বরূপ বলুন - একটি আইটেম যা আপনি প্রায় নিশ্চিত এটি একটি সাধারণ এক লাইন 30 সেকেন্ডের পরিবর্তন হয়ে যাবে - এটিকে 1 ঘন্টা দিন (বা সম্ভবত আপনার টাইমশিট বা সিআর সিস্টেমে সবচেয়ে কম সময় ব্লক যা হ'ল 15 মিনিট / 0.25 ঘন্টা) । এবং সামান্য বড় তবে তুলনামূলকভাবে তুচ্ছ আইটেমগুলির জন্য অর্ধ-দিন বা 1 দিনের ব্লক দিন।

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

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

Comments

দুষ্ট হওয়ার জন্য +1। ;)for(printf("MUHU"); 1; printf("HA"));

— মতিন উলহাক

@ মন্টু: যা করেছে তা বুঝতে পেরে আমাকে এক সেকেন্ড সময় নিল ... এটি দেখেনি for। বুদ্ধিমান;)

— এমপেন

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

— অ্যারোনআউট

যে বিষয়টি প্রায় আধা ঘণ্টারও কম লাগে না তা খুব ভালভাবে তৈরি। এমনকি কোডে একক পরিবর্তন করতে 5 মিনিট সময় লাগলে সেখানে ওভারহেডের একটি ভেলা পড়ে যায়।

— মার্ফ

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

— জন হপকিন্স

Answer 2

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

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

Comments

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

— ববি টেবিল

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

— টিন ম্যান

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

— ফ্র্যাঙ্ক শেয়ার

এই অনুমান প্যাডিং হয়? আমার কাছে কোডের মান বজায় রেখে একটি নতুন বৈশিষ্ট্য বাস্তবায়নের সময় মনে হচ্ছে।

— ডেভিড থর্নলি

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

— ব্র্যান্ডন ডুরেট

Answer 3

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

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

সঠিকভাবে নতুন ডিজাইন / রিফ্যাক্টরিং আপনার গ্রাহকদের বিনিয়োগ রক্ষা করতে এবং জিনিসকে টেকসই রাখতে পারে। আপনার এটি তৈরি করতে হবে। পরিবর্তনের জন্য ট্র্যাভেল লাইট tim

Answer 4

অতিরিক্ত-অনুমান সম্পর্কে সমস্ত মন্তব্য সহ আমি মনে করি যে বিন্যাসের একটি পরিমিত পরিমাণ (ভাল সুযোগ) মিস হচ্ছে।

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

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

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

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

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

সবশেষে - মনে রাখবেন, এটি যদি না ভাঙে তবে এটি ঠিক করবেন না। পরিসংখ্যানের জন্য নিজের কোডটি নিখুঁতভাবে চালিয়ে যাওয়া সন্তুষ্টিজনক হতে পারে তবে এটির ত্রুটিগুলি প্রবর্তনেরও একটি সুযোগ রয়েছে যাতে আপনার যদি এটি পরিবর্তন করার প্রয়োজন না হয় এবং এটি তৈরি না করে তবে এটি বেদনাদায়ক হতে পারে কিছু গণ্ডগোল ছেড়ে যাওয়া ভাল may একা - সংশোধন বা প্রতিস্থাপনের সুযোগটি শেষ পর্যন্ত চারদিকে ঘুরবে!

Answer 5

1) সঠিক পরিবর্তন নিয়ন্ত্রণ আপনার বন্ধু

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

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

2) রিফ্যাক্টরিংয়ের এমনটি করা উচিত যা ক্লায়েন্টকে আসল দীর্ঘমেয়াদী সুবিধা দেয়

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

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

Answer 6

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

Comments

+1 টি; এটি কাজ করতে পারে, তবে এটি খুব জটিল না হয়ে আপনার ক্লায়েন্টকে বিচ্ছিন্ন করার বিপদও চালায়। আপনি কিছু করতে পারেন কিনা তা প্রকল্পের ধরণের (আকার) এবং ক্লায়েন্টের প্রত্যাশার উপর নির্ভর করে।

— কেন হেন্ডারসন

Answer 7

আমি বর্তমানে একটি কোড বেসে নিম্নলিখিত মন্তব্য করছি যা আমি বর্তমানে কাজ করছি:

/*
 * Every time I see this function, I want to take a shower.
 */

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

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

Answer 8

আমার পছন্দটি হ'ল প্রথমে এই পরিস্থিতি এড়ানো।

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

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

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

Comments

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

— এমপেন

Answer 9

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

Comments

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

— এমপেন

Answer 10

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

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

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

Answer 11

এটিকে আপনার প্রক্রিয়ার অংশ করুন, আমি এটিকে "চরম রিফ্যাক্টরিং" বলি এবং এটি বড় হতে চলেছে! ;) কেবল দ্রুত স্টাফ করুন এবং যখন পর্যাপ্ত নতুন বৈশিষ্ট্য যুক্ত করা হয়েছে যে দাগযুক্ত টিস্যু রয়েছে, তখন এটি রিফ্যাক্টর করুন। ক্রমাগত নিজেকে জিজ্ঞাসা করুন "এখন আমি যদি স্ক্র্যাচ থেকে শুরু করেছিলাম তবে আমি কীভাবে এটি করতাম"

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

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

গ্রাহকরা যদি জেনে থাকেন যে আপনি পুনরায় কাজকর্মগুলি "সময় নষ্ট করছেন" তবে তারা এটি জিজ্ঞাসা / না বলা এবং সত্যিকারের তাড়াতাড়ি তাড়িত হতে সহায়তা করে if

এইভাবে বিকশিত কোডটি শেষ পর্যন্ত আপনার প্রচুর সময় সাশ্রয় করবে এবং নতুন বৈশিষ্ট্য যুক্ত করা ক্রমশ সহজ করবে।

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

Answer 12

একটি উচ্চ ক্ষমতার উপর নির্ভর করুন

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

একটি সাধারণ প্রকল্পের প্রবাহে, গুরুতর বিকাশ হওয়ার আগে সাধারণ স্পেসিফিকেশন হিমায়িত করা উচিত।

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

কোনও ব্যক্তির কাছে স্পেসিফিকেশনটি পুরোপুরি নিখুঁতভাবে জমাটবদ্ধ এবং শীঘ্রই জমা দিতে এবং পরে এটি প্রয়োগ করার জন্য নিবেদিত থাকে।

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

এই সমস্যাটি আপনার যে সমস্যাটিযুক্ত তা আপনার কোড করার সাথে খুব একটা সম্পর্কিত নয়। এটি এমন একটি লক্ষণ যা আপনার প্রকল্প পরিচালককে এই প্রকল্পে ব্যবহার করা হয়নি (এটি আপনার দোষ, তার দোষ, বা উভয়ই হোক)।

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

Answer 13

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

কয়েকটি কথায়: লাল ফেরারিতে বারান্দা লাগানোর পরিবর্তে প্রয়োজনীয়তাগুলি আবার বিবেচনা করুন এবং একটি ট্যাঙ্ক তৈরি করুন।

Answer 14

এটা আগুনে মেরে ফেল.

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

Answer 15

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

Answer 16

সহজ উত্তর। আমি কোনও ধরণের কোডিং বন্ধ করে দেব, যতক্ষণ না সে এখন পর্যন্ত যা চায় তার ঠিক চূড়ান্ত ধারণা নেই।

তারপরে তাদের ফিচারগুলির তালিকা ইত্যাদির অগ্রাধিকার প্রয়োজন, এখনই কোন আইটেমগুলি থাকা আবশ্যক তা নিশ্চিত করতে এবং পরে কী করা যেতে পারে ....

প্রতিটি বৈশিষ্ট্যের সময় / ব্যয় নির্ধারণ করতে আপনার অভিজ্ঞতা ব্যবহার করে এবং তারপরে তাদের বলুন, তারা যদি এটি চায় তবে এটি x পরিমাণ সময় এবং অর্থ গ্রহণ করতে পারে।

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

একবার আপনার চূড়ান্ত তালিকা থাকলে তাদের বলুন যে আপনি তাদের ভবিষ্যতের পরিবর্তনগুলি করুন, যেমন তারা পছন্দ করে তবে শীর্ষ মুহূর্তে 15/20 এ ফোকাস করা দরকার যে তাদের এখনই থাকতে হবে।

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

বর্তমান সংস্করণে কী করা হবে সে সম্পর্কে চূড়ান্ত সিদ্ধান্ত নেওয়ার পরে, সমস্ত আলোচনা / ধারণা / পরামর্শগুলি 100% বন্ধ করতে হবে।

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

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

এটি করা শক্ত, তবে বৈশিষ্ট্য স্কপ ক্রাইপটি সময়, শক্তি, অনুপ্রেরণা এবং স্পষ্ট চিন্তাভাবনার এতটাই ধ্বংসাত্মক।

Answer 17

প্রকল্পের সম্পূর্ণ দৃষ্টিকোণ থেকে:

আপনার দলের সাথে কোড থেকে শিখুন, পরের বার কী রিফ্যাক্টর এবং পুনরায় ব্যবহার করা যেতে পারে তা দেখুন, তারপরে একটি বিয়ার রাখুন।

একটি ইন-ডেভলপমেন্ট দৃষ্টিকোণ থেকে:

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

পরিকল্পনার দৃষ্টিকোণ থেকে:

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