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


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.