ক্রস-প্ল্যাটফর্ম বনাম নেটিভ সিদ্ধান্ত কাঠামো — একটি worked example
এই পাঠে যা শিখবেন
- একটি নির্দিষ্ট প্রজেক্ট ব্রিফ থেকে কীভাবে প্রাসঙ্গিক সিদ্ধান্ত-নির্ধারক ফ্যাক্টর বের করতে হয়
- একটি ওজনযুক্ত সিদ্ধান্ত-ম্যাট্রিক্স কীভাবে Python-এ বাস্তবায়ন করে তিনটি প্রার্থীকে র্যাঙ্ক করা যায়
- নেটিভ/React Native/Flutter — এই নির্দিষ্ট প্রেক্ষাপটে প্রতিটির স্কোর কেন এমন হলো, তার যুক্তি
- কেন এই ধরনের ফ্রেমওয়ার্কের ফলাফল প্রেক্ষাপট-নির্ভর, একটি সার্বজনীন "সঠিক উত্তর" নয়
১ · প্রজেক্ট ব্রিফ
একটি সিদ্ধান্ত কাঠামো ফাঁকা জায়গায় কাজ করে না — এটি সবসময় একটি নির্দিষ্ট প্রজেক্টের প্রেক্ষাপটে প্রয়োগ করতে হয়। ধরা যাক আমাদের প্রজেক্ট ব্রিফ এইরকম:
মাত্র ৩ জন ডেভেলপার, সবাই JavaScript/React-এ অভিজ্ঞ। কারো Swift বা Kotlin-এর অভিজ্ঞতা নেই।
টাইট — দুটি সম্পূর্ণ আলাদা নেটিভ টিম নিয়োগ করার সামর্থ্য নেই।
৩ মাসের মধ্যে iOS ও Android উভয় প্ল্যাটফর্মে একসাথে লঞ্চ করা জরুরি।
একটি সাধারণ সোশ্যাল ফিড, চ্যাট, ও প্রোফাইল — ভারী কাস্টম অ্যানিমেশন বা নেটিভ-অনলি হার্ডওয়্যার ফিচার প্রয়োজন নেই।
এই ব্রিফ থেকে পাঁচটি প্রাসঙ্গিক সিদ্ধান্ত-নির্ধারক ফ্যাক্টর বের করা যায়: টিমের পরিচিতি, টাইম-টু-মার্কেট, বাজেট দক্ষতা (একটি কোডবেস বনাম দুটি), নেটিভ লুক-ফিল, ও পারফরম্যান্স হেডরুম।
২ · ওজনযুক্ত সিদ্ধান্ত-ম্যাট্রিক্স — সংক্ষিপ্ত পুনরালোচনা
পদ্ধতিটি M3/L14 ও M4/L19-এর মতোই — প্রতিটি ফ্যাক্টরকে একটি ওজন দেওয়া হয় (যোগফল সবসময় ১.০), প্রতিটি প্রার্থী প্রতিটি ফ্যাক্টরে ১-১০ স্কেলে স্কোর পায়, তারপর:
ওজনযুক্ত স্কোর = Σ (ফ্যাক্টরের স্কোর × সেই ফ্যাক্টরের ওজন)
এই ব্রিফের জন্য টিমের পরিচিতি ও টাইম-টু-মার্কেটকে সবচেয়ে বেশি ওজন দেওয়া হয়েছে (প্রতিটি ০.৩০) — কারণ ছোট টিম, টাইট সময়সীমা। বাজেট দক্ষতা ০.২০, আর নেটিভ লুক-ফিল ও পারফরম্যান্স হেডরুম প্রতিটি ০.১০ — কারণ ব্রিফ অনুযায়ী ফিচারগুলো তুলনামূলক হালকা, তাই সর্বোচ্চ নেটিভ পারফরম্যান্স এই প্রজেক্টে কম গুরুত্বপূর্ণ।
৩ · কোড দিয়ে — এই নির্দিষ্ট প্রজেক্টের জন্য পূর্ণাঙ্গ worked example
# নেটিভ বনাম React Native বনাম Flutter -- এই নির্দিষ্ট প্রজেক্ট ব্রিফের জন্য ওজনযুক্ত সিদ্ধান্ত-ম্যাট্রিক্স
CRITERIA_WEIGHTS = {
"team_familiarity": 0.30, # টিম আগে থেকেই কী জানে
"time_to_market": 0.30, # ৩ মাসে দুই প্ল্যাটফর্মে লঞ্চ করার চাপ
"budget_efficiency": 0.20, # একটি কোডবেস বনাম দুটি আলাদা কোডবেস
"native_look_feel": 0.10, # এই প্রজেক্টে কম গুরুত্বপূর্ণ -- ফিচার হালকা
"performance_headroom": 0.10, # এই প্রজেক্টে কম গুরুত্বপূর্ণ -- ভারী অ্যানিমেশন নেই
}
assert abs(sum(CRITERIA_WEIGHTS.values()) - 1.0) < 1e-9, "ওজনগুলোর সমষ্টি অবশ্যই ১.০ হতে হবে"
# প্রতিটি প্রার্থী এই নির্দিষ্ট ব্রিফের প্রেক্ষাপটে ১-১০ স্কেলে স্কোর করা হয়েছে
CANDIDATES = {
"নেটিভ (Swift + Kotlin, দুটি আলাদা কোডবেস)": {
"team_familiarity": 2, # টিমের কেউ Swift/Kotlin জানে না
"time_to_market": 3, # দুটি সম্পূর্ণ আলাদা অ্যাপ বানাতে হবে ৩ মাসে
"budget_efficiency": 2, # কার্যত দ্বিগুণ ডেভেলপমেন্ট খরচ
"native_look_feel": 10,
"performance_headroom": 10,
},
"React Native": {
"team_familiarity": 9, # টিম আগে থেকেই React/JavaScript-এ দক্ষ
"time_to_market": 8,
"budget_efficiency": 8,
"native_look_feel": 7,
"performance_headroom": 6,
},
"Flutter": {
"team_familiarity": 4, # Dart সম্পূর্ণ নতুন করে শিখতে হবে
"time_to_market": 7,
"budget_efficiency": 7,
"native_look_feel": 8,
"performance_headroom": 8,
},
}
for name, scores in CANDIDATES.items():
assert all(0 <= v <= 10 for v in scores.values()), f"{name}-এর সব স্কোর ০-১০ সীমার মধ্যে হতে হবে"
def weighted_score(scores, weights):
return sum(scores[criterion] * weight for criterion, weight in weights.items())
print(f"{'প্রার্থী':45s} | ওয়েটেড স্কোর")
print("-" * 65)
results = []
for name, scores in CANDIDATES.items():
total = weighted_score(scores, CRITERIA_WEIGHTS)
results.append((name, total))
print(f"{name:45s} | {total:.2f}")
results.sort(key=lambda pair: pair[1], reverse=True)
print("\nচূড়ান্ত সুপারিশ (সর্বোচ্চ স্কোর প্রথমে):")
for rank, (name, total) in enumerate(results, start=1):
print(f"{rank}. {name} -- {total:.2f}")
winner, winner_score = results[0]
print(f"\nএই নির্দিষ্ট প্রজেক্ট ব্রিফের জন্য সুপারিশ: {winner} (স্কোর {winner_score:.2f})")
team_familiarity, time_to_market) এটি সবচেয়ে বেশি স্কোর করে। Flutter দ্বিতীয়
(৬.৩০) — নেটিভ লুক-ফিল ও পারফরম্যান্সে এগিয়ে থাকলেও Dart শেখার খরচ এই টাইট সময়সীমায় বড় বাধা। নেটিভ সবচেয়ে
কম স্কোর করে (৩.৯০) — যদিও এটি সেরা লুক-ফিল ও পারফরম্যান্স দেয়, এই প্রজেক্টের সবচেয়ে গুরুত্বপূর্ণ দুটি
ফ্যাক্টরে (পরিচিতি, সময়) এটি সবচেয়ে দুর্বল।
উপরের ওজন ও স্কোরগুলো এই নির্দিষ্ট টিম ও প্রজেক্টের জন্য যুক্তিসঙ্গত বিচার-বিবেচনা — এগুলো কোনো পরিমাপযোগ্য সার্বজনীন সত্য নয় (Full-Stack Web Frameworks কোর্সের L56-এও ঠিক একই সততার নোট দেওয়া হয়েছিল)। যদি টিম আগে থেকে Kotlin/Swift-এ দক্ষ হতো, বা প্রজেক্টে ভারী কাস্টম অ্যানিমেশন থাকত, বা সময়সীমা ৩ মাসের বদলে ১ বছর হতো — এই একই কাঠামো সম্পূর্ণ ভিন্ন সুপারিশ দিত। টুলটি সিদ্ধান্ত নেয় না, সিদ্ধান্তকে স্বচ্ছ ও পুনরাবৃত্তিযোগ্য করে তোলে মাত্র।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ যদি ব্রিফে বলা থাকত অ্যাপটিতে একটি জটিল কাস্টম ৩D অ্যানিমেশন-ভিত্তিক ফিচার লাগবে, তাহলে কোন ফ্যাক্টরের ওজন সবচেয়ে বেশি বাড়ানো উচিত হতো বলে আপনার মনে হয়?
সম্ভবত performance_headroom ও native_look_feel-এর ওজন বাড়ানো উচিত হতো —
জটিল কাস্টম অ্যানিমেশনের জন্য সর্বোচ্চ রেন্ডারিং নিয়ন্ত্রণ ও পারফরম্যান্স প্রয়োজন, যেখানে নেটিভ
সবচেয়ে এগিয়ে (স্কোর ১০)। ওজন যথেষ্ট বাড়ালে নেটিভের মোট ওয়েটেড স্কোর React Native-কে ছাড়িয়ে যেতে
পারত, যদিও দলের সীমিত Swift/Kotlin অভিজ্ঞতার কারণে team_familiarity-এর প্রভাব তখনও
থেকে যেত।
প্র ০২
কোড সেলে assert all(0 <= v <= 10 for v in scores.values()) লাইনটি কেন যোগ করা
হয়েছে — এটি কী ধরনের ভুল ধরার জন্য?
এটি একটি স্যানিটি-চেক — নিশ্চিত করে কেউ ভুলবশত ১-১০ স্কেলের বাইরের কোনো স্কোর (যেমন ১৫, বা ঋণাত্মক সংখ্যা) লিখে ফেললে কোডটি নীরবে ভুল ফলাফল না দিয়ে সাথে সাথে একটি স্পষ্ট এরর দেখায়। যেহেতু পুরো তুলনাটাই "সবাই একই স্কেলে স্কোর করা হয়েছে" এই ধারণার উপর নির্ভর করে, স্কেলের বাইরের একটি ভুল মান পুরো র্যাঙ্কিংকে অর্থহীন করে দিতে পারত।
প্র ০৩
Flutter-এর native_look_feel স্কোর (৮) React Native-এর (৭)-এর চেয়ে বেশি রাখা হয়েছে
কেন, অথচ Flutter নিজের রেন্ডারিং ইঞ্জিন (Skia) দিয়ে আঁকে, প্ল্যাটফর্মের আসল নেটিভ উইজেট ব্যবহার করে না?
এটাই একটি ভালো উদাহরণ যে স্কোরগুলো judgment call, স্বতঃসিদ্ধ নয়। যুক্তি হতে পারে — Flutter নিজের রেন্ডারিং ইঞ্জিন দিয়ে হলেও পিক্সেল-নিখুঁতভাবে উভয় প্ল্যাটফর্মের ডিজাইন গাইডলাইন অনুকরণ করতে সক্ষম (M4/L18-এ দেখা widget-tree রেন্ডারিং), যেখানে React Native প্ল্যাটফর্মের আসল নেটিভ উইজেট ব্রিজ করলেও দুই প্ল্যাটফর্মের মধ্যে সূক্ষ্ম আচরণগত অসামঞ্জস্য (inconsistency) দেখা দিতে পারে। কেউ বিপরীত মত দিয়ে ভিন্ন স্কোর দিতেই পারতেন — এটাই দেখায় কেন এই ধরনের স্কোরিং একটি দলের আলোচনার মাধ্যম, চূড়ান্ত রায় নয়।
অনুশীলন
-
চিন্তা করুন: যদি এই স্টার্টআপের টিমে ৩ জনের বদলে ২ জন Kotlin-এ ও ২ জন Swift-এ অভিজ্ঞ
ডেভেলপার যোগ দিত (মোট টিম বড় হয়ে যেত),
team_familiarityফ্যাক্টরে নেটিভের স্কোর কীভাবে বদলাত বলে মনে হয়, আর তাতে চূড়ান্ত সুপারিশে কী প্রভাব পড়তে পারে?নেটিভের
team_familiarityস্কোর ২ থেকে অনেক বেড়ে যেত (হয়তো ৮-৯-এ) — কারণ টিম এখন সত্যিই Swift/Kotlin-এ দক্ষ। যেহেতুteam_familiarity-এর ওজনও সর্বোচ্চ (০.৩০), এই একটি পরিবর্তনই নেটিভের মোট ওয়েটেড স্কোরকে উল্লেখযোগ্যভাবে বাড়িয়ে দিতে পারে, সম্ভবত React Native-এর কাছাকাছি বা তার চেয়ে বেশি নিয়ে যেতে পারে — নিশ্চিত হতে কোড সেলে স্কোর বদলে সরাসরি Run করাই সবচেয়ে নির্ভরযোগ্য। -
পরীক্ষা করুন: উপরের কোড সেলে
CRITERIA_WEIGHTS-এnative_look_feelওperformance_headroom-এর ওজন প্রতিটি ০.২৫-এ বাড়িয়ে দিন এবংteam_familiarityওtime_to_marketপ্রতিটি ০.২০-এ কমিয়ে দিন (budget_efficiency০.১০-এ, যোগফল ১.০ বজায় রেখে), তারপর Run চেপে র্যাঙ্কিং বদলায় কি না দেখুন।এই বদলে
assertলাইনটি প্রথমে যোগফল সত্যিই ১.০ কি না যাচাই করবে (০.২০+০.২০+০.১০+০.২৫+০.২৫ = ১.০০ ঠিক আছে)। এরপর নেটিভের সর্বোচ্চ স্কোরযুক্ত ফ্যাক্টরগুলো (native_look_feel,performance_headroom) বেশি গুরুত্ব পাবে, আর React Native-এর সুবিধাজনক ফ্যাক্টরগুলোর (team_familiarity,time_to_market) ওজন কমবে — ফলে নেটিভ ও React Native-এর মধ্যে ব্যবধান কমে আসতে পারে বা র্যাঙ্কিংও বদলে যেতে পারে; সঠিক সংখ্যা যাচাইয়ের একমাত্র নির্ভরযোগ্য উপায় সরাসরি Run করা।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- পরের পাঠ — চূড়ান্ত প্রকল্প L57 ক্যাপস্টোন — একটি মোবাইল অ্যাপের আর্কিটেকচার ডিজাইন ও সিমুলেট করা।
- আগের পাঠ L55 কেস স্টাডি: একটি মোবাইল অ্যাপকে লাখো ব্যবহারকারীর জন্য স্কেল করা।
- M1/L02 — নেটিভ বনাম ক্রস-প্ল্যাটফর্ম বনাম হাইব্রিড প্রেক্ষাপট এই পাঠের সিদ্ধান্তে ব্যবহৃত সাধারণ আর্কিটেকচার ম্যাপটি সেই পাঠে প্রথম প্রবর্তিত হয়েছিল।
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ অ্যাপ লাইফসাইকেল, মোবাইল UI/UX, MVVM/MVI আর্কিটেকচার, নেটিভ বনাম ক্রস-প্ল্যাটফর্ম, নেভিগেশন, স্টেট ম্যানেজমেন্ট, লোকাল স্টোরেজ, ডিভাইস ফিচার ও ডিপ্লয়মেন্ট।