การเปลี่ยนแปลงข้ามชาติของฉันจากแพลตฟอร์มการพัฒนาหนึ่งไปยังแพลตฟอร์มอื่นได้อย่างไร


10

ฉันทำงานในแผนกไอทีของ บริษัท ระหว่างประเทศขนาดใหญ่ เรากำลังพัฒนาแอปพลิเคชันอินทราเน็ตที่แตกต่างกันสำหรับธุรกิจ (การร้องเรียนการคืนเงินส่วนให้บริการ ฯลฯ ) ตอนนี้เราตัดสินใจโยกย้ายจากแพลตฟอร์ม PHP เป็น. NET (รวมกับ MS CRM Dynamics, Exchange และ MS Office ด้วยเหตุผลหลายประการ) เนื่องจากมีแอพพลิเคชั่นที่แตกต่างกันประมาณ 20 แอปพลิเคชันที่ธุรกิจใช้บนแพลตฟอร์ม PHP ปัจจุบันเราจะต้องหาวิธีที่ดีที่สุดในการย้ายแอปพลิเคชั่นทั้งหมดไปยังแพลตฟอร์มใหม่ ฉันไม่ต้องการดูรายละเอียดวิธีแปลงรหัส ฯลฯ ขณะที่เราทำการย้ายข้อมูลเราต้องการปรับปรุงแอปพลิเคชันเหล่านี้ทั้งหมด

ดังนั้นเราจึงสร้างวิธีหลักสองวิธีในการย้ายแอพเหล่านี้:

  1. รองรับเพียงแพลตฟอร์มเดียว มันหมายความว่าอะไร? สร้างโฮมเพจและโอนย้ายแอปทั้งหมดตามที่เป็นจริงไปยัง. NET (โดยไม่ต้องปรับปรุงในขณะที่เราทำเช่นนั้น) หลังจากอินทราเน็ตใหม่กำลังทำงานเราจะเริ่มสร้างแอปพลิเคชันที่ย้ายข้อมูลขึ้นใหม่และปรับปรุง นั่นจะช่วยให้เราพัฒนาอินทราเน็ตใน. NET ในขณะที่ต้องสนับสนุนแพลตฟอร์ม PHP

  2. สนับสนุนทั้งสองแพลตฟอร์มในบางครั้ง นั่นหมายถึงการสร้างโฮมเพจและแอพพลิเคชั่นใหม่ 1 หรือ 2 อัน (ซึ่งไม่มีอยู่ในแพลตฟอร์ม PHP ของเรา) ทำให้ผู้ใช้เหล่านี้พร้อมใช้งาน แต่ไม่ต้องถอดแพลตฟอร์ม PHP (เราจะรวมเมนูและลิงก์เพื่อให้ผู้ใช้ย้ายระหว่างแอพในหน้า PHP และแอปใหม่ได้ง่ายขึ้น) จากนั้นเราจะเริ่มเขียนแอปพลิเคชัน PHP ใหม่ขณะที่ปรับปรุง

ตอนนี้ฉันไม่แน่ใจว่าสิ่งที่จะดีกว่าในมือข้างหนึ่ง (ตัวเลือก 1) เราอาจทำให้ทุกอย่างง่ายขึ้นสำหรับผู้ใช้โดยไม่บังคับให้พวกเขาใช้สองแพลตฟอร์มที่แตกต่างกันในเวลาเดียวกัน แม้ว่าพวกเขาจะไม่เห็นการปรับปรุงใด ๆ ของการมีแพลตฟอร์มใหม่นอกเหนือจากทุกสิ่งที่ดูดีกว่าการทำงานของแอปพลิเคชันบนแพลตฟอร์มใหม่จะเหมือนเดิมในบางครั้ง นอกจากนี้ฉันคิดว่าเราจะเพิ่มตัวเอง (IT dep) มากขึ้นเพราะเราจะเขียนทุกแอปสองครั้ง
ในทางกลับกันผู้ใช้ตัวเลือกที่สอง (2) จะมีประสบการณ์ที่แย่กว่าเดิมเนื่องจากทั้งสองแพลตฟอร์มมีลักษณะที่แตกต่างกัน แต่พวกเขาจะตระหนักถึงประโยชน์ของแพลตฟอร์มใหม่เมื่อแอพพลิเคชั่นใหม่กำลังเคลื่อนไหว

มีใครในพวกคุณเจออะไรแบบนั้นบ้าง? คุณจะเลือกอะไร หรืออาจจะมีวิธีที่แตกต่างกันยิ่งกว่าสำหรับผู้ที่ฉันได้นำเสนอ? ฉันอยากรู้ว่าคุณคิดอย่างไรและคุณจะเข้าใกล้ได้อย่างไร


1
ไม่ใช่ # 2 ขั้นตอนในการ # 1 หรือไม่
แทซองชิน

ไม่พวกมันต่างกัน 2 อย่าง ใน 1 เราจะโยกย้ายอินทราเน็ตทั้งหมดก่อนที่จะอนุญาตให้ผู้ใช้ใช้งานและจากนั้นเราจะพยายามปรับปรุงแอพ ใน 2 เราจะโยกย้ายส่วนสำคัญของอินทราเน็ตอนุญาตให้ผู้ใช้ใช้งานจากนั้นเริ่มโยกย้ายแอพอื่น ๆ และปรับปรุงในขณะที่เราย้าย ...

@greengit: อ่านหัวข้อการรวมเข้ากับโปรแกรมประยุกต์ทางธุรกิจที่สำคัญอื่น ๆ เป็นหนึ่งในเหตุผล คำถามของฉันไม่ได้รับการรักษาเกี่ยวกับ 'เหตุใดจึงต้องโยกย้าย' แต่ 'วิธีการโยกย้าย'
Daniel Gruszczyk

ฉันอ่านหัวข้อ & มีคำถามเดียวกัน ฉันสงสัยอย่างมากว่าโครงการจะมีค่าใช้จ่ายที่สมเหตุสมผลหรือไม่ คุณสามารถบอกชื่อ บริษัท ให้เราทราบเพื่อที่เราจะสามารถขายชอร์ตได้ ;)
mcottle

ฮ่าฮ่าฉันไม่สนใจเรื่องค่าใช้จ่ายที่จะซื่อสัตย์เพราะฉันเป็นแค่นักเรียนไอทีในที่ทำงานกับ บริษัท ฉันแค่ขอความรู้ของตัวเอง ... ผู้จัดการของฉันเห็นได้ชัดว่าค่าใช้จ่ายเพียงพอที่จะได้รับจากซีอีโอ ...
Daniel Gruszczyk

คำตอบ:


5

ลองพิจารณาทั้งสองสถานการณ์:

การโยกย้ายทุกอย่างพร้อมกัน

ในขณะที่คุณกำลังย้ายฐานข้อมูลลูกค้าของคุณจะยังคงใช้แอพที่มีอยู่ เนื่องจากการโยกย้ายจะใช้เวลาไม่มากนี่หมายความว่าคุณจะต้องมีทีมบำรุงรักษาบน codebase เก่าสำหรับการแก้ไขข้อบกพร่องและการพัฒนาคุณสมบัติ การเปลี่ยนแปลงทุกอย่างที่คุณทำใน codebase เก่าจะต้องเกิดขึ้นใน codebase ใหม่ คุณจะต้องเขียนโค้ดทุกบรรทัดสองครั้งตราบใดที่การโยกย้ายยังไม่เสร็จสิ้นทำให้ค่าใช้จ่ายสูงขึ้นในการโยกย้าย ดังนั้นทุกอย่างก็ค่อยๆลดลงเป็น: เวลาตอบสนองสำหรับการย้ายถิ่นแบบสมบูรณ์จะเป็นอย่างไร ค่าใช้จ่ายในการพัฒนาของคุณจะพุ่งสูงขึ้นตราบใดที่เวลาตอบสนองยังคงอยู่

การย้ายถิ่นแบบทีละชิ้น

ในสถานการณ์นี้คุณจะสามารถควบคุมความพยายามได้ดีขึ้นสองเท่า แต่คุณจะยังมีค่าใช้จ่ายเพิ่มเติมอีกมากมาย การปรับใช้ของคุณจะเกี่ยวข้องกับสองแพลตฟอร์มที่แยกจากกันโดยมีประเด็นการปรับใช้และทรัพยากรเซิร์ฟเวอร์เพิ่มเติมที่จำเป็นเป็นสองเท่า หากคุณไม่มีแอพที่มีการจัดระเบียบแบบแยกส่วนมากคุณจะพบว่าบ่อยครั้งที่โค้ดบางส่วนมีอยู่ในแพลตฟอร์มอื่นที่ไม่ใช่แอพที่คุณต้องการ ตราบใดที่การโยกย้ายยังไม่เสร็จสิ้นค่าใช้จ่ายในการพัฒนาของคุณก็จะสูงขึ้น ในขณะเดียวกันความกดดันของฟีเจอร์จะหมายความว่าคุณต้องใช้เวลานานในการย้ายข้อมูลให้เสร็จ

ข้อสรุป

จากประสบการณ์ส่วนตัวฉันสามารถบอกคุณได้สองสิ่ง:

  • การเปลี่ยนภาษาโปรแกรมไม่ค่อยจ่าย จากการวิเคราะห์ค่าใช้จ่ายผลประโยชน์มันไม่น่าเป็นไปได้มากที่จะได้กำไรจากการเปลี่ยนเป็น. NET จาก PHP ดังนั้นคำแนะนำหลักของฉันคือ: ไม่ ลองแก้ปัญหาด้วย codebase ที่มีอยู่
  • ทีละชิ้นเป็นวิธีที่ดีที่สุด แต่คุณจะมีเวลาทำยากในระดับของโมดูลแอปพลิเคชัน คุณจะพบว่าคุณจะต้องพัฒนาและดูแลรักษาคุณสมบัติทั้งสองด้านของสถาปัตยกรรมตราบใดที่การโยกย้ายยังไม่เสร็จสมบูรณ์ เป็นความคิดที่ดีที่จะจัดลำดับความสำคัญของคุณลักษณะที่ไม่ได้ขึ้นอยู่กับสิ่งที่ลูกค้าต้องการมากที่สุด แต่จะ จำกัด จำนวนของความพยายามสองเท่า

คุณทำคะแนนได้ดีมาก แม้ว่ามันจะไม่ขึ้นอยู่กับตัวฉันเองถ้าเราเปลี่ยนแพลตฟอร์มหรือไม่และฉันจะทำงานให้กับ บริษัท จนถึงสิ้นเดือนกันยายนเท่านั้น (ฉันอยู่กับพวกเขาในตำแหน่งงานเดียว) การเปลี่ยนจาก PHP เป็น. NET อาจเป็นความคิดที่ดี แต่เนื่องจากกรอบการทำงานเก่า ๆ ของ PHP เราจำเป็นต้องมี MAJOR งานฐานข้อมูลและระบบที่ บริษัท ใช้ในขณะนี้คือ OLD และสร้างโดยคนที่ไม่มีทักษะการพัฒนาที่ยอดเยี่ยม ..
Daniel Gruszczyk

ด้วยคำถามของฉันจะเป็น: 'เปลี่ยนตรึง' บนแพลตฟอร์มเก่าเป็นความคิดที่ดี? สิ่งที่ฉันหมายถึงคือการเปลี่ยนแปลงใด ๆ กับระบบที่มีอยู่บนแพลตฟอร์ม PHP นอกเหนือจากการแก้ไขข้อผิดพลาดจะถูกหยุดจนกว่าเราจะเริ่มย้ายแอปพลิเคชันที่กำหนดให้กับ. NET ที่เป็นส่วนหนึ่งผู้จัดการของฉันของแผนสำหรับการโยกย้าย ...
แดเนียล Gruszczyk

หากนี่เป็นระบบที่ไม่สำคัญมันไม่น่าเป็นไปได้อย่างมากที่การเปลี่ยนแปลงจะหยุดชะงักในทางปฏิบัติ หากมีคนต้องการคุณสมบัติจริงๆพวกเขาจะเพิ่มระดับให้สูงกว่าผู้จัดการของคุณและคุณจะถูกบังคับให้ทำการเปลี่ยนแปลง นอกจากนี้การแก้ไขข้อบกพร่องด้วยตนเองสามารถใช้ทรัพยากรทีมจำนวนมาก และโปรดระลึกไว้เสมอว่าระบบเก่า ๆ ได้เห็นการปรับแต่งมากมายและการออกแบบใหม่มีแนวโน้มที่จะลืมการแก้ไขเพียงครั้งเดียวเหล่านั้นซึ่งจะต้องเกิดขึ้นอีกครั้งเพื่อให้ผู้ใช้ยอมรับผลิตภัณฑ์ที่ออกแบบใหม่
Joeri Sebrechts

อีกจุดหนึ่ง: หากระบบกำลังจะสร้างใหม่เจ้าหน้าที่รักษาความปลอดภัยอยู่ในสถานที่เพื่อให้แน่ใจว่ามีคุณภาพรหัสที่ดีขึ้นในเวลานี้ ฉันเคยเห็นแอปพลิเคชันที่เขียนขึ้นใหม่ 4 ครั้งเนื่องจากปัญหาเกี่ยวกับคุณภาพของแพลตฟอร์มและโค้ด
Joeri Sebrechts

2

ด้วยเหตุผลทางการเงิน บริษัท ส่วนใหญ่ที่ฉันทำงานด้วยวิธีที่สองฉันอาจเพิ่มได้อย่างถูกต้อง ต้องใช้เงินเวลาและความเสี่ยงเป็นจำนวนมากเพื่อให้ได้ # 1 ผู้ใช้ส่วนใหญ่จะเข้าใจ # 2 ตราบใดที่พวกเขาเห็นความคืบหน้าและการโต้ตอบกับพวกเขา ในระบบเศรษฐกิจแบบลีนและมีค่านี้ฉันสงสัยว่าใคร ๆ ก็จะใช้วิธีที่ # 1


นั่นคือความคิดของฉัน ผู้จัดการของฉันต้องการดำเนินการต่อด้วยหมายเลข 1 ซึ่งฉันเข้าใจยาก

2

วิธีบิ๊กแบงไม่ค่อยมีความคิดสร้างสรรค์เท่าที่ผู้ใช้ปลายทางกังวล ฉันขอแนะนำให้ใช้กับมันและบอกตามตรงฉันไม่สามารถเชื่อได้ว่าใครจะพิจารณาอย่างจริงจังว่าเป็นตัวเลือกที่กำหนดจำนวนแอปพลิเคชันที่เกี่ยวข้อง

ฉันอยากจะไปกับตัวเลือกที่สองและจัดการ re-works ในแต่ละกรณี เป็นที่ยอมรับว่าอาจใช้เวลานานกว่าวิธีที่หนึ่งบนกระดาษ แต่ในความเป็นจริงคุณกำลังเปิดรับความเสี่ยงทางธุรกิจจำนวนมากโดยใช้วิธีที่หนึ่งและฉันไม่อยากอยู่ใกล้ ๆ สำหรับการสนับสนุนทางโทรศัพท์ในวันแรกถ้ามี เพียงปัญหาเล็ก ๆ น้อย ๆ ที่ผู้ใช้ปลายทาง

นอกจากนี้หากแอปพลิเคชั่นที่ใช้บริการบนเว็บของคุณจำนวนมากที่เขียนไว้ใน PHP แล้วความเชี่ยวชาญด้าน. Net ที่มีอยู่จะเป็นอย่างไร

ฉันคิดว่าวิธีที่ผู้ใช้ของคุณจะต้องประสบกับการเปลี่ยนแปลงไม่ว่าจะเป็นบิ๊กแบง (คิวการสนับสนุนจำนวนมาก) หรือทีละน้อย (เพิ่มความคุ้นเคย) ฉันอยากจะคิดว่าคุณยังไม่ได้ปรับขนาดจริง ๆ ว่างานจะต้องทำมากแค่ไหนที่จะเข้าใกล้ php ทั้งหมดจนถึง. Net อย่างสมบูรณ์


ฉันเดาว่ามันซับซ้อนกว่าแค่สนับสนุนสองแพลตฟอร์มแยกกันหรือไม่ ทั้งสองวิธีไม่ใช่วิธีที่ดีจริงๆ ... ขอบคุณสำหรับเวลาของคุณ!
Daniel Gruszczyk

1

ประการแรกฉันเห็นด้วยกับทุกสิ่งที่ Joeri พูด

ตัวเลือกที่หนึ่งน่ากลัวอย่างแท้จริง หากคุณทำเช่นนี้และไม่สนับสนุนอย่างที่ Joeri อธิบายคุณจะต้องปิดการสนับสนุนเป็นเวลาสองสามปีเท่าที่ลูกค้าของคุณเห็น หลังจากสองปีพวกเขาได้รับเว็บไซต์เดียวกันอย่างมีประสิทธิภาพด้วยปัญหาเดียวกันทั้งหมดที่พวกเขาได้รู้จักและเกลียดในช่วงไม่กี่ปีที่ผ่านมา บวกกับความเสี่ยงที่ตลาดมีการเปลี่ยนแปลงในระหว่างกาลและทำให้แอปพลิเคชันล้าสมัย & ต้องการการปรับปรุงครั้งใหญ่ นอกจากนี้หากคุณปิดการสนับสนุนเป็นเวลาสองปีคุณคิดว่าจะเกิดอะไรขึ้นกับคำขอบริการทั้งหมด พวกเขาจะไม่หายไป อย่างน้อยผู้ใช้บางคนของคุณจะ "โกง" และพัฒนาระบบที่สำคัญของภารกิจใน (อาจ) เข้าถึงการเชื่อมต่อช่องว่างในระบบที่คุณกำลังเขียนใหม่ - จากนั้นคุณก็ยังสนับสนุนสองแพลตฟอร์ม ...

ตัวเลือกที่สองหมายความว่าคุณจะสนับสนุนเทคโนโลยีทั้งสองเป็นระยะเวลานาน ช่วงเวลานี้จะนานกว่าที่คุณคิดและคุณสามารถจบลงด้วยระบบนิเวศที่มีการแยกส่วนอย่างถาวร - นั่นคือรหัส PHP จำนวนมากที่ไม่คุ้มค่าที่จะเขียนใหม่ผสมกับรหัส. NET ที่ใหม่กว่า

ผลักดันอย่างหนักกับใครก็ตามที่แนะนำสิ่งนี้ การเขียนโค้ดเพื่อรวมแอปพลิเคชัน PHP กับผลิตภัณฑ์ที่คุณแนะนำจะถูกกว่าการเขียนทุกอย่างใน. NET จากนั้นจึงรวมรหัสที่เขียนใหม่กับผลิตภัณฑ์อย่าลืมการรวมจะไม่เกิดขึ้นอย่างน่าอัศจรรย์หากคุณใช้. NET .

อีกสิ่งหนึ่งคือนำจำนวนบรรทัดของโค้ด PHP และใส่ลงในเครื่องมือ COCOMO 2 เพื่อรับทราบระยะเวลาและจำนวนนักพัฒนาที่คุณต้องการเพื่อให้การเขียนใหม่เสร็จสมบูรณ์


จุดดี. คุณจะทำอย่างไรถ้าไม่ได้ขึ้นอยู่กับคุณหากคุณย้ายระบบหรือไม่ คุณจะเลือกวิธีใด หรือ mybe มีวิธีอื่นในรายการที่ฉันได้ระบุไว้หรือไม่ หากผู้จัดการของคุณไม่เห็นด้วยกับคุณคุณจะพยายามพิสูจน์ว่าแนวทางของคุณดีกว่าหรือไม่?
Daniel Gruszczyk

เขียนแอปพลิเคชั่น PHP ด้วยวิธี "Service Oriented" ที่เป็นชั้น ๆ ใช้บัสบริการขององค์กรเพื่อบัฟเฟอร์ส่วนต่อประสานระหว่าง PHP และ Microsoft สิ่งสำคัญคือทำการประเมิน COCOMO ที่น่ากลัวที่จะเขียนชีวิตของผู้จัดการของคุณ
mcottle

1

คุณมีตัวเลือกที่สาม: -

โอนย้ายโค้ด php ไปยังเซิร์ฟเวอร์ windows และ ISS ของคุณ (เป็นรหัสเดียวกับที่คุณวางแผนที่จะรัน. NET บน!)

จากนั้นคุณสามารถเพิ่มแอปพลิเคชั่นใหม่ใน. NET (และแปลงแอปพลิเคชั่นที่เก่ากว่าไปเป็น. NET) อย่างช้าๆในขณะที่แสดงผู้ใช้ของคุณด้วยสิ่งที่ดูเหมือนเป็นระบบเดียว


PHP ทำงานภายใต้ IIS อย่างแน่นอน
Bart
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.