เครื่องมือการเขียนโปรแกรมที่ประเมินต่ำที่สุดส่วนใหญ่ [ปิด]


35

เรามีเครื่องมือที่ยอดเยี่ยมมากมายซึ่งช่วยได้มากเมื่อการเขียนโปรแกรมเช่นโปรแกรมเมอร์ตัวแก้ไขข้อความที่ดี IDEs, debuggers, ระบบควบคุมเวอร์ชันเป็นต้นเครื่องมือบางอย่างมีมากหรือน้อย "ต้องมี" เครื่องมือสำหรับการทำงานให้สำเร็จ (เช่นคอมไพเลอร์) .

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

คุณทำอะไรประเภทของเครื่องมือการเขียนโปรแกรมคิดว่าเป็นประเมินมากที่สุดคนหนึ่ง? กระตุ้นคำตอบของคุณ


3
สมองของเรา - -
Trufa

ตกลงใครต้องการเพิ่มรายการเสียงกระเพื่อมใคร * grin *
ทำเครื่องหมาย C

คำตอบ:


70

เป็ดยางพารา ใช่จริงๆ.

http://en.wikipedia.org/wiki/Rubber_duck_debugging

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

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


6
ฉันทำสิ่งนี้ตลอดเวลากับสามีของฉัน ในฐานะผู้สนับสนุนด้านเทคนิคที่มีความสามารถในการเขียนโปรแกรมเพียงเล็กน้อยเขาเข้าใจถึง 60% ของสิ่งที่ฉันพูด แต่บังคับให้ฉันอธิบาย 40% ที่ฉันไม่เข้าใจเช่นกัน จำนวนครั้งที่มันใช้งานได้ค่อนข้างน่าประทับใจ
Ethel Evans

1
คุณหัวเราะ. ฉันมีเพื่อนร่วมงานมีเป็ดยางอยู่บนโต๊ะของเธอ
Berin Loritsch

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

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

1
@ Steve: นักวิจัยชาวญี่ปุ่นกำลังทำอยู่ แต่ฉันไม่คิดว่าพวกเขาจะอยู่ใกล้ทุกที่: youtube.com/watch?v=3g-yrjh58ms
Rei Miyasaka

42

ปากกาและสมุดโน้ต

  1. ทำงานโดยไม่มีกระแสไฟฟ้า
  2. แบบพกพา
  3. Doodle เปิด / ในเมื่อเบื่อในการประชุม
  4. เก็บข้อมูลที่เป็นประโยชน์
  5. ถ้าเขียนลงไปคนก็ให้ความสำคัญกับมันมากกว่า
  6. คนอื่นสามารถอ่านและเรียนรู้

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

3
รัสเซียใช้ดินสอ
งาน

@Job Hah ฉันยังใช้หมึกหนึ่งขวด! (... ก็แค่เขียนตัวอักษร แต่ก็ยัง :))
Mateen Ulhaq

แท็บเล็ตพีซีล่ะ
Mateen Ulhaq

1
@Job: ... และวอดก้า!
Spoike

38

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

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

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


1
++ แน่นอนdiffเป็น underappreciated ในเรื่องของการทำโปรไฟล์คุณไม่ได้คิดว่าคนเดียวต้องมีประโยชน์ แต่ตัวคุณเองก็ไม่รู้เหมือนกัน ตรวจสอบสิ่งนี้
Mike Dunlavey

ใช่ฉันได้คิดเกี่ยวกับการเรียนรู้เครื่องมือการทำโปรไฟล์ แต่ไม่เคยทำเช่นนั้น
Anto

23
+1 สำหรับการทำโปรไฟล์ +1 สำหรับเครื่องมือ diff และ -1 สำหรับเครื่องมือ XML บางคนเมื่อพบปัญหาให้คิดว่า "ฉันรู้ฉันจะใช้ XML" <Problem:Worsening> <Problem:TimeDescription>Now</Problem:TimeDescription> <Problem:Posessive>they have</Problem:Posessive> <Problem:Quantity>many, many</Problem:Quantity> <Problem:WorseningDescription>more problems</Problem:WorseningDescription></ProblemWorsening>
Mason Wheeler

2
@Mason: XML น่ารัก
Mike Dunlavey

10
@ Mason Wheeler: ฉันไม่ได้แนะนำ XML เป็นเครื่องมือในการแก้ปัญหาฉันแนะนำเครื่องมือ XML ที่ดี - เมื่อคุณต้องทำงานกับ XML ตรวจสอบให้แน่ใจว่าคุณมีเครื่องมือแก้ไข / แก้ไขที่ดีมาก สิ่งที่สามารถประมวลผลคำสั่ง Xpath, การตรวจสอบความถูกต้องของ schema, การแปลงค่า, ค่าเปรียบเทียบกับโครงสร้าง (เครื่องมือ diff แบบพิเศษที่ฉันเดา) ฯลฯ ... บรรณาธิการที่เรียบง่ายพร้อมการเน้นไม่สามารถตัดมันได้เมื่อสิ่งต่างๆ แย่กว่า (btw ฉันชอบรหัส XML ของคุณ;))
FrustratedWithFormsDesigner

37

นิพจน์ทั่วไป

พวกมันมีประโยชน์มาก พวกเขาช่วยเมื่อค้นหาไฟล์บันทึกการแยกข้อความ ฯลฯ พวกเขามีประโยชน์มาก

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


8
โปรดจำไว้ว่านิพจน์ทั่วไปไม่ใช่มีดทหารของสวิสแม้ว่าจะใช้ได้ดีเมื่อใช้อย่างถูกต้องก็ตาม
Anto

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

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

4
อืมด้วยเหตุผลบางอย่างที่ฉันได้รับความประทับใจ regex อยู่ไกลจากการประเมินต่ำเกินไป บ่อยครั้งที่ฉันเห็นคนเข้าถึง regex โดยที่ split / for-loop ง่าย ๆ จะพอเพียงหรือเมื่อ regexes ไม่ใช่คำตอบ (เช่นการแยก xml / html)
MAK

ฉันเคยเห็นปรากฏการณ์ทั้งสอง: Regex? สิ่งนั้นไม่สามารถอ่านได้ / ช้า / แทรกดูถูกที่นี่และ "เป็นวิธีที่ดีที่สุดในการแยก (แทรกไวยากรณ์ที่ไม่ปกติอย่างสมบูรณ์) ด้วย regex เดียวคืออะไร"
JasonTrue

24

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

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


เพื่อนร่วมทีมที่ดีจะไม่มีวันเกินคุณค่า ซอฟต์แวร์และฮาร์ดแวร์ส่วนใหญ่สามารถ
ประเภทไม่ระบุชื่อ

19

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


13
เครื่องมือที่ดี แต่ฉันไม่แน่ใจว่าฉันเรียกมันว่าประเมินต่ำกว่านี้อย่างน้อยก็ไม่อีกแล้ว (บางทีฉันอาจจะเห็นด้วยกับ 9 หรือ 10 ปีก่อน)
FrustratedWithFormsDesigner

12
ฉันขอโทษ แต่ Google ประเมินต่ำเกินไป อย่างน้อยที่สุด Google ก็ถูกประเมินค่ามากเกินไป :)
eestein

2
ฉันรู้ว่าฉันรู้ว่า! แต่เหตุผลของฉันที่บอกว่าประเมินต่ำเกินไปเป็นสิ่งที่ฉันสงสัยว่าคุณจะเห็นด้วย: อย่างน้อย 75% ของคำถามที่ถามเกี่ยวกับ StackOverflow นั้นสามารถตอบคำถามกับ Google ได้อย่างง่ายดายใช่ไหม? เห็นได้ชัดว่ามันเป็นระดับที่ต่ำกว่าถ้าคนจำนวนมากไม่ได้ใช้มัน หากเหตุผลของฉันมีข้อบกพร่องฉันจะลบคำตอบของฉัน
Adam Crossland

3
@ Adam Crossland: 75% เป็นคนใจดี ฉันคิดว่ามันสูงกว่านั้น
S.Lott

1
@adam @ s.lott ดังนั้นฉันเดาว่าประเด็นคือ Google ใช้ไม่ถูกต้อง ด้วยที่ฉันเห็นด้วย สามารถตอบคำถามได้มากมาย (ไม่จำเป็นต้องถาม) หากผู้คนรู้วิธีการใช้ Google อย่างถูกต้อง ความนับถือ.
eestein

16

เครื่องมือที่ประเมินค่าต่ำที่สุดที่อยู่ไกลออกไปเพื่อค้นหา "คอขวด" คือCtrl+ Cหรือปุ่ม "หยุดชั่วคราว" ในตัวดีบั๊ก

ตรวจสอบย่อหน้าสุดท้ายของการโพสต์นี้และโพสต์นี้และโพสต์นี้สำหรับการเริ่ม

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

ใช่นี่คือ downvote-bait แต่ใช้งานได้


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

@Kristof: มันดึงดูดที่จะคิดอย่างนั้นและมีปัญหาที่ไม่สามารถจัดการได้และมีบางกรณีที่ตัวอย่างไม่ง่ายที่จะได้รับ แต่ Profilers ไม่สามารถจัดการกับกรณีเหล่านั้นได้เช่นกันยกเว้นบางประเภทเช่นซูม และถึงอย่างนั้นพวกเขาก็ไม่ได้ดีขึ้นในแง่ของการนำคุณไปสู่ปัญหา
Mike Dunlavey

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

14

เครื่องมือการเขียนโปรแกรมประเภทใดที่คุณคิดว่าต่ำที่สุด กระตุ้นคำตอบของคุณ

คอมไพเลอร์

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


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

@ Matthieu M นั่นเป็นจุดที่ดีเช่นกัน หลายคนลืมวิธีง่าย ๆ ที่จะช่วยคุณ
kemiller2002

3
คำเตือนของคอมไพเลอร์ทุกชิ้นเป็นของขวัญล้ำค่า อย่าเพิกเฉย! ขอข้อมูลเพิ่มเติม! - ผู้ชนะควรได้รับคำสั่ง
Kristof Provost

@Kristof: -pedantic -Wall -Wextra -Werror... แม้ว่ามันจะยากที่จะสร้างอะไรก็ตาม: p
Matthieu M.

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

10

สมองของคุณ. เครื่องมืออื่น ๆ คงไม่มีความหมายอะไรมากหากปราศจากมัน


4
ฉันแสดงผลงานของฉันเป็นส่วนใหญ่ในบางครั้ง
David Thornley

3
"ถูกลืมมากขึ้นหรือน้อยลง": -S

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

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

1
ความคิดเห็นบางอย่างทำให้ฉันเปลี่ยนความเห็นของฉัน +1 :)
แอนโต

10

ดีมาก:

print

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


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

8

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


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

1
จริงสคริปต์ที่ยิ่งใหญ่ดูน่ากลัวและอาจใช้ Perl หรือ Python แม้ว่าพวกเขาจะยังยอดเยี่ยมในการทำงานเล็ก ๆ ให้สำเร็จ
Gaurav Sehgal

@Billy ใช้ python แก้ไขปัญหาสปาเก็ตตี้แล้ว :)
Evan Plaice

7

ปากกาและไวท์บอร์ด

คุณไม่สามารถเอาชนะเทคโนโลยีระดับต่ำเมื่อพยายามอธิบายบางอย่าง



อาจเป็นคำตอบที่ซ้ำกัน แต่ได้รับการโหวตของฉันแยกต่างหากสำหรับไวท์บอร์ด
Carson Myers

อืมค่อนข้างแน่ใจว่ามันไม่ซ้ำกันเมื่อฉันสร้างมันแปลกมาก ฉันจะเปลี่ยนเป็นปากกาและไวท์บอร์ด
Andy Lowry

6

แอ๊กชั่น มันก็เหมือนgrep -rแต่มันถูกออกแบบมาสำหรับ seaching ผ่านซอร์สโค้ดของคุณ


5

Perl และภาษาสคริปต์อื่น ๆ เหมาะสำหรับงานที่ซับซ้อนเกินไปสำหรับเครื่องมือ GUI เช่น Agent Ransack


1
ฉันไม่แน่ใจว่าพวกเขาจะถูกประเมินต่ำเกินไป ...
Anto

3
ประเมินต่ำกว่าแน่นอน ... โดยเฉพาะ Perl มันคือหรั่ง ได้รับการออกแบบมาเป็นอย่างดีด้วยคำขวัญที่เรียบง่าย แต่คงไว้ซึ่งความมีค่าสำหรับงานด่วนที่ต้องทำให้เสร็จ
โกง

@ Rook: ฉันไม่แน่ใจว่าภาษาที่มีผู้ให้บริการมากกว่า 100 รายจะถูกพิจารณาว่า "เรียบง่าย" ได้อย่างไร มีประโยชน์เป็นไปได้ แต่ไม่ใช่ "เรียบง่าย"
Billy ONeal

@Billy - Simple ไม่รวมพลัง ฉันพบเครื่องคิดเลขง่าย ๆ ฉันไม่ทราบว่าครึ่งหนึ่งของฟังก์ชั่น 300 รายการของฉันมีอะไรบ้าง แต่ก็ไม่ได้ลดความเรียบง่ายลง
โกง

4

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

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

การทดสอบหน่วยและ TDD มาถัดไปเพื่อให้รหัสของคุณสามารถทดสอบได้และป้องกันความกลัวในการปรับโครงสร้างใหม่

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


4

การทดสอบหน่วยมีประโยชน์ดังต่อไปนี้:

  • นักพัฒนากลายเป็นลูกค้ารายแรกของรหัส ยิ่งจับจุดบกพร่องได้เร็วเท่าไหร่ก็ยิ่งมีราคาถูกลงเท่านั้น ข้อบกพร่องที่อาจจะถูกจับก่อนที่จะสร้างการติดตั้งหรือใช้งาน
  • การทดสอบจะเปลี่ยนมุมมองของคุณในรหัส การออกแบบชัดเจนหรือไม่ มันจัดการกรณีมุม?
  • Hawthorne Effectจะปรับปรุงคุณภาพโดยการประกาศว่าทีมกำลังเผยแพร่การวัดคุณภาพ / การทดสอบ
  • แม้ว่าการทดสอบจะไม่ได้รับการตรวจสอบในการควบคุมแหล่งข้อมูล แต่ก็เป็นวิธีที่ดีในการสำรวจและเรียนรู้ภูมิประเทศใหม่
  • ความน่าจะเป็นสูงที่มีข้อผิดพลาดน้อยลง!

4

เครื่องกำเนิดรหัส

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

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


ฉันชอบเขียนโค้ดกำเนิดไม่ใช่สิ่งที่ง่ายที่สุดที่จะทำถูกต้อง แต่มีประโยชน์มาก
Zachary K

3

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


3

วิธีการอย่างเป็นทางการ

http://www.amazon.com/Discipline-Programming-Edsger-W-Dijkstra/dp/013215871X

http://www.amazon.com/Science-Programming-Monographs-Computer/dp/0387964800/ref=pd_sim_b_1

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

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

มันเป็นเพียงพีชคณิต (และแคลคูลัส) สำหรับรหัส ไม่มีอะไรซับซ้อนหรือซับซ้อนเกินไป


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

3

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


3

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


3

Stack Overflow - ความช่วยเหลือจากผู้เชี่ยวชาญอย่างรวดเร็วเมื่อคุณติดขัด

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


+1 แต่ไม่ผ่านการประเมินต่ำกว่านี้จริงๆ
MAK

4
อาจจะประเมินค่าสูงเกินไปหรืออย่างน้อยก็มากเกินไป
Anto

3

ฉันคิดว่ามันเป็นNotepad / TextPad / โปรแกรมแก้ไขข้อความอย่างง่าย ทุกคนมีเวลาที่พวกเขาต้องการการแก้ไขด่วนที่ไม่ต้องเปิด IDE และต้องการเพียงแค่การแก้ไขอย่างรวดเร็ว และคอมพิวเตอร์ทุกเครื่องมีโปรแกรมแก้ไขข้อความอย่างง่าย


2

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

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

สิ่งหนึ่งที่พบบ่อยเกี่ยวกับการยืนยันคือพวกเขาสามารถปิดได้ IMHO ทุกภาษาหรือไลบรารี่มาตรฐานควรมีalwaysAssert()ฟังก์ชั่นหรือเทียบเท่าคร่าวๆที่ทำสิ่งเดียวกันassertแต่ไม่สามารถปิดได้ สามารถใช้สำหรับการตรวจสอบสมมติฐานในส่วนที่ไม่สำคัญต่อประสิทธิภาพของโค้ดซึ่งประโยชน์ของการปิดการยืนยันนั้นไม่มีความสำคัญ


ตกลง แต่น่าเสียดายที่เครื่องมือที่เรียบง่าย แต่มีประสิทธิภาพเช่นนี้มักไม่ค่อยได้รับการพิจารณา
Peter Mortensen

2

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

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


2
ทั้ง underestimated และ underimplemented
ประเภทไม่ระบุชื่อ

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

2

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


2

ความอยากรู้

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



1

หาง

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

โปรแกรมตัวอย่างคือ;


Mac OS X เป็นระบบ UNIX ไม่จำเป็นต้องพูดถึงมันแยกกัน
rightfold

0

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

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