ฉันได้อ่านสิ่งต่างๆ มากมายบนอินเทอร์เน็ต เป็นเรื่องยากมากที่จะค้นหาอะไรเกี่ยวกับสถาปัตยกรรมซอฟต์แวร์ Java อย่างไรก็ตาม สถาปัตยกรรมของการพัฒนาซอฟต์แวร์โดยพื้นฐานแล้วจะเหมือนกัน ดังนั้นฉันจึงค้นหาบทความมากมายเกี่ยวกับสถาปัตยกรรมซอฟต์แวร์ในภาษาอื่น ๆ บนอินเทอร์เน็ต อีกครั้ง ให้ฉันพูดถึงมุมมองของฉันเกี่ยวกับสถาปัตยกรรมซอฟต์แวร์ โดยเฉพาะสถาปัตยกรรมโครงการ JAVA นั่นอาจจะไม่ถูกต้อง แต่นี่เป็นบทสรุปของฉันในช่วงไม่กี่ปีที่ผ่านมาด้วย
1. พยายามอย่าพิจารณาใช้ซ้ำนอกโครงการ
หลายๆ คนคิดว่าการปรับปรุงการนำซอฟต์แวร์กลับมาใช้ใหม่ได้ดีที่สุด อย่างไรก็ตาม สถานการณ์จริงของแต่ละโครงการจะแตกต่างกัน เมื่อออกแบบโมดูลหรือวิธีการบางอย่างในโครงการ การพิจารณานำกลับมาใช้ใหม่มากเกินไปนอกโครงการจะทำให้จำนวนเพิ่มขึ้นอย่างหลีกเลี่ยงไม่ได้ ของโครงการ ความซับซ้อนทำให้ค่าใช้จ่ายในการพัฒนาเพิ่มขึ้น บางคนอาจจะบอกว่านี่จะช่วยลดต้นทุนของโปรเจ็กต์ต่อไปได้หรือเปล่า? มีความต้องการอะไรบ้าง? ปัจจัยที่มีอิทธิพลในด้านต่างๆ มีอะไรบ้าง? ใครจะรู้ทั้งหมดนี้ในเวลานี้ หากคุณต้องการนำกลับมาใช้ใหม่จริงๆ คุณควรแยกชิ้นส่วนที่ใช้ซ้ำได้หลังจากโครงการเสร็จสิ้น แก้ไขและเพิ่มประสิทธิภาพ และใช้เป็นสินทรัพย์ที่นำกลับมาใช้ใหม่ได้ขององค์กร แทนที่จะคิดเพ้อฝันในโครงการปัจจุบัน พิจารณาการนำกลับมาใช้ใหม่ได้นอกโครงการ นี่เป็นข้อผิดพลาดทั่วไปที่ทำโดยโปรแกรมเมอร์จำนวนมากที่เพิ่งเริ่มใช้งานซอฟต์แวร์ บ่อยครั้ง ยิ่งพวกเขาคิดมากเท่าไร ซอฟต์แวร์ที่พวกเขาสร้างก็ยิ่งล้มเหลวในการบรรลุผลการออกแบบและล้มเหลวในการทำหน้าที่พื้นฐานหรือ กระบวนการโค้ดลอจิก หลายๆ ฟังก์ชั่นของโปรแกรมไม่สมบูรณ์และอื่นๆ
2. ตรวจสอบโครงสร้างโครงการบ่อยๆ
สถาปัตยกรรมโครงการมักจะเป็นสิ่งที่ถูกกำหนดก่อนที่การดำเนินโครงการจะเริ่มต้นและเป็นการออกแบบโดยรวม อย่างไรก็ตาม ในขณะนี้ ความเข้าใจในข้อกำหนดของโครงการและการประมาณความซับซ้อนยังอยู่ในขั้นเริ่มต้น หากไม่สามารถปรับปรุงสถาปัตยกรรมควบคู่ไปกับความเข้าใจในโครงการในระหว่างกระบวนการพัฒนาโครงการ สมาชิกของโครงการก็จะพัฒนาโครงการตามสถาปัตยกรรมที่ไม่ถูกต้องอย่างหลีกเลี่ยงไม่ได้ ดังนั้นจึงต้องตรวจสอบสถาปัตยกรรมโครงการบ่อยครั้งและต้องทำการปรับโครงสร้างใหม่ที่จำเป็น
3. การปรับโครงสร้างใหม่
บางคนบอกว่าเขียนเยอะแล้วแก้ไขก็ไม่เสียเวลา เขาอาจไม่คิดว่าบ่ายวันหนึ่งของการปรับโครงสร้างใหม่จะสามารถเร่งการพัฒนาในอีกไม่กี่เดือนข้างหน้าได้ นอกจากนี้ การปรับโครงสร้างใหม่ทำให้คุณนึกถึงวิธีการง่ายๆ มากขึ้นเพื่อทดแทนการใช้งานที่มีอยู่ได้ ประสบการณ์นี้ยังทำให้การพัฒนาโมดูลอื่นๆ ง่ายขึ้นอีกด้วย
4. หลีกเลี่ยงการบูรณาการมากเกินไป และปล่อยให้แต่ละโมดูลทำหน้าที่ของตัวเองเท่านั้น
ตัวอย่างการพัฒนา OA ทั่วไปคือ โดยปกติจะมีการอนุมัติมากมายในระบบธุรกิจ และหลายๆ คนจะนึกถึงการอนุมัติเป็นโมดูลสากลทันที ไม่มีปัญหาในเรื่องนี้ แต่ปัญหาปกติคือมีคนจำนวนมากเกินไปที่ใส่การประมวลผลทางธุรกิจหลังจากการอนุมัติลงในตรรกะทางธุรกิจของโมดูลการอนุมัติ ที่จริงแล้ว สิ่งเหล่านี้คือโมดูลธุรกิจของแต่ละโมดูลธุรกิจ และการอนุมัติควรทำเท่านั้น จะแล้วเสร็จเมื่อการอนุมัติเสร็จสิ้น อย่างไรก็ตาม สำหรับสิ่งที่ต้องทำหลังจากการอนุมัติเสร็จสิ้น ให้โมดูลที่ทำกระบวนการนี้จัดการเอง
5. หลีกเลี่ยงการยืดหยุ่นจนเกินไป
การออกแบบและโค้ดไม่ได้ยืดหยุ่นเท่าที่จะเป็นไปได้เสมอไป ตัวอย่างทั่วไปคือ เมื่อใช้งานทั่วไป คลาสหรือเมธอดสามารถดำเนินการกับอ็อบเจ็กต์ที่แตกต่างกันได้ อย่างไรก็ตาม ในสถาปัตยกรรมสามระดับที่ใช้กันทั่วไปใน JAVA หากเดิมทีชุดของคลาสมีจุดประสงค์เพื่อดำเนินการกับเอนทิตีเฉพาะ ก็ไม่จำเป็น เพื่อระบุว่าเป็นประเภททั่วไป จากนั้นระบุเพื่อใช้คลาสเอนทิตีเฉพาะเมื่อใช้งาน รู้สึกเหมือนฟุ่มเฟือย
6.ลดไอซิ่งบนตัวเค้ก
ไม่มีการรีเฟรชหน้า เอฟเฟกต์การแสดงผลที่เย็นกว่า ฯลฯ ล้วนแต่เป็นอุปสรรคต่อระบบธุรกิจ หากอินเทอร์เฟซทางธุรกิจมีความซับซ้อนมากด้วยเหตุนี้ ก็จะนำปัญหามาสู่การประมวลผลทางธุรกิจในกรณีร้ายแรง การประมวลผลทางธุรกิจไม่สามารถทำได้ ไม่ว่าอินเทอร์เฟซจะสวยงามแค่ไหน มันก็ไร้ประโยชน์เมื่อคุณดำเนินการต่อ เมื่อพูดถึงคำแนะนำชิ้นเดียว ให้พิจารณาคำแนะนำอื่นๆ หากคุณต้องการให้แน่ใจว่ากระบวนการทางธุรกิจดำเนินไปอย่างถูกต้อง ข้อกำหนดเบื้องต้นสำหรับสิ่งนี้คือการสื่อสารกับผู้ใช้ที่จำเป็น กล่าวอีกนัยหนึ่ง โครงการที่ดำเนินการโดย JAVA มุ่งเน้นไปที่การประมวลผลทางธุรกิจ เฉพาะเมื่อการประมวลผลทางธุรกิจได้รับการยอมรับอย่างดีเท่านั้นจึงจะสามารถนำมาพิจารณาถึงความสวยงามของอินเทอร์เฟซและการมองเห็นของผู้ใช้ได้
7. แบ่งส่วนอย่างเหมาะสม
นี่ก็คล้ายกับคห.4 พยายามลดความซับซ้อนของแต่ละโมดูลให้มากที่สุดและเปลี่ยนงานทางจิตให้เป็นงานทางกายภาพ ตัวอย่างทั่วไปคือแบบฟอร์มมักจะมีฟังก์ชันในการเพิ่ม แก้ไข ลบ และดู อย่างไรก็ตาม การดำเนินการสามรายการแรกมักดำเนินการโดยบุคคลที่จุดฟังก์ชันเฉพาะ ในสถานะเฉพาะ และมีสิทธิ์เฉพาะ (บางทีอาจเป็นเฉพาะในอินเทอร์เฟซเดียวในระบบเท่านั้น) อย่างไรก็ตาม การดำเนินการดูจะกระจายไปในทุกมุมของโปรเจ็กต์ หากการดำเนินการทั้งสี่นี้ถูกวางไว้ในอินเทอร์เฟซเดียวกัน แม้ว่าจำนวนอินเทอร์เฟซจะลดลง แต่ความซับซ้อนของอินเทอร์เฟซนี้จะต้องเพิ่มขึ้น ประมวลผลแล้ว ตัดสินที่จำเป็นเพื่อทำการตั้งค่าแบบอ่านอย่างเดียวสำหรับองค์ประกอบอินเทอร์เฟซ ความซับซ้อนที่เพิ่มขึ้นจะเป็นแบบทวีคูณ และหากคุณแยกมุมมอง ปริมาณงานจะเป็นแบบเส้นตรง แม้ว่าคุณจะต้องทำ 10 มุมมองอินเทอร์เฟซก็ตาม สูงกว่าครั้งก่อน มันง่ายกว่ามากที่จะจัดการกับการแปลงเป็น 10*10 และยังสามารถแยกส่วนประกอบได้อีกด้วย
8. รักษาการสื่อสารที่ดีกับลูกค้า
หลายคนไม่ใส่ใจกับการรักษาการสื่อสารกับลูกค้า สถาปนิกหลายคนเชื่อว่าการสื่อสารและการสื่อสารกับลูกค้าเป็นสิ่งจำเป็นเฉพาะในช่วงอุปสงค์ของโครงการเท่านั้น นี่เป็นนิสัยที่ไม่ดีมาก เนื่องจากความต้องการของลูกค้าจะเปลี่ยนแปลงไปตามกาลเวลา ในสภาพแวดล้อมด้วยการรักษาการสื่อสารที่ดีกับลูกค้าเป็นประจำเท่านั้นที่เราจะสามารถเข้าใจการเปลี่ยนแปลงความต้องการของลูกค้าโดยเร็วที่สุด ด้วยเหตุนี้จึงปรับแผนโครงสร้างโครงการของเราให้ตรงตามความต้องการของลูกค้าในเวลาที่สั้นที่สุด
9. การเชื่อมต่อระหว่างสถาปัตยกรรมโครงการและสถาปัตยกรรมฐานข้อมูล
หลายคนเชื่อว่าฐานข้อมูลไม่จำเป็นในระหว่างการพัฒนาโครงการ ตราบใดที่ฐานข้อมูลนั้นถูกนำไปใช้ในหน่วยความจำ โดยส่วนตัวแล้วฉันคิดว่านี่เป็นนิสัยการพัฒนาที่แย่มาก แม้ว่าฐานข้อมูลจะถูกกำหนดตามความต้องการเฉพาะของโครงการก็ตาม อย่างไรก็ตาม หากโครงการไม่คำนึงถึงสถาปัตยกรรมฐานข้อมูลเลยในระหว่างกระบวนการสถาปัตยกรรม ก็มีแนวโน้มว่าสิ่งที่นำไปใช้ในโครงการจะบันทึกลงในฐานข้อมูลได้ยาก หรือการออกแบบฐานข้อมูลจะยุ่งยากมาก ซึ่งแทบจะเพิ่ม ความยากในการพัฒนาโครงการ นอกจากนี้ การไม่พิจารณาฐานข้อมูลในระหว่างกระบวนการพัฒนาโครงการอาจทำให้เกิดปัญหา เช่น ความล้มเหลวในการใช้ตรรกะทางธุรกิจบางอย่าง ข้อมูลสูญหาย เป็นต้น หลังจากที่โครงการเชื่อมโยงกับฐานข้อมูลแล้ว
แน่นอนว่าหลายคนมีความคิดเห็นทางสถาปัตยกรรมที่แตกต่างกันไปตามรูปแบบสถาปัตยกรรมที่แตกต่างกัน และความคิดเห็นของฉันอาจไม่ถูกต้อง ฉันหวังว่าทุกคนจะได้เรียนรู้บางอย่างจากสิ่งที่ฉันทำ และฉันก็หวังว่าทุกคนจะสามารถแบ่งปันมุมมองเกี่ยวกับสถาปัตยกรรมได้ด้วย