ฉันเพิ่งจบการศึกษาจากมหาวิทยาลัยและเริ่มทำงานเป็นโปรแกรมเมอร์ ฉันไม่พบว่ามันยากที่จะแก้ปัญหา "ทางเทคนิค" หรือทำการดีบั๊กกับสิ่งที่ฉันจะบอกว่ามีวิธีแก้ปัญหา 1 ข้อ

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

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

ฉันจะผ่านช่วงสถาปัตยกรรมได้เร็วขึ้นและเข้าสู่ช่วงการเข้ารหัสและการดีบักที่ฉันชอบได้อย่างไร

สมบูรณ์แบบเป็นศัตรูของความดี

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

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

(และหวังว่ามันจะช่วยได้เมื่อคุณค้นพบว่าไม่มีทางเดียวที่จะแก้ปัญหา / แก้ปัญหาด้านเทคนิค)

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

ฉันจะแบ่งตรรกะนี้ออกเป็น 1 หรือ 2 ชั้นฉันจะตั้งชื่อชั้นเรียนได้อย่างไรฉันควรทำให้เป็นส่วนตัวหรือสาธารณะเป็นต้นคำถามประเภทนี้ใช้เวลานานมาก

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

เปรียบเทียบสิ่งนี้กับโครงการซอฟต์แวร์ฟรีมากมาย(แม้แต่โครงการใหญ่เช่น Linux kernel) นักพัฒนาไม่ได้ใช้ความพยายามอย่างมากในการ "สร้าง" ในระยะแรก UML เกือบจะไม่เคยใช้ในซอฟต์แวร์ฟรี นอกจากนี้คุณจะได้เรียนรู้เล็กน้อยโดยศึกษาซอร์สโค้ดของโครงการซอฟต์แวร์ฟรีหลายโครงการ

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

ฉันจะผ่านช่วงสถาปัตยกรรมได้เร็วขึ้นและเข้าสู่ช่วงการเข้ารหัสและการดีบักที่ฉันสนุกได้อย่างไร

สำหรับโครงการซอฟต์แวร์ขนาดเล็กซึ่งใช้เวลาน้อยกว่าหนึ่งปีในการทำงานง่ายมาก: อย่าทำสถาปัตยกรรม ใช้เวลาครึ่งชั่วโมงในการออกแบบโดยรวม แล้วเริ่มเขียนโค้ดด้วยซ้ำและการพัฒนาที่เพิ่มขึ้นวิธีการ: เขียนไม่กี่บรรทัดโหลรวบรวมมัน (กับทุกคำเตือนและการแก้ปัญหาข้อมูลเปิดการใช้งานเช่นg++ -Wall -Wextra -gกับGCCสำหรับ C ++) จนกว่าคุณจะไม่ได้รับการเตือน (และผ่านมันไปในแหล่งที่มาคงที่บางอย่างง่าย ตัววิเคราะห์รหัสหากคุณมีตัวอย่างเช่นclang-analyserให้ทดสอบโค้ดนั้นด้วยดีบักเกอร์ส่งไปยังการควบคุมเวอร์ชันของคุณ(เช่นgit) ล้างและทำซ้ำ อย่างไรก็ตามโปรดหลีกเลี่ยงหนี้สินทางเทคนิค: เมื่อสิ่งที่มีกลิ่นไม่ดีให้ทำงาน (โดยการปรับสภาพและการปรับใช้ใหม่) เพื่อปรับปรุง

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

ฉันแค่ต้องการสร้างโปรแกรมสถาปัตยกรรมได้รับความเสียหาย

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

ในบางกรณีคิดเกี่ยวกับวิธีการใช้โปรแกรมเมตาโปรแกรม : มีสถานการณ์ที่คุณต้องการสร้าง "ซอร์สไฟล์" บางอย่าง (ตัวอย่างเช่นใช้ parser generators เช่นควาย , เครื่องกำเนิดรหัสกาวเช่นSWIG , Google protobufและบางครั้งคุณอาจต้องการเขียน simple script - หรือใช้ preprocessor ทั่วไปเช่นGPP - เพื่อปล่อยรหัส C ++ หรือ Java บางส่วนของคุณเพื่อหลีกเลี่ยงการเข้ารหัสซ้ำ ๆ )

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

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

มีสามคำขวัญที่ฉันชอบเก็บไว้ในใจ

• "ทุกสิ่งควรทำอย่างเรียบง่ายเท่าที่จะเป็นไปได้ แต่ไม่ใช่เรียบง่าย"

  เพื่อยกตัวอย่างของคุณในเรื่อง "หนึ่งหรือสองชั้น?" ฉันจะถามว่า "วิธีแก้ปัญหาที่ง่ายกว่าคืออะไร"

• "ไม่มีข้อบกพร่องที่เห็นได้ชัด" กับ "เห็นได้ชัดว่าไม่มีข้อบกพร่อง"

  หลังเป็นที่นิยมกว่า!

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

  1. รหัสควรทำงานในทฤษฎี (เช่นในหัวของคุณ)
  2. ถ้ามันไม่ได้ผลในทางปฏิบัติคุณสามารถดีบั๊กมันได้จนกว่าการฝึกฝนจะตรงกับทฤษฎี

  สามเณรบางครั้งไม่ได้กังวลกับขั้นตอนที่ 1 แม้ว่าจะเรียกใช้ในหัวของคุณ (เช่นเพราะมันซับซ้อนเกินไป) - แต่ในกรณีนั้นมันเป็นเพียงการทำงาน "โดยบังเอิญ" มากกว่า "ในทางทฤษฎี" อาจเป็นเพราะคุณไม่ได้ ไม่ทดสอบให้เพียงพอเพื่อค้นหาข้อบกพร่องที่ไม่ชัดเจน

• กฎหมายของ Gall

  นี่คือ "refactor" หรือที่รู้จัก

  ในทางปฏิบัติหมายความว่า:

  1. เริ่มต้นด้วย [ny] ระบบง่าย ๆ ที่ใช้งานได้
  2. ตอนนี้ได้เวลาเพิ่มคุณสมบัติใหม่แล้ว
  3. สร้างระบบที่มีอยู่อีกครั้งเพื่อให้ (เช่นจนกระทั่ง) คุณสมบัติใหม่นั้นง่ายต่อการเพิ่ม

  4. เพิ่มคุณสมบัติใหม่

  5. ... และทำซ้ำตามข้างต้น

  สิ่งนี้ตรงกับคำขวัญอย่าง YAGNI นั่นคืออย่า refactor (กังวลเกี่ยวกับสถาปัตยกรรม) ก่อนที่คุณจะต้อง ... แต่สร้างสถาปัตยกรรมที่ถูกต้องทันเวลาเช่นเมื่อคุณต้องการมันเพื่อวัตถุประสงค์เฉพาะ

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

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

แก้ไข: @Basile คำตอบให้ตัวอย่างเกี่ยวกับวิธีที่คุณสามารถทำซ้ำและปรับปรุงในสถาปัตยกรรมขั้นต่ำของคุณ

เวลาที่ใช้คิดเกี่ยวกับสถาปัตยกรรมของระบบนั้นไม่เสียเวลา

ฉันเชื่อว่าคำถามของคุณอาจถูกใช้ถ้อยคำใหม่ว่า "ฉันจะมีประสิทธิภาพมากขึ้นในการตัดสินใจทางสถาปัตยกรรมได้อย่างไร"

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

-

และสำหรับคำตอบอีกต่อไป ...

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

ฉันคิดว่ามีสิ่งสำคัญ 3 ประการที่ควรคำนึงถึงเมื่อพูดถึงหัวข้อนี้:

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

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

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

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

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

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

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

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

หลักการเปิด / ปิด : "เอนทิตีของซอฟต์แวร์ ... ควรเปิดสำหรับส่วนขยาย แต่ปิดเพื่อทำการปรับเปลี่ยน"

• แนวคิดขององค์ประกอบมากกว่ามรดก

  หลักการที่คลาสควรใช้เพื่อให้เกิดพฤติกรรม polymorphic และการนำโค้ดมาใช้ใหม่โดยการจัดองค์ประกอบ (โดยมีอินสแตนซ์ของคลาสอื่นที่ใช้ฟังก์ชันที่ต้องการ) แทนการสืบทอดจากคลาสพื้นฐานหรือคลาสพาเรนต์

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

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

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

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

ในกรณีที่จำเป็นต้องมีสถาปัตยกรรมก่อนโครงการ:

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

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

3. หากคุณทำงานกับหลายคน / ทีมอธิบายถึงอินเทอร์เฟซของคุณก่อนและตรวจสอบให้แน่ใจว่าทุกคนเข้าใจสมมติฐานและปัญหาทั้งหมด - ถ้าคุณไม่มีบริบทที่ใช้ร่วมกันการรวมจะเป็น "สนุก" เช่นคุณสร้างเครื่องสร้างรูปภาพ Banana แต่ frontend-dev ของคุณต้องการเครื่องกำเนิดรูปภาพของ Apple หรือคุณสร้างสิ่งที่สามารถตอบได้ 100 คำร้องขอ / วินาที แต่ต้องการ 10,000 r / sec

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

ฉันจะไม่ทิ้งข้อตกลงและตัวย่อให้คุณ (ซึ่งส่วนใหญ่แทบจะไม่ได้รับการยอมรับจากนักเขียน / วิศวกรซอฟต์แวร์ส่วนใหญ่) ให้พิจารณาสิ่งต่อไปนี้แทน:

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

2. ทุกอย่างเป็นการแลกเปลี่ยน - คุณสามารถออกแบบระบบเดียวกันได้หลายวิธีซื้อขายเวลาและพื้นที่ความซับซ้อนและความยืดหยุ่นความเป็นนามธรรมและความสามารถในการอ่านหรือสิ่งใดสิ่งหนึ่งที่เป็นไปได้ ไม่มีวิธีแก้ปัญหาที่สมบูรณ์แบบในทุก ๆ ด้านและไม่มีกฎใดที่ไม่มีข้อยกเว้นในด้านวิศวกรรมซอฟต์แวร์ ใครก็ตามที่บอกคุณเป็นอย่างอื่นก็คือไร้เดียงสาหรือขายของบางอย่าง

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

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

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

สถาปัตยกรรมทำสองสิ่งสำหรับรหัสของคุณ:

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

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

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

ตอนนี้ส่วนที่คุณเป็นจริงสำหรับ:

คุณจะได้อะไรจากส่วนของสถาปัตยกรรมได้เร็วขึ้น:

1. อย่าทำมัน

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

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

1. ทำมันเร็ว
2. ขโมย
3. เรียนรู้ / ติดกับมัน
4. อย่าหักโหมจนเกินไป

การตัดสินใจเกี่ยวกับสถาปัตยกรรมควรเป็นส่วนเริ่มต้นของกระบวนการวางแผน ทันทีที่คุณมีความคิดว่าคุณจะสร้างแอพ / โปรแกรม / เว็บไซต์ประเภทใดคุณควรคิดว่าสถาปัตยกรรมประเภทใดที่จะสนับสนุนสิ่งนี้

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

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

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

(PS: ประโยคสุดท้ายนั้นไม่มีข้อแก้ตัวสำหรับคนขี้เกียจการจัดลำดับความสำคัญของซอฟต์แวร์ที่ใช้งานไม่ได้หมายความว่าคุณจะไม่ต้องเรียนรู้การเขียนโค้ดที่ดีสักวันหนึ่ง)

คำตอบนั้นง่ายมาก

• สร้างต้นแบบ (บรรจุกล่องเวลา)
• Refactor (ใช้เวลาเท่าที่คุณต้องการหรือมีปัจจัยหลายอย่าง)

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

ฉันจะผ่านช่วงสถาปัตยกรรมได้เร็วขึ้นและเข้าสู่ช่วงการเข้ารหัสและการดีบักที่ฉันสนุกได้อย่างไร

โดยการมอบหมายงานนี้ให้กับ (หรือขอความช่วยเหลือจาก) เพื่อนร่วมงานที่มีประสบการณ์มากขึ้นของคุณ

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

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

ฉันเห็นปัญหาร้ายแรงบางอย่างสำหรับคำถามนี้ เริ่มกันเลย.

วิธีหยุดการสูญเสียเวลาในการออกแบบส่วนประกอบ

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

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

สถาปัตยกรรมที่เหมาะสมมีวัตถุประสงค์เพื่อป้องกันของเสียในการเขียนโค้ด มันทำได้โดยการ จำกัด การ จำกัด และจัดทำเอกสารในวิธีที่เป็นไปได้ที่ระบบที่ซับซ้อนคือ 1) ออกแบบ 2) เขียนโค้ดและทดสอบ 3) ส่งมอบ 4) บำรุงรักษา 5) กู้คืนจากความล้มเหลวและ 6) ปลดประจำการในที่สุด

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

แต่ฉันเชือนแช ...

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

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

ฉันเพิ่งจบการศึกษาจากมหาวิทยาลัยและเริ่มทำงานเป็นโปรแกรมเมอร์ ฉันไม่พบว่ามันยากที่จะแก้ปัญหา "ทางเทคนิค" หรือทำการดีบั๊กสิ่งที่ฉันจะพูดมี 1 วิธี

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

แต่ดูเหมือนจะมีปัญหาหลายอย่างที่ไม่มีวิธีแก้ปัญหาเดียว

สิ่งเหล่านี้คือขนมปังและเนยในอาชีพของเราประเภทของปัญหาที่นายจ้างยินดีจ่ายเงินเดือน (โดยทั่วไป) ของเราที่สูงกว่าค่าเฉลี่ย

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

- สิ่งต่าง ๆ เช่นสถาปัตยกรรมซอฟต์แวร์

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

เมื่อเราพัฒนาซอฟต์แวร์สำหรับระบบดังกล่าว (ระบบธนาคารระบบตรวจสอบพลังงานระบบขายตั๋ว ฯลฯ ) เรามุ่งมั่นที่จะผลิตซอฟต์แวร์ที่เลียนแบบฟังก์ชั่นและข้อกำหนดของระบบดังกล่าว

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

สิ่งเหล่านี้ทำให้ฉันงงงวยและทำให้ฉันเป็นทุกข์มาก

ไม่เป็นไร มันไม่ใช่เรื่องง่ายที่จะเรียนรู้หรือสอนไม่ใช่การฝึกฝนมากมาย

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

น่าเสียดายที่นั่นไม่ใช่สถาปัตยกรรมซอฟต์แวร์

มันไม่ได้ออกแบบมา แต่เป็นรหัส ฉันจะให้คำแนะนำที่ด้านล่างของโพสต์นี้

ฉันจะผ่านช่วงสถาปัตยกรรมได้เร็วขึ้นและเข้าสู่ช่วงการเข้ารหัสและการดีบักที่ฉันสนุกได้อย่างไร

ฉันมีเวลายากที่จะหาวิธีตอบคำถามนี้เพราะมันค่อนข้างจะเป็นอารมณ์

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

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

คุณจะไม่ก้าวหน้าคุณจะไม่เติบโตหรือได้รับความรู้ใหม่

มีคำพูดนี้ในกองทัพบก "โอบกอดดูด"

วลีอื่น ๆ มีคำแนะนำที่คล้ายกัน "ถ้ามันไม่ดูดมันก็ไม่คุ้มค่า" และฉันชอบ "ถ้ามันดูด (และมันสำคัญ) ให้ทำจนกว่ามันจะหยุดดูด"

คำแนะนำของฉัน:

ดูเหมือนว่าคุณจะยังคงดิ้นรนที่จะเข้าใจความแตกต่างระหว่าง

1. การเข้ารหัส (วิธีการรหัสคลาสของคุณ, โมดูลหรือสิ่งใด, อนุสัญญาการตั้งชื่อ, การเปิดเผยการเข้าถึง, ขอบเขต, ฯลฯ ),

2. การออกแบบ (จำนวนเทียร์, front-end / back-end / db, แต่ละการสื่อสาร, สิ่งที่เกิดขึ้น) และการตัดสินใจทางสถาปัตยกรรมโดยปริยายซึ่งมาจากการออกแบบระบบที่เรียบง่าย

3. สถาปัตยกรรม (ตามที่พบในระบบที่ซับซ้อนที่ต้องใช้คนนับพันหากไม่นับแสนชั่วโมง)

ดังนั้นฉันขอแนะนำให้คุณเจาะลึกลงไปในหัวเรื่องแรก (การเข้ารหัส) เพื่อนำไปสู่ระดับถัดไป

ทำความสะอาดรหัส

Robert "Uncle Bob" Martin "Clean Code"เป็นจุดเริ่มต้นที่ดี

การทำงานร่วมกันของซอฟต์แวร์

นอกจากนี้ฉันขอแนะนำให้คุณทำความคุ้นเคยกับตัวชี้วัดซอฟต์แวร์เชิงวัตถุที่เรียกว่า LCOM หรือ LCOM4

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

http://www.aivosto.com/project/help/pm-oo-cohesion.html#LCOM4 https://www.computing.dcu.ie/~renaat/ca421/LCOM.html

หลักการซอฟต์แวร์

สิ่งนี้เกี่ยวข้องอย่างใกล้ชิดกับ"หลักการความรับผิดชอบเดี่ยว"หรือ SRY ที่เราทุกคนควรคุ้นเคย SRY เป็นหนึ่งใน 5 "โซลิด"ที่เราทุกคนต้องคุ้นเคยถ้าเราต้องมีความเชี่ยวชาญในการเขียนโปรแกรม

ในขณะที่เราดำเนินการตามหลักการของ SOLID เราต้องทำความคุ้นเคยกับหลักการ"GRASP"ซึ่งควบคุมหรือแนะนำวิธีที่เราใช้รหัสคลาส

หนังสือเพิ่มเติม

สุดท้ายฉันขอแนะนำต่อไปนี้:

• "Refactoring"โดย Martin Fowler และ Ken Beck จะเป็นหนังสือเล่มต่อไปที่ฉันอ่านในรายการนี้

• "ออกแบบโดยสัญญาตามตัวอย่าง"โดย Richard Mitchell, Jim McKim และ Bertrand Meyer (ต่อมาจากชื่อเสียงของหอไอเฟล) หนังสือเล่มนี้พิมพ์ออกมา แต่คุณสามารถหาสำเนาราคาถูกได้ใน Amazon

ด้วยสิ่งนี้คุณควรเข้าใจวิธีการเริ่มต้นการเขียนโปรแกรมและการออกแบบและด้วยการฝึกฝนเพื่อย้ายและต้นแบบสถาปัตยกรรมซอฟต์แวร์ (หรืออย่างน้อยเข้าใจ)

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

ทั้งหมดที่ฉันสามารถพูดได้คือ - ไม่มีทางลัด

ทั้งหมดที่ดีที่สุด

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

ในการเปรียบเทียบให้พิจารณาสถาปัตยกรรมของบ้าน สถาปนิกไม่เริ่มถามคำถามด้วยตนเองว่า: "บ้านนี้ควรมีหน้าต่างกี่บาน?", "ควรวางอิฐก้อนแรกไว้ที่ไหน" รายละเอียดการใช้งานเหล่านั้นไม่ใช่การออกแบบ แต่ได้มาจากการออกแบบ หอจดหมายเหตุเริ่มต้นด้วยวิสัยทัศน์บางทีภาพร่างของบ้านที่เสร็จแล้วอาจมีลักษณะอย่างไร มันเป็นบ้านครอบครัวเดี่ยวดูเพล็กซ์หรือไม่? มันเป็นบ้านที่หรูหราหรือเป็นบ้านที่ราคาไม่แพง? เช่นเดียวกันไม่ว่าตัวแปรจะเป็นแบบส่วนตัวหรือไม่และคุณแบ่งชั้นเรียนได้น้อยมากเกี่ยวกับสถาปัตยกรรม

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

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

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

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