รูปแบบการออกแบบที่ขมวดคิ้วอยู่หรือไม่?

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

สิ่งที่แปลกคือสิ่งที่เขาบอกฉัน: เขาบอกว่ามีชิ้นส่วนของรหัสที่เป็นฝันร้ายที่จะทำงานด้วยเพราะมันถูกเขียนจากตำราเรียนและไม่ได้คำนึงถึงโลกแห่งความจริง การเพิ่มฟิลด์ใหม่ลงใน UI / ฐานข้อมูล / ชั้นข้อมูลใช้เวลา 2-3 ชั่วโมงในการทำขณะที่รหัสของเขาใช้เวลา 30 นาที

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

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

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

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

คุณทำอะไรกับข้อความเหล่านี้?

นี่คือคำพูดของคนที่ประสบความสำเร็จและไม่สนใจคนที่พยายามบอกเขาว่าควรทำอย่างไรในรูปแบบศัพท์แสงที่เขาไม่เข้าใจ

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

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

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

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

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

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

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

Stackoverflow.SE และ Programmers.SE ส่วนใหญ่สนับสนุนให้คนที่จะปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดเช่นของแข็งไม่ได้มาตรฐานอุตสาหกรรม และเชื่อหรือไม่ว่ามาตรฐานอุตสาหกรรมโดยพฤตินัยมักจะเป็นสถาปัตยกรรม"ลูกใหญ่แห่งโคลน" - อย่างจริงจัง

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

1. รูปแบบการออกแบบเป็นเพียงชื่อที่ใช้ในการสื่อสารความคิด ฉันมักจะพบว่าตัวเองทำสิ่งต่าง ๆ ซึ่งต่อมาฉันพบว่ามีชื่อ ดังนั้นจึงไม่มี "วิธีรูปแบบการออกแบบ" ซึ่งตรงข้ามกับ "วิธีรูปแบบที่ไม่ใช่การออกแบบ"

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

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

หากต้องการเพิ่มคำอุปมาอื่นในซุปรูปแบบการออกแบบคือ Clippy ผู้ช่วย Microsoft Office "คุณดูเหมือนจะทำสิ่งเดียวกันกับเรื่องทั้งหมดฉันจะช่วยคุณได้ด้วยการเสนอ Iterator หรือผู้เยี่ยมชม?"

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

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

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

ดังนั้นจึงเป็นความผิดพลาดแน่นอนที่จะหลีกเลี่ยงการเขียน Iterator บนหลักการเพราะคุณต้องการหลีกเลี่ยงรูปแบบการออกแบบ

การเพิ่มเขตข้อมูลใหม่ลงใน UI / ฐานข้อมูล / ชั้นข้อมูลใช้เวลาทำ 2-3 ชั่วโมงโดยที่ในรหัสของเขาใช้เวลา 30 นาที

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

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

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

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

เพื่อนร่วมงานของคุณดูเหมือนจะทรมานจากอาการของโรค NIH ("ไม่ได้คิดค้นที่นี่")

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

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

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

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

วิธีการแบบเลเยอร์ได้รับการพิสูจน์แล้วว่าเหนือกว่าสถาปัตยกรรมอื่น ๆ ในแอพพลิเคชั่นส่วนใหญ่ขององค์กร แพคเกจชั้นนำระดับโลกมีโครงสร้างรอบความคิดนี้และมีประสิทธิภาพเหนือกว่าสถาปัตยกรรมด้านศิลปะตามคำสั่งของขนาด Martin Fowler นำเสนอวิธีการนี้ในหนังสือที่ยอดเยี่ยมของเขาเกี่ยวกับ "รูปแบบของสถาปัตยกรรมองค์กร" Oh! ขออภัยอีกครั้ง: มันเกี่ยวกับรูปแบบที่ผ่านการพิสูจน์แล้ว ไม่มีโอกาสได้เห็น NIH ของเพื่อนร่วมงานของคุณ ;-)

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

รูปแบบการออกแบบเป็นวิธีแก้ไขปัญหามาตรฐานสำหรับปัญหามาตรฐาน อย่างไรก็ตามหากคุณไม่มีปัญหาในการแก้ปัญหามันเป็นการสิ้นเปลืองความพยายาม

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

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

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

ในแง่ที่ว่าถ้าคุณไม่ได้ตั้งใจที่จะเขียนโค้ดแบบครั้งเดียว 100% โดยที่ไม่มีแนวคิดหรือการใช้งานที่สามารถใช้งานได้จากกรณีการใช้งานหนึ่งไปยังกรณีถัดไปคุณเกือบจะใช้รูปแบบการออกแบบอย่างน้อย พวกเขาอาจไม่มีชื่อทั่วไปที่ฉูดฉาด "Repository" หรือ "Unit of Work" หรือแม้แต่ "MVC" แต่นั่นไม่ได้ทำให้พวกเขา "ไม่ใช่รูปแบบการออกแบบ"

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

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

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

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

การเพิ่มเขตข้อมูลใหม่ลงใน UI / ฐานข้อมูล / ชั้นข้อมูลใช้เวลาทำ 2-3 ชั่วโมงโดยที่ในรหัสของเขาใช้เวลา 30 นาที

หากคุณต้องการ "เพิ่มประสิทธิภาพ" การออกแบบคุณต้องพูดในสิ่งที่คุณกำลังพยายามเพิ่มประสิทธิภาพ

ตัวอย่างเช่นจักรยานแข่งเป็นยานพาหนะที่ได้รับการปรับปรุง ... และโบอิ้ง 747 ยังเป็นยานพาหนะที่ได้รับการปรับปรุง ...

ตัวอย่างความคิดของรูปแบบ "MVC" ยกตัวอย่างเช่น:

• มุมมองต่าง ๆ ของโมเดลเดียวกัน (มุมมองไม่ขึ้นกับโมเดล)
• แต่ละชั้นสามารถพัฒนาแยกต่างหาก (เช่นโดยทีมที่แตกต่างกัน) และทดสอบแยกต่างหาก (การทดสอบหน่วย) ก่อนการรวม
• เป็นต้น

ในขณะที่รหัสของเขาอาจปรับให้เหมาะสมสำหรับสิ่งอื่นเช่น:

• บรรทัดน้อยที่สุดของรหัส
• ง่ายสำหรับคนคนหนึ่งในการเปลี่ยนแปลงที่มีผลต่อเลเยอร์ทั้งหมด (โดยไม่มีเลเยอร์ที่แตกต่างกันเลย)
• เป็นต้น

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

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

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

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

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

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

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

โดยปกติรูปแบบจะอนุญาตให้มีรูปแบบที่สอดคล้องกันและจะทำงานได้ดีกว่าการละเว้นรูปแบบทั้งหมดเพื่อสนับสนุนการเขียนแนวคิดดั้งเดิม 100% แต่คุณไม่สามารถหลีกเลี่ยงรูปแบบทั้งหมดได้ ตัวอย่างเช่นถ้า y = x + 5 คุณจะเขียน y = x + (5 * 3 + 15/3) / 4 จริงๆเพื่อหลีกเลี่ยงรูปแบบการเขียน x + 5 หรือไม่ ไม่คุณไม่ได้ คุณจะเขียน y = x + 5 แล้วไปยังปัญหาต่อไป

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

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

รูปแบบการออกแบบไม่ได้ขัดกับแนวปฏิบัติที่คล่องตัว สิ่งที่ตรงกันข้ามกับการปฏิบัติเปรียวคือการใช้รูปแบบการออกแบบเพื่อประโยชน์ในการใช้รูปแบบการออกแบบการปฏิบัติทั่วไปในหมู่นักศึกษาระดับบัณฑิตศึกษาและนักศึกษาให้คิดตามแนว "เราจะแก้ปัญหานี้โดยใช้รูปแบบโรงงานได้อย่างไร"

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

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