Gần đây tôi đã nhận thấy rất nhiều câu hỏi liên quan đến các kỹ thuật trừu tượng khác nhau và các câu trả lời về cơ bản là các kỹ thuật trong câu hỏi là "quá thông minh". Tôi nghĩ rằng một phần công việc của chúng tôi là lập trình viên là xác định các giải pháp tốt nhất cho các vấn đề chúng tôi đưa ra để giải quyết, và sự thông minh là hữu ích trong việc đó.

Vì vậy, câu hỏi của tôi là: những người nghĩ rằng các kỹ thuật trừu tượng nhất định là quá thông minh trái ngược với sự thông minh mỗi se , hoặc có một số lý do khác cho sự phản đối?

EDIT: Bộ kết hợp trình phân tích cú pháp này là một ví dụ về những gì tôi sẽ coi là mã thông minh. Tôi đã tải xuống cái này và xem nó trong khoảng nửa giờ. Sau đó tôi bước qua phần mở rộng vĩ mô trên giấy và thấy ánh sáng. Bây giờ tôi đã hiểu nó, nó có vẻ thanh lịch hơn nhiều so với trình kết hợp trình phân tích cú pháp Haskell.

Các giải pháp đơn giản là tốt hơn để bảo trì dài hạn. Và nó không chỉ luôn là về sự quen thuộc ngôn ngữ. Một dòng (hoặc dòng) phức tạp cần có thời gian để tìm hiểu ngay cả khi bạn là một chuyên gia về ngôn ngữ đã cho. Bạn mở một tập tin và bắt đầu đọc: "ok, đơn giản, đơn giản, hiểu rồi, vâng, WTF?!" Bộ não của bạn dừng lại ở tiếng rít và bây giờ bạn phải dừng lại và giải mã một dòng phức tạp. Trừ khi có một lý do cụ thể, có thể đo lường được cho việc thực hiện đó, đó là "quá thông minh".

Tìm hiểu những gì đang diễn ra ngày càng khó khăn hơn khi sự phức tạp tăng dần từ một phương pháp thông minh sang một lớp thông minh thành một mô hình thông minh. Bên cạnh những cách tiếp cận nổi tiếng, bạn phải tìm ra quá trình suy nghĩ để tạo ra một giải pháp "thông minh", có thể khá khó khăn.

Điều đó nói rằng, tôi ghét tránh một mô hình (khi việc sử dụng nó là hợp lý) chỉ vì ai đó có thể không hiểu nó. Chúng tôi tùy thuộc vào việc các nhà phát triển tiếp tục học hỏi và nếu chúng tôi không hiểu điều gì đó, đó là lý do để học nó, không phải để tránh nó.

Nguyên tắc KISS

Giữ cho nó đơn giản ngu ngốc. Giải pháp thông minh là tuyệt vời, nhưng thường thì giải pháp đơn giản nhất là tốt nhất.

Đầu tiên, gỡ lỗi khó gấp đôi so với viết mã ở vị trí đầu tiên. Do đó, nếu bạn viết mã một cách khéo léo nhất có thể, theo định nghĩa, bạn không đủ thông minh để gỡ lỗi nó.

Brian Kernighan

Lừa bỏ qua sự phức tạp; những người thực dụng phải chịu đựng nó; các chuyên gia tránh nó; thiên tài loại bỏ nó. - Alan Perlis

Giải pháp tốt nhất không phải lúc nào cũng là giải pháp thông minh nhất. Đôi khi các giải pháp đơn giản cũng tốt như nhau.

Trong Phần mềm, bạn luôn cần suy nghĩ về khả năng bảo trì. Nếu một đoạn mã quá thông minh đối với người sẽ duy trì nó, tôi sẽ nói rằng sự thông minh đó không đáng.

Để trích dẫn Brian Kernighan:

Đầu tiên, gỡ lỗi khó gấp đôi so với viết mã ở vị trí đầu tiên. Do đó, nếu bạn viết mã một cách khéo léo nhất có thể, theo định nghĩa, bạn không đủ thông minh để gỡ lỗi nó.

thông minh là một công cụ; tự nó không có hại. Nó chỉ trở nên có hại trong bối cảnh không cần thiết.

"Thông minh", khi được áp dụng cho mã, hầu như luôn luôn chỉ là một uyển ngữ cho "phức tạp không cần thiết".

Đọc mã tốt, rõ ràng, đơn giản là đủ khó. Đọc mã "thông minh" giống như nghiên cứu thơ Latin một lần nữa.

Sự nhầm lẫn xuất hiện bởi vì "thông minh" như một thuộc tính của một người có một ý nghĩa hoàn toàn khác. Trường hợp này cũng có thể được xem là một ví dụ về lý do tại sao thiết kế phần mềm cho người thật là khó: Bởi vì chúng mơ hồ.

Và bởi vì một số lập trình viên đau khổ để hiểu các giao thức xã hội mà hầu hết mọi người tuân theo, điều đó cấm họ trực tiếp tố cáo mã là "phức tạp không cần thiết", họ có thể khó phân biệt giữa hai nghĩa của từ thông minh . Trái với những gì một số người có thể nghĩ, tôi nghĩ cuối cùng thì "người dân" tốt hơn (nghĩa là: những người có sự đồng cảm và hướng nội và kiên nhẫn) làm cho các nhà phát triển tốt hơn. Bởi vì họ biết viết cho ai.

Hầu hết mọi người đang tập trung vào sự thông minh từ khía cạnh "Mã yêu cầu giải mã quá nhiều để tìm ra những gì nó đang làm" và tất cả những điều tồi tệ đi cùng với điều đó như

1. Không ai khác có thể tìm ra nó, hãy để một mình duy trì / gỡ lỗi nó.
2. Người viết thậm chí không biết nó làm gì.
3. Nó thực sự có thể không phải là tuyệt vời để bắt đầu với
4. Vân vân....

Tất cả những điểm tốt, nhưng có một khía cạnh tiêu cực khác của sự thông minh và đó là vấn đề bản ngã cũ. Điều này gây ra vấn đề dọc theo dòng

1. Một người quá "Thông minh" để sử dụng giải pháp của bất kỳ ai khác. Tại sao tìm kiếm những gì người khác đã làm khi bạn có thể phát minh ra cách lột da của chính con mèo đó?
2. Một số người nghĩ rằng họ đã phát minh ra giải pháp tuyệt vời nhất cho một vấn đề thường sẽ từ chối nhận bất kỳ đầu vào nào.
3. Không để ai sửa đổi mã "của họ" ngay cả khi có vấn đề rõ ràng hoặc cần thay đổi nhỏ.
4. Ngược lại, họ nghĩ rằng họ thông minh và cần sử dụng kỹ thuật "mới nhất" để chứng minh họ thông minh như thế nào nhưng không xử lý tốt nó trong các dự án cá nhân hoặc mã không sản xuất trước khi đưa nó vào các phần quan trọng của hệ thống.

Đôi khi chúng ta đều có lỗi với quá nhiều bản ngã, nhưng khi nó cản trở đội bóng thì đó là một vấn đề.

Thông minh tốt - tỷ lệ cao giữa các dòng mã thông minh so với các dòng trong một thay thế không thông minh. 20 dòng mã giúp bạn tiết kiệm từ việc viết 20000 là Thông minh cực kỳ tốt. Thông minh tốt là về tiết kiệm công việc của bạn.

Thông minh xấu - tỷ lệ thấp giữa các dòng mã được viết so với các dòng mã được lưu. Một dòng mã thông minh giúp bạn không phải viết năm dòng mã là Bad Clever. Thông minh xấu là về "thủ dâm cú pháp".

Chỉ cần lưu ý: Thông minh xấu gần như không bao giờ được gọi là "Thông minh xấu"; nó sẽ thường đi du lịch dưới các bí danh "đẹp", "thanh lịch", "súc tích" hoặc "cô đọng".

Tôi phải tự hỏi về định nghĩa thông minh của mọi người.

Cá nhân, tôi cảm thấy như mình đã thông minh khi thực hiện một vấn đề khó khăn, phức tạp và thực hiện nó theo cách rất đơn giản và dễ dàng, trong khi vẫn duy trì mức hiệu quả chấp nhận được.

tl; dr tôi cảm thấy thông minh khi trong quá trình đánh giá mã, người đánh giá của tôi nói "wow, điều đó dễ hơn tôi nghĩ nó sẽ xảy ra", trái ngược với "wtf là tất cả những điều này .."

Ngoài các câu trả lời lý thuyết được liệt kê, thường điều này được sử dụng trong bối cảnh quá thông minh cho những người khác.

Di chuyển giữa một nhóm chuyên sâu hiệu suất hàng đầu và một nhóm bảo trì tầng trung bình đôi khi để thấy sự khác biệt trong cuộc sống thực trong những gì "quá thông minh".

Bỏ qua các lập luận lý thuyết, quá thông minh thường dựa trên những gì các thành viên nhóm ít kỹ năng nhất có thể làm việc hợp lý, vì vậy nó rất liên quan đến môi trường.

Đôi khi tôi đã rất thông minh đến nỗi tôi đã sai.

Thực hiện, duy trì, kịp thời và giá rẻ là những cách tôi đo lường một giải pháp. Tôi đoán thông minh cũng có thể là một phần của giải pháp miễn là nó không ảnh hưởng tiêu cực đến những phẩm chất đó.

Nếu mã thông minh + số lượng bình luận cần thiết để làm cho mã dễ hiểu <= mã đơn giản, thì tôi nói hãy dùng mã thông minh. Mỗi lần.

Tôi nghĩ vấn đề nảy sinh khi những người viết "mã thông minh" cố tình không bình luận đúng, bởi vì chỉ khi ban đầu nó không thể hiểu được thì những thế hệ tương lai đi qua sẽ phải dành thời gian "đánh giá cao" sự thông minh của nó.

Tôi nhớ về một câu trích dẫn mà tôi đã thấy được gán cho nhiều người khác nhau, vì những câu trích dẫn hay thường có.

Để diễn dải:

Bất kỳ người thông minh nào cũng có thể làm cho phức tạp đơn giản, phải mất một thiên tài để làm cho phức tạp trở nên đơn giản.

Lấy một ý tưởng phức tạp và đơn giản hóa nó để có thể hiểu được sự thông minh của nhà xây dựng nhưng lấy một ý tưởng đơn giản và làm cho nó phức tạp cho thấy nhà xây dựng muốn được coi là thông minh.

Nếu giải pháp 'thông minh' khó tìm ra thì không nên sử dụng nó. Chẳng hạn, nếu thông qua các tác dụng phụ, bạn có thể hợp đồng một phép tính phức tạp thành một dòng, thật thông minh. Nhưng nếu phải mất một giờ để người khác tìm ra những gì trên thế giới bạn đã làm, thì quá thông minh.

Theo tôi, sự thông minh không phải là vấn đề. Thông thường chúng ta có thể nhầm lẫn về mã "thông minh" (không châm biếm) và mã "sâu sắc". Những gì tôi thấy là một vấn đề, là thực tế thường là mã "thông minh" (với sự châm biếm) chứa các yêu cầu ngầm không thể nhìn thấy, khiến cho việc gỡ lỗi và duy trì theo thời gian khó khăn hơn.

Có một số thuật toán được biết là thông minh. Quicksort là một, IMO.

Mã "Thông minh" (với sự mỉa mai) thường đưa ra các giả định về các biến được đặt và trạng thái của hệ thống hầu như bị ngắt kết nối với mã "thông minh" (như các tệp được mở trước đó, kết nối mạng, cơ sở dữ liệu, v.v.).

Lượng dữ liệu bạn phải tải lên não để duy trì chính xác mã "thông minh" thường là lớn để có tỷ lệ lợi ích chi phí tốt.

"Mã thông minh" là bất kỳ mã nào mà lập trình viên phải suy nghĩ thực sự khó khăn hoặc sử dụng một số kỹ năng nâng cao để viết nó. Vấn đề với nó là bỏ qua sự cần thiết phải có một "lề thông minh" nhất định, được thể hiện rõ nhất bởi Brian W. Kernighan:

"Gỡ lỗi khó gấp đôi so với viết mã ở vị trí đầu tiên. Do đó, nếu bạn viết mã càng khéo léo càng tốt, theo định nghĩa, bạn không đủ thông minh để gỡ lỗi."

Bởi vì những gì trông giống như minh để một nhà phát triển trong sự bùng nổ của sự sáng tạo chỉ có thể vượt qua như mớ hỗn độn và chỉ là một không đọc được , unmaintainable khối câu đố khó hiểu cho người khác.

Tuy nhiên, một khối câu đố hay, thông minh, hoạt động tốt, nhưng nếu bạn có kinh nghiệm, bạn sẽ thường nhận ra rằng nó sẽ khiến doanh nghiệp của bạn (không phải bạn, nhà phát triển) phải trả nhiều hơn để duy trì điều đó trên phương tiện hoặc lâu dài. Vì vậy, bạn thích làm dịu sự hăng hái của các nhà phát triển đồng nghiệp của bạn khi họ được thực hiện.

Tất nhiên, ngoại trừ, nếu có sự biện minh cho sự thông minh. Và nếu có một tài liệu tốt đi kèm với điều khó hiểu mà bạn vừa viết. Bạn đã nhận xét rằng đoạn mã thông minh, phải không? Giải thích ý định của nó, tại sao nó cần phải như thế nào, và nó hành xử như thế nào?

Nếu không có lý do nào, thì có lẽ đó chỉ là tối ưu hóa sớm, kỹ thuật quá mức hoặc một loại vấn đề YAGNI. Nếu phải mất 15 cấp độ gián tiếp để làm một cái gì đó đơn giản, thì rất có thể bạn cũng thuộc các loại trước đó. Và nếu nó không được ghi nhận, thì đó chỉ là rắc rối.

Mã tuyệt vời không nên yêu cầu người bảo trì luôn luôn ở mức 100% để hiểu nó. Mã tốt là thông minh. Mã tuyệt vời có thể gần như hiệu quả, nhưng tốt hơn trong nhiều khía cạnh khác. Mã tuyệt vời không nên yêu cầu IDE có 15 lượt xem để tuân theo thiết kế của ứng dụng của bạn.

Lưu ý: này, tôi đã viết một vài thứ tôi nghĩ là thông minh nhưng điều đó đã thu hút WTF? ngoài - nếu không phải là đồng phát triển của tôi - miệng của người quản lý của tôi. Phải nhìn nó từ quan điểm của họ.

Tôi có xu hướng thông minh , nhưng tôi cố gắng để trở nên thanh lịch .

Phát triển mã ngay bây giờ mà những người khác sẽ không thử và tránh sau này .

Đây là sự hiểu biết của tôi về vấn đề này, dựa trên kinh nghiệm của tôi và các câu trả lời khác:

1. Mã đã thông minh để viết, nhưng đi ra có thể đọc và duy trì được không được coi là có hại. Tuy nhiên, hầu hết các nhà phát triển sẽ không gọi loại mã đó là "thông minh"; họ có thể sử dụng một thuật ngữ khác như "thanh lịch". Có thể có hoặc không có một số tranh luận về việc liệu mã đó có tồn tại hay không.
2. Mã sản xuất đòi hỏi thời gian và nỗ lực đáng kể để hiểu ngay cả bởi một nhà phát triển dày dạn quen thuộc với ngôn ngữ này là "thông minh" và được mọi người coi là có hại.
3. Mã sản xuất đòi hỏi thời gian và nỗ lực đáng kể của các nhà phát triển thiếu kinh nghiệm được coi là có hại đối với một số người. Dù sao, tôi cũng đã thấy câu trả lời và tôi đã làm việc với các nhà phát triển, những người đã nói rõ ràng rằng họ muốn giữ mọi thứ "mẫu số chung thấp nhất".

Tôi biết một anh chàng; anh ấy có lẽ là người thông minh nhất mà tôi từng gặp. Anh ấy chắc chắn là một lập trình viên không thể tin được, có lẽ tốt hơn tôi từng có trong toàn bộ cuộc đời tôi về các chương trình lập trình tuyệt đối. Anh ta viết mã như anh ta đang gõ một tài liệu từ và có thể đảo ngược một danh sách được liên kết như bạn không tin. Nếu bạn muốn nói về việc viết một số mã phức tạp nghiêm trọng, anh ấy là người đàn ông của bạn và nếu tôi gặp phải một vấn đề khó tin thì tôi luôn hướng về anh ấy. Tuy nhiên, làm việc trong một dự án với anh ta trong một thiết lập nhóm là rất lớn. Ông không thể trực tiếp nhắm mục tiêu vấn đề kinh doanh và cung cấp một giải pháp hợp lý, hiệu quả và ngắn gọn cho nó. Đối với anh ta, một danh sách mã gồm 1000 dòng sẽ tốt hơn 100. Thay vì sử dụng các công cụ được cung cấp cho anh ta thông qua IDE hoặc khung, anh ta sẽ tung ra công cụ siêu tối ưu của riêng mình.

Trong khi tôi ngưỡng mộ khả năng của anh ấy để làm những điều phức tạp này, điều tôi cần là một người có thể giải quyết vấn đề và tiếp tục. Thật không hay để nói, hoặc thừa nhận, nhưng đôi khi trong thời gian thiết lập kinh doanh là tất cả mọi thứ và bạn phải giải quyết vấn đề và tiếp tục cuộc sống của mình, bạn luôn có thể quay lại sau và cải tạo lại địa ngục để cải thiện ma cua ban. Có một ranh giới giữa việc thông minh và cũng là một nỗi đau ở mông. Phương châm của tôi cho đội của tôi là luôn luôn, điều đơn giản nhất có thể sẽ hoạt động trong tình huống này và sau đó đi từ đó. Đôi khi đơn giản hơn không phải lúc nào cũng là câu trả lời nhưng đó là một nơi tốt để bắt đầu.

"Thông minh" trong ngữ cảnh này có nghĩa là "quá thông minh vì lợi ích của chính nó", tức là thứ gì đó hoạt động ngay bây giờ nhưng sẽ là cơn ác mộng để hiểu và thay đổi sau này.

Đặc biệt nếu đó là một thủ thuật khai thác tính năng tối nghĩa của ngôn ngữ lập trình hoặc sử dụng các hiệu ứng phụ kỳ lạ hoặc là một cách thực sự kỳ lạ để giải quyết vấn đề trong ngôn ngữ đích.

Tôi thích các giải pháp đơn giản, tôi thực sự thích cách ruby. Khi bạn muốn ví dụ tổng hợp 2 yếu tố đầu tiên trong danh sách. đầu tiên bạn cắt danh sách để làm cho nó có kích thước = 2 và sau đó bạn tổng hợp nó.

Tôi nhớ rằng một khi tôi đã sử dụng 1 danh sách thay vì 3 và tạo một chức năng lớn rất khó để duy trì / thay đổi.

trong thế giới ngày nay, chúng ta không phải hy sinh mã rõ ràng để thực hiện (ngoại trừ c ++, họ không phải làm như vậy, nhưng họ sẽ làm).

Thông thường khi bạn cần phải 'thông minh' để giải quyết vấn đề về mã. Nếu một cách giải quyết và không đơn giản thì bạn sẽ nhận được rất nhiều khuôn mặt bối rối hoặc các tác dụng phụ kỳ lạ khác khi giả định một số điều kiện (có thể đúng 100% tại thời điểm viết mã)

Do đó, thông minh == khó hiểu == xấu :( Nhưng cũng thật tuyệt vời khi tôi sử dụng chúng cho các giải pháp thực tế cho các vấn đề hạn chế.

Trích dẫn lại cho bối cảnh và dễ hiểu hơn:

"Gỡ lỗi khó gấp đôi so với viết mã ở vị trí đầu tiên. Do đó, nếu bạn viết mã càng khéo léo càng tốt, theo định nghĩa, bạn không đủ thông minh để gỡ lỗi."

Những gì Brian Kernighan viết ở đây rõ ràng đề cập đến sự chập chững, và anh ta đã sử dụng nhầm từ thông minh.

"Gỡ lỗi khó gấp đôi so với viết mã ở vị trí đầu tiên. Do đó, nếu bạn viết mã càng [bị sai] càng tốt, theo định nghĩa, bạn không đủ thông minh để gỡ lỗi."

Phép nhân chập, tích chập; vòng cuộn:

A thing that is complex and difficult to follow.

Tài giỏi:

Showing intelligence or skill; ingenious

Các lập trình viên có giáo dục biết rằng mã đơn giản là khéo léo. Mã đó là thông minh nhất có thể nên đơn giản theo định nghĩa. Các lập trình viên có giáo dục cũng sẽ tránh làm việc với và viết mã phức tạp như bệnh dịch hạch. Họ cũng sẽ biến mã phức tạp thành mã thông minh bất cứ khi nào họ có cơ hội. Mã thường bắt đầu phức tạp và tiếp cận sự thông minh vì kiến ​​thức về miền và sự hiểu biết về khả năng nhận thức của con người trong lập trình được hiểu rõ hơn thông qua kinh nghiệm và kiến ​​thức được chia sẻ.

Vì sự phổ biến của trích dẫn này và Brian Kernighan khá nổi tiếng trong ngành, việc lạm dụng từ này có tác động xã hội tiêu cực và tôi thực sự muốn thấy điều đó được giải quyết bởi chính người đàn ông đó. Trước khi viết bài viết này, tôi đã cố gắng xem liệu tôi có thể đơn giản gửi e-mail cho anh ấy không, nhưng, tôi không thể tìm thấy bất kỳ thông tin liên hệ email nào mà tôi hiểu :(.

Tác động xã hội tiêu cực mà tôi đã thấy là các lập trình viên khác tẩy chay các đồng nghiệp thông minh hơn của họ, bởi vì bây giờ họ thấy sự thông minh là một vấn đề. Vấn đề thực sự là những đồng nghiệp ngu ngốc nghĩ rằng họ thông minh bằng cách làm mọi thứ theo một cách mới lạ và liên tục phát minh ra những điều mới khi không có lợi thế thay vì hiểu và hiểu về cộng đồng lớn hơn và tái sử dụng những ý tưởng thông minh nhất có thể.

Tôi cần phải làm rõ rằng mặc dù thường đạt được một sự hiểu biết là khó hơn phát minh của riêng bạn. Bởi vì vấn đề phổ biến trong ngành cho thời hạn không thực tế phát minh ra vấn đề của riêng bạn cho vấn đề thích hợp nhỏ hơn của bạn sẽ được sử dụng để tiết kiệm thời gian. Điều này dựa trên sự quan sát rằng những thứ hữu ích, có thể tái sử dụng thường nhắm vào một phân khúc lớn hơn hoặc cung cấp một sự trừu tượng hóa hữu ích cho sáng chế. Nó cũng dựa trên thực tế là mọi người nhắm vào các hốc lớn để kiếm nhiều tiền hơn, khi điều này thường khiến công cụ này cực kỳ khó sử dụng vì sự phức tạp liên quan đến việc tạo ra thứ gì đó có thể sử dụng được cho một phạm vi rộng các ứng dụng.

Tác động xã hội tiêu cực khác là điều này ngăn cản sự tiến bộ và mong muốn thấu hiểu bởi vì trong thế giới bình thường của chúng ta, chúng ta sẽ ngay lập tức phủ nhận sự thiếu hiểu biết của chính mình và viết ra mã bị coi là sai lầm ngay cả khi, một khi đã hiểu, ý tưởng thực sự là khá thông minh.

TODO Tôi muốn trích dẫn một số tài liệu tham khảo nhưng tôi cũng muốn thiếu tài liệu tham khảo để không cản trở khả năng chia sẻ thông tin của tôi vì vậy tôi sẽ nhanh chóng trích dẫn những gì tôi nhớ là nguồn thông tin của mình và có thể tôi sẽ tìm thấy thông tin thực tế ngày (hoặc bạn có thể tìm thấy nó cho tôi! :)

• Guido Van Rossum nói về các vòng lặp sự kiện và cách anh ấy hiểu được chúng
• Một nhân viên GitHub đã tuyên bố rằng họ tránh tuyển dụng những người thông minh trên Y-Combinator
• Phần lớn các cuộc thảo luận và học hỏi diễn ra trong cộng đồng Python. Cộng đồng Python đặc biệt chỉ trích những ý tưởng mới, nhưng không loại bỏ những ý tưởng mới mà họ không hiểu được và bạn thường có thể thấy các tính năng ban đầu được xem là hỗn độn, coi ánh sáng ban ngày là một tính năng / gói ngôn ngữ cốt lõi.
• Kinh nghiệm của riêng tôi và ý kiến ​​chuyên môn dựa trên 10000 quan sát chân của tôi. Tôi thực sự không thể nhìn thấy các chi tiết cụ thể để khai sáng từ mọi nơi trên đó :( Hy vọng kinh nghiệm và sự quan sát của bạn sẽ cho bạn biết điều tương tự và ai đó có thể nhận xét bên dưới để đưa ra câu trả lời này.

Hãy thêm trích dẫn của riêng bạn! Ngoài ra, hãy thoải mái thêm dấu phẩy vào văn bản của tôi. Tôi đã không làm mới kiến ​​thức của mình về việc sử dụng dấu phẩy bằng tiếng Anh trong một thời gian khá lâu ...

Bởi vì mọi người thường không biết một ngôn ngữ, thành ngữ và mẫu. Họ có thể lấy một cuốn sách và học nó, nhưng họ không làm thế. Và vì những người đó bạn nên viết mã đơn giản.

Đó không phải là một sự thông minh. Đó là một kiến ​​thức.

Tôi không thể tìm ra kỷ luật từ nhắc đến bất cứ nơi nào quanh đây, vì vậy tôi sẽ chip trong. Tôi không muốn gửi các câu trả lời, nhưng để chia sẻ một cái nhìn sâu sắc khác nhau về vấn đề này, có lẽ một trong những câu hỏi ban đầu đã không có trong tâm trí .

Một nhà phát triển thông minh là một điều tốt.

Tuy nhiên, trước khi sự thông minh đến những đặc điểm khác. Như bạn có thể nhận ra tôi sẽ nói về kỷ luật . Một nhà phát triển thông minh và vô kỷ luật có thể rất tệ cho khả năng bảo trì dài hạn của hệ thống.

Giả sử rằng một lỗi phát sinh hoặc một yêu cầu mới xuất hiện. Một nhà phát triển thông minh có thể sớm nhận ra rằng một vài sửa lỗi cục bộ sẽ hoàn thành công việc trong 2 phút. Nếu nhà phát triển đó bị kỷ luật, anh ta sẽ hạn chế áp dụng các bản sửa lỗi đó cho mã nguồn và thay vào đó, sẽ tìm một cách có ý nghĩa để soạn hành vi mong muốn cho hệ thống. Bằng cách này, lần sau khi có nhu cầu sẽ sửa đổi các đoạn mã cụ thể, người bảo trì sẽ có một thời gian dễ dàng để hiểu mã và thực hiện các thay đổi mới mà không vi phạm bất cứ điều gì. Nếu không, bạn cũng có được hình ảnh.