คุณรันและทดสอบโค้ดในขณะที่เขียนโปรแกรมบ่อยแค่ไหน? [ปิด]


16

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

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

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

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


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

1
@Thorbjorn รูทีนย่อยมีความยาวประมาณ 999 บรรทัดและมีความสับสน: #define h for(int c=y-3; y; c++/(randomTypeIDefinedEarlier)s*(float)4*(lol)sin((helloWorld)mysub(2,1,++a,*(r+z))); goto xkcd)และนั่นเป็นเพียงหนึ่งบรรทัด
Mateen Ulhaq

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

คำตอบ:


6

มันขึ้นอยู่กับแง่มุมของโครงการที่คุณกำลังทำอยู่

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

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

  • สำหรับการออกแบบ UX ฉันใช้นักออกแบบภาพบางประเภทซึ่งมักจะดูว่ามันจะทำงานอย่างไร (หรือใกล้กับมัน) มันคือการรวบรวมรหัสการออกแบบ


63

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

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


12
โหวตขึ้นสำหรับ "... ไม่ฉลาดพอ .. " ฉันรู้สึกอย่างนั้นมาระยะหนึ่งแล้ว
leed25d

4
แล้วแคช L2 ของคุณล่ะ?
Mateen Ulhaq

ฉันจะลงคะแนนให้คะแนนนี้ แต่คะแนนอยู่ที่ 42 ...
Wayne Werner

รุ่นใหม่มีแคช L1 ที่ใหญ่กว่ามาก คุณซื้อของคุณเมื่อไหร่ คุณอาจต้องการไปปรับปรุงฮาร์ดแวร์
ปีเตอร์ Ajtai

ไม่ใช่อายุของโมเดลเท่าที่มันเป็น "งบประมาณ" :(
dss539

17

ฉันชอบที่จะเขียนการทดสอบของฉันก่อนที่ฉันจะเขียนรหัสการใช้งานของฉัน ฉันชอบสิ่งนี้ด้วยเหตุผลสามประการ:

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

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

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

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

1
@ Steve314: AFAIK เมื่อพิสูจน์ความถูกต้องของอัลกอริทึมอย่างเป็นทางการคุณจะต้องระบุให้ชัดเจนถึงความถูกต้องที่คาดหวัง คุณนำมาขึ้นเป็นจุดที่ดีได้ว่าคำนิยามของ "ความถูกต้อง" อาจจะไม่จริงถูกต้อง
David Weiser

1
@ dss539 ที่มาจากกรณีการใช้งานที่โปรแกรมตั้งใจจะนำไปใช้

4

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

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

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

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

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


3

ฉันรวบรวมและทดสอบว่าเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้เป็นจริง:

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

1

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

ในทางกลับกันถ้าฉันเขียนโปรแกรมด้วย Lisp ฉันจะลองใช้ฟังก์ชั่นแต่ละตัวหลังจากพิมพ์ลงไป

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


1

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


1

สามชั่วโมงต่อชั่วโมงไม่ว่าจะต้องการหรือไม่ก็ตาม

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


1

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

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


0

สำหรับฉัน -
ระยะเวลาสั้น ๆ (เวลาคิดไม่มาก) - เขียนโค้ดคอมไพล์ทดสอบ ดีบัก
เวลาที่เพียงพอ - ในขณะที่ (เสร็จสิ้น) {เขียนโค้ดขนาดเล็กคอมไพล์} ทดสอบทดสอบดีบั๊ก


ฉันพบว่าอดีตนั้นใช้เวลานานกว่าอันหลัง: คุณต้อง debug มากกว่านั้นถ้าคุณมีลูปทดสอบ / เขียนขนาดเล็กมาก
Frank Shearar

อาจจะ. แต่ระยะเวลาสั้น ๆ ก็หมายความว่า ass นั้นติดไฟแล้วและผู้จัดการต้องการรายงานซึ่งบอกว่างานบางอย่างเสร็จ 100%
Manoj R

0

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


0

ฉันลองและเขียนแบบทดสอบก่อนรหัส ฉันทำการทดสอบอย่างน้อยสองครั้งก่อนส่งคำสั่ง จากนั้นจะทำงานอีกครั้งด้วยเซิร์ฟเวอร์การรวมอย่างต่อเนื่อง

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