“ คุณไม่ต้องการมัน” และ“ ตอนนี้ดีกว่าที่ไม่เคยเล่นมาด้วยกัน”


17

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

ในทางกลับกันการฝึกฝนนี้ทำให้ฉันต้องสร้างล่วงหน้าค่อนข้างไกลถึงแม้จะมีโอกาสพอสมควรที่ฉันไม่ต้องการมัน

รูปแบบทั้งสองนี้มีวิธีการอย่างไร

คุณใช้วิธีปฏิบัติแบบใดเพื่อให้แน่ใจว่าพวกเขาเล่นได้ดี?

คุณจะสอนพวกเขาด้วยกันโดยไม่สร้างความสับสนได้อย่างไร


2
ดูก่อนที่คุณจะกระโดด แต่ผู้ที่ลังเลก็หายไป
mmyers

คำตอบ:


26

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

ฉันเอนตัวไปทาง "คุณไม่ต้องการมัน" ด้วยความเคารพในรหัส แต่ "ตอนนี้ดีกว่าไม่เคย" ด้วยการออกแบบ

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

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


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

9

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

ไม่ว่าในกรณีใดคุณจะไม่สูญเสียสิ่งใดกับ YAGNI

ในกรณีอื่นคุณเสียเวลาในการเขียนรหัสที่ไม่เคยใช้งานและการเขียนการทดสอบรหัสที่ไม่เคยใช้และการเขียนเอกสารสำหรับรหัสที่ไม่เคยใช้งานและการบำรุงรักษารหัสที่ไม่เคยใช้คนสงสัยว่ารหัสนี้ทำอะไร และถ้ามันเคยถูกใช้งานให้โฆษณาคลื่นไส้

ตัวอย่าง

หากฉันกำลังทำงานกับต้นแบบ / หลักฐานของแนวคิดหรือแอปพลิเคชันรุ่น1.0แล้วฉันไม่จำเป็นต้องออกแบบในระดับของ Facebook เฮ้ฉันไม่ต้องการการออกแบบที่จะขยายไปถึงระดับของ Facebook จนกว่าฉันจะเริ่มเห็นว่าฉันมีปริมาณการใช้งานแบบนั้น

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

วิธีปฏิบัติในการทำสิ่งต่าง ๆ คือวิธีที่เขาทำ เขาเริ่มต้นด้วย PHP และ MySQL และการออกแบบใหม่และเขียนซ้ำตามความต้องการตามมูลค่าทางธุรกิจการปรับให้ผู้ใช้หลายล้านคนมีมูลค่าทางธุรกิจมหาศาล แต่ไม่ใช่ในวันที่ 0 ในวันที่ 0 การเปิดตัวอะไรบางอย่างเป็นมูลค่าทางธุรกิจมหาศาล

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

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


2
หากการออกแบบของคุณไม่ดี (เช่นยืดหยุ่น) คุณสามารถสูญเสียมากกับ YAGNI
EricSchaefer

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

6

เซนของงูใหญ่วิธีพูดว่า:

ตอนนี้ดีกว่าไม่เคย แม้ว่าจะไม่เคยดีกว่าตอนนี้

แนวคิดก็คือไม่ใช่เพราะคุณสามารถกำหนดสิ่งที่คุณควร คุณต้องการมันตอนนี้เหรอ?

  • ใช่: ทำทันที!
  • ไม่: อย่าทำ! รอความต้องการ! YAGNI!

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

ดังนั้น YAGNI จนกว่าคุณจะทำแล้วทำทันที อย่ารอ!


3

ฉันไม่คิดว่าพวกเขาเล่นด้วยกันเลย ฉันคิดว่าคุณเอนไปทางใดทางหนึ่ง และฉันก็หันไปหา YAGNI

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

แค่สองเซ็นต์ของฉัน


และตอนนี้คำถามล้านดอลลาร์: "สำคัญ" หมายความว่าอะไร?
Aaronaught

1
"สำคัญ" หมายความว่าเป็นการทดสอบการยอมรับ
kindall

สำคัญหมายถึงลูกค้าตะโกนเมื่อมันไม่มี
พอลนาธาน

2
สำคัญหมายถึงลูกค้าไม่ชำระเงินหากไม่มี
Christopher Mahan

@ คริสโตเฟอร์ที่สามารถตีความได้ว่าเป็นการส่งเสริมความเป็นมืออาชีพ เช่นการป้องกันการฉีด SQL เป็นสิ่งสำคัญแม้ว่าลูกค้าจะไม่ทราบว่ามันคืออะไรและแน่นอนจะไม่ทดสอบก่อนจ่ายเงิน
Peter Taylor

2

รูปแบบทั้งสองนี้มีวิธีการอย่างไร

พวกเขาเป็นมุมฉากและไม่มีอะไรเกี่ยวข้องกัน

คุณใช้วิธีปฏิบัติแบบใดเพื่อให้แน่ใจว่าพวกเขาเล่นได้ดี?

หนอ ทำพวกเขาทั้งสอง? จะมีอะไรอีกไหม

คุณจะสอนพวกเขาด้วยกันโดยไม่สร้างความสับสนได้อย่างไร

YAGNI อธิบายคุณสมบัติที่ผู้ใช้เห็น คุณไม่ต้องการแฟนซี

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


2

ถ้า "ไม่เคย" เป็นนัยของ "ไม่ใช่ตอนนี้" แสดงว่าการออกแบบของคุณมีข้อบกพร่อง

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

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


1

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


ฉันชอบปรัชญานี้ในหลักการ แต่ในทางปฏิบัติฉันพบว่าการโยกย้ายนั้นเจ็บปวดพอที่จะทำให้ฉันคิดสองครั้ง คุณเคยพบว่าการโยกย้ายแบบจำลองของคุณเป็นไปในทิศทางที่คาดหวังการเปลี่ยนแปลงหรือไม่?
Justin Myles Holmes

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

0

ออกแบบโดยคำนึงถึงส่วนขยายในอนาคต แต่ไม่ต้องใช้ส่วนขยายเหล่านั้นจนกว่าคุณต้องการ

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

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.