คุณวางแผนสถาปัตยกรรมของแอปพลิเคชันอย่างไรก่อนที่จะเขียนโค้ดใด ๆ [ปิด]


84

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

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

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

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

ฉันขอขอบคุณข้อมูลของคุณ

คำตอบ:


32

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


30
ตรวจสอบให้แน่ใจว่าคุณได้ใส่ "ห้ามลบ" ที่มีความปลอดภัยสูงบนไวท์บอร์ด :)
MusiGenesis

1
คุณไม่สามารถเอาชนะไวท์บอร์ดและกระดาษสำหรับการออกแบบครั้งแรกได้ ง่ายยืดหยุ่นและแสดงออก
เด็กชาย Booji

3
คุณสามารถเคลือบไวท์บอร์ดหลังการใช้งานได้ ... : P
Patrick

41

ฉันพิจารณาสิ่งต่อไปนี้:

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

จากนั้นฉันเริ่มมองระบบเป็นกล่องดำและ:

  1. อะไรคือปฏิสัมพันธ์ที่ต้องเกิดขึ้นกับกล่องดำนั้น
  2. อะไรคือพฤติกรรมที่ต้องเกิดขึ้นในกล่องดำกล่าวคือสิ่งที่ต้องเกิดขึ้นกับการโต้ตอบเหล่านั้นเพื่อให้กล่องดำแสดงพฤติกรรมที่ต้องการในระดับที่สูงขึ้นเช่นรับและประมวลผลข้อความขาเข้าจากระบบการจองอัปเดตฐานข้อมูลเป็นต้น .

จากนั้นสิ่งนี้จะเริ่มให้คุณเห็นระบบที่ประกอบด้วยกล่องดำภายในต่างๆซึ่งแต่ละกล่องสามารถแยกย่อยออกไปได้อีกในลักษณะเดียวกัน

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

  • คลาสไดอะแกรมและ
  • แผนภาพลำดับ

คุณอาจต้องใช้แผนภาพกิจกรรมเช่นกันหากมีความคล้ายคลึงกันในพฤติกรรมที่ต้องอธิบาย

แหล่งข้อมูลที่ดีสำหรับการเรียนรู้ UML คือหนังสือ "UML Distilled" ที่ยอดเยี่ยมของ Martin Fowler ( ลิงก์ Amazon - ฆ่าเชื้อสำหรับสคริปต์ตัวเล็กลิงก์นาซี (-:) หนังสือเล่มนี้จะช่วยให้คุณเห็นส่วนสำคัญของแต่ละองค์ประกอบ UML.

โอ้. สิ่งที่ฉันได้อธิบายไว้คือแนวทางของ Ivar Jacobson Jacobson เป็นหนึ่งในสาม Amigos ของ OO ในความเป็นจริง UML ได้รับการพัฒนาโดยบุคคลอีกสองคนที่รวมกันเป็น Three Amigos, Grady Booch และ Jim Rumbaugh


18

แน่นอนคุณควรดู Code Complete ของ Steve McConnell - และโดยเฉพาะอย่างยิ่งในบทแจกของเขาเรื่อง "Design in Construction"

คุณสามารถดาวน์โหลดได้จากเว็บไซต์ของเขา:

http://cc2e.com/File.ashx?cid=336


เป็นการอ่านที่ดีมาก - มีข้อมูลคำแนะนำและแนวคิดดีๆมากมาย ไม่นานเช่นกัน
Booji Boy

ซื้อหนังสือและอ่านบทที่ 6 ด้วยซึ่งเป็นเนื้อหาเกี่ยวกับการออกแบบชั้นเรียนแต่ละชั้น จากนั้นอ่านบทอื่น ๆ ทั้งหมดด้วย - เป็นทองคำบริสุทธิ์
MarkJ

โอ้ใช่ตอนที่ 4 เป็นเรื่องเกี่ยวกับสถาปัตยกรรมแอปพลิเคชัน
MarkJ

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

9

หากคุณกำลังพัฒนาสำหรับ NET ไมโครซอฟท์ได้รับการตีพิมพ์เพียง (เป็น e-book ฟรี!) เดอะ2.0b1 สถาปัตยกรรมงานคู่มือ ให้ข้อมูลที่ดีมากมายเกี่ยวกับการวางแผนสถาปัตยกรรมของคุณก่อนที่จะเขียนโค้ดใด ๆ

หากคุณหมดหวังฉันคาดหวังว่าคุณสามารถใช้ชิ้นส่วนขนาดใหญ่สำหรับสถาปัตยกรรมที่ไม่ใช่. NET


ขณะนี้มีเวอร์ชันล่าสุด ไปที่โฮมเพจเพื่อดาวน์โหลดapparchguide.codeplex.com
MarkJ

8

ฉันจะเกริ่นนำโดยบอกว่าฉันทำงานพัฒนาเว็บไซต์เป็นส่วนใหญ่โดยที่สถาปัตยกรรมส่วนใหญ่ได้รับการตัดสินใจล่วงหน้าแล้ว (WebForms ปัจจุบันคือ MVC) และโครงการส่วนใหญ่ของฉันมีขนาดเล็กพอสมควรใช้ความพยายามเพียงคนเดียวซึ่งใช้เวลาน้อยกว่าหนึ่งปี ฉันยังรู้ด้วยว่าฉันจะมี ORM และ DAL เพื่อจัดการกับออบเจ็กต์ทางธุรกิจและการโต้ตอบกับข้อมูลตามลำดับ เมื่อเร็ว ๆ นี้ฉันได้เปลี่ยนมาใช้ LINQ สำหรับสิ่งนี้ "การออกแบบ" ส่วนใหญ่จึงกลายเป็นการออกแบบฐานข้อมูลและการทำแผนที่ผ่านตัวออกแบบ DBML

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

ตอนนี้ฉันมักจะมีความคิดที่ดีเกี่ยวกับสถาปัตยกรรม ถ้ามันซับซ้อนหรือมีบิตผิดปกติ - สิ่งที่แตกต่างจากการปฏิบัติปกติของฉัน - หรือฉันกำลังทำงานกับคนอื่น (ไม่ใช่เรื่องปกติ) ฉันจะทำแผนภาพสิ่งต่างๆ (อีกครั้งบนไวท์บอร์ด) เช่นเดียวกับการโต้ตอบที่ซับซ้อน - ฉันอาจออกแบบเค้าโครงหน้าและไหลบนไวท์บอร์ดเก็บไว้ (หรือจับภาพผ่านกล้อง) จนกว่าฉันจะทำส่วนนั้นเสร็จ เมื่อฉันมีความคิดทั่วไปว่าจะไปที่ไหนและต้องทำอะไรก่อนฉันจะเริ่มเขียนแบบทดสอบสำหรับเรื่องแรก โดยปกติแล้วจะมีลักษณะดังนี้: "โอเคฉันจะต้องมีชั้นเรียนเหล่านี้ฉันจะเริ่มด้วยอันนี้และต้องทำสิ่งนี้" จากนั้นฉันก็เริ่ม TDDing อย่างสนุกสนานและสถาปัตยกรรม / การออกแบบเติบโตขึ้นจากความต้องการของแอปพลิเคชัน

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



4

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

ฉันคิดว่าการแนะนำ UML ที่ดีที่สุดยังคงเป็นUML Distilledโดย Martin Fowler เนื่องจากมีความกระชับให้คำแนะนำเชิงปฏิบัติเกี่ยวกับตำแหน่งที่จะใช้และทำให้ชัดเจนว่าคุณไม่จำเป็นต้องซื้อเรื่องราว UML / RUP ทั้งหมดเพื่อให้ จะมีประโยชน์

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

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

แต่คำแนะนำที่ดีที่สุดคืออ่านอย่างกว้างขวางคิดให้ดีและฝึกฝน ไม่ใช่ทักษะที่สอนได้อย่างหมดจดคุณต้องลงมือทำจริงๆ


4

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

โดยพื้นฐานแล้วฉันทำงานเพียงเล็กน้อยเท่าที่จะทำได้เพื่อดูว่าฉันกำลังมุ่งหน้าไปในทิศทางที่ถูกต้องหรือไม่

ฉันมองไปที่การออกแบบของฉันสำหรับคำถามที่สำคัญ: เมื่อ A ทำ B ถึง C มันจะเร็วพอสำหรับ D หรือไม่ ถ้าไม่เราต้องการการออกแบบที่แตกต่างออกไป แต่ละคำถามเหล่านี้สามารถตอบได้ด้วยการขัดขวาง ถ้าหนามแหลมดูดีแสดงว่าเรามีการออกแบบและถึงเวลาที่จะขยายมัน

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

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

เรียกว่า "Extreme Programming"


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

ฉันเห็นสิ่งที่คุณทำที่นั่น
ผูกปม

4

"กระดานไวท์บอร์ดสเก็ตช์และโน้ตโพสต์อิทเป็นเครื่องมือออกแบบที่ยอดเยี่ยมเครื่องมือสร้างแบบจำลองที่ซับซ้อนมีแนวโน้มที่จะรบกวนสมาธิมากกว่าการส่องสว่าง" จากการปฏิบัติของนักพัฒนาซอฟต์แวร์ Agile โดย Venkat Subramaniam และแอนดี้ล่า


3

ฉันไม่มั่นใจว่าอะไรทำได้วางแผนล่วงหน้าก่อนนำไปใช้ ฉันมีประสบการณ์ 10 ปี แต่มีเพียง 4 บริษัท เท่านั้น (รวมถึง 2 ไซต์ใน บริษัท เดียวซึ่งเกือบจะตรงกันข้าม) และประสบการณ์เกือบทั้งหมดของฉันอยู่ในแง่ของการดูคลัสเตอร์ขนาดมหึมา ****** ** s เกิดขึ้น ฉันเริ่มคิดว่าสิ่งต่างๆเช่นการปรับโครงสร้างใหม่เป็นวิธีที่ดีที่สุดในการทำสิ่งต่างๆ แต่ในขณะเดียวกันฉันก็ตระหนักดีว่าประสบการณ์ของฉันมี จำกัด และฉันอาจจะมีปฏิกิริยากับสิ่งที่ฉันเห็น สิ่งที่ฉันอยากรู้จริงๆคือทำอย่างไรจึงจะได้รับประสบการณ์ที่ดีที่สุดเพื่อที่ฉันจะได้ข้อสรุปที่เหมาะสม แต่ดูเหมือนว่าจะไม่มีทางลัดและต้องใช้เวลามากในการเห็นคนทำสิ่งที่ไม่ถูกต้อง :( ฉัน ชอบที่จะไปทำงานใน บริษัท ที่ผู้คนทำในสิ่งที่ถูกต้อง (ตามหลักฐานจากการปรับใช้ผลิตภัณฑ์ที่ประสบความสำเร็จ)


2

ฉันขอแตกต่าง: UML สามารถใช้สำหรับสถาปัตยกรรมแอปพลิเคชัน แต่มักใช้สำหรับสถาปัตยกรรมทางเทคนิค (เฟรมเวิร์กคลาสหรือไดอะแกรมลำดับ ... ) เนื่องจากนี่คือที่ที่ไดอะแกรมเหล่านั้นสามารถซิงค์กับการพัฒนาได้ง่ายที่สุด .

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

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

ดังนั้นหากคุณต้องการประมวลผลพอร์ตการลงทุนทางการเงินขนาดใหญ่หลาย ๆ พอร์ต (ข้อกำหนดการทำงาน) คุณอาจกำหนดได้ว่าคุณต้องแบ่งข้อกำหนดขนาดใหญ่นั้นออกเป็น:

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

โดยพื้นฐานแล้วการคิดเกี่ยวกับสถาปัตยกรรมแอปพลิเคชันคือการตัดสินใจว่า "กลุ่มไฟล์" ใดที่คุณต้องพัฒนาในลักษณะที่สอดคล้องกัน (คุณไม่สามารถพัฒนาในไฟล์กลุ่มเดียวกับตัวเรียกใช้งาน, GUI, ผู้มอบหมายงาน, ... : พวกเขา จะไม่สามารถพัฒนาไปในจังหวะเดียวกันได้)

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


2

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


1

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

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

โมเดลโดเมนเหล่านี้สามารถแสดงเป็นโมเดลโดเมน UML, คลาสไดอะแกรมและ SQL ERD

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

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


1

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

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

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


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