ความแตกต่างระหว่างต้นแบบและโซลูชันระดับการผลิตคืออะไร

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

ฉันสร้างโซลูชันสาธิตจำนวนมากใน. Net ในอดีต ตอนนี้ฉันได้รับมอบหมายให้สถาปนิกและใช้โซลูชันเว็บระดับการผลิตดังนั้นฉันต้องการถาม - ในระดับสูงมากสิ่งที่ต้องใช้ในการแปลงตัวอย่างเป็นโซลูชันระดับการผลิต จากความเข้าใจของฉันสิ่งนี้จะต้องใช้ (นอกเหนือจากการใช้งานตามความต้องการของลูกค้า):

1. หน่วยทดสอบทุกวิธี
2. มั่นใจได้ว่าครอบคลุมรหัสได้ 100%
3. การบันทึกข้อยกเว้นและปุ่มลัดที่เป็นไปได้ทั้งหมด - ทำได้ด้วย AOP
4. ใช้รูปแบบการออกแบบส่วนต่อประสานการพึ่งพาซึ่งอาจเป็นไปได้โดยใช้เฟรมเวิร์กเช่น spring.net
5. การใช้เคาน์เตอร์วัดประสิทธิภาพและโปรไฟล์สำหรับเครื่องมือวัด
6. ใช้การรักษาความปลอดภัยที่เหมาะสม - เช่นการตรวจสอบ windows (ถ้านั่นคือสิ่งที่ลูกค้าต้องการ)
7. การจัดการธุรกรรมในทุก ๆ วิธี
8. สำรองข้อมูลไฟล์เว็บแอ็พพลิเคชันก่อนการปรับใช้โซลูชันใหม่

มีอะไรอีกบ้าง?

คำถามของฉันเกี่ยวข้องกับด้านเทคนิคมากกว่าการใช้งาน / เอกสารเพราะมิฉะนั้นเราจะเข้าไปอีกเส้นทาง :-)

ขอบคุณ.

ฉันคิดว่าความแตกต่างที่สำคัญที่สุดคือจุดประสงค์ของต้นแบบคือ:
1. เพื่อพิสูจน์ว่าปัญหาสามารถแก้ไขได้ด้วยวิธีใดวิธีหนึ่งหรือ
2. ให้ลูกค้า / ผู้บริหารรู้สึกถึงผลิตภัณฑ์ที่มีลักษณะและความรู้สึก

ในขณะที่วัตถุประสงค์ของระบบสดคือ:
1. เพื่อแก้ปัญหา / แก้ไขปัญหาบางอย่าง

แจ้งให้ทราบว่าวัตถุประสงค์ของทั้งสองมีความแตกต่างอย่างสิ้นเชิง
ดังนั้นในความคิดของฉันต้นแบบควรถูกโยนทิ้งก่อนที่จะพัฒนาระบบจริง

นี่ก็เป็นเพราะต้นแบบมักจะเป็นโครงการที่ 'รวดเร็วและสกปรก' โดยที่คุณไม่ต้องคำนึงถึงข้อสงสัยของคุณ (เช่นการทดสอบประสิทธิภาพความปลอดภัยและอื่น ๆ อีกมากมาย)
ดังนั้นคุณควรเริ่มต้นโครงการใหม่ที่เหมาะสมดีกว่าพยายามสร้างโครงการที่ไม่ดีขึ้น

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

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

การใช้เคาน์เตอร์วัดประสิทธิภาพและโปรไฟล์สำหรับเครื่องมือวัด .. อาจเหมาะสม แต่อาจมีค่าใช้จ่ายมากเกินไป อาจไม่จำเป็น

สิ่งที่คุณหายไปที่นี่ไม่สามารถอธิบายถึงบริบทขอบเขตและข้อกำหนดทางธุรกิจของโครงการได้

ตามบริบทและขอบเขตที่ฉันหมายถึง - คุณกำลังสร้างบางสิ่งบางอย่างที่จะใช้ภายในโดยธุรกิจ? ลูกค้าหัน? ใช้โดยผู้ใช้ปลายทางหรือไม่ อันที่จริงแล้วมันเป็น Notepad รุ่นที่ทันสมัยหรือ RDBMS ใหม่ตั้งแต่ต้น? สิ่งที่ควรรวมไว้จะแตกต่างกันมาก (อย่างหนาแน่น!) โดยโครงการที่คุณกำลังดู

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

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

ที่น่าสนใจฉันคิดว่าควรทำคะแนน 1, 2, 4 และ 7 ในระหว่างการคิดต้นแบบของคุณยกเว้นว่าฉันไม่คิดว่าคุณควรทดสอบทุกวิธีในทุกชั้นเรียน ทดสอบรหัสที่สำคัญไม่ว่าจะเป็นวิธีการรับ / ตั้งค่าอย่างถูกต้อง

จุดประสงค์ของการรักษาความปลอดภัยเป็นปัญหาใหญ่ขึ้นอยู่กับวัตถุประสงค์ของแอปพลิเคชันของคุณจุดที่ 6 อาจสำคัญพอที่คุณจะต้องทำให้สำเร็จในต้นแบบ ขึ้นอยู่กับวัตถุประสงค์ของแอปพลิเคชันของคุณซึ่งประสิทธิภาพเป็นกุญแจสำคัญจุดที่ 5 อาจสำคัญ ... คุณรู้ว่าฉันหมายถึงอะไร ความคิดเห็นของฉันคือคะแนน 3, 5 และ 6 อาจจำเป็นในต้นแบบหากถือว่าสำคัญ (จุด 8 นั้นใช้ได้จริงสำหรับแอปพลิเคชันการผลิต)

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

นอกจากสิ่งที่ถูกกล่าวถึงแล้วในโครงการผลิตคุณต้องมีสิ่งต่อไปนี้ (รวมถึงอื่น ๆ ):

0- เลือกวิธีการใช้งาน

1- จบและเผยแพร่ข้อกำหนดที่สำคัญ (รวมถึงกรณีการใช้งาน ฯลฯ )

2- รับสถาปัตยกรรมที่ถูกต้อง

3- เลือกเครื่องมือที่ถูกต้อง

ฐานข้อมูล 4-Design เพื่อประสิทธิภาพ

5- ผลิตการออกแบบคลาสและการออกแบบเวิร์กโฟลว์ของคุณ

6- กำหนดและใช้กลยุทธ์เพื่อรวมฐานข้อมูล / แหล่งข้อมูล / ฟีดที่สำรองข้อมูลไว้

7-Define and Implement ข้อกำหนดด้านความปลอดภัย

8-Arrange สำหรับการนำไปใช้งานจริง (เซิร์ฟเวอร์, การเชื่อมต่อ, ไลเซนส์ ฯลฯ )

9-Plan สำหรับข้อกำหนดของหน่วยเก็บและกำหนดมาตรการด้านประสิทธิภาพ

10- ผลิตสิ่งประดิษฐ์ทั้งหมดและติดตั้งในสภาพแวดล้อมการผลิต

11-Test

12-Deliver ทางออกสุดท้ายและนำความคิดเห็นกลับมาใช้

คุณลักษณะที่สำคัญที่สุดของการแก้ปัญหาคุณภาพการผลิตเป็น - ในความคิดของฉัน - ทนทาน

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

ต้นแบบมีสองชนิด:

• แอปพลิเคชั่น "พิสูจน์แนวคิด" อย่างรวดเร็วและสกปรกที่ "ล้างข้อมูล" และกลายเป็นรหัสการผลิต ขั้นตอน "ทำความสะอาด" มีแนวโน้มที่จะเป็นฝันร้ายหรือเป็น "การกวาดปัญหาใต้พรม" ซึ่งส่งผลให้เกิดหนี้สินทางเทคนิคจำนวนมาก

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

ฉันชอบแบบที่สอง พวกเขาถูกโยนออกไปเพราะไม่มีทางเลือกจริงๆ

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

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

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