Mã của một lập trình viên giỏi trông như thế nào? [đóng cửa]

Tôi là một lập trình viên có sở thích (bắt đầu với VBA để làm cho excel nhanh hơn) và đã làm việc với VB.NET / C # .NET và đang cố gắng học ADO.NET.

Một khía cạnh của lập trình luôn khiến tôi thất vọng là 'tốt' trông như thế nào? Tôi không phải là một người chuyên nghiệp nên có rất ít để so sánh. Điều gì tạo nên một lập trình viên giỏi hơn? Là nó:

• Họ đã hiểu rõ hơn về tất cả các đối tượng / lớp / phương thức trong một ngôn ngữ nhất định?
• Các chương trình của họ hiệu quả hơn?
• Thiết kế của các chương trình của họ tốt hơn nhiều về tài liệu tốt hơn, sự lựa chọn tốt về tên cho các chức năng, v.v.?

Nói một cách khác, nếu tôi xem mã của một lập trình viên chuyên nghiệp, điều đầu tiên tôi nhận thấy về mã của họ so với mã của tôi là gì? Ví dụ, tôi đọc những cuốn sách như 'Professional ASP.NET' của Wrox press. Các ví dụ về mã trong cuốn sách đó có phải là 'đẳng cấp thế giới' không? Đó có phải là đỉnh cao? Có lập trình viên hàng đầu nào nhìn vào mã đó và nghĩ rằng đó là mã hay không?

Danh sách dưới đây không phải là toàn diện, nhưng đây là những điều tôi đã nghĩ đến khi xem xét câu hỏi của bạn.

• Mã tốt được tổ chức tốt. Dữ liệu và hoạt động trong các lớp phù hợp với nhau. Không có phụ thuộc không liên quan giữa các lớp. Nó không giống như "spaghetti."

• Các bình luận về mã tốt giải thích tại sao mọi thứ được hoàn thành không phải những gì được thực hiện. Bản thân mã giải thích những gì được thực hiện. Nhu cầu nhận xét nên được tối thiểu.

• Mã tốt sử dụng các quy ước đặt tên có ý nghĩa cho tất cả, trừ các đối tượng nhất thời. tên của một cái gì đó cung cấp thông tin về thời điểm và cách sử dụng đối tượng.

• Mã tốt được kiểm tra tốt. Các bài kiểm tra đóng vai trò là một đặc tả thực thi của mã và các ví dụ về việc sử dụng nó.

• Mã tốt không phải là "thông minh". Nó thực hiện mọi thứ theo những cách đơn giản, rõ ràng.

• Mã tốt được phát triển trong các đơn vị tính toán nhỏ, dễ đọc. Các đơn vị này được sử dụng lại trong toàn bộ mã.

Tôi chưa đọc nó, nhưng cuốn sách tôi định đọc về chủ đề này là Clean Code của Robert C. Martin.

Điều đầu tiên bạn nhận thấy là mã của họ tuân theo một phong cách mã hóa nhất quán . Họ luôn viết các khối cấu trúc của họ giống nhau, thụt lề một cách tôn giáo và nhận xét khi thích hợp.

Điều thứ hai bạn nhận thấy là mã của chúng được phân đoạn thành các phương thức / hàm nhỏ kéo dài tối đa không quá vài chục dòng. Họ cũng sử dụng tên phương thức tự mô tả và nói chung mã của họ rất dễ đọc.

Điều thứ ba bạn sẽ nhận thấy, sau khi bạn làm rối với mã một chút là logic dễ làm theo, dễ sửa đổi - và do đó dễ bảo trì.

Sau đó, bạn sẽ cần một số kiến ​​thức và kinh nghiệm về kỹ thuật thiết kế phần mềm để hiểu các lựa chọn cụ thể mà họ đã thực hiện để xây dựng kiến ​​trúc mã của họ.

Về sách, tôi chưa thấy nhiều sách mà mã có thể được coi là "đẳng cấp thế giới". Trong sách, họ chủ yếu cố gắng trình bày các ví dụ đơn giản, có thể liên quan đến việc giải quyết các vấn đề rất đơn giản nhưng không phản ánh các tình huống phức tạp hơn.

Trích dẫn Fowler, tổng hợp khả năng đọc:

Bất kỳ kẻ ngốc nào cũng có thể viết mã mà máy tính có thể hiểu được.
lập trình viên giỏi viết mã mà con người có thể hiểu được.

'nough nói.

Cá nhân tôi sẽ phải trích dẫn "The Zen of Python" của Tim Peters. Nó cho các lập trình viên Python biết mã của họ trông như thế nào, nhưng tôi thấy rằng nó áp dụng cho tất cả các mã về cơ bản.

Đẹp còn hơn xấu.
Rõ ràng là tốt hơn ngầm.
Đơn giản là tốt hơn phức tạp.
Phức tạp là tốt hơn phức tạp.
Phẳng hơn là lồng nhau.
Thưa thớt tốt hơn dày đặc.
Số lượng khả năng đọc.
Các trường hợp đặc biệt không đủ đặc biệt để phá vỡ các quy tắc.
Mặc dù tính thực tế đánh bại sự thuần khiết.
Lỗi không bao giờ nên trôi qua một cách âm thầm.
Trừ khi im lặng một cách rõ ràng.
Khi đối mặt với sự mơ hồ, hãy từ chối sự cám dỗ để đoán.
Nên có một-- và tốt nhất là chỉ có một - cách thực hiện điều đó.
Mặc dù cách đó có thể không rõ ràng lúc đầu trừ khi bạn là người Hà Lan.
Bây giờ tốt hơn là không bao giờ.
Mặc dù không bao giờ thường tốt hơnngay bây giờ.
Nếu việc triển khai khó giải thích, đó là một ý tưởng tồi.
Nếu cách thực hiện dễ giải thích, đó có thể là một ý kiến ​​hay.
Không gian tên là một trong những ý tưởng tuyệt vời - hãy làm nhiều hơn nữa!

Mã là thơ.

Bắt đầu từ điểm logic này và bạn có thể rút ra nhiều phẩm chất mong muốn của mã. Quan trọng nhất, hãy quan sát rằng mã được đọc nhiều hơn nó được viết, do đó viết mã cho người đọc. Viết lại, đổi tên, chỉnh sửa và cấu trúc lại cho người đọc.

Một hệ quả sau:

Người đọc sẽ là bạn vào thời điểm n kể từ ngày tạo mã. Phần thưởng của việc viết mã cho người đọc là một hàm tăng đơn điệu của n. Người đọc nhìn vào mã của bạn lần đầu tiên được biểu thị bằng n == infinity.

Nói cách khác, khoảng cách thời gian từ khi bạn viết mã đến khi bạn xem lại mã càng lớn, bạn càng đánh giá cao những nỗ lực của mình để viết cho người đọc. Ngoài ra, bất kỳ ai mà bạn giao mã của mình sẽ đạt được lợi ích lớn từ mã được viết với người đọc là yếu tố được xem xét hàng đầu.

Hệ quả thứ hai:

Mã được viết mà không có sự cân nhắc cho người đọc có thể khó hiểu hoặc khó sử dụng một cách không cần thiết. Khi sự cân nhắc dành cho người đọc giảm xuống dưới một ngưỡng nhất định, người đọc nhận được ít giá trị hơn từ mã so với giá trị thu được bằng cách viết lại mã. Khi điều này xảy ra, đoạn mã trước đó sẽ bị loại bỏ và thật đáng tiếc, nhiều công việc được lặp lại trong quá trình viết lại.

Hệ quả thứ ba:

Hệ quả thứ hai đã được biết là tự lặp lại nhiều lần trong một vòng luẩn quẩn của mã được ghi chép kém, sau đó là các đoạn viết lại bắt buộc.

Tôi đã lập trình được 28 năm và tôi thấy đây là một câu hỏi khó trả lời. Đối với tôi mã tốt là một gói hoàn chỉnh. Mã được viết rõ ràng, với các tên biến và phương thức có ý nghĩa. Nó đã đặt tốt các bình luận nhận xét mục đích của mã và không chỉ làm xuất hiện mã mà bạn đã có thể đọc. Mã thực hiện những gì nó được cho là một cách hiệu quả, không lãng phí tài nguyên. Nó cũng phải được viết với một con mắt hướng tới khả năng bảo trì.

Điểm mấu chốt là nó có ý nghĩa khác nhau đối với những người khác nhau. Những gì tôi có thể gắn nhãn là mã tốt mà người khác có thể ghét. Mã tốt sẽ có một số đặc điểm chung mà tôi nghĩ rằng tôi đã xác định ở trên.

Điều tốt nhất bạn có thể làm là tiếp xúc với mã. Nhìn vào mã của người khác. Các dự án mã nguồn mở là một nguồn tốt cho điều đó. Bạn sẽ tìm thấy mã tốt và mã xấu. Bạn càng nhìn vào nó, bạn sẽ càng nhận ra rõ ràng những gì bạn xác định là mã tốt và mã xấu.

Cuối cùng bạn sẽ là người phán xét của chính mình. Khi bạn tìm thấy phong cách và kỹ thuật mà bạn thích áp dụng chúng, theo thời gian, bạn sẽ nghĩ ra phong cách của riêng mình và điều đó sẽ thay đổi theo thời gian. Không có người nào ở đây có thể vẫy đũa phép và nói điều gì là tốt và điều gì khác là xấu.

Đọc cuốn sách Code Complete. Điều này giải thích rất nhiều ý tưởng về cách cấu trúc mã và lý do làm như vậy. Đọc nó sẽ rút ngắn thời gian của bạn để thu thập kinh nghiệm cần thiết để phân biệt tốt và xấu.

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1229267173&sr=8-1

Bản thân tôi đã lập trình được gần 10 năm và đã làm việc với những người khác, tôi có thể nói không thiên vị rằng không có sự khác biệt giữa một lập trình viên giỏi và một lập trình viên trung bình.

Tất cả các lập trình viên ở cấp độ có thẩm quyền:

• Nhận xét đúng
• Cấu trúc hiệu quả
• Tài liệu sạch sẽ

Có lần tôi tình cờ nghe được một đồng nghiệp nói " Tôi luôn có tư duy rất logic và hợp lý. Tôi nghĩ đó là lý do tại sao tôi thích phát triển "

Theo tôi, đó là suy nghĩ của một lập trình viên bình thường. Một người nhìn thế giới theo các quy tắc và logic và cuối cùng tuân theo các quy tắc đó khi thiết kế và viết một chương trình.

Lập trình viên chuyên nghiệp, hiểu các quy tắc, nhưng cũng như bối cảnh của chúng. Điều này cuối cùng dẫn đến việc họ nảy ra những ý tưởng và triển khai mới, dấu ấn của một lập trình viên chuyên nghiệp. Lập trình cuối cùng là một hình thức nghệ thuật.

Nói một cách ngắn gọn, mã của một lập trình viên giỏi có thể được đọc và hiểu.

Theo tôi, mã của một lập trình viên giỏi là ngôn ngữ bất khả tri ; Mã được viết tốt có thể được đọc và hiểu trong một khoảng thời gian ngắn với sự suy nghĩ tối thiểu, bất kể ngôn ngữ lập trình được sử dụng là gì. Cho dù mã bằng Java, Python, C ++ hay Haskell, mã được viết tốt có thể hiểu được bởi những người thậm chí không lập trình bằng ngôn ngữ cụ thể đó.

Một số đặc điểm của mã dễ đọc là, các phương thức được đặt tên tốt, không có "thủ thuật" và "tối ưu hóa" phức tạp, các lớp được thiết kế tốt, có thể kể tên một số. Như những người khác đã đề cập, phong cách viết mã là nhất quán, ngắn gọn và dễ hiểu .

Ví dụ, một ngày nọ, tôi đang xem mã cho TinyMCE để trả lời một trong những câu hỏi trên Stack Overflow. Nó được viết bằng JavaScript, một ngôn ngữ mà tôi hầu như không sử dụng. Tuy nhiên, vì phong cách viết mã và các nhận xét được bao gồm, cùng với cấu trúc của chính mã, nó khá dễ hiểu và tôi có thể điều hướng qua mã trong vài phút.

Một cuốn sách đó là khá một cái mở mắt cho tôi trong lĩnh vực đọc mã tốt lập trình viên là đẹp Mã . Nó có nhiều bài báo được viết bởi các tác giả của các dự án lập trình khác nhau bằng các ngôn ngữ lập trình khác nhau. Tuy nhiên, khi tôi đọc nó, tôi có thể hiểu tác giả đang viết gì trong mã của mình mặc dù thực tế là tôi thậm chí chưa bao giờ lập trình bằng ngôn ngữ cụ thể đó.

Có lẽ điều chúng ta cần lưu ý là lập trình cũng là giao tiếp, không chỉ với máy tính mà còn với con người , vì vậy code của một lập trình viên giỏi gần giống như một cuốn sách được viết tốt, có thể truyền đạt cho người đọc những ý tưởng mà nó muốn truyền tải. .

• Dễ đọc
• dễ viết
• dễ bảo trì

mọi thứ khác đều là hình ảnh

Mã tốt nên dễ hiểu.
Nó nên được bình luận tốt.
Những phần khó càng nên nhận xét tốt hơn.

Mã tốt có thể đọc được. Bạn sẽ không gặp khó khăn gì khi hiểu mã đang làm gì trong lần đọc qua mã đầu tiên được viết bởi một lập trình viên chuyên nghiệp giỏi.

Thay vì lặp lại những gợi ý tuyệt vời của những người khác, thay vào đó tôi sẽ đề nghị bạn đọc cuốn Code Complete của Steve McConnell

Về cơ bản, nó là một cuốn sách có đầy đủ các phương pháp lập trình tốt nhất cho cả chức năng và phong cách.

[Câu trả lời hoàn toàn chủ quan]
Đối với tôi, code tốt là một hình thức nghệ thuật, giống như một bức tranh. Tôi có thể đi xa hơn và nói rằng đó thực sự là một bản vẽ bao gồm các ký tự, màu sắc, "hình thức" hoặc "cấu trúc" của mã và với tất cả những điều này rất dễ đọc / dễ biểu diễn. Sự kết hợp của tính dễ đọc, cấu trúc (tức là các cột, thụt lề, thậm chí các tên biến có cùng độ dài!), Màu sắc (tên lớp, tên biến, chú thích, v.v.) tất cả làm cho thứ mà tôi thích xem là một bức tranh "đẹp" có thể khiến tôi rất tự hào hoặc rất ghét mã của riêng mình.

(Như đã nói trước đây, câu trả lời rất chủ quan. Xin lỗi vì tiếng Anh của tôi.)

Tôi thứ hai đề xuất "Quy tắc sạch" của Bob Martin.

"Beautiful Code" đã được đánh giá cao vài năm trước.

Bất kỳ cuốn sách nào của McConnell đều đáng đọc.

Có lẽ "Lập trình viên thực dụng" cũng sẽ hữu ích.

%

Tôi chỉ muốn thêm 2 xu ... nhận xét của tôi vào mã của bạn - và chính mã của bạn, nói chung - sẽ nói mã của bạn làm gì, bây giờ nó hoạt động như thế nào. Khi bạn đã có khái niệm về mã 'khách hàng', là mã gọi mã khác (ví dụ đơn giản nhất là mã gọi một phương thức), bạn nên luôn lo lắng về việc làm cho mã của mình có thể hiểu được từ góc độ của "khách hàng". Khi mã của bạn phát triển, bạn sẽ thấy rằng đây là ... uh, tốt.

Rất nhiều nội dung khác về mã tốt là về những bước nhảy vọt về mặt tinh thần mà bạn sẽ thực hiện (chắc chắn, nếu bạn chú ý) ... 99% trong số đó phải làm thêm một chút công việc ngay bây giờ để giúp bạn có rất nhiều hoạt động sau này và khả năng tái sử dụng. Và cũng với việc làm đúng cách: tôi hầu như luôn muốn chạy theo cách khác thay vì sử dụng các biểu thức chính quy, nhưng mỗi khi tôi hiểu chúng, tôi thấy tại sao mọi người sử dụng chúng trong mọi ngôn ngữ mà tôi làm việc (chúng trừu tượng, nhưng làm việc và có lẽ không thể tốt hơn).

Về việc có nên xem sách hay không, theo kinh nghiệm của tôi thì chắc chắn là không . Nhìn vào các API và khuôn khổ và quy ước mã và mã của người khác và sử dụng bản năng của riêng bạn, đồng thời cố gắng hiểu tại sao mọi thứ lại như vậy và ý nghĩa của mọi thứ là gì. Điều mà mã trong sách gần như không bao giờ làm là lập kế hoạch cho những gì không có kế hoạch, đó là công việc kiểm tra lỗi. Điều này chỉ được đền đáp khi ai đó gửi email cho bạn và nói, "Tôi gặp lỗi 321" thay vì "này, ứng dụng bị hỏng rồi, yo."

Mã tốt được viết với tâm trí tương lai, cả từ quan điểm của lập trình viên và quan điểm của người dùng.

Điều này đã được giải đáp khá rõ trong cuốn sách của Fowler, "Tái cấu trúc", Đó là sự vắng mặt của tất cả các "mùi" mà ông mô tả trong suốt cuốn sách.

Tôi chưa xem 'ASP.NET chuyên nghiệp', nhưng tôi sẽ ngạc nhiên nếu nó tốt hơn OK. Xem câu hỏi này cho một số cuốn sách có mã thực sự tốt. (Tất nhiên, nó khác nhau, nhưng câu trả lời được chấp nhận là khó có thể đánh bại.)

Đây dường như là (nên) một Câu hỏi thường gặp. Có một bài báo ACM về mã đẹp. Có vẻ như có rất nhiều nhấn mạnh vào dễ đọc / hiểu. Tôi muốn đánh giá điều này là "dễ đọc / hiểu bởi các chuyên gia tên miền". Các lập trình viên thực sự giỏi có xu hướng sử dụng các thuật toán tốt nhất (thay vì các thuật toán O (n ^ 2) ngây thơ dễ hiểu) cho bất kỳ vấn đề nào đã cho, có thể khó làm theo, nếu bạn không quen thuộc với thuật toán, ngay cả khi lập trình viên đưa ra một tham chiếu đến thuật toán.

Không ai là hoàn hảo kể cả những lập trình viên giỏi nhưng mã của họ có xu hướng phấn đấu :

1. Tính đúng đắn và hiệu quả với các thuật toán đã được chứng minh (thay vì các bản hack ngây thơ và adhoc)
2. Sự rõ ràng (nhận xét về mục đích có tham chiếu đến các thuật toán không tầm thường)
3. Tính đầy đủ để bao gồm các vấn đề cơ bản (quy ước mã hóa, lập phiên bản, tài liệu, kiểm tra đơn vị, v.v.)
4. Succinctness (DRY)
5. Mạnh mẽ (khả năng chống chịu với đầu vào tùy ý và gián đoạn các yêu cầu thay đổi)

tôi thứ hai đề nghị cho "mã sạch" của chú bob. nhưng bạn có thể muốn xem tại http://www.amazon.com/Implementation-Patterns-Addison-Wesley-Signature-Kent/dp/0321413091 vì tôi nghĩ phần này giải quyết câu hỏi cụ thể của bạn tốt hơn một chút. mã tốt sẽ nhảy ra khỏi trang và cho bạn biết nó làm gì / hoạt động như thế nào.

Jeff Atwood đã viết một bài báo rất hay về cách các lập trình viên là Người đánh máy tham khảo đầu tiên: http://www.codinghorror.com/blog/archives/001188.html

Khi trở thành một nhân viên đánh máy, bạn luôn cần lịch lãm trong công việc, việc có cấu trúc và "ngữ pháp" phù hợp là rất quan trọng. Bây giờ chuyển đổi này thành kiểu "lập trình" sẽ bắt được kết quả tương tự.

Kết cấu

Bình luận

Vùng

Tôi là một kỹ sư phần mềm, có nghĩa là trong quá trình học tập của mình, tôi đã tiếp xúc với nhiều ngôn ngữ khác nhau nhưng lập trình của tôi luôn "cảm thấy" giống nhau, như cách viết của tôi trên fekberg.wordpress.com, tôi có một cách "đặc biệt" để gõ.

Bây giờ lập trình các ứng dụng khác nhau và bằng các ngôn ngữ khác nhau, chẳng hạn như Java, C #, Assembler, C ++, C, tôi đã đạt đến "tiêu chuẩn" của cách viết mà tôi thích.

Tôi xem mọi thứ dưới dạng "hộp" hoặc khu vực và mỗi khu vực có phần giải thích nhận xét. Một vùng có thể là "class Person" và bên trong Vùng này, tôi có một số phương thức cho các thuộc tính, mà tôi có thể gọi là "Access Method" hoặc tương tự và mỗi thuộc tính và vùng có nhận xét giải thích riêng.

Điều này rất quan trọng, tôi luôn xem mã của mình mà tôi làm, như "trở thành một phần của api", khi tạo cấu trúc API và sự sang trọng là RẤT quan trọng.

Nghĩ về điều này. Ngoài ra, hãy đọc bài báo của tôi trong Communication issues when adapting outsourcingđó giải thích sơ bộ về cách mã xấu có thể xung đột, Giải thích theo ý bạn: http://fekberg.wordpress.com/2008/12/14/communication-issues-when-adapting-outsourcing/

Mã tốt là dễ hiểu, dễ bảo trì và dễ thêm vào. Lý tưởng nhất là nó cũng hiệu quả nhất có thể mà không phải hy sinh các chỉ số khác.

Mã tuyệt vời đối với tôi là một cái gì đó đơn giản để nắm bắt nhưng tinh vi. Những điều khiến bạn phải thốt lên: "Ồ, tất nhiên, tại sao tôi không nghĩ về nó theo cách đó?". Mã thực sự tốt không khó hiểu, nó chỉ đơn giản là giải quyết vấn đề trong tầm tay một cách dễ hiểu (hoặc một cách đệ quy, nếu điều đó thậm chí còn đơn giản hơn).

Mã tốt là nơi bạn biết phương pháp làm gì từ tên. Mã xấu là nơi bạn phải tìm ra mã hoạt động để hiểu tên của nó.

Mã tốt là ở chỗ nếu bạn đọc nó, bạn có thể hiểu nó đang làm gì trong thời gian không quá nhiều so với việc đọc nó. Mã xấu là nơi bạn cuối cùng xem xét nó trong các lứa tuổi cố gắng tìm ra nếu nó xảy ra.

Mã tốt có những thứ được đặt tên theo cách làm cho những nhận xét tầm thường trở nên không cần thiết.

Mã tốt có xu hướng ngắn.

Mã tốt có thể được sử dụng lại để làm những gì nó làm ở bất kỳ nơi nào khác, vì nó không dựa vào những thứ thực sự không liên quan đến mục đích của nó.

Code tốt thường là một tập hợp các công cụ đơn giản để thực hiện các công việc đơn giản (tập hợp lại theo những cách được tổ chức tốt để thực hiện các công việc phức tạp hơn). Mã xấu có xu hướng trở thành những công cụ đa năng khổng lồ, dễ phá vỡ và khó sử dụng.

Code là sự phản ánh kỹ năng và tư duy của một lập trình viên. Các lập trình viên giỏi luôn có tầm nhìn về tương lai - mã sẽ hoạt động như thế nào khi các yêu cầu hoặc hoàn cảnh không giống như hiện nay. Nó sẽ có tỉ lệ như thế nào? Sẽ tiện lợi như thế nào khi tôi không phải là người duy trì mã này? Mã có thể tái sử dụng sẽ như thế nào để người khác làm những công việc tương tự có thể sử dụng lại mã và không viết lại. Điều gì xảy ra khi ai đó đang cố gắng hiểu mã mà tôi đã viết.

Khi một lập trình viên có tư duy đó, tất cả những thứ khác sẽ đúng chỗ.

Lưu ý: Cơ sở mã được nhiều lập trình viên sử dụng theo thời gian và thường không có chỉ định cụ thể về cơ sở mã cho một lập trình viên. Do đó, mã tốt là sự phản ánh tất cả các tiêu chuẩn của công ty và chất lượng của lực lượng lao động của họ.

(Tôi sử dụng "anh ấy" bên dưới vì đây là người mà tôi khao khát trở thành, đôi khi thành công).

Tôi tin rằng cốt lõi trong triết lý của một lập trình viên giỏi là anh ta luôn nghĩ "Tôi đang viết mã cho chính mình trong tương lai khi tôi sẽ quên tất cả về nhiệm vụ này, tại sao tôi lại làm việc đó, rủi ro là gì và thậm chí là nó như thế nào. mã phải hoạt động. "

Như vậy, mã của anh ta phải:

1. Làm việc (không quan trọng là mã đi đến câu trả lời sai nhanh như thế nào. Không có tín dụng nào trong thế giới thực).
2. Giải thích cách anh ấy biết rằng mã này hoạt động. Đây là sự kết hợp của tài liệu (javadoc là công cụ tôi lựa chọn), xử lý ngoại lệ và mã kiểm tra. Theo một ý nghĩa rất thực tế, tôi tin rằng, dòng cho dòng, mã kiểm tra có giá trị hơn mã chức năng nếu không có lý do nào khác ngoài việc nó giải thích "mã này hoạt động, đây là cách nó nên được sử dụng và đây là lý do tại sao tôi nên nhận đã thanh toán."
3. Được duy trì. Mã chết là một cơn ác mộng. Bảo trì mã kế thừa là một việc vặt nhưng nó phải được thực hiện (và hãy nhớ rằng, đó là "di sản" ngay khi nó rời khỏi bàn làm việc của bạn).

Mặt khác, tôi tin rằng một lập trình viên giỏi không bao giờ nên làm những điều này:

1. Ám ảnh về định dạng. Có rất nhiều IDE, trình chỉnh sửa và máy in đẹp có thể định dạng mã theo chính xác tiêu chuẩn hoặc sở thích cá nhân mà bạn cảm thấy phù hợp. Tôi sử dụng Netbeans, tôi thiết lập các tùy chọn định dạng một lần và nhấn alt-shift-F thỉnh thoảng. Quyết định cách bạn muốn mã trông, thiết lập môi trường của bạn và để công cụ thực hiện công việc khó khăn.
2. Ám ảnh về các quy ước đặt tên gây thiệt hại cho giao tiếp của con người. Nếu quy ước đặt tên đang khiến bạn phải đặt tên cho các lớp của mình là "IElephantProviderSupportAbstractManagerSupport" thay vì "Zookeeper", hãy thay đổi tiêu chuẩn trước khi bạn gây khó khăn hơn cho người tiếp theo.
3. Quên rằng anh ấy làm việc như một đội với những con người thực tế.
4. Hãy quên rằng nguồn gốc chính của lỗi mã hóa đang nằm trên bàn phím của anh ấy ngay bây giờ. Nếu có sai sót hoặc có lỗi, anh ấy nên nhìn lại bản thân mình trước.
5. Quên rằng những gì xung quanh đến xung quanh. Bất kỳ công việc nào anh ấy làm bây giờ để làm cho mã của anh ấy dễ tiếp cận hơn với độc giả trong tương lai gần như chắc chắn sẽ mang lại lợi ích trực tiếp cho anh ấy (bởi vì ai sẽ là người đầu tiên được yêu cầu xem mã của anh ấy?

1. Nó hoạt động
2. Nó có các bài kiểm tra đơn vị chứng minh rằng nó hoạt động

Phần còn lại là đóng băng ...

• Mã tốt nhất có một sự sang trọng nhất định mà bạn nhận ra ngay khi bạn nhìn thấy nó.
• Nó trông được làm thủ công, cẩn thận và chú ý đến từng chi tiết. Nó rõ ràng được sản xuất với một người có kỹ năng và có nghệ thuật về nó - bạn có thể nói nó trông như được điêu khắc và đánh bóng, thay vì thô và sẵn sàng.
• Nó nhất quán và dễ đọc.
• Nó được chia thành các chức năng nhỏ, có tính gắn kết cao, mỗi chức năng làm một việc và làm tốt điều đó.
• Nó được kết hợp tối thiểu, có nghĩa là phụ thuộc rất ít và được kiểm soát chặt chẽ, thường là ...
• Các hàm và lớp có sự phụ thuộc vào trừu tượng hơn là triển khai.

Trớ trêu thay, lập trình viên càng giỏi thì càng ít không thể thiếu anh / cô ấy sẽ trở thành vì mã sản xuất là duy trì tốt hơn bởi bất cứ ai (như đã nêu theo thoả thuận chung của Eran Galperin).

Kinh nghiệm của tôi nói ngược lại cũng đúng. Các tồi tệ hơn các lập trình viên các khó khăn hơn để duy trì / code của mình, do đó, không thể thiếu hơn anh / cô ấy sẽ trở thành, vì không có linh hồn khác có thể hiểu được câu đố sản xuất.

Tôi có một ví dụ điển hình:

Đọc mã nguồn GWT (google web takeit), bạn sẽ thấy rằng mọi kẻ ngốc đều hiểu nó (một số sách tiếng Anh khó đọc hơn mã này).