বিপুল একতরফা প্রয়োগের বিপদ


20

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

আমি স্মৃতি থেকে বলতে পারার চেয়ে আরও বিভিন্ন কার্যকারিতা সহ ডিভাইসটি বেশ উন্নত এবং তাদের 98% এই বিশাল নির্বাহযোগ্য দ্বারা পরিচালিত হয়। একদিকে প্রোগ্রামটি বেশ রক্ষণাবেক্ষণযোগ্য, ভালভাবে ভিতরে রুপান্তরিত, সঠিকভাবে নথিভুক্ত, ডিরেক্টরি এবং ফাইল ইত্যাদির দ্বারা কার্যকারিতা যুক্তিসঙ্গত পৃথককরণ রয়েছে।

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

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

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

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

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


7
সূর্য খুব তাড়াতাড়ি উঠলে ইংল্যান্ড সমুদ্রের
ম্যাক্সপাম

1
অথবা পৃথিবীর মূল অংশে চাপ কিছুটা বেড়েছে।
স্টুপার ইউজার

1
@ ম্যাক্সপাম আমি দেখছি আপনি সেখানে কী করেছেন ... xkcd.com/687
টেটো

3
@ ম্যাক্সএম: ভাগ্যক্রমে, আমাদের অ্যাপ সানরাইজ এবং সানসেটগুলি চালায় না। আমরা বিশ্বাস করি রাজকুমারী সেলেস্টিয়া তার চাকরিতে ব্যর্থ হবে না।
এসএফ

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

উত্তর:


5

শেষে ক্ষুদ্র মন্তব্য বাদে (দ্বিতীয়, সিপিইউ তদারকি) আপনি আমার সংস্থার বর্ণনা দিচ্ছেন। হ্যাঁ, আমাদেরও ইস্টার দরকার।

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

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


ধন্যবাদ - কোনও "বেস্ট পদ্ধতি অনুসরণ / উত্সর্গীকৃত" এবং "সম্ভাব্য অসুবিধাগুলি विरूद्ध ভারসাম্যহীন সম্ভাব্য সুবিধাগুলি" এন্ট্রিগুলি বেড়ার অপর পাশের প্রথম হাতের অভিজ্ঞ ব্যক্তির মতো সদা সহায়ক।
এসএফ

23

আমি স্মৃতি থেকে বলতে পারার চেয়ে আরও বিভিন্ন কার্যকারিতা সহ ডিভাইসটি বেশ উন্নত এবং তাদের 98% এই বিশাল নির্বাহযোগ্য দ্বারা পরিচালিত হয়। একদিকে প্রোগ্রামটি বেশ রক্ষণাবেক্ষণযোগ্য, ভালভাবে ভিতরে রুপান্তরিত, সঠিকভাবে নথিভুক্ত, ডিরেক্টরি এবং ফাইল ইত্যাদির দ্বারা কার্যকারিতা যুক্তিসঙ্গত পৃথককরণ রয়েছে।

আপনি নিজেই বলেছিলেন - এটি বেশ রক্ষণাবেক্ষণযোগ্য, ভাল মডুলারাইজড ...

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

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

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

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

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


16

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

একটি পরীক্ষার স্যুট থাকা আপনার অ্যাপ্লিকেশনটি বোঝার উন্নতি করবে এবং যখন অ্যাপ্লিকেশনটিতে কোনও পরিবর্তন ঘটে তখন আপনাকে জানায়।


2
তবে এটি উভয় সম্ভাব্য স্থাপত্যের জন্য প্রযোজ্য ...
এসএফ।

3
হ্যাঁ, এটি ঘটে ...
রবার্ট হার্ভে

10
... এবং সেইজন্য এই উত্তরটি ইউনিট পরীক্ষার প্রচার ব্যতীত আলোচনায় কিছু যুক্ত করে না।
বেনজাদো

2
@ বেনজাদো: ওপি-র দৃশ্যে যা অত্যন্ত গুরুত্ব বহন করে।
রবার্ট হার্ভে

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

8

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

এম্বেড থাকা সিস্টেমগুলির জন্য, আপনার এক প্রক্রিয়াটি আপনার তৈরি করা সমস্ত প্রক্রিয়া চালনার জন্য একটি O / S বাস্তবায়নের প্রয়োজনীয়তাটি হারাতে পারে। আপনার সমস্ত প্রক্রিয়া কোথায় চলছে তা যাচাই করার জন্য আপনাকে একটি সিস্টেম প্রয়োগ করতে হবে এবং সম্ভব হলে এগুলি পুনরায় চালু করতে হবে। যদি এটি সম্ভব না হয় তবে আপনাকে সেই অনুযায়ী প্রতিক্রিয়া জানাতে হবে।

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

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

যখন প্রয়োজন হয় তখন ক্রাশ জোর করা একঘেয়ে এক্সিকিউটেবলের সাথেও সহজ।


1
+1, ইঞ্জিনিয়ারিং
ট্রেড অফস

+1 আমি আন্তরিকভাবে একমত। একাধিক এক্সিকিউটেবলের ওয়ারেন্ট দেওয়ার জন্য নির্দিষ্ট কোনও কারণ নেই। এক্সিকিউটেবলের মধ্যে যোগাযোগ এবং সমন্বয়ের এর দাম রয়েছে।
এরিক রবার্টসন

+1: যদি এটি না ভেঙে যায় তবে এটি ঠিক করবেন না।
বব মারফি

1

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

একবার এটি হয়ে যাওয়ার পরে, পরীক্ষাটি একটি দুঃস্বপ্ন হয়ে যায় এবং আপনি অচল হয়ে যাওয়ার পথে ভাল আছেন।

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

যদিও আপনি ভাল জায়গায় পরীক্ষা করতে চান।


1

আদর্শভাবে, উত্তর হ্যাঁ। একাধিক বাইনারি থাকার এটি আরও স্থিতিশীল করার সম্ভাবনা রয়েছে ....

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

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

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


1

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

আপনি যদি বিভিন্ন প্রক্রিয়া ব্যবহার করেন তবে আপনি কমপক্ষে একই হিপ বা কল স্ট্যাক ব্যবহার করছেন না এবং একটি একক সাবপ্রসেস পুনরায় আরম্ভ করা আরও সহজ হতে পারে।

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

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

বলা হচ্ছে এটি সম্ভবত একটি দুরূহ কাজ।

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


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

0

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

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

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