'ง่าย' เป็นวิธีการแก้ปัญหา KISS จริงหรือไม่ [ปิด]

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

ในทางตรงกันข้ามใช่มันทำให้ฉันเครียดเป็นพิเศษในแง่ของการส่งมอบกำหนดเวลาบางครั้ง ...

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

จากนั้นฉันก็เริ่มที่จะตัดสินความเข้าใจของฉัน 'ง่าย' ...

SIMPLE หมายถึงสั้นเกินไปที่จะใช้งานได้ แต่ยากที่จะรักษาและขยายออกไป?

SIMPLE หมายถึงการทำลายหลักการ OOP มากมายหรือไม่?

SIMPLE หมายถึงการโกงหรือไม่

SIMPLE หมายถึงเพียงแค่รักษากำหนดเวลาโดยไม่ต้องไม่มี dealy หรือไม่? เป็นต้น

จริงๆแล้วมันคืออะไร

คำถามคือ : คุณสามารถเขียนคำจำกัดความที่แน่นอนของ SIMPLE ในแง่ของหลักการ KISS ได้หรือไม่? ถ้ามี

ขอบคุณ!

มาเรียนภาษาฝรั่งเศสกันเถอะ:

ความสมบูรณ์แบบของ La คือความสมบูรณ์แบบที่ไม่ต้องเสียเงิน - Antoine de Saint-Exupéry

ซึ่งแปลเป็น:

ความสมบูรณ์แบบนั้นเกิดขึ้นได้ไม่ใช่เมื่อไม่มีอะไรจะเพิ่มเติมอีกต่อไป แต่เมื่อไม่มีอะไรเหลือให้เอาไป - Antoine de Saint-Exupéry

สถานการณ์

คุณต้องตัดและเหน็บแนม

โซลูชัน A: ไม่ใช่ KISS

โซลูชัน B: KISS

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

"ทำสิ่งต่าง ๆ ให้ง่ายที่สุด แต่ไม่ใช่ง่ายกว่า" -Einstein

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

มีความสมดุลระหว่าง over-engineering (โอ้คนนี่ดูเหมือนจะเป็นสถานที่ที่ยอดเยี่ยมในการแสดงทักษะการออกแบบลวดลายของฉัน!) และภายใต้วิศวกรรมศาสตร์ (ถ้าฉันใช้โรงงานฉันไม่ได้มีข้อต่อนี้ การเปลี่ยนแปลงรหัส ... ) เป้าหมายคือการบำรุงรักษา

Simple ไม่ได้หมายถึงการทำลายหลักการการเขียนโปรแกรมที่ดี ในความเป็นจริงมันหมายถึงสิ่งที่ตรงกันข้าม

SIMPLE หมายถึงสั้นเกินไปที่จะใช้งานได้ แต่ยากที่จะรักษาและขยายออกไป?

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

SIMPLE หมายถึงการทำลายหลักการ OOP มากมายหรือไม่?

ไม่ได้หลักการ OOP ส่วนใหญ่ได้รับการออกแบบมาเพื่อรักษาความสะอาดโค้ดและจัดระเบียบได้มากขึ้น

SIMPLE หมายถึงการโกงหรือไม่

ไม่ได้เขียนเรื่องยากที่จะรักษาโค้ด & แฮ็กไว้ภายใต้หน้ากากของการรักษากำหนดเวลาคือ

SIMPLE หมายถึงเพียงแค่รักษากำหนดเวลาโดยไม่ต้องไม่มี dealy หรือไม่? เป็นต้น

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

นี่เป็นเรื่องยุ่งยากมากที่จะอธิบายเพราะความเรียบง่ายไม่ได้หมายถึงสิ่งเดียวกันกับทุกคน

ตัวอย่าง. นักพัฒนาบางคนคิดว่า?:ง่าย แต่คนอื่น ๆ คิดว่าifข้อความนั้นดีกว่า เมื่อถึงระดับนี้คุณจะไม่พอใจทุกคน

โดยทั่วไปวิธีการง่าย ๆ โดยไม่มีความซับซ้อน เพื่อที่จะเข้าใจความเรียบง่ายเราจำเป็นต้องเข้าใจความซับซ้อน

ความซับซ้อนมีสองประเภท:

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

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

คุณสามารถตรวจสอบความซับซ้อนที่สำคัญได้ด้วยคำถามต่อไปนี้:

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

ตรวจสอบความซับซ้อนโดยไม่ตั้งใจของคุณ:

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

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

ฉันหวังว่านี้จะช่วยและไม่ลืมที่: เรียบง่ายไม่ได้หมายความว่า EASY

ฉันรู้สึกเหมือนหลักการที่อยู่เบื้องหลัง X11 ( http://en.wikipedia.org/wiki/X_Window_System#Principles ) เป็นสิ่งที่ควรค่าแก่การเอาใจใส่ ฉันไม่ได้ประสบความสำเร็จในเป้าหมายนี้เสมอไป

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

คำถามคือ: คุณสามารถเขียนคำจำกัดความที่แน่นอนของ SIMPLE ในแง่ของหลักการ KISS ได้หรือไม่? ถ้ามี

เลขที่

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

ความซับซ้อนสามารถทำได้โดยยากที่เข้าใจการอ้างอิง - กำจัดเหล่านั้น! ไฟล์ / คลาสจำนวนมากเชื่อมโยงกัน - ไม่มีทาง! และรหัสที่ซับซ้อน (ความหมาย: ลูปที่ถูกล่ามโซ่เลเยอร์ ITE หลายชั้น ฯลฯ ) - ไม่มีใครอยากอ่าน

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

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

แต่: มันง่ายกว่ามาก (!) ในการอ่านทุกอย่างถ้ามีสต็อปเต็มรูปแบบที่แสดง: ฉันคิดเสร็จแล้วไปต่อด้วยสิ่งต่อไป

นั่นคือสิ่งที่ฉันจะนิยามว่าเรียบง่าย