কীভাবে আমার বহুজাতিক একটি উন্নয়ন প্ল্যাটফর্ম থেকে অন্য প্ল্যাটফর্মে স্থানান্তর করতে পারে?


10

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

সুতরাং আমরা এই অ্যাপসটি সরানোর 2 প্রধান উপায় নিয়ে হাজির হয়েছি:

  1. একটি মাত্র প্ল্যাটফর্ম সমর্থন করুন। এর অর্থ কী? হোমপৃষ্ঠাটি তৈরি করুন এবং সমস্ত অ্যাপ্লিকেশনগুলি সেগুলি NET- তে হ'ল আক্ষরিকভাবে স্থানান্তর করুন (আমরা এটি করার সময় তাদের উন্নতি না করে)। নতুন ইন্ট্রানেট চলার পরে আমরা স্থানান্তরিত অ্যাপ্লিকেশনগুলি পুনর্নির্মাণ এবং সেগুলি উন্নত করতে শুরু করব। এটি আমাদের পিএইচপি প্ল্যাটফর্ম সমর্থন করার সময় .NET এ ইন্ট্রানেট বিকাশ করতে পারে।

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

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

আপনার কেউ কি এরকম কিছু পেরিয়ে এসেছেন? আপনি কি চয়ন করবেন? বা সম্ভবত আমি উপস্থাপন করেছি তাদের আরও আলাদা, ভাল উপায় আছে? আপনি কী ভাবছেন এবং কীভাবে আপনি এর কাছে পৌঁছবেন তা আমি জানতে চাই।


1
# 2 কি # 1 এর এক ধাপ নয়?
তায়ে-সং শিন

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

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

আমি বিষয়টি পড়েছি এবং একই প্রশ্ন ছিল। প্রকল্পটি কখনও ব্যয়যোগ্য হিসাবে গ্রহণযোগ্য হতে পারে কিনা তা নিয়ে আমি খুব সন্দেহ করি। আপনি কী আমাদের সংস্থার নাম বলতে পারেন যাতে আমরা এটি স্বল্প বিক্রয় করতে পারি? ;)
ম্যাকটল

হাহাহা, আমি কোম্পানির সাথে কাজের জায়গাটিতে কেবল একজন আইটি শিক্ষার্থী হওয়ায় সৎ হওয়ার জন্য আমি ব্যয়গুলি নিয়ে যত্ন করি না। আমি কেবল নিজের জ্ঞান চাইছি ... আগ্রহের সাথে আমার ম্যানেজার সিইওর কাছ থেকে এগিয়ে যাওয়ার জন্য যথেষ্ট ব্যয়কে ন্যায্য করেছেন ...
ড্যানিয়েল গ্রুসস্কেক

উত্তর:


5

আসুন উভয় দৃশ্যের বিবেচনা করা যাক:

সবকিছু-একবারে মাইগ্রেশন

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

পিস টু-পিস মাইগ্রেশন

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

উপসংহার

ব্যক্তিগত অভিজ্ঞতা থেকে আমি আপনাকে দুটি জিনিস বলতে পারি:

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

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

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

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

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

2

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


ঠিক আমার চিন্তা ছিল। আমার ম্যানেজার # 1 নিয়ে এগিয়ে যেতে চান, যা বুঝতে আমার অসুবিধা হয়।

2

বিগ ব্যাং পদ্ধতির ক্ষেত্রে শেষ ব্যবহারকারীরা যতটা সচেতন তত কমই গঠনমূলক। আমি এর বিপরীতে পরামর্শ দেব এবং সত্য বলতে আমি বিশ্বাস করতে পারি না যে কেউ এটিকে সংশ্লিষ্ট অ্যাপ্লিকেশনগুলির সংখ্যা দিয়ে গুরুত্ব সহকারে একটি বিকল্প হিসাবে বিবেচনা করবেন।

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

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

আমি মনে করি আপনার ব্যবহারকারীদের যেভাবেই পরিবর্তন আনতে হবে, তা হ'ল বিগ ব্যাং (কিউ প্রচুর সমর্থন কল) বা পিসমিল (ক্রমবর্ধমান পরিচিতি)। আমি ভাবতে চাইছি আপনি সম্পূর্ণ পিএইচপি থেকে সম্পূর্ণরূপে সম্পূর্ণরূপে চলে যাওয়ার জন্য ঠিক কতটা কাজ করতে হবে তা আপনি ঠিক আকার ধারণ করেননি either হয় হয় না।


আমার ধারণা, এটি দুটি পৃথক প্ল্যাটফর্মকে সমর্থন করার চেয়ে আরও জটিল। যে কোনও উপায়ে সত্যিই ভাল পন্থা নয় ... আপনার সময়ের জন্য ধন্যবাদ!
ড্যানিয়েল গ্রাসসেকেক

1

প্রথমত, আমি জোয়েরি যা বলে তার সাথে আমি একমত।

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

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

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

আরও একটি জিনিস, পিএইচপি কোডের লাইন সংখ্যা নিয়ে নিন এবং পুনর্লিখনটি সম্পূর্ণ করার জন্য আপনাকে কত দিন এবং কত বিকাশকারী প্রয়োজন হবে সে সম্পর্কে ধারণা পেতে এটি একটি ককোমো 2 সরঞ্জামে রেখে দিন।


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

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

1

আপনার কাছে তৃতীয় বিকল্প রয়েছে: -

আপনার উইন্ডোজ সার্ভার এবং আইএসএস এ পিএইচপি কোডটি স্থানান্তর করুন (আপনি যা চালানোর পরিকল্পনা করছেন ঠিক তেমন একটি। নেট চালু!)

তারপরে একক সিস্টেমের মতো দেখতে আপনার ব্যবহারকারীদের উপস্থাপনের সময় আপনি .NET- এ নতুন অ্যাপ্লিকেশন যুক্ত করতে পারেন (এবং ধীরে ধীরে কিছু পুরানোগুলিকে .NET তে রূপান্তর করুন)।


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