คุณจะเปลี่ยนโปรแกรมจากการพัฒนาเป็นรีลีสได้อย่างไร


67

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

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

เมื่อเนื้อหาได้รับการทดสอบและอนุมัติแล้วก็ไม่มีเหตุผลที่จะเขียนใหม่ เป็นประจำฉันยืนอยู่ที่นั่นพร้อมกับต้นแบบ 'เสร็จสิ้น' ที่ทำงานและฉันได้รับข้อผิดพลาดในระหว่างการทดสอบและฉันเห็นว่ามันเป็นผลมาจากการเข้ารหัสที่ไม่ฉลาดซึ่งเป็นผลมาจากกระบวนการพัฒนาทั้งหมด ฉันอยู่ในระหว่างการทดสอบและการแก้ไขข้อผิดพลาดจะเป็นการเขียนซ้ำ ... มันเป็นระเบียบ!

มีวิธีที่ดีกว่า / ตำราฉันแน่ใจ แต่ฉันต้องทำงานในสภาพแวดล้อมการทำงานจริงที่ไม่ใช่ทุกอย่างเป็นตำรา

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

แก้ไข

ฉันต้องการชี้แจงบางสิ่ง

  • ฉัน 100% ในด้านของการทำก่อนและหลังรหัสสะอาดและอ่านได้ แต่ฉันก็ต้องทำสิ่งต่างๆให้สำเร็จและไม่สามารถฝันถึงความงามของรหัสได้ทั้งหมดที่สะอาดและเป็นประกาย ฉันต้องไปหาการประนีประนอม

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

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


68
คำถามของคุณคือ "ฉันขุดตัวเองเป็นหลุมฉันจะออกไปได้อย่างไร" คำตอบมาตรฐานคือขั้นตอนที่หนึ่งของหลักสูตร STOP DIGGING DEEPER กระบวนการพัฒนาของคุณสามารถสรุปได้ว่า "สร้างหนี้ด้านเทคนิคจำนวนมหาศาลแล้วเพิกเฉยเมื่อถึงกำหนด" หากนี่เป็นปัญหาให้เปลี่ยนกระบวนการพัฒนาของคุณ ตรวจสอบเฉพาะโค้ดที่สะอาดใช้งานได้ดีตรวจสอบอย่างดีซึ่งตรงตามข้อกำหนดที่เขียนไว้อย่างดี อย่าเป็นหนี้และคุณไม่ต้องเป็นหนี้
Eric Lippert

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

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

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

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

คำตอบ:


98

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

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

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

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

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

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

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

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

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


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

44
@ NikkyD: มันไม่ขยายกรอบเวลา กรอบเวลาถูกป่องแล้ว คุณไม่ได้คำนึงถึงการขยายตัวเมื่อคุณเขียนซอฟต์แวร์และเข้าสู่หนี้ทางเทคนิคที่คุณไม่ได้ตั้งงบประมาณไว้
Eric Lippert

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

10
@ NikkyD: ไม่ฉันขอแนะนำให้เขียนรหัสของคุณคล้ายกับวิธีการเล่นบิลเลียดของลูก: แต่ละนัดนั้นดูง่ายสำหรับคนนอก และในการเล่นบิลเลียดหรือการเข้ารหัสนี่ใช้เวลาหลายปีในการฝึกฝน ;-)
Doc Brown

16
@ NikkyD: ประสบการณ์ของฉันเมื่อ "เพิ่มคุณสมบัติเล็ก ๆ น้อย ๆ ต้องมีจำนวนมาก refactoring" รหัสเป็นระเบียบอยู่แล้วและความต้องการ "มาก refactoring" มาจากความจริงที่คุณต้องเปลี่ยนฟังก์ชั่นหรือชั้นเรียนที่คุณทำ ไม่สะอาดพอในอดีต อย่าปล่อยให้สิ่งต่าง ๆ มาไกลขนาดนี้ แต่ถ้าคุณอยู่ในสถานการณ์เช่นนั้นค้นหาการประนีประนอม อย่างน้อยปฏิบัติตาม "กฎ boyscout" และปล่อยให้รหัสอยู่ในสถานะที่ดีขึ้นกว่าเดิมก่อนที่คุณจะเพิ่มคุณสมบัติ ดังนั้นแม้ว่าคุณลักษณะนั้นจะถูกลบออกไปในสัปดาห์หน้ารหัสควรจะอยู่ในสภาพที่ดีกว่าเมื่อก่อน
Doc Brown

22

คุณมีสองปัญหาแยกกันทั้งคู่มีอาการเดียวกัน (รหัสเลอะเทอะ):

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

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

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


21

มันเป็นปัญหาที่พบบ่อย - โดยเฉพาะอย่างยิ่งเมื่อทำการประดิษฐ์บอลลูนทดลองซอฟต์แวร์เป็นหลัก เหมือนเดิม

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

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

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

ตัดรหัสการผลิตตั้งแต่เริ่มแรกสามารถดูเหมือนลาก แต่ขึ้นอยู่กับสภาพแวดล้อมของคุณมีเครื่องมือมากมายที่สามารถใช้บดออกจากการพัฒนาเช่นGhostDocและStyleCop

เป็นสิ่งที่ควรค่าแก่การพัฒนาความคิดตั้งแต่เริ่มแรก คุณต้องแปลกใจว่าระบบ back-of-a-fag-packet ที่ควรจะเป็นโซลูชั่นหยุดช่องว่างกลายเป็นแอปพลิเคชั่นสำคัญ


คุณหมายถึงวิธีแก้ปัญหาช่องว่างหยุดทุกครั้งที่เคยเขียนใช่มั้ย
RubberDuck

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

11

อย่างต่อเนื่อง

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

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


6
+1 และจากมุมมองส่วนตัวฉันพบว่ามันยากเกินไปที่จะเปลี่ยนเกียร์จากการแฮ็คโปรเจ็กต์ส่วนตัวที่บ้านและเขียนรหัสการผลิตในงานประจำวันของฉัน การเขียนรหัสมืออาชีพในโครงการงานอดิเรกของฉันจ่ายเงินปันผลทันที - รหัสอ่านง่ายขึ้นและมีข้อบกพร่องน้อยกว่ามาก
Robbie Dee

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

"ทำไมฉันถึงปฏิเสธสิ่งนั้นต่อตัวฉันเองและทำเพื่อโปรแกรมเมอร์ในอนาคต" วิวรณ์! และคาดเดาอะไร บางครั้งคุณ (และบางครั้งบ่อย) เป็นโปรแกรมเมอร์ในอนาคต
Radarbob

@ RobbieDee การสังเกตขั้นสุดยอด! ในการให้สัมภาษณ์ Malcom Gladwell - คนที่นำกฎ "10,000 ชั่วโมง" มาสู่การรับรู้ที่เป็นที่นิยม (ในหนังสือOutliers ) - กล่าวว่ามันจะต้องเป็น ความหมายมุ่งเน้นไปที่การปรับปรุงการปฏิบัติเฉพาะด้วยความตั้งใจที่จะปรับปรุงด้านที่เฉพาะเจาะจงของทักษะและอื่น ๆ
Radarbob

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

4

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

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

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

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

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


1

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

คำตอบคือเพื่อ

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

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


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

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

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

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

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

0

ที่คุณเขียน:

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

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

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

ฉันคิดว่าคุณเลื่อนการ "ล้างข้อมูล" ไปเป็นจำนวนมาก

กฎง่ายๆของฉันคือ:

  • เริ่มต้นด้วยคุณสมบัติ (ย่อย)
  • รู้สึกฟรีเพื่อเขียนไม่สมบูรณ์และ inclomplete สิ่งที่บางทีบาง C & P จะได้รับความรู้สึกสำหรับสิ่งที่ผมกำลังดำเนินการหรือถ้าฉันมีรอยขีดข่วนชั่วโมงที่ผ่านมา (s) ของการเข้ารหัส (ทราบว่านี้สามารถไปจับมือกับการทดสอบ TDD / เป็นเพียงว่าทุกอย่างกระชับลงเล็กน้อยเพื่อรับข้อเสนอแนะอย่างรวดเร็วเกี่ยวกับพื้นที่การนำไปใช้งานที่ฉันกำลังสำรวจ)
  • คุณลักษณะย่อย "ใช้งานได้" ดีพอสำหรับตอนนี้
  • ตอนนี้ทำทำความสะอาด: ก่อนที่จะมี SCC กระทำ
    • ลองดูรหัสเพื่อดูว่ามีอะไรชัดเจน
    • ทำ diff vs last commit เพื่อตรวจสอบการเปลี่ยนแปลงและอาจจะมีปัญหาบางอย่าง
    • แก้ไขสิ่งที่ฉันจดบันทึกไว้ใน scratchpad ของฉัน
  • ตอนนี้ฉันยอมรับแล้ว - คุณภาพของรหัสนี้พร้อมส่งแล้ว

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

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