ทักษะการดีบักมีความสำคัญต่อการเป็นโปรแกรมเมอร์ดีหรือไม่?


24

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

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


13
เขาได้รับอนุญาตให้รันโปรแกรมหรือไม่หรือเขาต้องพบข้อผิดพลาดในการดูรหัส?
Michael K

9
คุณสามารถโค้ดได้ดีเท่าที่จะดีบั๊ก ทั้งสองไปจับมือกันในหนังสือของฉัน
Demian Kasier

3
บางคนดีกว่าคนอื่น บ่อยครั้งเป็นการยากที่จะตรวจพบข้อผิดพลาดในรหัสต่างประเทศ - โดยเฉพาะในระหว่างการสัมภาษณ์ที่เครียด
leed25d

6
@Fanatic: เฉพาะในกรณีที่คุณทำงานกับรหัสของคุณเท่านั้น การดีบักส่วนใหญ่ที่ฉันทำในที่ทำงานคือการขุดหาข้อผิดพลาดของคนอื่น
Mason Wheeler

3
@Manoj R คุณแน่ใจหรือไม่ว่าคุณจะพบปัญหาเดียวกันตามระยะเวลาที่เท่ากัน? คุณแน่ใจหรือว่าเพียงเพราะผู้สมัครไม่พบปัญหาในกระดาษภายใน 20 นาทีว่าเธอจะไม่สามารถทำได้ดีกับ Google (ใช่ Google ร่วมเพศ) ที่ด้านข้างของเธอและฝึกสองสามสัปดาห์?
งาน

คำตอบ:


37

ใช่มันสำคัญมาก

เกี่ยวกับผู้สมัครนั้นเป็นไปได้ว่าเขา / เธอไม่คุ้นเคยกับโค้ดฐาน x เพื่อทำการดีบั๊ก

ตัวแก้ปัญหาที่ดีควรสามารถแก้ไขข้อบกพร่องได้เนื่องจากทั้งหมดที่จำเป็นต้องมีก็คือต้องมีวิธีการ / วิธีการที่มีเหตุผลมาก


1
ยิ่งไปกว่านั้นทักษะอื่น ๆ ในการเขียนโปรแกรมการดีบักมาพร้อมกับประสบการณ์และมีความสามารถน้อยลง
ปีเตอร์ B

24

หากคุณไม่สามารถดีบักได้คุณไม่ได้เป็นโปรแกรมเมอร์เลย

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

นอกจากงานที่คุณเกี่ยวข้องกับการใช้คำถามตอบทฤษฎีทั้งวันคุณต้องการคนที่สามารถใช้ทักษะใดก็ได้ที่พวกเขาได้รับ

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

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


2
+1 สำหรับ "ถามตัวเองว่าเป็นการทดสอบความสามารถในการดีบั๊กอย่างยุติธรรม" - ฟังดูเหมือนไม่ใช่ การทดสอบที่เป็นธรรมจะรวมรหัสที่เรียกใช้ได้กับตัวดีบั๊กเช่นวางไว้ในสภาพแวดล้อมการทำงานที่เป็นธรรมชาติและปกติ (พิจารณาว่าพวกเขาแทบจะไม่ได้ทำงานกับตัวดีบั๊ก)
doppelgreener

11

กฎการจ้างงานหลัก - ไม่ต้องสงสัยเลยว่าไม่ต้องสงสัย

หากคุณต้องการใช้รหัสใหม่จำนวนมากสำหรับราคาถูก - คุณสามารถรับคนนั้น แต่โดยส่วนตัวแล้วฉันจะค้นหาต่อไป


7
ฉันจ้างคนจำนวนมากในช่วงหลายปีที่ผ่านมาและรู้สึกเสียใจกับผู้สมัคร "อาจ" เกือบทุกคนที่ฉันจ้าง
JohnFx

10

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

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


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

7

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


5

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

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

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

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

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


ดังนั้นการดีบั๊กจึงเป็นสิ่งที่มาจากการฝึกฝนและสามารถเรียนรู้ได้และไม่ควรให้น้ำหนักมากในขณะเลือกผู้สมัคร
Manoj R

1
เพื่อความชัดเจน: คุณควรชั่งน้ำหนักอย่างหนักสำหรับนักพัฒนาอาวุโส แต่น้อยกว่าสำหรับนักพัฒนารุ่นเยาว์ ตัวอย่างเช่นบางคนเพิ่งออกจากวิทยาลัยซึ่งเริ่มเขียนโปรแกรมปีแรกของพวกเขาอาจใช้เวลานานกว่า 10 ครั้งในการดีบักบางสิ่งบางอย่าง แต่มีเหตุผลที่ดีในการลงทุนในผู้พัฒนารุ่นน้อง
Macneil

5

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

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

จ้างสิ่งที่คุณต้องการไม่ใช่แบบอย่างที่ดีสำหรับโปรแกรมเมอร์


3

โปรแกรมเมอร์ควรต้องการทักษะการดีบั๊กหรือไม่?

ใช่.

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

ฉันควรพิจารณาเขาสำหรับงานหรือไม่

บางทีมันขึ้นอยู่กับ

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

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


2
+1 เพื่อย้ำการแก้ไขข้อผิดพลาดเป็นสิ่งที่จำเป็น แต่ไม่ใช่ข้อผิดพลาดระหว่างการสัมภาษณ์
Gaurav

3

โปรแกรมเมอร์ควรต้องการทักษะการดีบักที่ดีหรือไม่?

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

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

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

ฉันยังไม่ได้อ่านหรือประเมินว่าทำไมโปรแกรมของ Zeller ถึงล้มเหลวแต่ฉันสามารถแนะนำการดีบักโดย Agans เป็นการอ่านสั้น ๆ ที่รวดเร็วซึ่งสามารถช่วยให้กระบวนการการดีบักแบบ ad-hoc มีความแข็งแกร่งมีรูปแบบเป็นรูปธรรมและเป็นระเบียบมากขึ้นซึ่งสามารถช่วย มีประสิทธิภาพมากขึ้นในการดีบัก พิมพ์สำเนาและนำไปแขวนไว้ที่ห้องเล็ก ๆ หรือวิธีแก้ปัญหาโปสเตอร์ Debug Rulesมันเป็นเครื่องเตือนใจที่สมบูรณ์แบบสำหรับวันที่เลวร้ายเหล่านั้น ฉันมีไม่กี่วันที่ไม่ดีและใช้เวลาน้อยลงในการดีบัก (อ่าน: เกาหัวของฉันด้วยความสับสน ) โดยพยายามที่จะติดตามพวกเขาด้วยจิตวิญญาณหากไม่ได้อยู่ในจดหมาย


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

2

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

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


1

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

  • ระบุปัญหาหลัก
  • ดีกว่าที่จะเห็นภาพการไหล

และอื่น ๆ อีกมากมาย.


1

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

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


1

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

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

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


1

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

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

การดีบักเป็นทักษะหลักที่โปรแกรมเมอร์ไม่สามารถขาดได้


0

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


0

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

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

1) พวกเขาอาจเปิดเผยถึงช่องโหว่ที่ประชาชนนำไปสู่การสูญเสียรายได้ธุรกิจและชื่อเสียงสำหรับนักพัฒนาและผู้ขาย

2) Worms ค้นหาระบบที่มีช่องโหว่ที่สามารถใช้ประโยชน์และคัดลอกตัวเองไปยังเซิร์ฟเวอร์เหล่านั้น เช่น. ในเดือนมกราคม 2546 หนอน Slammer ใช้ประโยชน์จากช่องโหว่ใน MS SQL Server

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

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

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