โซลูชันซอฟต์แวร์จากปี 2000 ฉันควรพยายามแก้ไขหรือสร้างสิ่งใหม่ทั้งหมดหรือไม่

9

ฉันถูกส่งออกไปเพื่อหารือเกี่ยวกับระบบที่ บริษัท หนึ่งกำลังใช้งานอยู่และสิ่งที่ควรทำกับ บริษัท

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

ข้อมูลบางอย่างเกี่ยวกับระบบ

มันได้รับการพัฒนาประมาณปี 2000
ระบบขนาดเล็กพอสมควรผู้ใช้ 2-5 คน 6 รูปแบบ ~ 8 ตารางพร้อมปริมาณข้อมูลโดยเฉลี่ย
สร้างขึ้นใน Visual Basic รุ่นแรกสร้างด้วยการลากและวาง อินเตอร์เฟสนั้นเป็นเพียงหน้าต่างที่มีเมนูและบางรูปแบบ
ใช้ฐานข้อมูล MSSQL (เซิร์ฟเวอร์ SQL2005) เพื่อเก็บข้อมูลและโปรแกรมควบคุม ODBC เพื่อทำการสืบค้นข้อมูลถูกย้ายจาก excel ก่อนระบบนี้และก่อนที่ excel จะถูกจัดการคำนวณและเขียนด้วยมือและกระดาษ
ผู้ใช้ทำงานในสภาพแวดล้อม Microsoft XP (และสูงกว่า)

ปัญหาหลักของพวกเขาคือพวกเขาไม่สามารถปรับและคำนวณราคาไม่สามารถเพิ่มประเภทกล่องใหม่ ฯลฯ อย่างถูกต้องอีกต่อไปเพราะพวกเขาไม่สามารถ (หรือมากกว่าพวกเขาไม่รู้วิธีการ) สัมผัสข้อมูลบนเซิร์ฟเวอร์

ฉันแนะนำ 3 วิธีแก้ปัญหาที่เป็นไปได้

พยายามแก้ไขระบบปัจจุบัน
สร้างอินเทอร์เฟซใหม่สด (โดยเฉพาะอย่างยิ่งสภาพแวดล้อมที่คล้ายกัน VB.net หรือ VB)
นำกลับไปใช้โซลูชัน Excel เนื่องจากเป็นระบบขนาดเล็กเช่นนี้

อาจมีตัวเลือกเพิ่มเติม แต่ตัวเลือกเหล่านี้เป็นสิ่งที่ฉันคิดได้

คำถามของฉันคือ

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

— ShadowScripter
แหล่งที่มา

3

คุณไม่สามารถตัดสินใจได้ว่าระบบปัจจุบันจะเสียอย่างรุนแรงเพียงใดจนกว่าคุณจะได้จัดทำเอกสารสกีมาฐานข้อมูล

@ ThorbjørnRavnAndersenนั่นเป็นเรื่องจริง ฉันมองที่ฐานข้อมูลเท่านั้น ตัดสินจากยุคที่มันถูกสร้างขึ้นฉันจะสมมติว่ามันถูกออกแบบมาอย่างน่ากลัวจริงๆและต้องการการปฐมพยาบาล ... หรือการผ่าตัด

— ShadowScripter

1

คุณรู้หรือเปล่าว่าใครเป็นคนเขียนระบบดั้งเดิมขึ้นมา? มันเป็นความพยายามในบ้านหรือมันถูกทำสัญญาออกมา?

— maple_shaft

7

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

4

นักพัฒนาต้องการเริ่มต้นที่ "เขียนใหม่ตั้งแต่ต้น" และ refactor เมื่อจำเป็นเท่านั้น ฉันควรเริ่มต้นที่ "refactor ค่อยๆ" และเขียนใหม่เมื่อจำเป็นเท่านั้น

— quant_dev

5

บางสิ่งที่มีเพียง 6 รูปแบบและควร สร้างใหม่ในกรอบงานที่ทันสมัยยิ่งขึ้น ฉันได้ทำงานกับการโยกย้ายโครงการ VB6 ที่มีประมาณ 200 รูปแบบพร้อมกับคลาสและตารางฐานข้อมูลอีกมากมาย ดูเหมือนว่าคุณกำลังมองหาสิ่งที่ยุ่งเหยิง แต่ภาพลักษณ์นั้นอาจหลอกลวงได้

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

— jfrankcarr
แหล่งที่มา

ด้วยขนาดที่เล็กของมันฉันเห็นด้วย ภาพรวมดูเหมือนจะไม่ซับซ้อนเกินไป ตัดสินจากคำตอบที่เขียนได้ดูเหมือนเหมาะสมที่สุด ฉันจะตรวจสอบอย่างละเอียดก่อนตัดสินใจขั้นสุดท้าย ขอบคุณสำหรับคำแนะนำ! :)

— ShadowScripter

@ShadowScripter ฉันจะดูการเขียนเป็นภาษาที่ดีกว่า VB ในขณะที่คุณอยู่ที่นั้น ตรวจสอบแหล่งที่มาเปิดลาซารัสโครงการ

— Spencer Rathbun

5

ฉันมีคำแนะนำที่แตกต่างกันเล็กน้อยถึงคำตอบส่วนใหญ่

พยายามแก้ไขระบบปัจจุบัน

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

สร้างอินเทอร์เฟซใหม่สด (โดยเฉพาะอย่างยิ่งสภาพแวดล้อมที่คล้ายกัน VB.net หรือ VB)

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

ข้อกังวลอีกประการคือวิธีการสื่อสารกับฐานข้อมูล Microsoft กำลังค่อยๆกำจัดวิธีเก่า ๆ ในการสื่อสารกับผลิตภัณฑ์ฐานข้อมูล (Access, MSSQL) อย่างช้าๆดังนั้นวิธีที่คุณโต้ตอบกับผลิตภัณฑ์เหล่านั้นจะเป็นตัวกำหนดว่าจะสามารถใช้โซลูชันบน Windows 9 และ Windows 10 ได้หรือไม่ในอนาคต

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

ฉันไม่รู้สึกว่ามีสิ่งใด "ผิดปกติ" กับแอปพลิเคชัน Visual Basic 6 นอกเหนือจากความจริงแล้วยังไม่ทราบการรองรับสำหรับเวอร์ชันในอนาคต แม้กระทั่งทุกวันนี้ด้วยระบบปฏิบัติการ Windows 7 และ 64 บิตการสนับสนุนและการสนับสนุนก็ยากขึ้นเรื่อย ๆ นี่คือเหตุผลสำคัญที่การเขียนเป็นภาษาสมัยใหม่ด้วยการสนับสนุน 64- บิตที่เหมาะสมอาจเป็นความคิดที่ดี

หากพวกเขาไม่มีแหล่งที่มา ณ จุดนั้นการเขียนซ้ำเป็นคำตอบเดียวของพวกเขา

— Ramhound
แหล่งที่มา

คุณสามารถอ้างอิงการอ้างอิงถึง " Microsoft is slowly getting rid of some of the older ways to communicate..." ได้ไหม ต้องการอ่านเพิ่มเติมเกี่ยวกับเรื่องนี้

— ShadowScripter

@ShadowScripter - ตัวอย่างเช่นผู้ให้บริการ Microsoft.Jet.OLEDB.4.0 เพื่อเข้าถึงไฟล์ฐานข้อมูลการเข้าถึงแบบดั้งเดิมไม่ได้รับการสนับสนุนเมื่อกระบวนการไม่ใช่กระบวนการแบบ 32 บิต WinRT อาจเปลี่ยนวิธีที่เราเชื่อมต่อกับผลิตภัณฑ์เหล่านี้ของ Microsoft ฉันลืมตำแหน่งที่ฉันอ่านเกี่ยวกับการเปลี่ยนแปลงในอนาคตความเข้าใจของฉันคือหลังจาก MSSQL 2012 Microsoft จะสนับสนุนเฉพาะวิธีการเชื่อมต่อที่เฉพาะเจาะจงเท่านั้น หลักสูตรนี้ในบริบทของผู้ให้บริการที่ติดตั้งใน Windows และข้อเสนอการพัฒนา

— Ramhound

1

การเขียนอินเตอร์เฟสใหม่เป็นตัวเลือกที่ยอดเยี่ยมเนื่องจากระบบมีขนาดค่อนข้างเล็ก ข้อดีคือ -

ปรับปรุงเสถียรภาพ (สมมติว่าคุณทำได้ดี!)
ปรับปรุงการบำรุงรักษา
อินเตอร์เฟซที่ทันสมัย

ข้อเสียเปรียบหลักคือมันอาจจะยังมีค่าใช้จ่ายที่ค่อนข้างยุติธรรมมากกว่าแฮ็คโค้ดที่มีอยู่

— Craig Schwarze
แหล่งที่มา

การเขียนอินเทอร์เฟซใหม่เป็นสิ่งที่ฉันได้เรียนรู้เช่นกัน และตามจริงแล้วฉันไม่แน่ใจว่าฉันจะเริ่มต้นที่ส่วนติดต่อเก่าโดยพิจารณาจากมาตรฐานของวันนี้เป็นอย่างไร ... แย่ไปหมด

— ShadowScripter

1

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

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

รวบรวมความต้องการ
ทำความเข้าใจกับระบบปัจจุบัน
มาพร้อมกับสกีมาฐานข้อมูลที่มีความหมายว่าพวกเขาตั้งใจจะใช้ซอฟต์แวร์อย่างไร

โครงการนี้ประสบความสำเร็จทางการเงินไม่ประสบความสำเร็จ!

— ZweiBlumen
แหล่งที่มา

ฉันได้ยินสิ่งที่คุณพูดก่อนที่จะตัดสินใจขั้นสุดท้ายฉันต้องรู้ทันถึงความล้มเหลวหน้าที่และวัตถุประสงค์ในปัจจุบัน มันไม่เหมือนที่ฉันต้องการเข้าไปข้างในพร้อมกับปืนที่จ้องมองกรีดร้องAll right, let's do this. LEEEEEEEROOOOOOOY...! : P

— ShadowScripter

0

ตัวเลือกอื่นอาจเป็นการประนีประนอมระหว่างการเขียนสิ่งใหม่ทั้งหมดและการแฮ็กแอปที่มีอยู่

มอบฟังก์ชั่นใหม่ในแอพพลิเคชั่นใหม่ให้พวกเขา

สิ่งนี้สามารถทำได้ง่ายกว่าและไม่เสียค่าใช้จ่ายเท่าการเขียนซ้ำทั้งหมด

เมื่อดำเนินการเสร็จแล้วและพวกเขามีความสุขที่พวกเขาสามารถเพิ่ม / อัปเดตข้อมูลมันเปิด doot ro เฟสสองอาจแทนที่ funcationality ที่มีอยู่ในแอปใหม่

นี่อาจเป็นวิธีที่น่าพอใจมากกว่า

— Ozz
แหล่งที่มา

1

ฉันคิดว่ามันเป็นความคิดที่ดี แต่ถ้าเฟสที่สองไม่เคยเกิดขึ้นพวกเขาจะจบลงด้วยแอปพลิเคชันแยกเก่าที่ขึ้นอยู่กับแอปพลิเคชันใหม่อื่น ๆ ปล่อยให้พวกเขามีสองแอปพลิเคชัน

— ShadowScripter

0

การเขียนซ้ำมักจะมีแนวโน้มที่จะใช้งบประมาณไม่เพียงพอ ...

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

นอกจากนี้ VB6 ไม่ดีสำหรับการสนับสนุน เมื่อคุณต้องการค้นหาผู้เชี่ยวชาญใน 10 ปีนั่นจะเป็นปัญหามาก

— coder
แหล่งที่มา