ส่วนใหญ่ของรหัสของฉันมีข้อบกพร่องในการออกแบบที่สำคัญ ปิดมันหรือแก้ไขมันตอนนี้เหรอ? [ปิด]


186

ฉันเป็นนักเรียนมัธยมปลายที่ทำงานในโครงการ C # กับเพื่อนของฉันเกี่ยวกับระดับทักษะเดียวกันกับฉัน จนถึงตอนนี้เราได้เขียนโค้ด 3,000 บรรทัดและโค้ดทดสอบ 250 บรรทัดในช่วง 100 คอมมิต เนื่องจากโรงเรียนฉันจึงเลื่อนโครงการไปสองสามเดือนและเมื่อเร็ว ๆ นี้ฉันสามารถเลือกได้อีกครั้ง

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

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

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

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


13
อย่างจริงจัง: การมีข้อบกพร่องด้านการออกแบบที่สำคัญในผลิตภัณฑ์ของเขาไม่เคยหยุด Larry Ellison ทำไมปล่อยให้มันรบกวนคุณ
— Pieter Geerkens

54
งานก็ไม่ได้ไปเสียเปล่า มันทำให้คุณเป็นโปรแกรมเมอร์ที่ดีขึ้น
— sampathsris

10
นี้อาจจะไม่นำไปใช้กับคุณในขณะนี้ แต่ในอนาคตถ้าคุณเขียนสิ่งที่คุณตั้งใจที่จะรักษาอย่างมืออาชีพไม่เคยทำเขียนขนาดใหญ่ขนาดใหญ่
— gcampbell

8
@JoeBlow "ซอฟต์แวร์ 100% กลายเป็นไร้ประโยชน์อย่างรวดเร็วและจะต้องทำซ้ำตั้งแต่เริ่มต้น" คำสั่งนี้ไม่สมเหตุสมผล คุณกำลังบอกฉันว่าซอฟต์แวร์ที่ฉันใช้ทุกวัน ... ไร้ประโยชน์อย่างสมบูรณ์และต้องทำใหม่ตั้งแต่ต้น?
— oldmud0

10
"ใช่ - แน่นอนไม่มีใครใช้ OS9 หรือ Windows3 ซอฟต์แวร์เป็นสิ่งที่น่าสังเกต" ตามปกติคุณเข้าใจผิดแม้จะมีความมั่นใจ! เคอร์เนล Windows NT ซึ่งเปิดตัวใน NT 3.1 นั้นเป็นแกนหลักของ Windows 10 แม้แต่ Windows ยังไม่มี "การเขียนใหม่ทั้งหมด" ในระยะเวลา 20 ปี
— Lightness Races ในวงโคจร

คำตอบ:


273

ถ้าฉันอยู่ในรองเท้าของคุณฉันอาจจะลองแบบนี้:

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

  • แล้วและเพียงแล้วคิดเกี่ยวกับการเขียนจากรอยขีดข่วน (ช่วยให้เรียกสิ่งนี้ว่า "รุ่น 2.0") บางทีคุณสามารถใช้รหัสบางส่วนใหม่ได้ตั้งแต่ V1.0 บางทีหลังจากนอนหลับอีกครั้งในสถานการณ์ที่คุณตัดสินใจคุณสามารถ refactor V1.0 และบันทึกส่วนใหญ่ แต่อย่าตัดสินใจก่อนที่จะไม่มี "การพิสูจน์แนวคิด V1.0" ในมือ

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

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


71
นอกจากนี้ยังอาจดูรุ่นที่ใช้งานได้เป็นโอกาสในการเรียนรู้เกี่ยวกับกระบวนการการเปลี่ยนโฉม
— jpmc26

20
นี้. ฉันมักจะพบมากกว่าหนึ่งพวงของข้อบกพร่องการออกแบบ / ปรับปรุงข้อ จำกัด การออกแบบ / ความต้องการในขณะที่ฉันคืบหน้าจากอะไรไปต้นแบบการทำงานที่ 1 การเข้าถึงสถานะการทำงานจริงเป็นสิ่งสำคัญ
— ยูจีน Ryabtsev

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

9
การทำโครงงานเสร็จจะช่วยให้คุณเห็นปัญหาที่อาจเกิดขึ้นที่คุณยังไม่เคยเจอและอาจแสดงให้คุณเห็นว่าบางสิ่งที่คุณคิดว่าเป็นปัญหาอาจไม่ใหญ่เท่าที่คุณคิด จดบันทึกที่ดีและเริ่มออกแบบแผนสำหรับ 2.0 ในขณะที่คุณเสร็จสิ้น 1.0
— CaffeineAddiction

9
ประโยคสุดท้ายนั้นน่าทึ่ง:Better take this as an opportunity to learn how to achieve intermediate goals, instead of an opportunity to learn how to leave projects in an unfinished state behind.
— แบรนดอน

119

โครงการไอทีที่เสร็จสมบูรณ์แล้วแม้แต่โครงการที่ผิดพลาดก็ยังดีกว่าโครงการที่ยังไม่เสร็จ

คนที่ยังไม่เสร็จสามารถสอนคุณได้มากเช่นกัน แต่ไม่มากเท่ากับคนที่เรียนจบ

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

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

จากมุมมองของการจ้างงานในกรณีส่วนใหญ่คุณจะได้รับความชื่นชมมากขึ้นสำหรับโครงการที่เสร็จสมบูรณ์


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

56

ฉันจะเริ่มโครงการอย่างมีความสุข

คุณเป็นนักเรียนและคุณยังเรียนรู้อยู่ สิ่งนี้ทำให้คุณอยู่ในตำแหน่งที่แตกต่างจากคำถามที่คุณเชื่อมโยง

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

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

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

  • การทำงานใน codebase ที่ใช้งานไม่ได้จะทำให้คุณขวัญเสียยิ่งกว่าการเขียนใหม่

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

ในที่สุดนี่คือความคิดเห็นหนึ่งเกี่ยวกับภูมิปัญญาของบางครั้งการก้าวถอยหลังเพื่อก้าวไปข้างหน้า


46
การเขียนใหม่จาก Scrarch นั้นไม่ค่อยได้เรียนรู้จากความผิดพลาดและมักจะสร้างใหม่
— whatsisname

28
ในความคิดของฉันการเสร็จสิ้นโครงการมีความสำคัญมากกว่านั้นคือการมีโครงการที่สมบูรณ์แบบ การคุกคามของการวนซ้ำ "ไม่ดีพอ" นั้นเป็นจริง
— Pieter B

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

15
มันควรจะเน้นคน OP ที่ทำงานในโครงการของเล่น ฉันได้อ่านบทความของ Joel เกี่ยวกับการเขียนใหม่ตั้งแต่ต้นและไม่มีประเด็นใดที่เกี่ยวข้องกับคดีนี้ OP ไม่ได้ขายรหัสให้กับโลกแห่งความเป็นจริงไม่มีเส้นตาย ฯลฯ การใช้เวลาสองเท่าในการเขียนโปรแกรมเวลาทำให้พวกเขาเรียนรู้มากขึ้นเป็นสองเท่า
— Kevin

6
@whatsisname พวกเขาจะไม่ทำผิดพลาดแบบเดียวกัน ดังที่คุณกล่าวข้างต้นพวกเขาจะสร้างสิ่งใหม่ซึ่งจะสอนสิ่งใหม่ให้กับพวกเขา
— Kevin

34

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

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

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

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


25

ฉันทำตามอุดมการณ์"ทำให้ทำงานถูกต้องทำให้เร็ว"ในการพัฒนาซอฟต์แวร์

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

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

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

การพูดสร้างแรงบันดาลใจที่ดี: เพียงแค่ทำมัน

เช่นเคยมี xkcd ที่เกี่ยวข้อง:

การเพิ่มประสิทธิภาพ xkcd


1
ในโอเพ่นซอร์สคุณสามารถแทรกขั้นตอนที่ 0 "เพียงแค่สร้างมัน" แม้ว่ามันจะไม่ได้ผลถ้ามันน่าสนใจพอปล่อยมันและอาจมีคนช่วยคุณด้วยขั้นตอนที่ 1
— Jörg W Mittag

1
ส่วนตัวผมชอบรหัสที่ถูกต้อง ฉันคิดว่าการออกแบบที่ถูกต้องอาจมีประโยชน์มากกว่ารหัสที่เป็นปัญหา ไม่คำนึงถึงลำดับ # 1 และ # 2 ฉัน +1 เพราะฉันชอบเห็นการแยกบันทึก หากมีปัญหาการใช้งานที่สำคัญเช่นการตรวจสอบสภาพการแข่งขันปัญหาดังกล่าวมักจะสามารถแก้ไขได้โดยไม่จำเป็นต้องออกแบบ API ใหม่ (ฟังก์ชั่นที่เรียกว่าอะไร) ดังนั้นคุณสามารถแก้ไขข้อผิดพลาดได้โดยมุ่งเน้นที่รายละเอียดการใช้งาน สิ่งที่ออกแบบในระดับสูงกว่าการทำงาน ดังนั้น (อาจ) สามารถมีค่าในการมีรหัส (กึ่ง?) การทำงานของรหัส
— TOOGAM

ฉันไม่คิดว่าสิ่งนี้ใช้ได้ สหกรณ์จะเห็นได้ชัดว่าการพูดคุยเกี่ยวกับปัญหาการออกแบบพื้นฐาน คุณไม่สามารถ "แก้ไข" อย่างปลอดภัยในภายหลัง
— Lightness Races ในวงโคจร

1
อย่าลืมขั้นตอนที่ 0.5, 1.5, 2.5 และ 3.5: ทำให้อ่านได้
— candied_orange

23

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

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

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


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

2
ที่โค้ด 3k บรรทัดอาจใช้เวลานานกว่าในการตรวจสอบการคอมมิทแล้วจึงเขียนใหม่ทั้งหมด
— Matthew Whited

เกี่ยวกับ repo คอมไพล์เพียงลบและเริ่มต้นใหม่ รหัสปัจจุบันเกือบจะไม่มีค่าทั้งหมดอย่างแน่นอน มีเหตุผลอะไรที่จะเก็บไว้ในเซิร์ฟเวอร์บ้าง - ไม่มี. คลิกที่ลบ
— Fattie

1
@JoeBlow: ไม่มีเหตุผลที่จะลบ repo git เพียงสร้างสาขาใหม่ คุณไม่สามารถบอกได้เมื่อคุณอาจต้องการอ้างอิงถึงสิ่งเก่า ๆ
— วินไคลน์

19

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

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

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


12

ฉันไม่เห็นด้วยอย่างสุภาพด้วยคำแนะนำที่เขียนใหม่เป็นความคิดที่ไม่ดี

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

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


3
"อุตสาหกรรมที่ยอมรับ" หมายถึงอะไร แหล่งที่มาของจำนวนคืออะไร?
— Christian

1
@Christian นี้น่าจะเป็นแหล่งที่มา: ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20100036670.pdf

1
TDD เป็นวิธีที่จะไป!
— 2rs2ts

10

คุณทำให้ฉันตกอยู่ในประโยคนี้:

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

ฉันเชื่อในหลักการ (ระบุไว้ในSystemantics ) ว่า

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

ดังนั้นการเขียนระบบที่ซับซ้อนรวมถึง

  • การเขียนระบบอย่างง่าย
  • ทำให้แน่ใจว่ามันใช้งานได้

... เช่นขั้นตอนต่อไปนี้:

  1. เขียนรหัสเล็กน้อย
  2. ทดสอบเพื่อให้แน่ใจว่าใช้งานได้
  3. เขียนโค้ดเพิ่มอีกนิด
  4. ทดสอบอีกครั้ง
  5. เป็นต้น

โปรดทราบว่าขั้นตอนที่ 3 อาจเกี่ยวข้องกับ:

  1. เขียนโค้ดเพิ่มอีกนิด
    1. refactor รหัสที่มีอยู่เพื่อเตรียมการสำหรับการเพิ่มใหม่
    2. ทดสอบการปรับโครงสร้างใหม่เพื่อให้แน่ใจว่ายังใช้งานได้
    3. เพิ่มฟังก์ชั่นใหม่

นอกจากนี้ขั้นตอนที่ 2 "ทดสอบเพื่อให้แน่ใจว่าใช้งานได้" อาจเกี่ยวข้องกับการเขียนใหม่หากไม่เป็นเช่นนั้น

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

  • ซอร์สโค้ดนั้นง่ายกว่า
  • และไม่มีข้อบกพร่องใหม่แนะนำ
  • (และกำจัดแมลงเก่าบางตัว)

อนึ่ง "การทดสอบเพื่อให้แน่ใจว่าการทำงาน" ไม่ได้หมายความว่า "การทดสอบหน่วย" - เมื่อโครงสร้างทีมเป็นเรื่องง่ายที่คุณสามารถทดสอบ (แบบง่าย) ระบบโดยใช้การทดสอบ (แบบง่าย) ระบบ (แทนการทดสอบหน่วย)


7

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

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

เขาโกรธ แต่ 3 วันต่อมาเขาก็จบโปรแกรมด้วยโค้ดที่สะอาดและมีข้อบกพร่องน้อยกว่าและมีโค้ดน้อยกว่า

พยายามประเมินอย่างซื่อสัตย์เกี่ยวกับตัวเลือกที่ดีที่สุดในเวลาที่พร้อมใช้งานสำหรับโครงการ

มีให้เลือก 3 แบบ

  • ลบออก (สมบูรณ์ไม่มีการมองย้อนกลับ)
  • ทำงานต่อในการออกแบบเก่า
  • รหัส refactor ในขณะที่คุณไป

ฉันเป็นโปรแกรมเมอร์มืออาชีพมานานกว่า 10 ปีและในสายงานของฉันฉันได้สรุปว่าตัวเลือกสุดท้ายเป็นตัวเลือกที่ดีที่สุด แต่ก็ไม่ใช่ตัวเลือกที่ดีที่สุดเสมอไป


3
ฉันเคยมีรหัสที่มีจุดบกพร่อง ฉันใช้เวลาสามวันเพื่อค้นหาข้อผิดพลาดเมื่อการทดสอบของฉันมลายไปและฉันประสบความสำเร็จในการลบรหัสไม่มีการสำรองข้อมูล ฉันเขียน codebase ทั้งหมดจากหน่วยความจำในทุกที่ที่มีข้อบกพร่องทั้งหมดของฉันได้หายไป ประมาณ 3,000 บรรทัดรหัสเบส ดังนั้นบางครั้งมันกังวล แต่ในการผลิตสิ่งนี้ไม่เคยเกิดขึ้น
— joojaa

6

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

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

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


6

refactor refactor Refactor! refactor !!!!

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

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

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

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

จะมีบางสิ่งที่จะนำกลับมาใช้ใหม่


4

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

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

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

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


3

คุณต้องใส่ตัวเองในรองเท้าของนายจ้าง

สำหรับนายหน้าส่วนใหญ่คุณจะมีค่ามากที่สุดถ้าคุณทำแบบนี้: - จบด้วยการทดสอบ 100% สำหรับรหัสใหม่ที่คุณเขียน - เพิ่มการทดสอบสำหรับรหัสเก่า (ออกแบบไม่ดี) - ปรับโครงสร้างใหม่เพื่อให้ได้สิ่งที่คุณต้องการในการออกแบบ

ทำทุกอย่างด้วยกระบวนการกำหนดเวอร์ชันสาขาและแท็กที่ดี

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

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


นายจ้างคนไหน OP อยู่ในโรงเรียนมัธยมทำโครงการสัตว์เลี้ยง
— Lightness Races ในวงโคจร

การแสดงอย่างมืออาชีพตั้งแต่เริ่มต้นต้องไม่เลวร้ายเกินไปและโรงเรียนมัธยมไม่ไกลจากโอกาสในการทำงานจริง IMHO
— Steve Chamaillard

1
"การแสดงอย่างมืออาชีพ" ไม่มีอะไรเกี่ยวข้องเลยไม่ว่าคุณจะปรับโครงสร้างใหม่หรือไม่ก็ตาม
— การแข่งขัน Lightness ใน Orbit

มันมีในบางวิธี การเริ่มโครงการและสูญเสียงานเป็นมืออาชีพส่วนใหญ่ในขณะที่ refactoring มันและการปรับปรุงจึงแสดงผลลัพธ์ที่ดีขึ้นในระยะยาว (ส่วนใหญ่)
— Steve Chamaillard

และนี่ไม่ใช่หนึ่งในนั้น
— การแข่งขัน Lightness ใน Orbit

3

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

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

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

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


3

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

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


2

ทั้ง? ทั้งสอง?

ดำเนินการต่อไปใช้เวลาในการทบทวนการออกแบบที่มีอยู่และเพิ่มฟังก์ชั่นใหม่

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

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

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


2

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

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


2

คำถามแรกที่คุณควรถามตัวเองว่า "ข้อบกพร่องนั้นเลวร้ายเพียงใด"

คุณทำผิดอะไร

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


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

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

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


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


1

ขึ้นอยู่กับว่าโค้ดของคุณยุ่งแค่ไหน

  • หากคุณทำข้อผิดพลาดจริง n00b ซึ่งทำให้รหัสของคุณซับซ้อนหรือ verbose มากเกินไปฉันขอแนะนำให้เขียนส่วนเหล่านั้นใหม่

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

  • หากคุณไม่ชอบสิ่งที่เรียกว่าวิธีการหรือสิ่งที่พวกเขาอยู่ในชั้นเรียนหรือสิ่งเล็ก ๆ เช่นนั้นเพียงแค่ใช้ IDE (จำไว้ว่านี่คือ C # ไม่ใช่ javascript, python, perl, php ฯลฯ ) เมื่อคุณทำงานกับโค้ดที่ใช้องค์ประกอบที่ได้รับผลกระทบและคุณมีภาพที่ชัดเจนในหัวของสิ่งที่องค์ประกอบนั้นควรทำ จากนั้นทำการสร้างใหม่ถ้า IDE ของคุณทำให้ไม่เจ็บปวด

มิฉะนั้นให้ทำงานและฝึกฝนทักษะของคุณในโครงการต่อไป


1

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

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

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

เหตุผลสองสามข้อในการพิจารณาเลือกการเขียนซ้ำเป็นการทดสอบของคุณ:

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

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

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