เกือบเสร็จโครงการแล้ว แต่มีรหัสสปาเก็ตตี้ ฉันจะเขียนใหม่หรือพยายามส่งมันต่อไปหรือไม่? [ปิด]

ฉันเป็นนักพัฒนาเว็บมือใหม่ (มีประสบการณ์หนึ่งปี)

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

Cocky เมื่อฉันย้อนกลับไปตอนนั้นฉันได้รับอนุปริญญาด้านวิทยาศาสตร์คอมพิวเตอร์

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

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

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

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

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

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

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

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

ฉันจะเขียนใหม่หรือพยายามส่งต่อหรือมีตัวเลือกอื่นที่ฉันพลาดไปหรือไม่?

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

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

ประการที่สองคุณได้เรียนรู้สิ่งที่มีค่ามากมายดังนั้นคุณควรชื่นชมประสบการณ์ที่ได้สอน :

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

นี่คือคำแนะนำเพิ่มเติมสำหรับคุณเกี่ยวกับวิธีดำเนินการ:

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

ดูเหมือนว่าทุก ๆ ระบบที่ถูกขว้างมาให้ฉันแก้ไข

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

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

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

แก้ไข (เนื่องจากคำถามนี้มีจำนวนมากฉันอาจเพิ่มเนื้อหาเพิ่มเติมบางส่วน)

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

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

โอ้และอย่าสับสนกับการทดสอบผู้ใช้กับการทดสอบหน่วยหรือกับการทดสอบระบบ

• การทดสอบหน่วย - ฟังก์ชั่นรหัสของฉันคืนค่าที่เหมาะสมหรือไม่
• การทดสอบระบบ - ไม่เกิดข้อผิดพลาดเมื่อฉันคลิกที่ X
• การทดสอบการยอมรับของผู้ใช้ (UAT) - โปรแกรมสอดคล้องกับข้อกำหนดหรือไม่? มันทำในสิ่งที่พวกเขาขอให้คุณทำหรือไม่? สามารถถ่ายทอดสดได้หรือไม่

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

เมื่อคุณผ่านขั้นตอนนี้มาสองสามครั้งคุณสามารถเริ่มมองหา Agile .. แต่นั่นคืออีกโลกหนึ่ง :)

TL; การทดสอบDRเป็นสิ่งที่ดี

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

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

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

ล่าสุดอีกหนึ่งบิตแนะนำให้อ่านที่: บอลบิ๊กของโคลน

ฉันลืมที่ฉันอ่านครั้งแรก แต่ฉันแค่ต้องการที่จะสะท้อนค่อนข้างมีพลังมากขึ้นสิ่งที่คนอื่นพูดว่า:

การจัดส่งสินค้าเป็นคุณสมบัติ

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

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

สมบูรณ์แบบเป็นศัตรูของความดี

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

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

ฉัน [... ] อ่านโค้ดสะอาดของลุงบ๊อบ

ฉันมีความคิดที่ไม่หยุดยั้งนี้ฉันต้องเขียนโครงการใหม่ทั้งหมด

หนังสือเล่มนี้มีส่วนชื่อเหมาะสมมาก "The Grand Redesign in the Sky"

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

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

คุณทำได้ดี

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

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

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

กรณีเดียวที่ฉันเห็นการเขียนซ้ำที่สมบูรณ์ทำได้ดีมากคือเมื่อทีมนำเครื่องมือ / กรอบงานใหม่มาใช้พร้อมกัน

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

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

เวลาที่ดีกว่าในการเขียนทุกอย่างใหม่ก็คือเมื่อลูกค้ารายอื่นขอให้คุณสร้างสิ่งที่คล้ายกัน

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

สิ่งที่ฉันจะพูดเพื่อตอบคำถามของคุณได้รับการกล่าวถึงโดยคนอื่น อ่าน "สิ่งที่คุณไม่ควรทำตอนที่ฉัน" โดย Joel Spolsky (พร้อมด้วยข้อความอื่น ๆ ของเขาเกี่ยวกับ "นักบินอวกาศสถาปัตยกรรม") จำไว้ว่า "ความสมบูรณ์แบบคือศัตรูของความดี" เรียนรู้การ refactor ทีละน้อย การจัดส่งสินค้าเป็นสิ่งสำคัญ ฯลฯ

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

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

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

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

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

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

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

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

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

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

นี่คือสิ่งที่ฉันจะทำเอง:

1. ออกทำข้ออ้างและยอมแพ้ (คุณสามารถคืนเงินส่วนหนึ่งได้ดังนั้นคุณจะไม่ดูแย่)
2. ทำความสะอาดรหัสของคุณให้มากที่สุด
3. จัดทำเอกสารในส่วนที่ดีทั้งหมดของงานของคุณเช่นการออกแบบที่ดีความคิดที่ดี ฯลฯ

ทำไมฉันถึงแนะนำสิ่งเหล่านี้ให้คุณ?

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

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

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

อีกสองข้อเสนอแนะฉันจะพนันอย่างน้อยหนึ่งข้อที่คุณยังไม่ได้ทำ

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

2) เริ่มใช้การควบคุมเวอร์ชันแม้ว่าหวังว่าคุณจะทำเช่นนั้นแล้ว

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

แก้ไข

ว้าวมีบางคนไม่ชอบสิ่งนี้ - downvote และการตั้งค่าสถานะการลบ? ทำไม?

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

เพื่อตอบคำถามของคุณ: ดังที่คนอื่น ๆ พูดไว้ไม่ จัดส่งและทำความสะอาดทีละขั้นตอนในการแก้ไขข้อบกพร่อง

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

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

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

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