ดูดน้อยทุกปี? [ปิด]


10

ดูดน้อยทุกปี -Jeff Atwood

ฉันเจอบทความที่ลึกซึ้งแล้วการอ้างอิงโดยตรงจากโพสต์

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

  1. สิ่งนี้เกิดขึ้นบ่อยแค่ไหนหรือไม่เกิดขึ้นกับคุณ?
  2. นานแค่ไหนก่อนที่คุณจะเห็นการปรับปรุงที่แท้จริงในการเข้ารหัสของคุณ เดือนปี?
  3. คุณเคยทบทวนรหัสเดิมของคุณอีกครั้งหรือไม่?
  4. รหัสเก่าของคุณทำให้เกิดภัยพิบัติบ่อยแค่ไหน หรือคุณต้องจัดการกับหนี้ทางเทคนิคของคุณบ่อยเพียงใด

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

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

  • สิ่งนี้เกิดขึ้นหรือไม่
  • ถ้าเป็นเช่นนั้นกี่ปีในการเขียนโค้ดกับภาษาใดภาษาหนึ่งคาดว่าสิ่งนี้จะเกิดขึ้น?

ที่เกี่ยวข้อง:

เคยมองย้อนกลับไปที่บางส่วนของรหัสเก่าของคุณและแสยะด้วยความเจ็บปวด?

Star Wars Moment in Code "ลุค! ฉันเป็นรหัสของคุณ!" "ไม่! เป็นไปไม่ได้! มันเป็นไปไม่ได้!"


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

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

คำตอบ:


6
  > Sucking Less Every Year ?

ไม่มีแต่ดูดที่แตกต่างกันทุกปี :-)

หลังจากการรีวิวครั้งแรกของฉันเมื่อหลายปีก่อนฉันได้รับความเดือดร้อนเกี่ยวกับการตั้งชื่อแบบแผนที่หายไป

จากนั้นฉันก็พบว่ารหัสของฉันถูกนำไปใช้ (ไม่จำเป็น) เพื่อให้เป็นรหัสทั่วไปที่สุดเท่าที่จะเป็นไปได้

จากนั้นฉันก็ได้เรียนรู้การพัฒนาเพิ่มขึ้น InversionOfControl สิ่งที่ดอทเน็ต generics ที่ไหนและอีกมากมาย

ข้อสรุป

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


19

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

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


2
ฉันเห็นด้วย 100% พวกเขาเป็นนักฆ่าเงียบ! โอ้และชื่อผู้ใช้ที่ยอดเยี่ยม xkcd? :)
jamiebarrow

@jamiebarrow: แน่นอน :)
Bobby Tables

อีกกรณีที่ล้มเหลวคือคนที่บอกว่า "ซอฟต์แวร์ทั้งหมดไม่ดีมันเป็นแฮ็คทั้งหมดความคิดของคุณสำหรับการปรับปรุงไม่สำคัญ" ชนิดของการตกต่ำในการทำงานกับประเภทเหล่านั้น
Doug T.

13

ประเด็นต่อไปนี้ไม่ใช่คำแนะนำ แต่เป็นบันทึกส่วนตัว:

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

ฉันไม่ได้เรียนรู้ทั้งหมดภายในหนึ่งปีทุกอย่างต้องใช้เวลา ...


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

ในความเป็นจริงฉันคิดว่าภายใต้ "ไม่แก้ไขถ้ามันไม่พัง" ฉันจะเพิ่ม "ถ้ามันพังและมันซับซ้อนทำซ้ำและแก้ไขข้อผิดพลาดด้วยรหัสทดสอบ"
jamiebarrow

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

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

4

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

ฉันรู้ว่าไม่มีโปรแกรมเมอร์คนใดที่ภูมิใจในซอฟต์แวร์ของเขา แต่มันดี กว่าหมายความว่าโปรแกรมเมอร์ได้เรียนรู้ในกระบวนการ

นอกจากนี้หากคุณอ่านหนังสือ "รหัสสะอาด" จากนั้นคุณจะเพิ่มรหัสของคุณเอง "ปัจจัยการดูด" หลายครั้ง : D


1
ฉันไม่เห็นด้วยกับคุณในจุดหนึ่งฉันเชื่อว่ารหัสบางอย่างที่คุณภูมิใจ สิ่งที่น่าขันก็คือคุณสามารถมีโครงการหนึ่งไปได้ดีมากและภาคภูมิใจกับมันด้วยความรำคาญเล็กน้อย จากนั้นโครงการต่อไป WTF ของคุณต่อชั่วโมงจะสูง ... สำหรับรหัสของคุณเอง! : D
jamiebarrow

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

+1 สำหรับรหัสสะอาดแม้ว่าการเปรียบเทียบจะเป็นของคุณเสมอ
Aditya P

4

จริง ๆ แล้วฉันมีเหรียญสองด้านสำหรับเรื่องนี้

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

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

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


3

อืม ... ฉันค่อนข้างประหลาดใจเป็นอย่างมากที่รหัสเก่าของฉันดีมาก

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


3
  1. สิ่งนี้เกิดขึ้นบ่อยแค่ไหนหรือไม่เกิดขึ้นกับคุณ?

  2. นานแค่ไหนก่อนที่คุณจะเห็นการปรับปรุงที่แท้จริงในการเข้ารหัสของคุณ เดือนปี?

  3. คุณเคยทบทวนรหัสเดิมของคุณอีกครั้งหรือไม่?

  4. รหัสเก่าของคุณทำให้เกิดภัยพิบัติบ่อยแค่ไหน หรือคุณต้องจัดการกับหนี้ทางเทคนิคของคุณบ่อยเพียงใด

  1. ทุกครั้งที่ฉันเรียนรู้สิ่งใหม่หวังว่าทุกวัน

  2. ถ้าฉันจะนำสิ่งที่เรียนรู้ไปใช้มันก็จะเกิดขึ้นทันทีเมื่อฉันนำมันไปใช้

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

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


3

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

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

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

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

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

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

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

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


มันเหมือนถ้าคุณถามสิ่งนี้คุณมีความเสี่ยงที่จะปรากฏเป็นเหมือนคนที่ไม่รู้วิธีเขียนโค้ดที่ดี
Aditya P

@AdityaGameProgrammer: มีความแตกต่างระหว่าง buggy, ugly code และรหัสที่ดีซึ่งหลังจากหนึ่งปีหรือน้อยกว่านั้นอาจถูกเขียนด้วยวิธีที่หรูหรากว่า (1. ) ไม่มีใครสามารถเขียนโค้ดที่สมบูรณ์แบบซึ่งจะยังคงสมบูรณ์แบบตลอดไปดังนั้นเราต้องยอมรับว่าโค้ดของเราสามารถปรับปรุงได้ตลอดเวลา (2. ) เราได้รับประสบการณ์และความรู้เมื่อเวลาผ่านไปซึ่งเป็นแหล่งสำหรับการปรับปรุงรหัสเก่า
Arseni Mourzenko

1

มันเกิดขึ้นค่อนข้างบ่อยเมื่อฉันดูรหัสและสงสัยว่า "ฉันกำลังคิดอะไรเมื่อฉันเขียนสิ่งนี้?"

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

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

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

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


1

1. สิ่งนี้เกิดขึ้นบ่อยแค่ไหนหรือไม่เกิดขึ้นกับคุณ?

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

2. นานแค่ไหนก่อนที่คุณจะเห็นการปรับปรุงที่แท้จริงในการเข้ารหัสของคุณ? เดือนปี?

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

3. คุณเคยทบทวนรหัสเดิมของคุณอีกครั้งหรือไม่?

ไม่บ่อยเท่าที่ฉันต้องการ รหัสเก่าของฉันส่วนใหญ่เป็นของนายจ้างคนก่อน ๆ รหัสส่วนบุคคลได้รับการล้างสีขาวบ่อยเกินไป

4. รหัสเก่าของคุณทำให้เกิดภัยพิบัติบ่อยแค่ไหน? หรือคุณต้องจัดการกับหนี้ทางเทคนิคของคุณบ่อยเพียงใด

การที่นายจ้างคนก่อนหน้ามีรหัสเก่าของฉันส่วนใหญ่แล้วฉันก็ต้องล้างรหัสส่วนตัวส่วนใหญ่ของฉัน ... ไม่ค่อยบ่อยนัก


White wash = ปัจจัยใหม่? คุณอ้างถึงรหัสโครงการหรือฐานรหัสส่วนตัวของคุณ
Aditya P

1
@AdityaGameProgrammer: White wash = โยนทิ้งหมดแล้วเขียนใหม่ตั้งแต่ต้น ฉันกำลังพูดถึงรหัสส่วนตัวของฉัน
Steven Evers
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.