มีเหตุผลหรือไม่ที่จะคาดหวังว่านักพัฒนาอาวุโสจะรู้ว่ารูปแบบการออกแบบของ OOP คืออะไร [ปิด]

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

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

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

เพิ่ม หลังจากอ่านคำตอบแล้วฉันควรให้คำอธิบายเล็กน้อย:

• งานนี้สำหรับนักพัฒนา. NET ที่มีประสบการณ์ด้าน OOP / OOD
• รหัสที่มีอยู่ใช้ชื่อคลาสที่ชอบIParameterGraphVisitorและIStorageFactoryในหลาย ๆ ที่
• คุณจะถามผู้คนเกี่ยวกับประสบการณ์ในอดีตของพวกเขาด้วยการออกแบบ OO ที่พวกเขาสร้างขึ้นได้อย่างไรหากพวกเขาไม่มีคำศัพท์ที่จะอธิบายการออกแบบของพวกเขา นั่นคือสิ่งที่ฉันต้องการจะทำและสิ่งที่ฉันสามารถทำได้คือ "โปรดคุณวาดลำดับชั้นการออกแบบ / วัตถุของโครงการสุดท้ายของคุณบนไวท์บอร์ด"

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

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

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

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

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

คุณจะถามคำถามอะไรแทนความสามารถในการออกแบบของพวกเขา

ในคอนเสิร์ตที่มีด้านบนฉันจะเพิ่มคำถามเหล่านี้ในรายการของคุณเท่านั้น:

• อะไรคือข้อเสียของรูปแบบการออกแบบ (โดยทั่วไปและอย่างที่พวกเขากล่าวถึงอย่างชัดเจน)
• เมื่อไม่ใช้พวกเขาและทำไม?

ปรับปรุง

@GrandmasterB มีจุดดีที่ผู้พัฒนาบางรายอาจใช้รูปแบบการออกแบบเฉพาะโดยไม่ทราบชื่อ ด้วยวิธีที่เขาพูดถูกนี่เป็นคำถามคำศัพท์ / การสื่อสาร แต่อีกด้านหนึ่งของเหรียญคือว่ามันย่อมเป็นคำถามคำศัพท์ / การสื่อสาร :-) นั่นคือหนึ่งในผลประโยชน์หลักของการออกแบบรูปแบบคือการให้คำศัพท์ทั่วไปที่นักพัฒนาอย่างมากการปรับปรุงการสื่อสาร (พยายามอธิบายความคิดพื้นฐานของอะแดปเตอร์โดยไม่ต้องใช้คำนั้นหรือคำพ้องความหมาย "wrapper" et al!) ดังนั้นผู้สมัครที่มีความสามารถและมีความรู้ความสามารถอาจเป็นได้โดยไม่ต้องรู้จักคำศัพท์ที่ยอมรับกันอย่างกว้างขวางในทีมของคุณ

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

ในการสัมภาษณ์คุณควรถามสิ่งที่สำคัญที่ผู้สมัครต้องรู้เพื่อทำงาน

หากพวกเขาต้องรู้ชื่อของรูปแบบที่พวกเขามาจากแก๊งสี่นั้นเป็นข้อกำหนดที่ถูกต้อง

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

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

ขึ้นอยู่กับพื้นที่ความเชี่ยวชาญของพวกเขา ฉันไม่คิดว่านักพัฒนา C แบบฝังจะรู้เรื่องลวดลายการออกแบบมาก หากเรากำลังพูดถึงนักพัฒนา Java หรือ. NET พวกเขาควรคุ้นเคยกับรูปแบบการออกแบบและโดยเฉพาะอย่างยิ่งวิธีที่จะไม่นำไปใช้กับพวกเขา

สมมติว่าคุณกำลังมองหาผู้อาวุโสใน OOP คำตอบก็คือใช่ รูปแบบการออกแบบเป็นศัพท์ของภาษา OOP

ยิ่งไปกว่านั้นในปัจจุบันนี้ไม่มีเหตุผลที่โปรแกรมเมอร์ OOP ที่มีประสบการณ์ 10 ปีไม่สามารถตั้งชื่อรูปแบบการออกแบบได้เป็นรูปแบบการออกแบบที่ใช้กันอย่างแพร่หลายใน API มาตรฐานไลบรารีและกรอบการพัฒนา

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

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

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

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

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

เหมาะสม แน่นอน จำเป็น ไม่

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

ใช่นักพัฒนาหลายคนใช้รูปแบบการออกแบบโดยไม่รู้ตัว

นั่นไม่ใช่เหตุผลที่ฉันถามคำถาม

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

พวกเขายังช่วยในกระบวนการ refactoring การดูรหัสหนึ่งอาจทำให้รูปแบบของรูปแบบโรงงานบางรูปแบบ แต่รูปแบบของโรงงาน GoF นั้นทนต่อการทดสอบของเวลา นั่นเป็นสาเหตุที่รูปแบบของโรงงานไม่ใช่ YET ANOTHER fp (การปรับแต่งวงล้อไม่เหมาะกว่า Joel ในซอฟต์แวร์มีข้อเสียมากมายในการทำเช่นนั้น)

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

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

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

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

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

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

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

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

เช่นเดียวกับคลาส Peopleware ที่พูดถึงการจ้างนักเล่นปาหี่โดยไม่ขอให้พวกเขาเล่นปาหี่ - เพียงเพราะพวกเขาบอกว่าพวกเขาไม่ได้มีความหมายอะไรมาก .. ลองพวกเขา

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

แน่นอนพวกเขาควรรู้รูปแบบ แต่ไม่จำเป็นต้องเป็น buzzwords

ตัวอย่างเช่น MVC มีทางเลือกที่คล้ายกันมากเช่น PAC, 3 ระดับ ไม่กี่ปีที่ผ่านมาคำศัพท์ยอดนิยมอีกคำสำหรับ MVC คือ "รุ่น 2" จริง ๆ แล้วฉันรู้จักนักพัฒนาที่ดีมากที่รู้จักรูปแบบนั้นอย่างสมบูรณ์แบบ แต่ไม่ทราบว่า buzzword ปัจจุบันสำหรับ MVC นั้นเป็นอย่างไร

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

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

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

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

คุณบอกว่าซอฟต์แวร์ที่มีอยู่ใช้รูปแบบการออกแบบ นั่นเป็นข้อได้เปรียบหรือไม่? ถ้าเป็นเช่นนั้นได้อย่างไร เป็นเป้าหมายของคุณหรือไม่ที่ซอฟต์แวร์ใหม่ที่เขียนขึ้นนั้นสอดคล้องกับรูปแบบที่มีอยู่หรือมีการนำรูปแบบใหม่มาใช้หรือไม่? ทำไม?

ฉันนึกถึงนักพัฒนาอาวุโสที่ไม่รู้เกี่ยวกับรูปแบบการออกแบบในสถานการณ์ต่อไปนี้:

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

ทำไมนักพัฒนาซอฟต์แวร์ในสภาพแวดล้อมที่ไม่ใช่ OO ควรรู้เกี่ยวกับรูปแบบการออกแบบ OO ฉันทำงานในร้านค้าที่ทำเฉพาะ Cobol, PL / SQL เท่านั้น, Progress 4GL และอื่น ๆ หลักการออกแบบ OO นั้นไม่เกี่ยวข้องฉันคาดหวังว่าผู้อาวุโสในสภาพแวดล้อมเหล่านั้นจะมีความรู้ที่เกี่ยวข้องกับสภาพแวดล้อมเหล่านั้นไม่ใช่การออกแบบ OO รูปแบบ

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