একাধিক সাবপ্রজেক্টে কখন একটি প্রকল্প পৃথক করতে হয়


30

আমি জানতে চাই যে প্রকল্পটি বিভক্ত করার জন্য যদি আমি একটির পরিবর্তে দুটি ভাণ্ডারে কাজ করছি তা বোঝা যায় কিনা।

আমি যা বলতে পারি তা থেকে:

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

এখন পর্যন্ত, সংগ্রহস্থলের এই কাঠামো রয়েছে:

রুট:

  • সামনের অংশ/*
  • ব্যাকএন্ড / *

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

আমাকে বলা হয়েছে যে এটি অর্থহীন এবং এটি করে আমরা কোনও উপকার পাব না।

এখানে আমার কিছু যুক্তি দেওয়া হল:

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

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

উত্তর:


23

আমার সংস্থায়, আমরা সিস্টেমের প্রতিটি উপাদানগুলির জন্য পৃথক এসভিএন সংগ্রহস্থল ব্যবহার করি। আমি আপনাকে বলতে পারি যে এটি অত্যন্ত হতাশাগ্রস্থ হয়। আমাদের বিল্ড প্রক্রিয়াটিতে বিমূর্ততার অনেক স্তর রয়েছে।

আমরা জাভা দিয়ে এটি করি, সুতরাং জাভাক সংকলন, জিবএক্স বাইন্ডিং সংকলন, এক্সএমএল বৈধকরণ ইত্যাদি সহ আমাদের ভারী বিল্ড প্রক্রিয়া রয়েছে

আপনার সাইটের জন্য, যদি আপনি সত্যিই এটি "বিল্ড" না করেন (যেমন ভ্যানিলা পিএইচপি) এটি কোনও বড় বিষয় নাও হতে পারে।

পণ্যকে একাধিক ভাণ্ডারে বিভক্ত করার জন্য ডাউনসাইড

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

আমার কেসটি কিছুটা চরম কারণ আমাদের পণ্যটি 14 টি বিভিন্ন রেপোতে বিভক্ত এবং প্রতিটি রেপো পরে 4-8 মডিউলগুলিতে বিভক্ত। যদি আমি মনে করি, আমাদের কোথাও প্রায় 80 বা কিছু "প্যাকেজ" রয়েছে যা সকলকে স্বতন্ত্রভাবে পরীক্ষা করা এবং তারপরে একত্রিত হওয়া প্রয়োজন।

স্রেফ ব্যাকএন্ড / ফ্রন্টএন্ডের সাথে আপনার কেস কম জটিল হতে পারে তবে আমি এখনও এর বিরুদ্ধে পরামর্শ দিই।

চূড়ান্ত উদাহরণগুলি বেশ কিছু কিছুর পক্ষে বা বিপক্ষে বাধ্যতামূলক যুক্তি হতে পারে :)

মানদণ্ড আমি সিদ্ধান্ত নিতে ব্যবহার করব

নিম্নলিখিত বিষয়গুলি বিবেচনা করে আমি একাধিক উত্স কোড সংগ্রহস্থলে কোনও পণ্যকে বিভক্ত করার বিষয়টি বিবেচনা করব:

  1. বিল্ড - প্রতিটি উপাদান তৈরির ফলাফলগুলি কি এক সাথে একত্রিত হয়ে পণ্য গঠন করে? একগুচ্ছ উপাদান থেকে .class ফাইলগুলি .jar বা .war ফাইলগুলির একটি সিরিজের সাথে সংযুক্ত করার মতো।
  2. স্থাপনা - আপনি কি এমন উপাদানগুলি শেষ করেছেন যা একক হিসাবে বা বিভিন্ন সার্ভারে যায় এমন বিভিন্ন ইউনিট হিসাবে একত্রে নিযুক্ত হয়? উদাহরণস্বরূপ, ডাটাবেস স্ক্রিপ্টগুলি আপনার ডিবি সার্ভারে যায়, যখন জাভাস্ক্রিপ্ট আপনার ওয়েব সার্ভারে যায়।
  3. সহ-পরিবর্তন - তারা কি প্রায়শই বা একসাথে পরিবর্তনের ঝোঁক রাখে? আপনার ক্ষেত্রে এগুলি পৃথকভাবে পরিবর্তিত হতে পারে তবে এখনও ঘন ঘন।
  4. ব্রাঞ্চিং / মার্জ করার ফ্রিকোয়েন্সি - যদি প্রত্যেকে ট্রাঙ্কে এবং শাখাগুলিতে পরীক্ষা করে দেখে বিরল হয়, তবে আপনি এটিকে সরিয়ে নিতে সক্ষম হতে পারেন। যদি আপনি প্রায়শই শাখা এবং মার্জ করেন তবে এটি দুঃস্বপ্নে পরিণত হতে পারে।
  5. তত্পরতা - যদি আপনার কোনও মুহুর্তের নোটিশে (সম্ভবত সা.এ.এস. এর সাথে) পরিবর্তন, বিকাশ, প্রকাশ এবং প্রকাশের দরকার হয় তবে মূল্যবান সময় জাগ্রাল শাখা এবং রেপো ব্যয় না করে কি আপনি এটি করতে পারবেন?

আপনার যুক্তি

আমি এই বিভাজনের জন্য আপনার বেশিরভাগ যুক্তিগুলির সাথেও একমত নই। আমি তাদের সকলের সাথে বিতর্ক করব না কারণ এই দীর্ঘ উত্তরটি আরও দীর্ঘতর হবে, তবে কয়েকটি যে দাঁড়াচ্ছে:

আমাদের দুটি মডিউল রয়েছে যা একে অপরের মধ্যে নির্ভর করে না।

ছাইপাঁশ. আপনি যদি আপনার ব্যাকএন্ড দূরে নিয়ে যান তবে আপনার অগ্রভাগ কী কাজ করবে? আমি যা ভেবেছিলাম.

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

যদি আপনার প্রকল্পের মূলটি সম্মুখভাগ / এবং ব্যাকএন্ড / ভাগে বিভক্ত হয় তবে আপনি সেই শ্রেণিবিন্যাসের ইতিহাসটি স্বাধীনভাবে দেখতে পারেন।

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

আপনার প্রকল্পটি বিভিন্ন ভাণ্ডারে বিভক্ত করা এর সমাধান করে না। একটি ফ্রন্টএন্ড দ্বন্দ্ব এবং ব্যাকএন্ডের দ্বন্দ্ব এখনও আপনাকে 2 টি দ্বন্দ্বের সাথে ছেড়ে দেয়, এটি 1 ভান্ডার 2 বার বা দ্বন্দ্ব 2 বার বা 2 টি সংগ্রহের দ্বন্দ্ব 1 দ্বন্দ্ব। কারও এখনও তাদের সমাধান করা দরকার।

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

অন্য দিকে

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


সবকিছুর মধ্যে সংযম, যেমন আমার মা বলতেন ...
উইলিয়াম পায়েেন

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

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

1
তারপরে আপনার কোনও বিল্ড বা স্থাপনার সমস্যা নেই, যাতে এটি ঠিক থাকে। তবে আবারও, যদি আপনি কোনও বড় পরিবর্তন করেন তবে আপনাকে এপিআই পরিবর্তন করতে হবে যা সম্মুখভাগ এবং ব্যাকএন্ড উভয়কেই প্রভাবিত করে এবং এভাবে আপনি দু'বার শাখা করবেন, দুবার মার্জ করবেন, দ্বিগুণ ট্যাগিং করবেন ইত্যাদি But তবে যতক্ষণ না এটি কেবল দু'বার থাকে এবং না হয় 3 ... 4 ... 12 ... 20 এ পরিণত হবে না, সম্ভবত এটি খারাপ ধারণা নয়।
ব্র্যান্ডন

এমনকি যথাযথ সংস্করণ সহ এপিআই পরিবর্তন হলে, প্রতিটি এফআইআই সংস্করণ সমর্থন করে এমন প্রতিটি ফ্রন্টএন্ডের জন্য শাখা সংস্করণ তৈরি করা সম্ভব। ব্যাকএন্ডে কিছু "পিছনে" সামঞ্জস্য থাকা উচিত এবং পুরানো এপিআই যতক্ষণ সম্ভব কাজ করা উচিত।
Loïc Faure-Lacroix

3

আপনার কিছু যুক্তি বৈধ এবং কিছু নেই।

আমাদের দুটি মডিউল রয়েছে যা একে অপরের মধ্যে নির্ভর করে না।

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

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

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

সংঘাত এবং মার্জিং (এটি হওয়া উচিত নয় তবে কেউ ব্যাকএন্ডে চাপ দিলে অন্যান্য বিকাশকারীকে সামনের পরিবর্তনগুলিতে ঠেকাতে ব্যাকএন্ডের পরিবর্তনগুলি টানতে বাধ্য করবে))

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

একজন বিকাশকারী কেবল ব্যাকএন্ডে কাজ করতে পারে তবে সর্বদা ব্যাকএন্ড বা অন্যদিকে টানতে হবে।

এটি পূর্ববর্তীটির মতো একই বোগাস যুক্তি।

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

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

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

এটি একটি বৈধ যুক্তি, তবে এটি তেমন শক্তিশালী নয়।

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

এটি একটি বৈধ যুক্তি।

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

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

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

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


সত্যি কথা বলতে, বেশিরভাগ বগাস যুক্তিগুলি শাখাগুলি দিয়ে সমাধান করা যায়। অগ্রভাগের জন্য শাখা এবং ব্যাকএন্ডের জন্য শাখা। সিঙ্কের জন্য মাস্টার তবে কোনও উপায়ে, এর মতো শাখা পরিচালনা করা জিনিসগুলিকে দুটি রেপো করার চেয়ে জটিল করে তুলছে।
Loïc Faure-Lacroix

1
@ সিবিয়াম: প্রকৃতপক্ষে, তারা বগু যুক্তি, কারণ তারা কোনও সমস্যা হাইলাইট করে না যা একক সংগ্রহস্থল ব্যবহার করে বিদ্যমান থাকতে পারে, এমনকি যদি সমস্ত পরিবর্তনগুলি কেবল ট্রাঙ্ক / মূল হিসাবে করা হয়।
বার্ট ভ্যান ইনজেন শেহেনো

আপনার সমালোচনাগুলি বৈধ বলে আমি মনে করি। আমি শুধু মনে করি না যে প্রশ্নের পয়েন্ট ছিল।
sylvanaar

2

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

  • এপিআই সংজ্ঞা
  • ব্যাক-এন্ড
  • সামনের অংশ

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

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

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

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