Có một lợi ích trong việc biên dịch mã của bạn khi bạn đi cùng?

Gần đây tôi đã có một cuộc phỏng vấn việc làm trong đó họ đã cho tôi một giờ để viết một số mã thực sự. Đó không phải là một số tiền lớn, có thể ít hơn 100 dòng. Sau khoảng 45 phút, tôi biên dịch, chạy nó và làm cho nó hoạt động. Tôi có thể đã dành 5-10 phút để xử lý các lỗi biên dịch và một vài lỗi nhỏ, nhưng nhìn chung nó rất trơn tru. (Ngẫu nhiên, tôi đã nhận được một lời đề nghị từ họ.)

Tuy nhiên, điều khiến tôi bối rối là sau khi tôi trao mã hoàn thành, người phỏng vấn nói với tôi rằng điều duy nhất tôi làm sai là "không biên dịch khi tôi đi cùng". Tôi hỏi anh ta sự khác biệt là gì và anh ta nói "anh sẽ làm gì nếu hoàn thành mã và nó không được biên dịch kịp thời".

Theo cách hiểu của tôi, đó là một đối số không hợp lệ, bởi vì "lấy mã để biên dịch" trong một độ dài mã nhất định thường liên quan đến việc sửa một số lỗi biên dịch không đổi và mất một khoảng thời gian khá ổn định, điều này sẽ giống nhau cho dù bạn có làm điều đó sau khi viết xong mã hoặc nếu bạn xen kẽ nó với thời gian mã hóa của bạn. Nếu bất cứ điều gì, làm gián đoạn mã hóa của bạn để tìm kiếm dấu chấm phẩy bị thiếu có lẽ sẽ gây bất lợi cho hiệu quả của bạn. Ngoại trừ trong những trường hợp cực đoan khi tôi đang thử nghiệm những điều tối nghĩa xung quanh các trường hợp cạnh trên những thứ như các hàm ảo trong các lớp dẫn xuất, v.v ... có vẻ hợp lý khi hy vọng rằng mã được viết bởi một nhà phát triển có kinh nghiệm sẽ biên dịch, trừ lỗi đánh máy không thường xuyên và thậm chí nếu không, nó '

Trong một sự cố tương tự khác, tôi đã nhận được một cơ sở mã không hoàn chỉnh trong một cuộc phỏng vấn, và được yêu cầu hoàn thành nó và thực hiện các sửa đổi cần thiết để chạy nó. Tôi bắt đầu bằng cách đọc qua mã hiện có, và sau vài phút (ngay cả trước khi tôi xem xong mã), người phỏng vấn nói với tôi rằng thế là đủ. Khi tôi hỏi anh ta sẽ làm gì (nghĩa là "tôi đã làm gì sai"), anh ta nói với tôi rằng anh ta sẽ bắt đầu bằng cách ngay lập tức lấy mã để biên dịch.

Tại sao điều đó thậm chí có liên quan? Theo ý kiến ​​của tôi và theo kinh nghiệm của tôi, việc một đoạn mã biên dịch hay không về cơ bản là ngẫu nhiên, liên quan đến những thứ như có hay không dấu chấm phẩy bị thiếu, và ít liên quan đến tính chính xác của chương trình bên dưới. (Đối với tôi, tập trung vào biên dịch giống như chạy một bài viết thông qua kiểm tra chính tả mà không cần đọc lại để kiểm tra ngữ pháp.)

Nếu bạn đưa cho tôi một đoạn mã chưa hoàn chỉnh, điều đầu tiên tôi làm sẽ là đọc nó. Tôi thậm chí sẽ không biên dịch nó cho đến khi tôi biết mã đang làm gì và tôi biết thuật toán này là chính xác.

Dù sao, đây chỉ là một vài sự cố gần đây, nhưng nói chung tôi đã nghe nhiều nhà phát triển nói về việc biên dịch mã của họ khi họ đi cùng, nhưng chưa ai có thể cho tôi biết lợi ích của việc đó. Tôi hiểu lợi ích của việc kiểm tra mã của bạn khi bạn thực hiện, nhưng tại sao lại biên dịch?

Vì vậy, câu hỏi của tôi là: Có điều gì tôi đã bỏ lỡ? Có thực sự có một lợi ích để biên dịch khi bạn đi cùng? Hay đây là một loại huyền thoại được truyền bá bởi cộng đồng phần mềm mà bạn phải biên dịch mã của mình thường xuyên?

Có thực sự có một lợi ích để biên dịch khi bạn đi cùng?

Có. Nó cung cấp cho bạn một vòng phản hồi ngắn hơn - mà nói chung, khi thiết kế (UI, phần mềm viết, thiết kế trực quan, v.v.) là một điều tốt.

Một vòng phản hồi ngắn có nghĩa là bạn có thể nhanh chóng sửa lỗi sớm, trước khi chúng trở nên đắt hơn để sửa.

Để mượn ví dụ của bạn, giả sử bạn đã mã hóa bằng ngôn ngữ giống như C và quên một }nơi nào đó ở giữa chương trình.

Nếu bạn biên dịch ngay sau khi bạn viết xong câu lệnh, bạn có thể khá chắc chắn rằng bạn vừa giới thiệu lỗi biên dịch và có thể sửa nó ở đó và sau đó, trong vài giây.

Tuy nhiên, nếu bạn không, bạn sẽ phải dành một khoảng thời gian tốt để đọc mã, tìm kiếm vị trí chính xác của }nó và chắc chắn, một khi bạn đã xác định được lỗi rằng bản sửa lỗi thực sự là dự định. Điều này sẽ diễn ra một lúc sau khi bạn để lại đoạn mã đó. Nó sẽ không rõ ràng như trong thời điểm bạn viết nó.

Bây giờ, vâng, kết quả cuối cùng là như nhau, nhưng bạn đã lãng phí một khoảng thời gian tốt cho các vấn đề cú pháp mà trình biên dịch có mặt để giúp bạn - một lượng thời gian có thể rút ngắn đáng kể nếu bạn biên dịch khi bạn thực hiện.

Biên dịch là một hình thức kiểm tra, đặc biệt là trong các ngôn ngữ sử dụng rộng rãi các loại như Haskell hoặc ML . Trong các ngôn ngữ khác, đó là một cú pháp cú pháp cho bạn biết rất ít.

Có nói rằng, "biên dịch khi bạn đi" dường như là một thói quen rất tình huống. Bạn cũng có thể bị đánh dấu là "co giật" vì biên dịch thường xuyên hơn định kiến ​​cá nhân của người phỏng vấn. Nghe có vẻ như nitpicking; không ai thích phải thừa nhận rằng một người được phỏng vấn đã aced bài kiểm tra; nó mách nước cho quy mô của đàm phán lương.

Không phải tất cả các hệ thống xây dựng đều nhanh. Tôi đã làm việc trong một dự án (C ++) trong đó Make sẽ dành 30 giây chỉ để thống kê mọi thứ để xác định xem có cần xây dựng hay không và hầu hết các tệp sẽ mất vài phút để xây dựng nếu bạn thực hiện thay đổi. Chúng tôi miễn cưỡng làm điều này thường xuyên hơn sau mỗi 10-15 phút. Chắc chắn ai đó sẽ cung cấp một giai thoại khi biên dịch liên quan đến việc lấy cỗ bài của bạn và mang chúng đến một tòa nhà khác ...

Biên dịch khi bạn cảm thấy bạn đã hoàn thành một đơn vị khái niệm hoàn chỉnh trong đầu và sẵn sàng để xác nhận nó. Mỗi phút một lần hoặc mỗi tuần một lần tùy thuộc vào quy trình làm việc.

Vì vậy, câu hỏi của tôi là: Có điều gì tôi đã bỏ lỡ?

Có: tâm trí của bạn không phải là một trình biên dịch. Trong khi một trình biên dịch có thể thực hiện n chuyển đổi ngữ cảnh mỗi giây, tâm trí của bạn không thể. Số lượng chuyển đổi bối cảnh mà tâm trí của bạn có thể thực hiện trong một ngày phụ thuộc vào một số yếu tố như kinh nghiệm / sự quen thuộc với cơ sở mã, mức độ đắm chìm trong mã, mức độ sạch của mã, mức độ phức tạp của vấn đề bạn đang giải quyết, bạn mệt mỏi đến mức nào, nếu bạn thường xuyên bị gián đoạn hoặc trong một môi trường ồn ào, v.v.

Biên dịch một cơ sở mã (tất cả cùng một lúc), lần đầu tiên (nghĩ "dự án với 20 tệp") sẽ buộc bạn chuyển ngữ cảnh từ những gì bạn đang nghĩ về (ví dụ: "giá trị này được đặt thành 5 ở đây, sau đó trong vòng lặp for blottabla và thuật toán phức tạp mang lại giá trị chính xác khi trả về ") cho một vấn đề biên dịch hoàn toàn không liên quan đến những gì bạn đang nghĩ về (các tên tệp / mô-đun / chức năng / tiền điều kiện / cú pháp / tên biến, v.v. ).

Càng nhiều mã bạn biên dịch cùng một lúc, càng có nhiều chuyển đổi bối cảnh mà bạn phải thực hiện. Đây không phải là vấn đề đối với một cơ sở mã nhỏ, khi tất cả các mã bạn đã viết là bất cứ điều gì bạn đã viết trong một giờ. Tuy nhiên, đây là một vấn đề lớn khi làm việc trong một cơ sở mã hiện có, với nhiều phụ thuộc lẫn nhau (và nhiều lần không có giấy tờ).

Có thực sự có một lợi ích để biên dịch khi bạn đi cùng?

Bạn giảm thiểu bối cảnh chuyển đổi tâm trí của bạn phải thực hiện, cho phép bạn tập trung hơn vào tác động và tác dụng phụ của những thay đổi bạn thực hiện. Nó cũng làm cho bạn bớt mệt mỏi (và ít mắc lỗi hơn) và tăng chất lượng đầu ra của bạn (tức là bạn có thể đảm bảo các tác dụng phụ được giảm thiểu dễ dàng hơn khi bạn thay đổi và biên dịch một tệp cùng một lúc, so với khi bạn biên dịch và thay đổi mười).

Nếu bạn biên dịch trong các lần lặp rất ngắn (điều này giả sử quá trình biên dịch được tối ưu hóa để mất một thời gian ngắn), có thể sửa các lỗi biên dịch mà không thoát khỏi "vùng".

Hay đây là một loại huyền thoại được truyền bá bởi cộng đồng phần mềm mà bạn phải biên dịch mã của mình thường xuyên?

Nó được tuyên truyền bởi danh sách phần mềm là tốt, nhưng nó có lý do chính đáng đằng sau nó.

Theo hiểu biết của tôi, đó là một đối số không hợp lệ, bởi vì "lấy mã để biên dịch" trong một độ dài mã nhất định thường liên quan đến việc sửa một số lỗi biên dịch không đổi và mất một khoảng thời gian khá cố định

Đối với tôi có vẻ như bạn có ít kinh nghiệm (không có), trong việc bảo trì các cơ sở mã kế thừa từ trung bình đến lớn (hàng trăm hoặc hàng ngàn tệp nguồn). Đây là nơi mà thái độ này (tức là "biên dịch khi bạn đi") sẽ giúp ích nhiều nhất, và đây là nơi bạn hình thành thói quen này.

Tôi sẽ tưởng tượng rằng những người quan sát bạn đã rút ra một kết luận tương tự ("bạn có ít hoặc không có kinh nghiệm trong các cơ sở mã lớn").

Tôi nghĩ rằng có nhiều hơn một chút hợm hĩnh chuyên nghiệp ở đây. Hàm ý dường như là "nếu bạn chưa bao giờ có nhu cầu biên dịch thường xuyên thì bạn chưa bao giờ làm việc với bất cứ điều gì phức tạp - hãy lấy thêm kinh nghiệm và quay lại khi bạn học cách làm việc chính xác như chúng ta làm."

Nhưng rõ ràng là có một mặt khác của điều này. Một số dự án mất một tuổi để biên dịch. Tôi đã làm việc với các khung công tác mất 30 phút trở lên để biên dịch sau các chỉnh sửa nhỏ. Trời giúp bạn nếu bạn cần chỉnh sửa một tập tin tiêu đề. Việc biên dịch lại đầy đủ thường được thực hiện qua đêm và nếu bạn đang dựa vào trình biên dịch để bắt lỗi của mình thì vẫn có những lỗi hiếm gặp không được phát hiện trong quá trình xây dựng một phần. Bạn chỉ không biên dịch lại cứ sau 5 phút trong những điều kiện này - trừ khi bạn cảm thấy lười biếng .

Trình biên dịch không thể giúp bạn với các lỗi logic hoặc ngữ nghĩa và lỗi cú pháp thực sự không quá khó để tránh rằng việc dành một nửa thời gian trong ngày để biên dịch trở nên đáng giá. Tất nhiên, bạn sẽ thường xuyên mắc lỗi đánh máy, nhưng tôi sẽ cho rằng bạn có thể đọc cả kiểu chạm và đọc. Nếu bạn có quyền tự do lựa chọn, hãy sử dụng kiểu mã hóa sử dụng bố cục tốt để làm nổi bật các lỗi trực quan và bạn sẽ không bao giờ bỏ dấu ngoặc, dấu ngoặc hoặc dấu chấm phẩy nữa. Nó cần một chút thực hành và một chút kỷ luật hơn hầu hết được sử dụng, nhưng nó có thể. Tôi có thể viết mã trong một vài giờ mỗi lần, trong một trình soạn thảo văn bản đơn giản và biên dịch nó lần đầu tiên tốt hơn chín lần trong số mười lần. Chắc chắn, tôi có thể biên dịch thường xuyên hơn, nhưng tôi không thể nhớ lần cuối cùng tôi gặp lỗi có thể dễ dàng sửa chữa hơn.

Nếu bạn không phải là người thích tái biên dịch liên tục, bạn đang ở trong một công ty tốt. Đây là Donald Knuth:

Đối với câu hỏi thực sự của bạn, ý tưởng biên dịch ngay lập tức và "kiểm tra đơn vị" chỉ hấp dẫn tôi khi tôi cảm thấy theo cách của mình trong một môi trường hoàn toàn không biết và cần phản hồi về những gì hoạt động và những gì không. Nếu không, rất nhiều thời gian bị lãng phí cho các hoạt động mà tôi chỉ đơn giản là không bao giờ cần phải thực hiện hoặc thậm chí nghĩ về.

Tất cả điều đó đang được nói ... nếu bạn đang làm việc trong bối cảnh mà việc biên dịch là một hành động miễn phí, tại sao bạn lại không? Ở nhà, trên các dự án cá nhân, cứ sau 30 giây tôi lại nhấn ctrl-S và phím tắt "biên dịch", trong một IDE liên tục chạy mã thông qua giao diện người dùng của trình biên dịch để làm nổi bật lỗi thời gian thực. Tại sao lại bỏ qua một bữa trưa miễn phí?

Có công đức để biên dịch khi bạn đi. Nhưng tôi rất đồng ý rằng ở lại làm nhiệm vụ là một chiến lược mã hóa OK.

Lợi ích đáng kể nhất đối với việc biên dịch gia tăng là tâm lý mà nhiều người có được nếu họ chờ kết thúc để biên dịch và kiểm tra : cuối cùng chúng tôi quan tâm đến việc chạy mã hơn bất kỳ thứ gì khác vào thời điểm đó. Chúng tôi nói "Ồ, chỉ cần thêm khung này để trình biên dịch ngừng phàn nàn" hoặc "oh chỉ cần viết hoa cái này" mà không cần suy nghĩ nếu có lỗi ngữ nghĩa cơ bản mà lỗi cú pháp này che giấu. Tôi thực sự tìm thấy các lỗi cú pháp thường tự lồng vào các lỗi ngữ nghĩa (điều ngược lại không đúng).

Ví dụ, giả sử tôi đã thay đổi ý nghĩa của một biến và kết quả là đã thay đổi tên của nó. Thay đổi tên tạo ra lỗi cú pháp sau này trong mã nhưng nếu tôi chỉ vui lòng trình biên dịch bằng cách sửa tên, tôi đã bỏ qua lý do tại sao lỗi đó xuất hiện.

Tôi hiểu lợi ích của việc kiểm tra mã của bạn khi bạn thực hiện, nhưng tại sao lại biên dịch?

Nhưng làm thế nào bạn sẽ kiểm tra mã của bạn khi bạn đi cùng khi bạn không biên dịch phù hợp?

Trường hợp cực đoan là phát triển dựa trên thử nghiệm (TDD). Rõ ràng là TDD không hoạt động với chiến lược của bạn, vì TDD có nghĩa là các chu kỳ kiểm tra ghi, biên dịch (nên không thành công), viết mã, biên dịch lại, chạy thử, sửa lỗi, biên dịch lại, biên dịch lại, biên dịch lại -chỉ, chạy thử, và ...

Vì vậy, không phải ai cũng làm TDD, ít nhất là không phải lúc nào cũng vậy (tôi cũng vậy, tôi thừa nhận). Với chiến lược hiện tại của bạn, bạn sẽ không bao giờ có cơ hội thậm chí thử TDD. Nhưng ngay cả khi bạn không làm TDD, IMHO cực kỳ hữu ích để kiểm tra mã của bạn thường xuyên hơn - điều này là không thể khi bạn không biên dịch mã thường xuyên. Và khi thử nghiệm của bạn thất bại, bạn đã chạy để gỡ lỗi nó (điều này có thể giúp bạn hiểu tại sao thuật toán đẹp mắt mà bạn đã viết vài phút trước đó không hoạt động tốt như bạn nghĩ nó nên làm). Và bạn viết càng nhiều mã mà không biên dịch, bạn càng viết nhiều mã mà không cần kiểm tra, do đó, càng có nhiều khả năng bạn sẽ gặp phải trường hợp bạn không thể dự đoán rằng thời gian để khắc phục sự cố là "O (1)", vì bạn đã viết.

Tôi thực sự đồng ý với bạn rằng lỗi trình biên dịch sẽ không phải là vấn đề lớn đối với một nhà phát triển có kinh nghiệm. Tôi không nghĩ rằng chi phí sửa chữa chúng tăng đáng kể theo thời gian để lo lắng. Nếu có thể hoãn việc sửa tất cả các lỗi của trình biên dịch cho đến trước khi đẩy, tôi sẽ làm như vậy, vì nó sẽ gây ra sự gián đoạn nhỏ hơn và hợp nhất hơn nhiều.

Thật không may, tìm lỗi trình biên dịch không phải là điều duy nhất trình biên dịch làm. Có nguy cơ nêu rõ, việc biên dịch là cần thiết để chạy chương trình của bạn và chạy chương trình của bạn là cần thiết để tìm tất cả các lỗi thời gian chạy phức tạp, tinh tế và thú vị hơn mà ngay cả các nhà phát triển có kinh nghiệm tạo ra. Và những loại lỗi đó là khó khăn hơn và do đó tốn kém hơn để khắc phục thời gian bạn trì hoãn gỡ lỗi chúng lâu hơn, bởi vì chúng có thể xây dựng hoặc che dấu lẫn nhau.

Tuy nhiên, tôi không nhất thiết phải đánh dấu ai đó trong một bài tập phỏng vấn để hoãn biên dịch cho đến khi kết thúc. Các bài tập phỏng vấn có xu hướng rất đơn giản và các nhà phát triển có kinh nghiệm thường biết giới hạn của họ. Bạn càng tự tin về những gì bạn đã viết, bạn sẽ càng đi giữa các lần biên dịch. Đó chỉ là bản chất của con người.

Tuy nhiên, để không đánh dấu bạn xuống, sự tự tin sẽ phải được chứng minh. Nếu bạn đã dành 45 phút để viết một cái gì đó mà không cần biên dịch, sau đó cần thêm 45 phút để gỡ lỗi, tôi sẽ cân nhắc rất nhiều với bạn.

Một điều quan trọng về việc biên dịch thường xuyên, thiếu trong các câu trả lời khác như tôi có thể thấy là: nếu bạn hiếm khi biên dịch và nhận được một số lượng lớn lỗi biên dịch, hầu hết đều vô nghĩa, vì chúng được tạo ra bởi lỗi đầu tiên. Có thể là do bạn đã gõ sai, hoặc lỗi chính tả hoặc lỗi cú pháp đơn giản khiến một số khai báo không hợp lệ.

Bạn luôn có thể sửa cái đầu tiên, biên dịch lại, sửa cái còn lại, v.v., nhưng với cơ sở mã lớn, điều này có thể chậm. Nhưng nếu bạn cố đọc lướt qua danh sách dài các lỗi trình biên dịch và các lỗi phát hiện độc lập, thì bạn sẽ mất rất nhiều thời gian để đọc các tin nhắn không liên quan hoặc điều hướng mã từ vị trí lỗi thứ cấp sang nguyên nhân thực tế.

Một điều nữa đối với các bản dựng thông thường là, không có gì ngăn bạn bắt đầu biên dịch ngay khi bạn có một khối mã hoàn chỉnh được viết, nên biên dịch. Sau đó, bạn có thể tiếp tục viết thêm mã trong khi quá trình biên dịch diễn ra, miễn là bạn không lưu các chỉnh sửa mới cho đến khi quá trình biên dịch kết thúc. Vì vậy, thực tế không có thời gian lãng phí để chờ xây dựng. Nếu bạn đợi cho đến khi bạn viết tất cả những gì bạn sẽ viết vào lúc đó, thì bạn phải chờ để biên dịch mà không có gì để làm. Về cơ bản, đây là phiên bản thủ công của những IDE hiện đại có thể tự động làm nền.

Đối với một trình biên dịch mã lập trình đủ kinh nghiệm không bao giờ là nút cổ chai.

Một khi bạn biết một ngôn ngữ đủ tốt (tức là khi bạn không còn phải suy nghĩ về cú pháp và thay vào đó chỉ là mã cho chức năng), bạn có xu hướng không mắc các lỗi cú pháp đơn giản. Những lỗi bạn thực hiện thường là lỗi chính tả hoặc lỗi sao chép và chúng có thể được dọn sạch trong thời gian ngắn chỉ với một vài lần biên dịch.

Tôi thường xuyên viết mã cả ngày mà không biên dịch, sau đó tôi sẽ biên dịch và chỉ sửa những lỗi cú pháp và cảnh báo trình biên dịch báo cáo trước khi tôi cam kết mã của mình (với một lưu ý là "cần phải được kiểm tra!" ). Tôi không gặp vấn đề gì khi dọn sạch hơn 1000 dòng mã C hoặc C ++ chỉ trong vài phút.

Gỡ lỗi và kiểm tra mặt khác là những gì phải mất một thời gian. Lỗi logic phát sinh vì tất cả các loại lý do và tôi chưa gặp trình biên dịch sẽ cho tôi biết về chương trình con mà tôi hoàn toàn quên viết, hoặc sẽ nhận thấy rằng cây nhị phân của tôi không hoạt động vì tôi đã dán node->leftkhi cần node->right.

Mặc dù tôi nghĩ rằng thường không khôn ngoan khi đấu tranh với người phỏng vấn, tôi nói nếu bạn cảm thấy phong cách của mình đáng để bảo vệ thì bạn nên chỉ ra rằng bạn đã dành cho mình đủ thời gian để gỡ lỗi mã bạn đã viết. Đó là điều không một lập trình viên giỏi nào bỏ bê.

ps - Nếu tôi đã xem bạn xem lại mã bằng cách đọc nó, tôi sẽ thuê bạn ngay tại chỗ. Đó là những gì một chuyên gia làm, mọi lúc.

Không, không phải là không hợp lý để ngừng biên dịch cho đến khi bạn đã thực hiện đủ số lượng mã (và 'số lượng đủ' tùy thuộc vào bộ mã hóa và mã được viết).

Ví dụ: nếu bạn là một lập trình viên tuyệt vời, người dành thời gian của mình để làm cho đúng và bạn không viết số lượng lớn hoặc mã phức tạp, thì việc biên dịch thường xuyên là một sự lãng phí và có lẽ cũng là một sự phiền nhiễu. Nếu bạn không, thì biên dịch mọi chức năng có thể là một điều tốt. Nó phụ thuộc vào mỗi người.

Để làm ví dụ ngược lại, hãy tưởng tượng bạn đang viết mã JavaScript - không có trình biên dịch. Thay vào đó (với bản chất của hầu hết mã JavaScript), bạn sẽ chạy chương trình (hoặc làm mới trang) để xem kết quả mã hóa của mình. Bây giờ, bạn không thể làm điều đó cho đến khi bạn viết đủ mã để có ý nghĩa. Do đó, các nhà phát triển JavaScript có xu hướng "biên dịch" thường xuyên nhất có thể, điều này không nhất thiết phải rất thường xuyên.

Nói tóm lại, không có câu trả lời đúng ở đây - người phỏng vấn không sai, nhưng bạn cũng vậy. Làm những gì khiến bạn làm việc hiệu quả và quên đi những gì bất cứ ai nói với bạn rằng bạn phải làm. Có nhiều yếu tố quan trọng hơn về mã hóa so với xu hướng của bạn để đạt được F7thường xuyên (hoặc không) là hoàn toàn không có hậu quả.

Với một môi trường phát triển tốt, tôi thấy ít lý do để biên dịch trừ khi bạn thực sự có kế hoạch kiểm tra mã. Các công cụ kiểm tra cú pháp nền nắm bắt hầu hết mọi thứ mà người phỏng vấn dường như đang nói đến, mặc dù tôi sẽ thừa nhận vẫn còn một vài trường hợp (liên quan đến những thay đổi lan truyền trên các tệp) mà không phải lúc nào cũng được xác định đầy đủ.

Điều đó đang được nói, tôi sẽ cố gắng biên dịch và chạy khá nhiều đơn vị mã nhỏ nhất có thể thực sự tạo ra kết quả. Nửa giờ trước tôi đã tạo ra một phương tiện in một số kết quả tìm kiếm và tôi đã thực hiện nửa tá bản in thử (sang .pdf, không phải giấy) để thay đổi kết quả để làm cho nó trông đẹp hơn - tỷ lệ khoảng 1 biên dịch trên 10 dòng.

Theo ý kiến ​​của tôi và theo kinh nghiệm của tôi, việc một đoạn mã biên dịch hay không về cơ bản là ngẫu nhiên, liên quan đến những thứ như có hay không dấu chấm phẩy bị thiếu, và ít liên quan đến tính chính xác của chương trình bên dưới. (Đối với tôi, tập trung vào biên dịch giống như chạy một bài viết thông qua kiểm tra chính tả mà không cần đọc lại để kiểm tra ngữ pháp.)

Kinh nghiệm của tôi rất khác nhau: ít hơn 5% lỗi biên dịch tôi nhận được là về cú pháp . Tôi biết rõ ngôn ngữ, khi tôi gặp lỗi, chủ yếu là lỗi loại, nói với tôi rằng ngữ nghĩa không đúng.

Đây là lý do tại sao tôi rất vui khi được hưởng lợi nhanh nhất có thể từ phản hồi của trình biên dịch. Bạn đã bao giờ có kinh nghiệm sử dụng một IDE mà gạch dưới các lỗi biên dịch trong thời gian thực chưa? Có một vòng phản hồi ngắn hơn có thể rất có giá trị.

Nếu bạn đưa cho tôi một đoạn mã chưa hoàn chỉnh, điều đầu tiên tôi làm sẽ là đọc nó. Tôi thậm chí sẽ không biên dịch nó cho đến khi tôi biết mã đang làm gì và tôi biết thuật toán này là chính xác.

Nếu bạn dự kiến ​​sẽ làm việc với mã được viết bởi người khác, bạn không luôn có thời gian để đọc mọi thứ. Tin tốt là: mã được viết tốt có độ khớp thấp và sẽ cho phép bạn suy luận độc lập về chỉ một phần mã mà bạn cần.

Trong những trường hợp đó, bạn phải cho rằng mã bạn chưa đọc là chính xác và điều tra một cách lười biếng khi có vấn đề.

"lấy mã để biên dịch" trong một độ dài mã nhất định thường bao gồm sửa một số lỗi biên dịch không đổi và mất một khoảng thời gian khá cố định, điều này sẽ giống nhau cho dù bạn có làm điều đó sau khi bạn viết xong mã hay nếu bạn xen kẽ nó với thời gian mã hóa của bạn.

Chuyển ngữ cảnh là tốn kém cho bộ não của bạn, do đó sửa các lỗi nhỏ ngay khi bạn viết chúng có thể hiệu quả hơn.

EDIT: Tôi cũng có thể tạo sự tương tự với kiểm soát nguồn, khi cả nhóm làm việc trên cùng một nguồn. Biên dịch khi bạn thực hiện cũng giống như thực hiện các cam kết thường xuyên, điều này giúp tránh có nhiều đau đớn khi bạn phải hợp nhất và sắp xếp mọi thứ.

Bạn nói rằng bạn vô hiệu hóa những thứ như dòng màu đỏ dưới văn bản của bạn. Bạn cũng làm điều đó khi gõ email hoặc viết một tài liệu kỹ thuật? Sau đó, bạn phải đọc lại tất cả các trang thay vì sửa lỗi khi bạn đi.

Một lợi thế khác là, khi làm việc với mã của bạn, nếu bạn luôn biên dịch hoặc biên dịch gần như mọi lúc, bạn có thể hưởng lợi từ rất nhiều tính năng IDE dựa trên ngữ nghĩa (đổi tên an toàn, tái cấu trúc, tìm cách sử dụng ký hiệu ...) .

Nếu bạn muốn hiểu rõ hơn về cách các tính năng này trợ giúp, bạn có thể thử kích hoạt chúng và thực hành, để tự trải nghiệm lợi ích của chúng. Bạn cũng có thể thử thực hiện một số lập trình cặp với bất kỳ ai đã quen với họ và xem họ được hưởng lợi như thế nào từ họ.

Tôi đã suy nghĩ lâu hơn một chút về điều này, bởi vì tôi cảm thấy rằng có điều gì đó rất, rất sai với người phỏng vấn và không thể chỉ ra chính xác nó là gì. Đây là vấn đề: Đối với bất kỳ mã nào tôi đã viết trong hai mươi năm qua, lượng thời gian cần thiết để biến một thuật toán khả thi thành mã mà biên dịch được tối thiểu. Bất kỳ lợi ích nào về hiệu quả trong lĩnh vực đó có rất ít ảnh hưởng đến tổng thời gian phát triển đến mức nó hoàn toàn không đáng kể và một người phỏng vấn từ chối một ứng cử viên cho sự thiếu hiệu quả trong lĩnh vực đó không biết điều gì tạo nên một nhà phát triển giỏi.

Hầu hết thời gian nên dành cho việc thu thập thông tin những gì mã phải làm, thu thập thông tin và thông số kỹ thuật về các dịch vụ bên ngoài cần sử dụng, tạo ra một thiết kế toàn cầu sẽ dẫn đến mã chính xác và duy trì thay vì hack cùng mã và tìm thuật toán điều đó sẽ dẫn đến mã làm việc thay vì mã được vá lại với nhau cho đến khi nó hoạt động (mã rõ ràng không có lỗi so với mã không có lỗi rõ ràng).

Sau đó đến một lượng nhỏ thời gian viết mã biên dịch.

Sau đó, một lượng thời gian lớn hơn dành để đảm bảo rằng mã hoạt động và để đảm bảo rằng chúng tôi biết rằng mã hoạt động và sẽ vẫn hoạt động. Điều này được thực hiện bằng cách viết các bài kiểm tra đơn vị, bước qua mã và ở mức độ lớn bằng cách có mã được thiết kế tốt ở vị trí đầu tiên.

Người phỏng vấn này tập trung vào một cái gì đó được bao phủ bởi mười từ trong câu trả lời của tôi. Mà đại diện cho 10 phần trăm hoặc ít hơn thời gian làm việc thực tế. Và có ảnh hưởng gần như bằng không đến khả năng của nhà phát triển đó để tạo ra mã đáng tin cậy và hoạt động.

Ưu điểm của "biên dịch khi bạn đi cùng" là bạn nhận được phản hồi liên tục và sẽ không có cơ hội đi sai trước khi bị đẩy đi đúng hướng. Đối với một lập trình viên có năng lực như bạn, đó không phải là một sự cân nhắc lớn, nhưng đối với nhiều người khác thì nó là như vậy. Nói cách khác, "biên dịch khi bạn đi cùng" là một cách "giảm thiểu tổn thất tối đa", mặc dù có một số tổn thất hiệu quả tiềm năng trong trường hợp của bạn.

Các công ty ngày nay không chỉ quan tâm đến một sản phẩm hoàn chỉnh. Họ muốn biết rằng đó là "dưới sự kiểm soát" tất cả cùng. Đối với họ, "có được một nửa niềm vui."

Các câu trả lời khác ở đây có khả năng bảo vệ tốt cho việc biên dịch thường xuyên trong công việc , nhưng vì câu hỏi của bạn tập trung vào các cuộc phỏng vấn , tôi muốn giải quyết góc độ của nó.

Trong các cuộc phỏng vấn của tôi, tôi làm ngược lại chính xác: ứng viên không thể sử dụng trình biên dịch. Họ viết các chương trình ngắn trên bảng trắng và sau đó chúng tôi thảo luận về chúng. Tôi đã thấy rằng quá nhiều nhà phát triển sử dụng trình biên dịch (hoặc trình thông dịch) như một cái nạng, và đó là một sự lãng phí thời gian lớn hơn nhiều so với việc biên dịch quá ít khi. Nếu tôi cung cấp cho bạn rất nhiều tiền và thậm chí bạn không thể viết FizzBuzz một cách chính xác mà không có trình biên dịch, thì bạn sẽ không bao giờ cắt giảm nó trên cơ sở lâu dài, giải quyết các vấn đề khó hơn 100 lần so với các bài tập đồ chơi trong cuộc phỏng vấn. Tuy nhiên, những bài tập đơn giản này loại bỏ nhiều ứng viên hơn bất kỳ phần nào khác của cuộc phỏng vấn.

Mục tiêu của một cuộc phỏng vấn là đánh giá sự phù hợp lẫn nhau của ứng viên và doanh nghiệp. Một câu hỏi phỏng vấn tốt nên nêu rõ mục tiêu của câu hỏi và cách đánh giá người được phỏng vấn. Đặt ra một câu hỏi mẹo cho người được phỏng vấn và sau đó phạt họ vì không biết câu trả lời ẩn không giúp người phỏng vấn hoặc người được phỏng vấn. Thật không may, hầu hết các lập trình viên - ngay cả những người cao cấp - không được đào tạo để phỏng vấn các lập trình viên khác, vì vậy họ chỉ dựa vào những lời sáo rỗng và hỏi những loại câu hỏi tương tự mà họ đã hỏi khi họ phỏng vấn, mà không biết nhiều về việc liệu đây có phải là những kỹ thuật hiệu quả để đánh giá ứng viên hay không.

Tôi không khẳng định rằng cách tiếp cận của tôi là "một cách thực sự", nhưng nó đã phục vụ tôi rất tốt. Giống như rất nhiều phương pháp phần mềm bắt đầu bằng chữ in hoa, có một số "nhiệm vụ" tương đương để phỏng vấn. Tất cả đều là giường tầng. Bạn cần phải làm những gì làm việc cho bạn và doanh nghiệp của bạn.

Trong các dự án lớn hơn, với một số chương trình con, bạn muốn kiểm tra các phần này, trước khi sử dụng chúng trong sơ đồ lớn hơn, vì cách dễ dàng hơn để gỡ lỗi nếu bạn biết một số phần đã hoạt động.

Để kiểm tra các phần nhỏ hơn này, bạn cần phải biên dịch.

Có thể là người phỏng vấn nhầm lẫn tình huống này với một chương trình nhỏ không được thiết kế theo cách này.

Về cuộc phỏng vấn thứ hai, một lợi ích của việc biên dịch là bạn có thể quan sát, chỉ trong vài giây, các chương trình làm gì (hoặc không). Từ đó dễ dàng hơn để đọc mã và tập trung nỗ lực của bạn vào các phần có liên quan. Có lẽ đây là những gì người phỏng vấn đã mong đợi.

Đọc một cơ sở mã không xác định như thế này từ đầu đến cuối có thể khá không hiệu quả (bạn không phải là trình biên dịch), trong khi biên dịch / chạy ứng dụng sẽ nhanh chóng cho bạn một bức tranh lớn hơn.