Nếu đội của tôi có kỹ năng thấp, tôi có nên hạ thấp kỹ năng về mã của mình không? [đóng cửa]


156

Ví dụ: có một đoạn mã phổ biến trong JS để nhận giá trị mặc định:

function f(x) {
    x = x || 'default_value';
}

Loại đoạn trích này không dễ hiểu bởi tất cả các thành viên trong nhóm của tôi, mức độ JS của họ thấp.

Tôi không nên sử dụng thủ thuật này sau đó? Nó làm cho mã ít được đọc bởi các đồng nghiệp, nhưng dễ đọc hơn các mã sau theo bất kỳ nhà phát triển JS nào:

function f(x) {
    if (!x) {
        x = 'default_value';
    }
}

Chắc chắn, nếu tôi sử dụng thủ thuật này và một đồng nghiệp nhìn thấy nó, thì họ có thể học được điều gì đó. Nhưng trường hợp thường là họ thấy điều này là "cố gắng tỏ ra thông minh".

Vậy, tôi có nên hạ mức mã nếu đồng đội của tôi có cấp thấp hơn tôi không?


42
Tôi tin rằng điều này dẫn đến câu hỏi "Bạn có nên viết mã thành ngữ và buộc mọi người đến mức đó không? Hoặc viết mã không thành ngữ có thể giải thích rõ ràng mọi thứ?"

53
Đừng hạ thấp cấp độ kỹ năng của mã của bạn! Tôi đã học được rất nhiều từ việc đọc mã của các lập trình viên tiên tiến hơn. Tạo một văn hóa trong đó, nếu đồng nghiệp của bạn không hiểu điều gì đó, họ được khuyến khích hỏi (và tìm hiểu). Chỉ cần chắc chắn rằng bạn nhất quán.
Kosta Kontos

6
Bạn có đánh giá mã? Đó sẽ là một nơi tuyệt vời để họ đặt câu hỏi về mã như thế.
thegrinner

3
Một phần của kỹ năng mã hóa là sự rõ ràng, có tính đến "đối tượng" của bạn. Thành ngữ đặc biệt này có vẻ đáng để dạy, nhưng chắc chắn sẽ có trường hợp sẽ có ý nghĩa hơn khi sử dụng một phong cách mã hóa minh bạch hơn.
LarsH

3
Có phải nó chỉ có nghĩa là ai nghĩ rằng ví dụ thứ hai có chất lượng tốt hơn thì ví dụ đầu tiên vì những gì đang được thực hiện là rõ ràng? Có vẻ như ví dụ thứ hai dễ đọc hơn phiên bản tay ngắn là ví dụ đầu tiên. Có công cụ nào sẽ tự động lấy mã do con người tạo ra để tối ưu hóa nó cho Javascript không? Dựa trên kinh nghiệm Javascript của tôi, mã thực sự được chạy không nhất thiết phải chạy hiệu quả nhất có thể.
Ramhound

Câu trả lời:


135

Ok, đây là của tôi về chủ đề lớn và phức tạp này.


Ưu điểm cho việc giữ phong cách mã hóa của bạn:

  • Những thứ như x = x || 10là thành ngữ trong phát triển JavaScript và cung cấp một dạng thống nhất giữa mã của bạn và mã của các tài nguyên bên ngoài bạn sử dụng.
  • Cấp độ mã cao hơn thường biểu cảm hơn, bạn biết những gì bạn nhận được và dễ đọc hơn các chuyên gia được đào tạo cao.
  • Bạn sẽ thích công việc của bạn hơn. Cá nhân tôi đánh giá cao việc tạo mã đẹp. Tôi nghĩ rằng nó mang lại cho tôi rất nhiều sự hài lòng trong công việc của tôi.
  • Nói chung nó tạo ra phong cách dễ đọc hơn. Gắn bó với các thành ngữ của ngôn ngữ có thể rất có giá trị - chúng thường là thành ngữ vì một lý do.

Nhược điểm để giữ phong cách mã hóa của bạn:

  • Các lập trình viên cấp thấp sẽ khó theo kịp hơn. Đây thường là những người duy trì mã của bạn và những người sẽ thực sự phải đọc nội dung bạn viết.
  • Người duy trì mã, thường là mã JavaScript đến từ các ngôn ngữ khác. Các lập trình viên của bạn có thể thành thạo Java hoặc C # nhưng không hiểu chính xác cách thức và thời điểm JavaScript khác nhau. Những điểm này thường là thành ngữ - một biểu thức hàm được gọi ngay lập tức (IIFE) là một ví dụ về cấu trúc như vậy.

Ý kiến ​​cá nhân của tôi

Bạn không nên hạ thấp kỹ năng của mã của bạn. Bạn nên khao khát viết mã có ý nghĩa, rõ ràng và súc tích. Nếu bạn có bất kỳ nghi ngờ nào về trình độ của nhóm của bạn - hãy giáo dục họ . Mọi người sẵn sàng học hỏi nhiều hơn bạn nghĩ và sẵn sàng thích nghi với các cấu trúc mới khi tin rằng họ tốt hơn.

Nếu họ nghĩ rằng bạn 'chỉ cần thông minh', hãy cố gắng tranh luận quan điểm của bạn. Hãy sẵn sàng thừa nhận rằng đôi khi bạn sai, và dù thế nào, hãy cố gắng giữ phong cách nhất quán trong môi trường làm việc của bạn. Làm như vậy sẽ giúp tránh sự thù địch.

Điều quan trọng nhất là phải kiên định.

Mã nhóm nên được viết như thể một người đã mã hóa nó. Bạn hoàn toàn phải đồng ý về hướng dẫn mã hóa. Bạn nên tuân thủ những hướng dẫn đó. Nếu các nguyên tắc mã hóa xác định rằng việc đọc các tham số tùy chọn nên được thực hiện theo cách 'kém thông minh', thì đó là cách.


1
Tôi biết học tập là một điều bất biến, nhưng đó có thực sự là công việc của nhà phát triển này để đào tạo nhân viên của mình không? Đó thực sự là công việc của ban quản lý để tìm ra khóa đào tạo phù hợp nhất cho họ.
corsiKa

8
@corsiKa Những nhà phát triển đó không có khả năng học tất cả các đặc điểm riêng của ngôn ngữ thông qua "đào tạo có trả tiền" (nghĩa là loại quản lý đào tạo sẽ gửi nhân viên đến). Tôi coi đó là nơi làm việc bị bệnh khi đồng nghiệp không học hỏi lẫn nhau. Nó không giống như OP sẽ phải cung cấp cho họ đào tạo trong lớp học. Mọi người chỉ có thể đặt câu hỏi khi họ bị mắc kẹt và như đã đề cập trong một nhận xét ở trên, đánh giá mã có thể tốt để chia sẻ loại kiến ​​thức đó.
MetalMikester

2
Các nhân viên của anh ta nên tự học, từ các ví dụ do OP (và những người khác) đặt ra. Nếu không, họ sẽ không bao giờ tiến bộ ngoài kiến ​​thức hiện tại của họ. OP không cần phải dành hàng giờ mỗi ngày để đào tạo cá nhân họ, nhưng đánh giá mã và một phiên túi màu nâu thường xuyên có thể giúp tất cả mọi người (tốt, tất cả những ai muốn tìm hiểu, đó là).
alroc

1
@corsiKa đồng ý rằng việc xem xét mã của một nhà phát triển cấp cao không phải là đào tạo đầy đủ, mặc dù đó có thể là một cách tốt để xác định những điều mà nhà phát triển cơ sở nên tìm kiếm sau này.
Dan Lyons

2
@yms Đủ công bằng, đó là một quan điểm hợp lệ. Tôi không bao giờ tranh luận rằng khả năng đọc là vua. Tôi phản đối mạnh mẽ việc sử dụng nhiều ngôn ngữ như thể chúng là cùng một ngôn ngữ. Một phản đối 'kiếm được' trong hàng trăm giờ gỡ lỗi. Mặc dù tôi hoàn toàn đồng ý rằng khả năng đọc là vua, tôi tin rằng bạn không thể đối xử với các mã bằng nhiều ngôn ngữ tương tự nhau. Hơn nữa, tôi nghĩ rằng hầu hết JavaScript 'tiếng xấu' là do chính xác điều đó. Mọi người mong đợi nó hoạt động như một ngôn ngữ khác nhưng không được. Tôi đồng ý rằng khả năng đọc là nhiệm vụ quan trọng. Mã tốt hơn luôn luôn dễ đọc hơn :)
Benjamin Gruenbaum

47

Nhận xét tốt

Bạn có nên hạ thấp kỹ năng của mã của bạn? Không nhất thiết, nhưng bạn chắc chắn nên nâng cao kỹ năng bình luận của bạn . Hãy chắc chắn bao gồm các nhận xét tốt trong mã của bạn, đặc biệt là xung quanh các phần bạn nghĩ có thể phức tạp hơn. Đừng sử dụng quá nhiều bình luận mà mã trở nên khó theo dõi, nhưng hãy chắc chắn làm rõ mục đích của từng phần.

Thực tế là việc bình luận nhiều hơn một chút với các bình luận có thể hữu ích với các thành viên nhóm kém kỹ năng hơn, nhưng những người có kỹ năng thấp nhất bỏ qua chúng, đặc biệt là nếu có quá nhiều, vì vậy đừng lạm dụng nó.

Một vấn đề của phong cách?

Ví dụ bạn cung cấp có phần cơ bản, nhưng cũng khá phong cách. Một nhận xét xung quanh mỗi biến mặc định sẽ khá tẻ nhạt để duy trì và đọc. Thay vào đó, các phím tắt hoặc mẫu mã kiểu cách hoặc lặp đi lặp lại có lẽ nên được thiết lập như một tiêu chuẩn. Nếu bạn nghĩ rằng một cái gì đó giống như hình thức mặc định tham số đó nên được hiểu và sử dụng mọi lúc, hãy viết những ý tưởng này xuống và đưa chúng lên nhóm trưởng của bạn. Có thể tất cả những gì cần thiết để dạy cho đồng đội của bạn là một cuộc họp đơn giản nơi bạn thảo luận về các tiêu chuẩn bạn đề xuất.

Như một câu trả lời khác đã được nêu, giữ cho nó phù hợp .

Dạy một người đàn ông câu cá ...

Dạy cho đồng đội của bạn có lẽ là cách tốt nhất bạn có thể giúp mọi người tham gia. Hãy nói rõ rằng nếu bất cứ ai có câu hỏi về một đoạn mã có tên của bạn trong nhật ký cam kết hoặc dấu thời gian thì họ sẽ cảm thấy thoải mái khi hỏi bạn về điều đó. Nếu nhóm của bạn có đánh giá mã, đây là một cơ hội tuyệt vời để giải thích bất kỳ mã nào được nhận xét tốt (ahem) cho các đồng đội của bạn. Nếu nhóm của bạn không có đánh giá mã, tại sao không? Nhận nó!

Bạn cần phải cẩn thận, mặc dù. Bạn có thể không phải lúc nào cũng ở bên để dạy mọi người và thậm chí bạn có thể quên những gì ban đầu bạn đang cố gắng làm trong một phần mã nhất định.

Thủ thuật "thông minh"

Giữ cho khả năng của các đồng đội của bạn trong tâm trí chắc chắn rất quan trọng, nhưng viết mã có thể duy trì thường có nghĩa là không sử dụng các phím tắt phức tạp cho các vấn đề có thể có các giải pháp phổ biến hơn. Điều này rất quan trọng ngay cả khi đồng đội của bạn thông minh. Bạn không muốn làm cho mã mất quá nhiều thời gian để nắm bắt hoặc có các tác dụng phụ tinh tế nhưng quan trọng có thể bị bỏ qua. Nói chung, tốt nhất là tránh các thủ thuật "thông minh" khi có những lựa chọn thay thế phù hợp. Bạn không bao giờ biết ai có thể phải duy trì mã xuống dòng - thường thì các phiên bản cũ hơn của chúng ta sẽ không nhớ các chi tiết hoặc lý do cho các thủ thuật này.

Nếu bạn thấy rằng bạn phải thực hiện một mẹo thông minh, ít nhất hãy làm theo lời khuyên tiếp theo ...

HÔN

Khi nghi ngờ, hãy giữ nó đơn giản . Cho dù mã có đơn giản hay không không nhất thiết phải tương ứng với kỹ năng lập trình viên như bạn nghĩ. Trong thực tế, một số giải pháp tuyệt vời nhất cho một vấn đề là những giải pháp đơn giản nhất và một số giải pháp phức tạp hơn kết thúc trên TheD DailyWTF . Giữ mã của bạn đơn giản và súc tích có thể làm cho một số quyết định thông minh hơn nhưng có thể phản tác dụng dễ nắm bắt hơn.


10
Vấn đề là các tính năng ngôn ngữ được xem là "thủ thuật thông minh", ngay cả khi tôi nghĩ rằng chúng rõ ràng không có. Bao giờ nhìn thấy một đóng cửa? Bạn đã bao giờ nhìn thấy IIFE chưa? Bạn đã bao giờ thấy một tham chiếu chức năng được thông qua như một cuộc gọi lại? Đó là những tính năng ngôn ngữ mà mọi nhà phát triển JS có kinh nghiệm đều biết. Tuy nhiên, chúng là "những mánh khóe thông minh" đối với các nhà phát triển JS ít kinh nghiệm.
Florian Margaine

1
@FlorianMargaine nghe có vẻ như bạn cần phải thay đổi thuật ngữ, nghĩa là: đây không phải là "những mánh khóe thông minh", đây là những tính năng nâng cao hơn của ngôn ngữ ... 1 ngụ ý mã của bạn không dễ hiểu / là một điều xấu, 2 ngụ ý cơ hội học hỏi và cải thiện kỹ năng mã hóa 'của tôi' (làm thế nào để người khác thay đổi thuật ngữ của họ? Nhận xét, khuyến khích câu hỏi, chia sẻ bài viết mã giải thích cách các tính năng này hữu ích, v.v ...)
Andrew Bickerton

3
Nếu nó làm dịu cơn đau đầu của bạn, một phần của sự thất vọng có thể là Javascript như một ngôn ngữ ... không có ý nghĩa. Nó có ý nghĩa với Hoa Kỳ, những người đăng bài ở đây, bởi vì chúng tôi đã thực hiện nó trong một thời gian dài. Nhưng cho dù chúng ta đã làm cho ngôn ngữ hoạt động "tốt" như thế nào, với con mắt trung lập, nó chỉ không có ý nghĩa. Trên một ghi chú khác; đáng buồn thay, bạn có thể chứng minh giá trị của việc thuê các nhà phát triển có kinh nghiệm , hoặc tốt nhất là, các nhà phát triển 'bất kỳ ngôn ngữ' nào có sẵn sàng học hỏi các mô hình mới.
Katana314

1
@FlorianMargaine Tôi cũng làm việc chủ yếu với JavaScript, tôi biết nỗi đau mà bạn đang cảm thấy. Tôi đã tiếp cận điều này bằng cách cố gắng giáo dục đồng đội. Các video JavaScript Crockford ( 1 , 2 ) giúp đỡ. Tôi không nghĩ những điều bạn liệt kê nằm trong thủ thuật "thông minh" - đồng đội của bạn nên học chúng - nhưng một số điều bạn làm với các tính năng ngôn ngữ đó có thể là loại "thông minh" tồi. Làm thế nào để thuyết phục công ty của bạn thuê Devs có kinh nghiệm có lẽ là một câu hỏi hoàn toàn khác ...
Corion

2
Bình luận không phải lúc nào cũng tốt. Tôi đã đọc "Clean Code" một thời gian trước và một số điểm anh ấy đưa ra về nhận xét là tuyệt vời. Nếu bạn cảm thấy cần phải viết bình luận để giải thích mã của mình, rất có thể mã đó được viết xấu. Nếu mã được biểu cảm nhiều hơn, một nhận xét là không cần thiết. Mỗi khi bạn chuẩn bị viết bình luận, hãy dừng lại một chút để xem xét liệu tái cấu trúc có thể là một lựa chọn tốt hơn không. Nếu mã là biểu cảm, việc giải thích mục đích của nó trở nên không cần thiết. Ngoài ra, các bình luận có thể trở nên sai lệch hoặc đơn giản là sai nếu mã được thay đổi nhưng các bình luận không được cập nhật để phù hợp.
Pappa

34

Dường như có ác cảm rất lớn với việc tạo một hàm trong JS. Sự ác cảm này khiến mọi người cố gắng khéo léo và sử dụng các thủ thuật lố bịch chỉ để giữ các công cụ trong một dòng giống như một cuộc gọi chức năng sẽ có. Tất nhiên tên hàm trong một cuộc gọi cũng đóng vai trò là tài liệu bổ sung. Chúng tôi không thể đính kèm một nhận xét cho một biểu hiện khó khăn bởi vì sau đó nó sẽ đánh bại quan điểm thực hiện nó vì vậy chúng tôi chỉ gọi nó là "thành ngữ js" và đột nhiên nó có thể hiểu được.

Javascript cực kỳ dễ truy cập, hầu hết mọi người không ăn thông số kỹ thuật cho bữa sáng như chúng tôi. Vì vậy, họ sẽ không bao giờ hiểu những giả định ẩn và trường hợp cạnh của một thành ngữ là gì.

x = x || 'default_value';

Joe trung bình sẽ không hiểu điều này hoặc đã ghi nhớ rằng đó là thành ngữ cho giá trị mặc định. Cả hai đều có hại, trong thực tế sau này thậm chí còn có hại hơn. Anh ta sẽ không hiểu các giả định và trường hợp cạnh ở đây. Anh ta sẽ không quan tâm để đọc các đặc điểm kỹ thuật và hiểu nó bao giờ.

Khi tôi nhìn vào mã mà tôi nhìn thấy "nếu nó nullhay undefined, sau đó đặt nó vào giá trị mặc định này. Mặc dù nó cũng sẽ mặc nhiên điều trị +0, -0, NaN, false, và ""giá trị là không phù hợp. Tôi sẽ phải nhớ rằng 3 tháng kể từ bây giờ khi nhu cầu đó để thay đổi. Tôi có lẽ sẽ quên nó. ".

Giả định ngầm định rất có thể gây ra lỗi trong tương lai và khi cơ sở mã của bạn chứa đầy các mánh khóe như thế này thì không có cơ hội nào bạn giữ tất cả chúng trong đầu mỗi khi bạn nghĩ về việc sửa đổi sẽ ảnh hưởng gì. Và đây là cho "JS pro", kẻ thù trung bình sẽ viết lỗi ngay cả khi các yêu cầu phải chấp nhận giá trị giả để bắt đầu.

Đoạn mã mới của bạn có cú pháp quen thuộc hơn nhưng vẫn có vấn đề ở trên.

Bạn có thể đi với:

function f(x) {
    x = valueOrDefault(x, "default_value");
}

Bây giờ bạn có thể có logic rất phức tạp để xử lý các trường hợp cạnh và mã máy khách vẫn trông đẹp và dễ đọc.


Bây giờ, làm thế nào để bạn phân biệt giữa tính năng ngôn ngữ nâng cao như truyền một hàm làm đối số hoặc một mẹo thông minh như thế || "default"nào?

Các thủ thuật thông minh luôn hoạt động theo một số giả định ẩn có thể bị bỏ qua khi mã được tạo ban đầu. Tôi sẽ không bao giờ phải sửa đổi IIFE thành một thứ khác vì một yêu cầu đã thay đổi, nó sẽ luôn ở đó. Có thể vào năm 2020 khi tôi có thể sử dụng các mô-đun thực tế nhưng vâng.

| 0hoặc phiên bản sùng bái hàng hóa ~~numđược sử dụng cho sàn giả định giới hạn số nguyên dương và 32 bit có chữ ký.

|| "default" giả định tất cả các giá trị giả đều giống như không chuyển một đối số nào cả.

Và như vậy.


4
Bạn đang tập trung vào một ví dụ. Còn việc sử dụng những thứ như IIFE, đóng cửa, tham chiếu chức năng thì sao? Đó là điểm chính của câu hỏi của tôi.
Florian Margaine

1
@FlorianMargaine Bạn không nghĩ rằng tôi đã giải quyết điều đó trong phần thứ hai đủ tốt?
Esailija

3
Chà, nó không nói gì về cách xử lý tình huống mà tôi chỉ đơn giản sử dụng "tính năng ngôn ngữ nâng cao", mà đồng đội hiểu nhầm là "mánh khóe thông minh".
Florian Margaine

Tôi thích câu trả lời +1 này, tôi nghĩ rằng nó bỏ lỡ một phần lớn của câu hỏi, nhưng nó nói về các phần và kịch bản khác về nó một cách sâu sắc và giải thích các vấn đề trong các nhà phát triển nhóm khác tự mình chọn các khái niệm đó mà không cần hướng dẫn từ bạn mã.
Benjamin Gruenbaum

@FlorianMargaine bạn có nghĩa là làm thế nào để thực sự xử lý một tình huống trong thực tế tại nơi làm việc của bạn, nơi bạn đang sử dụng IIFE và ai đó nghĩ rằng đó là một mẹo thông minh? Giống như tôi đã giải thích, vì không có giả định ẩn, một ghi nhớ như "các biến sẽ không phải là toàn cầu" sẽ chỉ hoạt động tốt đối với mức trung bình.
Esailija

23

Bạn không nên hạ thấp kỹ năng lập trình của mình, nhưng bạn có thể cần điều chỉnh cách bạn viết mã. Mục tiêu, gần như trên tất cả, là làm cho mã của bạn rõ ràng cho những người phải đọc và duy trì nó.

Thật không may, nó có thể là một chút của một cuộc gọi phán xét về việc bất kỳ phong cách cụ thể là "thông minh" hay chỉ sử dụng nâng cao. Mã trong câu hỏi là một ví dụ tốt về điều này - giải pháp của bạn không nhất thiết phải tốt hơn giải pháp khác. Một số sẽ tranh luận nó là, một số sẽ không đồng ý. Vì cả hai giải pháp đều có hiệu suất thời gian chạy bằng nhau một cách hiệu quả (đọc: người dùng sẽ không bao giờ biết sự khác biệt), hãy chọn phong cách mà toàn bộ nhóm cảm thấy thoải mái nhất.

Trong một số trường hợp, bạn cần dạy cho họ cách viết mã tốt hơn, nhưng vào những lúc khác, bạn cần phải thỏa hiệp vì lợi ích của sự rõ ràng.


+1. Không có ví dụ cụ thể nào mà OP đưa ra là tốt hơn về mặt thực nghiệm so với cái khác, chúng chỉ đơn thuần là khác nhau.
Ross Patterson

câu trả lời rất hay @ bryan-sồiley. Chúc mừng
Andy K

7

Điều này có thể đã được nói trong một câu trả lời khác, nhưng tôi muốn trả lời câu hỏi này theo đơn đặt hàng của riêng tôi.

Hướng dẫn chung

Khi bạn làm việc trong một nhóm, bạn không phải là đối tượng mục tiêu của một đoạn mã. Đối tượng của bạn là nhà phát triển của nhóm của bạn. Đừng viết mã họ không thể hiểu mà không có lý do chính đáng.

  1. Trừ khi có một nhược điểm cụ thể đối với nó, tất cả các mã phải được viết theo một mẫu hoặc hướng dẫn cụ thể sẽ cho phép bảo trì dễ dàng bởi các nhà phát triển sẽ duy trì nó. (Một cảnh báo: Theo các mẫu xấu chỉ vì chúng hiện đang ở trong cơ sở mã là thực tiễn khủng khiếp.)
  2. Nếu bạn có thể tìm thấy một lý do chính đáng để sử dụng một thành ngữ ngôn ngữ cụ thể mà đối tượng mục tiêu không dễ đọc, hãy thêm một nhận xét. Nếu bạn thấy rằng bạn cần thêm một nhận xét cho mọi dòng khác, bạn có thể muốn viết lại mã của mình để khán giả của bạn dễ đọc hơn. Tôi không thấy nó có giá trị là thành ngữ vì lợi ích của thành ngữ.

Ví dụ cụ thể

Chúng tôi có một số lượng lớn các tập lệnh perl trong cơ sở mã của chúng tôi. Chúng tôi thường chỉ sử dụng perl cho các hoạt động rất đơn giản và phần lớn mã được viết bởi các nhà phát triển java, vì vậy nó có kiểu dáng giống như java. Chúng tôi có một tập hợp các tập lệnh perl và một khung được viết bởi 'perl guru' đã rời khỏi công ty của chúng tôi. Mã này chứa nhiều thành ngữ perl tối nghĩa hơn và không có nhà phát triển nào của chúng tôi, kể cả bản thân tôi, có thể đọc mã perl này mà không cần nỗ lực mở rộng. Chúng tôi thường nguyền rủa anh ta cho nó. :)


5

Nếu bạn viết mã tốt nhưng bạn nghĩ rằng đồng nghiệp hiện tại hoặc tương lai của bạn có thể gặp khó khăn khi theo dõi nó, bạn nên thêm một nhận xét ngắn gọn để giải thích nó.

Bằng cách đó, bạn có thể dạy họ điều gì đó mà không xúc phạm trí thông minh cá nhân của họ hoặc làm xấu hổ bất cứ ai trong một cuộc thảo luận nhóm.


3

Tôi sẽ không gọi ví dụ của bạn là một mánh khóe, mà chỉ là thành ngữ. Nếu bạn nên sử dụng nó phụ thuộc vào IMHO không quá nhiều vào cấp độ hiện tại của nhóm của bạn, nhưng nếu (ít nhất là một số) đồng đội của bạn sẵn sàng học một số thành ngữ mới. Tất nhiên, bạn nên thảo luận về chủ đề này với họ và không thực thi phong cách này trên họ. Và bạn không nên yêu cầu họ học mỗi ngày 5 điều mới hoặc "thủ thuật". Nhưng thành thật mà nói, nếu bạn chỉ có đồng đội không sẵn sàng học một cái gì đó mới, thậm chí nó đơn giản và nhỏ bé hơn thành ngữ này, bạn nên xem xét để thay đổi sang một nhóm khác.


3

Đọc câu hỏi này và các câu trả lời và thảo luận tiếp theo dường như có hai điểm. Thứ nhất: sử dụng các tính năng ngôn ngữ nâng cao có ổn không? Thứ hai: làm thế nào tôi có thể làm điều này mà không xuất hiện như thể tôi đang 'khoe'?

Trong trường hợp đầu tiên, nó có ý nghĩa để sử dụng các cải tiến và các tính năng nâng cao. Ví dụ: trong C #, bạn không phải sử dụng các biểu thức Linq hoặc Lambda nhưng hầu hết mọi người làm vì nó làm cho mã trở nên gọn gàng và dễ hiểu hơn, một khi bạn thực sự biết nó đang làm gì. Lúc đầu trông nó thật lạ.

Mọi người đã quen với các mẫu và trong nhiều trường hợp, mọi người sử dụng cách làm việc đã định chỉ để hoàn thành công việc. Tôi có tội với điều này như người đàn ông tiếp theo. Tất cả chúng ta đều có thời hạn. Ở một số khía cạnh, bạn có lỗi khi giới thiệu những ý tưởng mới và cách suy nghĩ mới! Điều này đến điểm thứ hai và đây có lẽ là nơi bạn có thể gặp phải sự kháng cự mạnh nhất.

Đối với người sử dụng trang web, họ không quan tâm đến phong cách nào được sử dụng, tất cả những gì họ quan tâm là nó có hoạt động không? Có nhanh không Vì vậy, nếu không có lợi thế về hiệu suất theo cách của bạn thì không có cách nào đúng hay sai trong ví dụ bạn đưa ra. Cách của bạn làm cho mã dễ đọc hơn hay không? Nó có thể làm một khi đồng nghiệp của bạn đã quen với nó.

Vì vậy, làm thế nào để bạn giới thiệu những thay đổi này? Hãy thử và thảo luận với các đồng nghiệp của bạn dọc theo những dòng này: bạn có biết rằng chức năng này có thể được viết theo cách này không? Đánh giá mã và lập trình cặp có thể là thời điểm tốt để cho phép 'thụ phấn chéo' các ý tưởng. Thật khó khăn cho tôi để quy định phải làm gì vì tôi không biết môi trường bạn đang làm việc. Tôi thấy rằng một số lập trình viên có thể rất phòng thủ và chống lại sự thay đổi. Một lần nữa tôi đã phạm tội này. Cách tốt nhất để làm việc với các loại lập trình viên này là dành thời gian tìm hiểu những gì khiến họ đánh dấu, tìm hiểu nền tảng của họ và sau đó so sánh và đối chiếu phong cách và kinh nghiệm của bạn với họ. Nó cần thời gian nhưng đó là thời gian chi tiêu tốt. Nếu có thể hãy thử và khuyến khích họ.


Nếu bạn nghĩ rằng sẽ dễ dàng hơn cho bạn để kiểm tra ý của bạn trong môi trường C # thì tôi nghi ngờ OP sẽ không phiền - tôi chắc chắn là không. Câu hỏi này không phải về JavaScript :) Hãy tưởng tượng từ bỏ các tham số tùy chọn hoặc lambdas trong mã của bạn vì các nhà phát triển nhóm khác không hiểu nó - bạn sẽ làm điều đó chứ? Tôi nghĩ rằng bạn nêu ra một số ý tưởng thú vị ở đây nhưng nếu bạn ngừng lo lắng về ngôn ngữ cụ thể, bạn có thể viết nó theo một cách hấp dẫn hơn :)
Benjamin Gruenbaum

1
Tôi làm việc chủ yếu với C # vì vậy đó là ví dụ dễ hiểu nhất. Bạn thực hiện một quan điểm tuyệt vời, liên quan đến việc liệu tôi sẽ từ bỏ các tính năng ngôn ngữ hữu ích chỉ vì những người khác không biết về chúng. Câu trả lời sẽ là không, nhưng tất nhiên điều khó khăn là khiến người khác thấy được những lợi thế của cách thức mới này, dường như là vấn đề chính của Florian.
Daniel Hollinrake

3

Vậy thì đừng làm việc cho Royal McBee Computer Corp, bởi vì ai sẽ nói bạn không phải là lập trình viên thiếu kinh nghiệm.

chắc chắn, thật tuyệt khi viết mã ngắn gọn và ngắn gọn và nó có thể hữu ích trong môi trường javascript (tốt, cho đến khi ai đó tạo trình biên dịch js để tải xuống trình duyệt, nhưng đó là một câu chuyện khác).

Tuy nhiên, điều quan trọng là khả năng mã của bạn tồn tại trong vài phút để bạn viết nó. Chắc chắn, nó nhanh chóng và dễ dàng và bạn có thể tách nó ra và tiếp tục, nhưng nếu bạn phải quay lại nó nhiều năm sau đó, đó là lúc bạn có thể nghĩ "muppet đã viết cái này" và nhận ra đó là bạn! (Tôi đã làm điều đó, chắc chắn rằng hầu hết mọi người cũng vậy .. Tôi đổ lỗi cho thời hạn quá tích cực, trung thực).

Đây là điều quan trọng duy nhất cần ghi nhớ, vì vậy trong khi tôi nói có - hãy đi với nhà điều hành cụ thể đó nếu nó hoạt động và rõ ràng, và các nhà phát triển 'thiếu kinh nghiệm' của bạn (mặc dù, đó là sự xúc phạm đối với họ, tôi biết rất nhiều của các nhà phát triển thiếu kinh nghiệm, người biết tất cả các toán tử và thủ thuật khi họ ghi nhớ các hướng dẫn và tài liệu tham khảo trang web khác nhau, họ viết mã tồi tệ nhất mặc dù họ biết mọi mẹo nhỏ ... có thể có nhiều điều hơn là trùng hợp ngẫu nhiên)

Dù sao, nếu bạn có thể đọc câu chuyện về Mel , bạn sẽ nhận ra các mánh khóe không phải là thứ tốt nhất để đặt bất kỳ mã nào, mặc dù Mel là một lập trình viên thực sự của đơn hàng đầu tiên. Điều này đặt trả tiền cho bất kỳ đối số nào trong đó ai đó nói rằng họ có thể viết mã tốt và mọi người khác cần phải tìm hiểu thêm để theo kịp.


1
Tôi không biết một lập trình viên duy nhất đã quay lại mã của họ (từ một tháng trước!) Và đã đi "ai đã viết cái này". Chúng tôi luôn phát triển trong phong cách (ít nhất là chúng tôi cố gắng). Trong trường hợp cụ thể này, OP đang viết mã tiêu chuẩn, không phải mã WTFish. OP không thảo luận về việc viết mã "thông minh" hoặc mã "ngắn hơn để được mát mẻ", đó là mã thành ngữ.
Benjamin Gruenbaum

2

Vâng, đối với những người mới bắt đầu trông giống như JS cơ bản với tôi.

Nhưng nói chung - bạn không nên sử dụng các cách hack thông minh, để diễn giải "gỡ lỗi khó gấp đôi so với lập trình. Nếu bạn viết mã thông minh nhất có thể, thì theo định nghĩa bạn không thể gỡ lỗi".

Điều đó không có nghĩa là bạn nên tránh mã chỉ vì người khác sẽ không hiểu mã - bạn nên viết mã theo cách rõ ràng và nhất quán nhất có thể. Nhưng tiêu chí rõ ràng của bạn phải là "tôi sẽ hiểu điều này trong lần đọc đầu tiên trong một năm" chứ không phải "có ai có thể hiểu được không".

Viết một cách rõ ràng, rằng bạn không gặp khó khăn trong việc hiểu và để người khác làm việc để tăng kỹ năng của họ - đừng tự làm khổ mình để cứu người khác một số rắc rối giả định.


1

Tôi đã thảo luận với các đồng đội của mình về loại tiêu chuẩn mã hóa mà chúng tôi muốn có vì đây chủ yếu là về cách thực hiện một số thứ có thể được thực hiện theo hàng chục cách cho cơ sở mã của chúng tôi. Nếu có một sự đồng thuận sẽ là nỗ lực ban đầu của tôi để trả lời.

Nếu không có, thì tôi có thể xem xét loại tiêu chuẩn được đề xuất nào có ý nghĩa và bắt đầu áp dụng nó vào thực tế một khi tôi đã xóa nó với quản lý và một số nhóm. Ý tưởng ở đây là đảm bảo rằng quản lý ổn với ý tưởng này và tôi không chỉ làm việc của riêng mình và sau đó buộc mọi người khác phải thực hiện nó.

Tôi sẽ xem xét điều này giống như câu hỏi về loại tiêu chuẩn và thực hành nào mà nhóm của bạn có chứ không chỉ là mức độ kỹ năng vì có nhiều cách để đánh giá mã. Làm thế nào tốt những người khác có thể duy trì nó là một trong những tiêu chí đó.


1

Vấn đề là bạn muốn khả năng đọc tốt của nguồn, nhưng khả năng đọc nằm trong mắt của kẻ si tình.

Tôi sẽ đề nghị rằng chúng ta cần các công cụ tốt hơn để giải quyết vấn đề này. Không có gì phức tạp, hãy nhớ, chúng tôi đã có công nghệ để làm điều đó trong hơn 50 năm. Bao gồm một trình phân tích cú pháp trong trình soạn thảo và yêu cầu trình soạn thảo lưu nguồn dưới dạng sexps (vâng, giống như lisp). Sau đó, nguồn được đọc, trình soạn thảo sẽ bỏ nó thành cú pháp và kiểu chữ (bạn biết, khoảng trắng, tab, dấu phẩy), hình thành người dùng thích.

Bằng cách này, bạn có thể nhập và đọc x = x || 10và các lập trình viên khác sẽ đọc nó dưới dạng

if (0 == x) { x = 10;}

emacs có tất cả các mảnh để làm điều đó một cách dễ dàng.


1
Trong trường hợp này, chúng tôi biết ai là kẻ si tình. Họ là đồng nghiệp của chúng tôi. Tôi nghĩ rằng cụm từ đó thường được sử dụng khi bạn không biết đối tượng của mình.
dcaswell

-1

Thay vì làm giảm mã, tại sao không cải thiện chất lượng của đội? Đào tạo, huấn luyện, giáo dục và thực hành tuyển dụng được cải thiện có thể làm rất nhiều để đảm bảo cải tiến liên tục.
Thống kê, thối mã, từ chối cải tiến và đổi mới bởi vì ai đó không muốn làm việc để tự cải thiện chỉ gây rắc rối xuống dòng, và sớm hơn là sau này.

Tất nhiên trong trường hợp cụ thể mà bạn thể hiện, bạn chỉ đang cố tỏ ra thông minh và cố tình viết mã bị che giấu, điều này không bao giờ là một ý tưởng hay. Mã trước hết phải dễ đọc, dễ hiểu, không được viết để cho thấy bạn thông minh đến mức nào khi tạo ra thứ gì đó trong các câu lệnh ít nhất có thể (trường hợp đặc biệt, ngoại trừ trường hợp nhiều câu lệnh sẽ dẫn đến hiệu suất kém không thể chấp nhận được cho).


5
Trong trường hợp này, tôi không thông minh. Tôi đang viết mã thành ngữ cho bất kỳ nhà phát triển có kinh nghiệm. Bạn có thấy tại sao bây giờ tôi đang vật lộn không? :)
Florian Margaine

3
Đoạn đầu tiên của bạn được đặt tại chỗ, nhưng -1 vì đoạn thứ hai của bạn không được đánh dấu. Thật không chính xác khi nói ví dụ này là một nỗ lực có chủ ý trong việc thông minh. Nó thực sự rất rõ ràng và quan trọng hơn, đó là một phong cách thành ngữ mà nhiều nhà phát triển javascript giỏi đồng ý. Đây không phải là thành ngữ duy nhất trong javascript cho các tham số chức năng mặc định, nhưng nó là một thành ngữ phổ biến.
Ben Lee
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.