Là kỹ năng sửa lỗi quan trọng để trở thành một lập trình viên tốt?

Cùng với các phẩm chất khác, một lập trình viên cần kỹ năng sửa lỗi tốt? Nếu tôi có một ứng viên không thể tìm thấy lỗi trong chương trình đã cho, nhưng có thể giải được tất cả các câu đố và chương trình, tôi có nên xem xét anh ta cho công việc không?

EDIT: - Các câu đố là những quả bóng màu đỏ, xanh dương và đỏ-xanh bình thường như thế nào. Các chương trình giống như tìm các số 0 k liên tục trong một mảng. Chương trình gỡ lỗi là một cái gì đó không thành công vì điều kiện nên> =, nhưng thay vào đó là>. Tất cả mọi thứ là trên giấy.

Vâng, nó rất quan trọng.

Về ứng cử viên cụ thể đó, có thể họ không đủ quen thuộc với mã cơ sở x để gỡ lỗi.

Một người giải quyết vấn đề tốt sẽ có thể gỡ lỗi, vì tất cả những gì thường được yêu cầu là có một phương pháp / phương pháp rất logic.

Nếu bạn không thể gỡ lỗi, bạn gần như không phải là một lập trình viên, hãy để một người giỏi.

Gỡ lỗi là một ứng dụng thực tế, thực tế không chỉ về kỹ năng kỹ thuật mà còn cả khả năng phân tích và quá trình suy nghĩ. Kết quả là tôi đánh giá nó là một bài kiểm tra hữu ích và phù hợp hơn nhiều so với các câu hỏi phỏng vấn hoặc bảng trắng.

Trừ khi công việc bạn có liên quan đến việc dành cả ngày để trả lời các câu hỏi lý thuyết, bạn cần một người có thể áp dụng bất kỳ kỹ năng nào họ có.

Những gì bạn cần làm là tự hỏi mình có phải là một bài kiểm tra công bằng về khả năng sửa lỗi - họ có thể chạy mã, đặt các điểm ngắt và cứ như vậy trong thế giới thực không? Đó là loại lỗi gì? Đây có phải là thứ mà trình biên dịch sẽ chọn và gắn cờ (trong trường hợp đó là một câu hỏi khá vô nghĩa vì họ không bao giờ cần phải phát hiện ra nó)?

Nếu nó chỉ được viết trên giấy thì về cơ bản nó chỉ là một bài kiểm tra đọc chi tiết và đó là một kỹ năng thậm chí còn trừu tượng hơn so với câu hỏi phỏng vấn kỹ thuật trung bình của bạn và tôi cho rằng, khá nhiều vô giá trị.

Quy tắc tuyển dụng chính - trong mọi nghi ngờ nói không.

Nếu bạn cần triển khai nhiều mã mới với giá rẻ - bạn có thể lấy anh chàng đó, nhưng cá nhân tôi sẽ tiếp tục tìm kiếm.

Trừ khi nhà phát triển có thể viết mã sạch mọi lúc (hoàn toàn không thể) và chỉ làm việc trên các dự án "trường xanh" (sẽ không bao giờ như vậy), thì có, kỹ năng sửa lỗi là hoàn toàn cần thiết. Chắc chắn rồi. Tôi đã có kinh nghiệm với các nhà phát triển, những người không thích gỡ lỗi, vì vậy họ lười biếng và ném mã qua tường để QA cho họ thử nghiệm. Nhưng những nhà phát triển đó không tồn tại rất lâu.

Phát triển phần mềm là một nghề thủ công và một kỹ năng giải quyết vấn đề. Những vấn đề này bao gồm cả vấn đề kinh doanh và vấn đề với mã của họ (và của người khác). Nhân tiện, nhiều dự án bảo trì đặc biệt là về sửa lỗi, vì vậy gỡ lỗi là một kỹ năng hoàn toàn cần thiết.

Tôi nhớ rằng có rất nhiều trang web "câu hỏi phỏng vấn", và hoàn toàn có thể nghiên cứu cho rất nhiều câu hỏi và câu đố. Một điều bạn không thể nghiên cứu là gỡ lỗi mã mà bạn chưa từng thấy trước đây. Hoặc bạn đã viết đủ mã mà bạn biết cách gỡ lỗi hoặc bạn chưa biết. Nếu đó là một vị trí cấp đầu vào, tôi sẽ không loại trừ ứng viên, nhưng nếu họ tuyên bố có kinh nghiệm với ngôn ngữ và không thể gỡ lỗi mã trong đó, thì chắc chắn nó sẽ giương cờ đỏ.

Sự khác biệt chính mà tôi đã thấy giữa các lập trình viên cơ sở và lập trình viên cao cấp là kỹ năng gỡ lỗi của họ. Kỹ năng gỡ lỗi là thứ chỉ đi kèm với thực hành và kinh nghiệm.

Ví dụ, nghĩ về một lỗi lạ trong đó chương trình Java hoạt động tốt trên bảng điều khiển ở chế độ tương tác, nhưng không thành công khi bạn cố gắng sử dụng một ống Unix cho cùng một đầu vào. Nếu bạn đã gặp phải vấn đề này trước đây, bạn có thể kiểm tra để chắc chắn rằng new Scanner(System.in)nó chỉ được gọi một lần; lỗi là nó tiêu thụ bộ đệm khi đường ống, nhưng rõ ràng không phải khi ở chế độ tương tác. Tôi mong đợi một lập trình viên cao cấp hơn sẽ xác định lỗi này nhanh hơn. Có lẽ bởi vì họ đã trải nghiệm điều đó trước đây hoặc bởi vì họ đã có vấn đề khác với bộ đệm trong quá khứ.

Đối với việc giải câu đố và viết mã mới, trong khi kinh nghiệm là quan trọng, đây là điều mà một lập trình viên cấp cơ sở có thể có thể thực hiện tốt, hoặc thậm chí tốt hơn, một lập trình viên cao cấp hơn. Đó là, trí thông minh và kỹ năng có thể có tác động lớn hơn, độc lập với kinh nghiệm.

Nếu bạn đang ở một vị trí để đầu tư vào một lập trình viên cơ sở, người có thể có ý tưởng mới và có thể giúp nhóm "gel", và họ có vẻ tốt khi viết mã mới, hãy tiếp tục và thuê chúng. Nếu bạn đang tìm kiếm một lập trình viên cấp cao, thì việc thiếu kỹ năng sửa lỗi này có thể là một dấu hiệu cảnh báo chính: Họ có thể có mười năm kinh nghiệm mà chỉ trải qua mười năm đầu tiên.

Là một lưu ý phụ, có nhiều cách để trở nên tốt hơn trong việc gỡ lỗi mà không cần có 10 năm kinh nghiệm trước. Tôi giới thiệu cuốn sách Tại sao các chương trình thất bại: Hướng dẫn về gỡ lỗi có hệ thống như một cách để tìm hiểu các nguyên tắc khoa học và để hiểu rõ hơn về cách tái tạo, tìm và sửa lỗi.

Nó phụ thuộc vào môi trường của bạn. Nếu bạn chơi sodoku và các câu đố khác cả ngày, có lẽ nó sẽ là một ứng cử viên sáng giá.

Tuy nhiên, đôi khi bạn có lỗi trong mã của mình hoặc nó không luôn hoạt động chính xác như mong đợi, tôi khuyên bạn nên nhờ ai đó xử lý sự cố.

Thuê cho những gì bạn cần, không phải là một lý tưởng của những gì một lập trình viên nên được.

Cùng với các phẩm chất khác, một lập trình viên cần kỹ năng sửa lỗi tốt?

Vâng.

Mã gỡ lỗi là một phần của việc giải quyết vấn đề. Tôi chưa bao giờ gặp phải một nhà phát triển đã viết mã hoàn hảo và không có lỗi. Một nhà phát triển sẽ gỡ lỗi mã của anh ấy / cô ấy hoặc của người khác. Đó là một điều cần thiết.

Tôi có nên xem xét anh ta cho công việc?

Có lẽ, nó phụ thuộc.

Không thể gỡ lỗi một chương trình trong một cuộc phỏng vấn có lẽ không nên là một người giải quyết nếu người nộp đơn có thể hoàn thành tất cả các câu đố và chương trình khác trong cuộc phỏng vấn. Nó thực sự phụ thuộc vào độ sâu và hơi thở của cuộc phỏng vấn.

Làm thế nào nhiều gỡ lỗi vị trí đòi hỏi? Nếu nhiều, thì có lẽ nên đặt nhiều trọng lượng hơn vào việc ứng viên có thể trả lời câu hỏi gỡ lỗi tốt như thế nào. Nhưng vì bạn chỉ đề cập rằng một câu hỏi gỡ lỗi đã được hỏi, nên có vẻ như không phải vậy.

một lập trình viên cần kỹ năng sửa lỗi tốt?

Vâng. Điều đó nói rằng, tôi sẽ yêu cầu bạn xem xét phương pháp luận trong cuộc phỏng vấn (ví dụ như câu đố / kiểu kiểm tra) kém hoàn hảo (không sao, thiếu sót) ở chỗ nhiều người tìm thấy mã trên giấy là một trải nghiệm lạ, lạ.

Vì gỡ lỗi là một quá trình , không phải là câu trả lời hoặc kết quả (ví dụ: lỗi ), tôi sẽ đề nghị sử dụng một cuộc đối thoại hoặc thảo luận tương tác như một phương tiện tốt hơn để đánh giá khả năng gỡ lỗi của ứng viên. Trong khi hầu hết mọi người sử dụng một hệ thống gỡ lỗi không chính thức, các ứng viên giỏi sẽ có một mô hình tương tự nói chung, đặt câu hỏi để hiểu hệ thống hoặc các giả định và yêu cầu, sau đó cô lập vấn đề (thường phân chia và chinh phục) và so sánh một cách có phương pháp mã các yêu cầu và đánh giá dự kiến đầu vào / đầu ra, chứ không phải là dù muốn dù không thay đổi một loạt các việc cùng một lúc bừa bãi cho đến khi nó hoạt động.

Tôi cũng bày tỏ sự dè dặt về các vấn đề giải đố trong các cuộc phỏng vấn, đặc biệt là ở dạng viết, như thể ứng viên không có các giả định đúng về khung tham chiếu ( mẹo), câu đố có thể không thể giải được với họ. Tức là nhiều câu đố phỏng vấn phải chịu một con đường chính xác duy nhất, trong khi cuộc sống phức tạp và những suy nghĩ sáng tạo nhất là những cách tiếp cận mới lạ đáng ngạc nhiên để giải quyết một vấn đề có thể không hoạt động với một câu đố được nấu sẵn cụ thể, với một giải pháp dự kiến . Nó giống như mong đợi tất cả người chơi kèn chơi nhạc jazz. Điều này có thể được quản lý bằng cách đặt câu hỏi như một cuộc thảo luận tương tác không đối đầu (áp lực có thể gây nhiễu sáng tạo). Một lần nữa, với tôi, câu trả lời là thứ yếu để thấy một quá trình suy nghĩ tốt được thể hiện. Bạn có thể sẽ cần yêu cầu họ suy nghĩ thành tiếng, nhưng điều này có xu hướng hiệu quả hơn theo kinh nghiệm của tôi.

Tôi chưa đọc hoặc đánh giá Tại sao các chương trình của Zeller thất bại , nhưng tôi có thể khuyên bạn nên gỡ lỗi bằng cách đọc nhanh, có thể giúp củng cố quy trình gỡ lỗi đặc biệt thành một nỗ lực có cấu trúc, cụ thể và có tổ chức hơn, có thể giúp hiệu quả hơn trong việc gỡ lỗi. Đồng thời in ra một bản sao và treo nó tại tủ của bạn hoặc cách giải quyết, áp phích Quy tắc gỡ lỗi , đó là một lời nhắc hoàn hảo cho những ngày tồi tệ mà dường như không có gì là đúng. Tôi có vài ngày tồi tệ và dành ít thời gian hơn để chủ động gỡ lỗi (đọc: gãi đầu bối rối ) bằng cách cố gắng theo dõi họ trong tinh thần nếu không phải trong thư.

Tôi sẽ nói rằng việc gỡ lỗi là điều cần thiết, trừ khi lập trình viên giỏi đến mức anh ta không bao giờ mắc lỗi nào. Tôi không tin rằng điều đó là không thể, nhưng tôi không thể tưởng tượng nó với các ngôn ngữ và công cụ phổ biến hiện nay.

Tôi không thích khái niệm được đưa vào vị trí như thế trong một cuộc phỏng vấn. Nếu ứng viên lo lắng (và ai không), anh ấy / cô ấy có thể vẽ một máy quay trống với tư cách là một lập trình viên, anh ấy có thể thường xuyên xử lý các vấn đề như vậy. Sau đó, nếu đó là một cuộc phỏng vấn nổi tiếng hoặc bài kiểm tra comp-sci, ứng viên có thể biết kết quả bằng cách học vẹt, nhưng không có khả năng suy nghĩ theo cách của mình thông qua một vấn đề mới lạ. Ngoài ra, nếu ứng viên không quen với ngôn ngữ này, anh ta sẽ phải vật lộn. Nhiều lỗi rất khó vì một lập trình viên giỏi biết anh ta định gõ gì và não anh ta dùng các phím tắt trong khi đọc mã. Tôi không thể tìm thấy kiểu C sử dụng = where == nên được sử dụng bởi kiểm tra, bởi vì tôi biết ý định đó là gì và bộ não của tôi sẽ sử dụng một phím tắt phân tích cú pháp khi đọc nó.

Một phần tốt của lập trình giải quyết vấn đề, và để giải quyết vấn đề, bạn phải biết vấn đề cốt lõi không chỉ là triệu chứng hay sự không nhất quán. Gỡ lỗi là nghệ thuật xác định vấn đề cốt lõi.

• xác định vấn đề cốt lõi
• có thể hình dung tốt hơn dòng chảy

và nhiều thứ khác nữa.

Tôi sẽ thêm một chút vào tình huống trong việc chỉ ra lỗi và xem phản ứng của người đó. Có phải họ quá kịch tính về kiểu "D'oh! Tôi là một thằng ngốc, thật là ngu ngốc ...", quá thờ ơ trong trại, "Vâng, bất cứ anh chàng nào", hoặc ở đó lắng nghe tích cực về những gì đã được sai với một số lời xin lỗi hoặc nhận xét để biểu thị rằng họ nhận được rằng họ đã làm hỏng một cái gì đó mà họ nên giải quyết? Chỉ cần một cái gì đó để suy nghĩ trong các tình huống trong tương lai.

Để gỡ lỗi một cách kịp thời là một kỹ năng tuyệt vời. Điều này khác một chút so với việc đưa ra một vấn đề cho ai đó khi nó được sửa chữa. Đôi khi phải có các biện pháp tích cực để cứu hệ thống cần được thừa nhận vì tôi tưởng tượng hầu hết các công ty sẽ không muốn doanh số bị dừng trong nhiều tuần trong khi ai đó sửa lỗi phần mềm kế toán mà công ty sử dụng.

Gỡ lỗi là một kỹ năng quan trọng. Trên thực tế tôi sẽ nói nhiều hơn rằng xử lý sự cố là kỹ năng quan trọng. Ai đó nên biết cách xác định vấn đề (bao gồm thông tin người dùng cần hỏi và nhật ký cần xem xét), cách tái tạo nó, nguồn dữ liệu nào anh ta có sẵn để chẩn đoán sự cố và cách gỡ lỗi và cách khắc phục một điều mà không phá vỡ cái gì khác Tuy nhiên, xác định rằng trong một cuộc phỏng vấn là khó khăn.

Tôi sẽ cho anh ta một vấn đề thực sự để tìm và cơ hội sử dụng các công cụ có sẵn và sau đó hỏi anh ta đã thực hiện những bước nào để tìm ra vấn đề hoặc anh ta có thể làm gì nếu không thể tìm ra vấn đề trong thời gian quy định. Bạn đang thực sự tìm kiếm ai đó tấn công vấn đề một cách có hệ thống và có nhiều công cụ trong bộ công cụ của anh ấy hơn là chỉ là trình gỡ lỗi và google (ngoại trừ ở cấp Junior khi anh ấy nên thử tối thiểu cả hai (những người không thể nghĩ đến hãy thử hai điều đó có lẽ không đủ năng lực hoặc ít nhất là tôi sẽ không nắm lấy cơ hội của anh ấy) nhưng có lẽ vẫn chưa có nhiều công cụ xử lý sự cố nâng cao).

Tôi sẽ chú trọng nhiều hơn vào các kỹ năng khởi động hơn là các câu trả lời cho các câu đố (tôi cũng không hỏi những người đó) hay kỹ năng lập trình sai lệch. Tôi hiếm khi thấy một nhà phát triển có thể khắc phục sự cố tốt, những người cũng không thể viết mã tốt hoặc thực hiện các sửa lỗi cần thiết. Tôi đã thấy nhiều người có thể ghép một số mã với nhau để có được sản phẩm "Làm việc" nhưng không thể khắc phục vấn đề nếu cuộc sống của họ phụ thuộc vào nó. Chủ yếu là vì họ không thực sự hiểu những gì họ đang làm hoặc hiểu vấn đề họ đang cố gắng giải quyết. Những người làm việc tốt biết cách xác định vấn đề thực sự không chỉ là triệu chứng. Một das như vậy họ biết những câu hỏi để hỏi để xác định vấn đề cho sự phát triển mới là tốt.

Có 4 đến 5 kỹ năng chính trong bất kỳ công việc nào và lập trình cũng không khác. Ở cấp độ chuyên nghiệp, bạn phải giỏi tất cả các kỹ năng cơ bản quan trọng. Nếu bạn có 4 trên 5 thì nó vẫn giữ bạn lại.

Bạn có thể tưởng tượng một nhân viên bán hàng có thể trình bày, thuyết phục, nói rõ, khách hàng đủ điều kiện, nhưng không thể đóng giao dịch? Họ ở ngoài đó và bạn không muốn họ trong nhóm bán hàng của bạn.

Gỡ lỗi chắc chắn là một kỹ năng cốt lõi mà một lập trình viên không thể thiếu.

Tôi có phong cách mã hóa như vậy, đòi hỏi phải bắt chước gỡ lỗi. Khi tôi hoàn thành với 3 dòng mã, tôi chạy nó và kiểm tra nó, thường in ra một vài biến. Trong các trường hợp, khi tôi nhận được kết quả hoặc hành vi không mong muốn, tôi đặt nhiều kết xuất trong mã của mình - thay vì gỡ lỗi. Tôi sử dụng trình gỡ lỗi thực sự rất hiếm. Lạ nhưng có thật.

Gỡ lỗi là giai đoạn phát triển phần mềm xuất hiện sau khi một thử nghiệm nhất định được thực hiện trên phần mềm của bạn và một lỗi đã được phát hiện. Đó là hành động tìm kiếm và sửa lỗi trong phần mềm của bạn. Trong rất nhiều trường hợp, việc tìm lỗi thường đòi hỏi nhiều thời gian hơn để sửa nó.

Đó là quá trình loại bỏ các lỗi (lỗ hổng) vốn có trong ứng dụng / hệ thống máy tính. Nếu điều này không được thực hiện thì tin tặc có thể lợi dụng các lỗi và có thể thực hiện nhiều hoạt động độc hại:

1) Họ có thể phơi bày lỗ hổng cho công chúng dẫn đến mất doanh thu, kinh doanh & danh tiếng cho các nhà phát triển và nhà cung cấp.

2) Worms tìm kiếm các hệ thống dễ bị tấn công mà chúng có thể khai thác và do đó, tự sao chép vào các máy chủ đó. ví dụ. Vào tháng 1 năm 2003, Slammer Worm đã tận dụng lỗ hổng trong MS SQL Server.

3) Trường hợp giun đã được đề cập làm thế nào chúng ta có thể quên virus. Virus cũng bị mất bởi các nhà phát triển của họ, lợi dụng các lỗi có trong chương trình cho mục đích chính là phơi nhiễm không đứng đắn ...

4) Và nếu các chương trình không được sửa lỗi đúng cách, người tiêu dùng sẽ không bao giờ giữ được nếu họ không nhận được giá trị tiền của họ. Trong trường hợp đó, bạn thậm chí không cần một hacker để thực hiện công việc bẩn thỉu - bạn cũng có thể tin tưởng vào công chúng tốt.