কোনও অ্যাপ্লিকেশন একটি খারাপ কোডবেসে নির্মিত কীভাবে প্রমাণ করবেন?

Question

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

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

Comments

প্রোগ্রামারস.স্ট্যাকেক্সেঞ্জঞ্জ / প্রশ্নগুলি / ৫৯০৫০ / Maybe সম্ভবত "বড় পুনর্লিখন "টি সাধারণত ব্যবসায়ের দৃষ্টিকোণ থেকে শেষ হয় কীভাবে খারাপভাবে মনোযোগ দেওয়া উচিত। আরও একটি "সিনিয়র স্তর" প্রোগ্রামার এটি করবে That

— কোয়ান্টিন-স্টারিন

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

— জেসন লুইস

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

— কোয়ান্টিন-স্টারিন

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

— অ্যালেক্স

এটি আরও সাধারণ সমস্যার একটি অংশ: আপনার পূর্বসূরীর দীর্ঘমেয়াদি ব্যয়ে তাত্ক্ষণিক ফলাফলের জন্য যা। দায়িত্ব নেওয়ার সময় আপনাকে ব্যাখ্যা করতে হবে কেন আপনি একই আউটপুটটি ধরে রাখতে পারেন না।

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

Answer 1

'তবে এটি এখন কাজ করে' হ'ল সফটওয়্যার ইঞ্জিনিয়ারদের বৈধ হতাশার মানক প্রতিক্রিয়া। আমি প্রথমে যা করব তা হ'ল ডকুমেন্টেশন সংকলন করা (যদি থাকে) এবং সেটি কোড এবং ডকুমেন্টেশনের মধ্যে দ্বন্দ্ব প্রদর্শনের জন্য ব্যবহার করুন।

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

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

অবশ্যই এটি আপনার পরিবেশ, সংস্থার আকার ইত্যাদির উপর নির্ভর করে

আমি সবসময় প্র্যাকমেটিক প্রোগ্রামারটি একবার দেখার পরামর্শ দিই যদি আপনি এটি না পড়ে থাকেন। প্রতিটি সফ্টওয়্যার পেশাদারদের জন্য কেবল এটি পড়ার দরকার নেই, তবে এটি পরিচালনা, সহকর্মী, ব্যবহারকারী ইত্যাদির সাথে व्यवहार করার জন্য কিছু ভাল পরামর্শ রয়েছে যারা সফটওয়্যার ইঞ্জিনিয়ারিংকে নৈপুণ্য হিসাবে দেখেন না।

Comments

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

— ক্রিসআর

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

— জেসন লুইস

সংক্ষেপে, আপনি যদি কিছু লোড টেস্টিং সফ্টওয়্যার পেতে পারেন তবে আপনি এটি উচ্চ লোডের নীচে কীভাবে ভেঙে যেতে পারে তা দেখাতে পারেন।

— এইচএলজিইএম

Answer 2

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

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

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

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

Answer 3

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

Comments

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

— THNX

@ ক্রিসারামেকারস: কোনও ব্যবস্থাপকের কাছে কিছুই "প্রমাণিত" হতে পারে না। "প্রমাণ" ভুলে যান। তথ্য সংগ্রহ করুন। তথ্যগুলি আপনার কাছে রয়েছে। আরও তথ্য আরও বিশ্বাসযোগ্য। তবে এর কোনও "প্রমাণ" নেই।

— এস.লট

Answer 4

এমন একটি উদাহরণ বেছে নিন যা সহজেই বুঝতে পারে যেখানে ম্যানেজমেন্ট এটিকে একটি সাধারণ পরিবর্তনের অনুরোধ মনে করবে, কিন্তু বিদ্যমান নকশার কারণে এটি আরও বেশি কঠিন।

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

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

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

Comments

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

— ল্যারি ওব্রায়ান

Answer 5

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

আপনার ক্ষেত্রে, আমি মনে করি 2 টি জিনিস প্রমাণিত হতে হবে।

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

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

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

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

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

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

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

Answer 6

আমার ধারণা এটি নির্ভর করে কোড বেজ সম্পর্কে কী খারাপ। "আমি যেভাবে করবো সেভাবে নয়" হওয়ার অর্থ এটি খারাপ কোড ভিত্তি নয় base

জিনিসগুলি যা আসলে একটি খারাপ কোড-বেস করে:

• সুরক্ষা গর্ত

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

• ভগ্ন

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

• আসলে কাজ করে না

  এটি কাজ করে বলে মনে হচ্ছে তবে ফলাফলগুলি ভুল। এটি সাধারণত লাইনের নীচে সমস্যার কারণ যেমন সংখ্যাগুলি মিলছে না, উচ্চ ত্রুটির হার ইত্যাদি causes

খারাপ কোডবেস কী নয় (কেবল ভাল নয়):

• অপ্রচলিত অসমর্থিত প্রযুক্তিতে লেখা। (ভিবি 6, সিওবিওএল,। নেট 1.1 ইত্যাদি)

একটি নতুন প্রযুক্তিতে স্থানান্তরিত করার সুবিধাগুলি নোট করুন। মাইগ্রেশন পাথের সন্ধান করার চেষ্টা করুন যা একসাথে টুকরো টুকরো করে তোলে যাতে আপনি ঝুঁকি হ্রাস করতে এবং ব্যবহারকারী এবং পরিচালনার আস্থা তৈরি করতে পারেন। নিশ্চিত করুন যে যুক্তিটি মূলত আসলটির মতোই কাজ করে।

• Undocumented / খারাপ ফরম্যাটেড কোড

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

Answer 7

আপনি আপনার নিজের প্রশ্নের উত্তর একরকম দিয়েছেন।

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

এরপরে এটি পরিমাপ করার পরিষ্কার করার সহজ প্রস্তাবটি X ঘন্টা ব্যয় করতে পারে।

Comments

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

— জেসন লুইস

@ জেসন - আমি আপনার বক্তব্যটি দেখতে পাচ্ছি, তবে আমার অভিজ্ঞতায় অস্বীকারটি নীচের দিকে চলে এবং 'তাকে তাই বলেছিল' শৃঙ্খলে উঠে যাওয়ার পথে 'নন-টিম প্লেয়ার' নামার পথে খুব দ্রুত দেখা হবে।

— জেনো

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

— জেসন লুইস

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

— maple_shaft

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

— জেসন লুইস

Answer 8

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

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

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

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

Answer 9

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

Answer 10

সমস্ত পরিপক্ক সফ্টওয়্যার জঞ্জাল দেখাচ্ছে বলে কারণ রয়েছে :

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

Comments

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

— জেসন লুইস

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

— tp1