সম্ভাব্য একতরফা অ্যাপ্লিকেশনকে কয়েকটি ছোটগুলিতে বিভক্ত করা কি বাগগুলি প্রতিরোধ করতে সহায়তা করে? [বন্ধ]

Question

এটি জিজ্ঞাসার আরেকটি উপায় হ'ল; কেন প্রোগ্রাম একচেটিয়া হতে থাকে?

আমি মায়ার মতো অ্যানিমেশন প্যাকেজের মতো কিছু নিয়ে ভাবছি যা লোকে বিভিন্ন বিভিন্ন কর্মপ্রবাহের জন্য ব্যবহার করে।

যদি অ্যানিমেশন এবং মডেলিংয়ের ক্ষমতাগুলি তাদের নিজস্ব পৃথক অ্যাপ্লিকেশনে বিভক্ত হয়ে ফাইলগুলির মধ্যে পাস করার সাথে পৃথকভাবে বিকশিত হয়, তবে তাদের সংরক্ষণ করা কি সহজ হবে না?

Comments

If the animation and modelling capabilities were split into their own separate application and developed separately, with files being passed between them, would they not be easier to maintain?মিশ্রিত করবেন না সহজ প্রসারিত করতে সঙ্গে আরও সহজ বজায় রাখার জন্য একটি মডিউল -per se- জটিলতা এবং সন্দেহজনক ডিজাইন মুক্ত নয়। মায়া তার প্লাগইনগুলি না থাকলেও বজায় রাখা পৃথিবীর নরক হতে পারে। অথবা উলটা.

— লাইভ

আমি যুক্ত করব যে একটি একক একক প্রোগ্রামটি বিক্রি করা সহজ এবং বেশিরভাগ লোকের পক্ষে সহজতর হতে পারে ।

— দারথফেনেক

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

— কর্সিকা

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

— দারথফেনেক

@ কর্সিকা - আমি অনুমান করব যে আমি যে প্রচুর ওয়েবসাইট ব্যবহার করি সেগুলি এখনও এককথায় রয়েছে। সর্বোপরি ইন্টারনেট ওয়ার্ডপ্রেসে চলে।

— Žদ্রো

Answer 1

হ্যাঁ. সাধারণত দুটি ছোট কম জটিল অ্যাপ্লিকেশন একক বৃহত অ্যাপ্লিকেশনগুলির চেয়ে বজায় রাখা খুব সহজ।

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

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

Comments

হ্যাঁ এবং পারফরম্যান্সের বিবেচনাগুলিও রয়েছে যেমন সিরিয়ালাইজিং ডেটা বনাম কোনও পয়েন্টারকে পাশ কাটাতে খরচ।

— জিমি জেমস 14

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

— ডক ব্রাউন

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

— ভু

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

— ভু

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

— আর স্মিটজ

Answer 2

কোনও সম্ভাব্য একতরফা প্রয়োগকে কয়েকটি ছোটগুলিতে বিভক্ত করা বাগগুলি প্রতিরোধে সহায়তা করে

বিষয়গুলি বাস্তবে খুব কমই সহজ।

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

যাহোক,

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

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

বৃহত্তর অ্যাপ্লিকেশনটি উপাদানগুলিতে কীভাবে বিভক্ত হতে পারে এবং উপাদানগুলির মধ্যে ইন্টারফেসগুলি কতটা বিস্তৃত হয় এবং কীভাবে সেই ইন্টারফেসগুলি ব্যবহৃত হয় তার উপরও এটি অনেকটা নির্ভর করে।

সংক্ষেপে, এটি প্রায়শই একটি বাণিজ্য বন্ধ এবং সাধারণত "হ্যাঁ" বা "না" উত্তর সঠিক নয় এমন কিছুই নয়।

কেন প্রোগ্রাম একচেটিয়া হতে থাকে

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

তাদের রক্ষণাবেক্ষণ করা কি সহজ হবে না?

এখানে "সহজ রক্ষণাবেক্ষণ" প্রায়শই আসে যে কোনও অ্যাপ্লিকেশনের বিভিন্ন অংশ বিভিন্ন দল আরও সহজেই বিকাশিত হতে পারে, তাই আরও ভাল বিতরণ কাজের চাপ, স্পষ্ট মনোযোগ সহ বিশেষায়িত দল এবং on

Comments

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

— ওয়ারবো

Answer 3

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

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

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

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

Comments

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

— দ্য গ্রেট ডাক

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

— ওডাল্রিক

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

— ভু

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

— অ্যালেক্স

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

— ভু

Answer 4

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

Comments

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

— ট্রেভর বয়েড স্মিথ

Answer 5

এটি মনে রাখা গুরুত্বপূর্ণ যে পারস্পরিক সম্পর্ক কার্যকারণ নয়।

একটি বড় একঘেয়েমি তৈরি করা এবং তারপরে এটিকে কয়েকটি ছোট ছোট অংশে বিভক্ত করা ভাল ডিজাইনের দিকে নিয়ে যেতে পারে বা নাও পারে। (এটি ডিজাইনের উন্নতি করতে পারে তবে এটির কোনও গ্যারান্টি নেই))

তবে একটি ভাল নকশা প্রায়শই একটি সিস্টেমকে বৃহত একরঙার পরিবর্তে কয়েকটি ছোট ছোট অংশ হিসাবে নির্মিত হওয়ার দিকে পরিচালিত করে। (একটি মনোলিথ করতে সেরা নকশা হতে, এটা ঠিক অনেক কম হওয়ার সম্ভাবনা আছে।)

ছোট অংশগুলি আরও ভাল কেন? কারণ এগুলি সম্পর্কে তর্ক করা সহজ। এবং যদি সঠিকতা সম্পর্কে যুক্তি করা সহজ হয় তবে আপনি সঠিক ফলাফল পেতে পারেন।

সিএআর হোয়ারের উদ্ধৃতি দিতে:

সফ্টওয়্যার ডিজাইন তৈরির দুটি উপায় রয়েছে: একটি উপায় হ'ল এটিকে এত সহজ করা যে স্পষ্টতই কোনও ঘাটতি নেই এবং অন্য উপায়টি এটিকে এত জটিল করে তোলা হয়েছে যে কোনও স্পষ্ট ঘাটতি নেই।

যদি তা হয় তবে কেন কেউ অযথা জটিল বা একক সমাধান তৈরি করবেন? Hoare উত্তর পরবর্তী বাক্যে উত্তর সরবরাহ করে:

প্রথম পদ্ধতি অনেক বেশী কঠিন।

এবং পরে একই উত্সে (1980 টিউরিং অ্যাওয়ার্ড লেকচার):

নির্ভরযোগ্যতার দাম হ'ল অত্যন্ত সরলতার সাধনা। এটি এমন একটি মূল্য যা অত্যন্ত ধনী ব্যক্তিদের প্রদান করা সবচেয়ে কঠিন।

Answer 6

এটি হ্যাঁ বা কোনও উত্তর সহ কোনও প্রশ্ন নয়। প্রশ্নটি কেবল রক্ষণাবেক্ষণের স্বাচ্ছন্দ্যই নয়, এটি দক্ষতার দক্ষতা ব্যবহারের প্রশ্নও।

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

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

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

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

Answer 7

কোন । এটি বজায় রাখা সহজ করে না। যদি আরও কিছু সমস্যা স্বাগত জানায়।

কেন?

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

• আপনার এখন দুটি পণ্য যা প্রয়োজন:

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

• আপনার কাছে এখন তিনটি ভোক্তা বাজার রয়েছে: মডেলার, অ্যানিমেটার এবং মডেলার অ্যানিমেটর

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

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

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

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

Answer 8

অনেক ভাল উত্তর ছিল কিন্তু প্রায় একটি মৃত বিভক্ত থাকায় আমি আমার টুপিটিও রিংয়ের মধ্যে ফেলে দেব।

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

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

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

Comments

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

— পিটার বি

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

— সিএল 40

এবং এছাড়াও: একবার সংকলিত একঘেয়ে অ্যাপ্লিকেশন হিসাবে বেরিয়ে আসতে পারে, একটি খুব মডুলার অ্যাপ্লিকেশন হতে পারে কোড ওয়াইস।

— পিটার বি

Answer 9

ইউআই অ্যাপ্লিকেশনগুলির জন্য এটি সামগ্রিক বাগের পরিমাণ হ্রাসের সম্ভাবনা নেই তবে যোগাযোগের কারণে সৃষ্ট সমস্যার জন্য বাগ মিক্সের ভারসাম্যকে পরিবর্তন করবে।

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

যদি প্রোগ্রামটির সাথে সম্পর্কিত ডেটাগুলির ইউনিটগুলি বৃহত্তর (অর্থাত্ চিত্রগুলি) হয় তবে যে কোনও ক্রস-প্রক্রিয়া বিলম্বকে আরও দীর্ঘ করতে হবে এবং এটি নির্ধারণ করা আরও শক্ত হবে - "10 এমবি চিত্রে রূপান্তরকরণ প্রয়োগ করুন" এর মতো কিছু সঙ্গে সঙ্গে + 20 এমবি ডিস্ক / নেটওয়ার্ক আইও অর্জন করবে ইন-মেমরি ফর্ম্যাট থেকে সিরিয়ালিজাব ফর্ম্যাট এবং ফিরে 2 রূপান্তর করতে। ব্যবহারকারীর কাছ থেকে এটি করার জন্য প্রয়োজনীয় সময়টি আড়াল করতে সত্যিই খুব বেশি কিছু করার দরকার নেই।

অতিরিক্তভাবে যে কোনও যোগাযোগ এবং বিশেষত ডিস্ক আইও অ্যান্টিভাইরাস / ফায়ারওয়াল চেকের সাপেক্ষে - এটি বাগ এবং আরও বেশি বিলম্ব পুনরুত্পাদন করতে অনিবার্যভাবে আরও একটি স্তর যুক্ত করে।

বিভাজক একঘেয়েমি "প্রোগ্রাম" যেখানে যোগাযোগের বিলম্ব সমালোচনা না করে বা ইতিমধ্যে অপ্রয়োজনীয় নয় তেজ দেয়

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

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

Answer 10

[এটি] বাগগুলি প্রতিরোধে সহায়তা করে ?

প্রতিরোধ? ঠিক আছে, না, সত্যিই নয়।

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

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