Giá trị thực của kiểu mã nhất quán là gì


47

Tôi là một phần của nhóm tư vấn thực hiện một giải pháp mới cho khách hàng. Tôi chịu trách nhiệm cho phần lớn các đánh giá mã trên cơ sở mã phía máy khách (React và javascript).

Tôi đã nhận thấy rằng một số thành viên trong nhóm sử dụng các mẫu mã hóa duy nhất đến một điểm mà tôi có thể chọn một tệp một cách ngẫu nhiên để nói ai là tác giả từ phong cách đó.

Ví dụ 1 (hàm nội tuyến một lần)

React.createClass({
  render: function () {
    var someFunc = function () {
      ...
      return someValue;
    };
    return <div>{someFunc()}</div>
  }
});

Tác giả lập luận rằng bằng cách gán một tên có ý nghĩa cho someFunc, mã sẽ dễ đọc hơn. Tôi tin rằng bằng cách nội tuyến chức năng và thêm một nhận xét thay vì hiệu quả tương tự có thể đạt được.

Ví dụ 2 (các hàm không liên kết)

function renderSomePart(props, state) {
    return (
      <div>
        <p>{props.myProp}</p>
        <p>{state.myState}</p>
      </div>
    );
}

React.createClass({
  render: function () {
    return <div>{renderSomePart(this.props, this.state)}</div>;
  }
});

Đây là cách chúng tôi thường làm (tránh phải vượt qua trạng thái và đạo cụ):

React.createClass({
  renderSomePart: function () {
    return (
      <div>
        <p>{this.props.myProp}</p>
        <p>{this.state.myState}</p>
      </div>
    );
  },
  render: function () {
    return <div>{this.renderSomePart()}</div>;
  }
});

Mặc dù các mẫu mã hóa này đúng về mặt kỹ thuật, chúng không phù hợp với phần còn lại của cơ sở mã cũng như kiểu dáng và mẫu mà Facebook (tác giả của React) gợi ý trong các hướng dẫn và ví dụ.

Chúng tôi cần phải giữ tốc độ nhanh để giao hàng đúng giờ và tôi không muốn gây gánh nặng cho đội một cách không cần thiết. Đồng thời chúng ta cần phải ở mức chất lượng hợp lý.

Tôi đang cố gắng tưởng tượng mình là nhà phát triển bảo trì của khách hàng phải đối mặt với những mâu thuẫn như thế này (mọi thành phần có thể yêu cầu bạn hiểu một cách khác để làm điều tương tự).

Câu hỏi:

Giá trị theo cảm nhận của khách hàng và các nhà phát triển bảo trì của một cơ sở mã nhất quán so với việc cho phép các mâu thuẫn như thế này được duy trì và có khả năng lan truyền là gì?


50
Giá trị của một chỉnh hình phù hợp là gì? Một tốc độ vĩnh viễn, liên tục tăng tốc trong việc đọc và viết văn bản. Giá trị của phong cách mã nhất quán là gì? Một tốc độ vĩnh viễn, nhất quán trong việc đọc và viết mã. bạn có thể muốn gì khác?
Kilian Foth 7/07/2015

9
Khi bạn đọc những thứ bạn đã quen với các mẫu trong những gì bạn đang đọc và dự đoán làm thế nào để đọc những thứ trong tương lai. Nếu không có tính nhất quán, người ta không thể lường trước các mẫu và cần phải giải thích thêm mã, làm chậm trình đọc.
Canada

1
Joel có một số ý tưởng tốt về chủ đề đó. Nói tóm lại, một tiêu chuẩn mã hóa tốt làm cho các lỗi dễ nhìn thấy. joelonsoftware.com/articles/Wrong.html

13
Tôi muốn thêm rằng các hàm được đặt tên hầu như luôn được ưu tiên hơn các hàm ẩn danh trong JavaScript. Khi gỡ lỗi, điều này giúp một tấn xác định vị trí của bạn trong ngăn xếp.
Mike McMahon

1
@yoniLavi bạn nên hỏi điều đó trên meta.
RubberDuck

Câu trả lời:


48

Lợi thế chuyển mã

Theo các mẫu được cung cấp bởi thư viện, Reacttrong trường hợp của bạn, có nghĩa là sản phẩm bạn phân phối sẽ dễ dàng được chọn và duy trì bởi các nhà phát triển khác, những người cũng quen thuộc với React.

Các vấn đề tương thích ngược tiềm năng

Một số thư viện sẽ có phiên bản chính mới và khả năng tương thích ngược có thể bị tổn hại nếu các mẫu của bạn khác biệt đáng kể, do đó làm chậm / tạm dừng nâng cấp trong tương lai của bạn. Tôi không chắc làm thế nào Reactsẽ đối phó với các bản phát hành mới, nhưng tôi đã thấy điều này xảy ra trước đây.

Thành viên mới trong nhóm bắt đầu nhanh hơn năng suất

Nếu bạn làm theo những gì được cung cấp bởi tác giả, nhiều khả năng bạn sẽ thuê các nhà phát triển tài năng sử dụng khuôn khổ của bạn và bắt đầu họ nhanh hơn với hệ thống của bạn thay vì dạy các mẫu mới.

Các vấn đề tiềm năng chưa được khám phá

Có thể có những vấn đề trong tương lai mà bạn chưa phát hiện ra với cách tiếp cận của mình, được giải quyết bằng cách tiếp cận của tác giả.

Điều đó đang được nói, đổi mới luôn luôn là một rủi ro, nếu bạn cảm thấy mạnh mẽ rằng phương pháp của bạn tốt hơn và nó hiệu quả với nhóm của bạn, hãy thực hiện nó!


Cảm ơn bạn cho những điểm tuyệt vời. Chúng tôi thường theo mô hình được cung cấp bởi thư viện. Các ví dụ tôi đã đưa ra (tìm thấy trong các đánh giá mã) đi chệch hướng. Tôi đã lo lắng rằng khách hàng có thể từ chối và yêu cầu chúng tôi làm lại một phần giao hàng của chúng tôi vì nó không "trông giống như React". Bây giờ tôi biết tại sao họ sẽ làm điều đó.
Andreas Warberg 7/07/2015

2
+1 "rather than teaching new patterns"- đào tạo về thủ tục là một khoảng thời gian rất lớn với những nhân viên mới. Luôn cố gắng giảm thiểu chi phí thời gian bằng cách cõng những mẫu nổi tiếng
Gusdor 8/07/2015

1
@Alexus: Về khả năng tương thích ngược, React vẫn chưa có ở phiên bản 1.0. Phiên bản hiện tại, 0.13, đã phá vỡ tính tương thích theo một số cách khá quyết liệt, mặc dù những lỗi này có xảy ra hay không phụ thuộc vào cơ chế nào được sử dụng để gọi các thành phần React. Có các quy tắc rất nhất quán về cách gọi React có thể không ngăn việc nâng cấp React phá mã, nhưng sửa mã nhất quán thì dễ dàng hơn, nhanh hơn và đáng tin cậy hơn. Mối quan tâm của bạn về các vấn đề tương thích ngược chắc chắn là hợp lý trong trường hợp React. Ví dụ: xem nhận xét của tôi về stackoverflow.com/a/20913637/18192
Brian

53

Sự không nhất quán làm cho bạn dừng lại và suy nghĩ tại sao , cái nàoở đâu :

  • Khi bạn đọc một phần của mã và thấy rằng nó sử dụng một kiểu khác với phần còn lại của mã, nó làm cho bạn tự hỏi - tại sao phần đặc biệt này lại khác? Nó có một lý do đặc biệt mà tôi cần phải nhận thức? Điều này rất nguy hiểm, bởi vì nếu thực sự có lý do cho phần đó khác đi, bạn cần phải biết về nó nếu không bạn có thể tạo ra một số lỗi khó chịu. Vì vậy, thay vì suy nghĩ về vấn đề ban đầu khiến bạn cảm động, bạn đã lãng phí thời gian để suy nghĩ tại sao nó lại khác biệt và bạn không thể tìm ra điều đó để bạn đến gặp tác giả ban đầu để hỏi họ, cũng lãng phí thời gian của họ và thậm chí tệ hơn - trong quá trình cả hai bạn thả lỏng mô hình tinh thần về các vấn đề bạn đang làm việc.

    Nhân với mọi nhà phát triển khác trong nhóm cần chạm / đọc mã đó.

  • Khi bạn cần phải thêm vào một mã mà sử dụng nhiều phong cách, bạn cần phải dừng lại và quyết định phong cách để sử dụng cho ngoài của bạn. Bạn phải đưa ra đủ các quyết định quan trọng - thật lãng phí thời gian để suy nghĩ về các quyết định không quan trọng.

  • Khi kiểu dáng nhất quán, thật dễ dàng để điều hướng xung quanh mã, bởi vì tính nhất quán giúp bạn nhanh chóng tìm thấy vị trí của công cụ. Với phong cách không nhất quán, thậm chí grepping trở nên khó khăn hơn bởi vì bạn không biết phong cách mà thứ bạn đang tìm kiếm đang sử dụng.


6
Tuyệt vời, cái nhìn sâu sắc của fanstastic. Tại sao một số nhà phát triển dường như chỉ 'hiểu' điều này và những người khác chiến đấu chống lại nó?
Dogweather

2
Nghi ngờ bởi vì một phong cách nhất quán đang được đề xuất bây giờ rất không phù hợp với những gì họ đã làm trong các dự án trước đó. Đặc biệt đối với những người có nhiều kinh nghiệm trong các môi trường khác nhau.
Khởi động

4

Mã có thể được viết tốt nhưng không hoàn toàn phù hợp, vì vậy một số khách hàng sẽ không quan tâm. Khi mọi thứ bắt đầu trở nên tồi tệ, bạn có muốn cho họ một cú đánh khác chống lại bạn không? Nếu tôi thuê một công ty làm việc trong một dự án đa nhà phát triển và họ không cho tôi biết rằng họ có một tiêu chuẩn mã hóa và tuân theo nó, tôi sẽ nghi ngờ.

Chúng tôi cần phải giữ tốc độ nhanh để giao hàng đúng giờ và tôi không muốn gây gánh nặng cho đội một cách không cần thiết.

Miễn là các tiêu chuẩn mã hóa không quá điên rồ, mọi người sẽ không khó để lên tàu. Các dự án bị đình trệ vì mọi người không biết nên viết mã nào hoặc không viết và không phải vì gõ và định dạng. Bạn sẽ biết bạn đã đi xa khi phải mất một khoảng thời gian không tương xứng để tuân thủ. Hy vọng rằng, đây không phải là cuộc đua đầu tiên của bạn.

Thực hiện bài kiểm tra của riêng bạn Tất cả những gì bạn cần làm là chuyển đổi bài tập giữa chừng từ nhà phát triển này sang nhà phát triển khác và yêu cầu họ hoàn thành tập tin của người khác. Họ có dành thời gian định dạng lại hoàn toàn mọi thứ cho phiên bản của họ? Có quá khó để làm theo? Nó sẽ trở nên tồi tệ hơn cho đội bảo trì của khách hàng của bạn.


2

Tôi đã có may mắn đối xử với các kiểu mã giống như tôi đối xử với các kiểu viết bằng tiếng Anh tự nhiên. Có một loạt các phong cách từ tiếng Anh đàm thoại, bắt chước cách chúng ta nói chuyện hàng ngày, đến tiếng Anh chính thức, vốn thường nặng nề và nghiêm khắc bởi ý nghĩa của nó luôn rất chính xác.

Xem xét những gì bạn muốn sản phẩm cuối cùng trông như thế nào theo nghĩa đó. Một số tình huống rất ủng hộ việc sử dụng bất kỳ cấu trúc nào là tốt nhất tại thời điểm đó. Những người khác đòi hỏi một nhịp điệu và cấu trúc thống nhất. Điều này đặc biệt đúng nếu sản phẩm của bạn là tốt nhất mặc dù nó được viết bằng tiếng Anh chính thức. Colloquialism có thể giúp đỡ trong trường hợp đó, nhưng họ xé nát cảm giác bao trùm của sản phẩm.

Nói chung, tiêu chuẩn mã hóa của bạn càng nhất quán, nhà phát triển phải mất ít nỗ lực hơn để kêu gọi sự chú ý của họ đến điều gì đó thú vị. Nếu bạn hỗ trợ sự đa dạng lớn trong các tiêu chuẩn mã hóa, các nhà phát triển phải to hơn khi thông báo rằng họ đang làm điều gì đó bất thường hoặc duy nhất. Nỗ lực này để thể hiện những gì nhà phát triển coi là quan trọng thường có thể làm lu mờ phạm vi động của chính mã. Khi điều này xảy ra, rất dễ có lỗi xảy ra vì đơn giản là quá khó để nhìn thấy chúng.

Mặt trái của lập luận đó, các tiêu chuẩn mã hóa của bạn càng lỏng lẻo, các nhà phát triển càng tự do phải điều chỉnh cú pháp của họ cho vấn đề. Trái ngược hoàn toàn với lập luận về tiêu chuẩn tiền mã hóa, quá nhiều tiêu chuẩn hóa có thể dẫn đến cấu trúc mã được dựng đứng, điều này cũng có thể khiến cho các lỗi dễ dàng xảy ra.

Những gì bạn đang tìm kiếm là phương tiện hạnh phúc của nhóm của riêng bạn.


2

Như một số người khác đã chỉ ra, khi các nhà phát triển bảo trì phải đi sau bạn, một phần mã theo kiểu khác sẽ khiến họ dừng lại và cố gắng tìm ra điều gì đặc biệt về phần đó. Cũng có nguy cơ rất thực sự của phong cách không nhất quán được lan truyền sang các phần khác, dẫn đến một mớ hỗn độn lớn sau đó.

Tôi có ấn tượng rằng, sâu thẳm, bạn đã biết câu trả lời cho câu hỏi này và thậm chí bạn sẽ không phải đối mặt với nó nếu không phải vì điều này:

Chúng tôi cần phải giữ tốc độ nhanh để giao hàng đúng giờ và tôi không muốn gây gánh nặng cho đội một cách không cần thiết.

Đây dường như luôn là sự đánh đổi toàn cầu ... làm nhanh và làm đúng. Chỉ bạn mới có thể đánh giá hậu quả của việc hy sinh các thực hành mã hóa tốt đối với việc thay đổi thời hạn của khách hàng. Tuy nhiên, tôi phải đồng ý với JeffO khi anh ta quan sát thấy rằng theo một phong cách mã hóa (có thể bất thường hoặc phản trực giác) không nên làm chậm đội của bạn mạnh đến mức thời hạn trượt đáng kể.

Mặc dù tôi đã biết về khái niệm này trong nhiều năm, nhưng gần đây tôi mới biết đến thuật ngữ " nợ kỹ thuật ". Bạn thực sự cần phải xem xét các khoản nợ kỹ thuật cuối cùng sẽ phải trả nếu bạn không tuân theo một phong cách kỷ luật ngay bây giờ.

Thật không may, như eBusiness đã nói, trừ khi khách hàng của bạn đặc biệt am hiểu về kỹ thuật hoặc sẽ tự duy trì mã sau đó, thật khó để họ đánh giá cao giá trị của các tiêu chuẩn mã hóa nhất quán. Tuy nhiên, bất kỳ doanh nhân hợp lý nào cũng có thể nắm bắt được khái niệm rằng "một chút bảo trì phòng ngừa ngay bây giờ" (dưới dạng mã hóa tốt) "sẽ giúp tránh chi phí sửa chữa đáng kể sau này" (dưới dạng lãng phí thời gian của nhà phát triển sau này để dọn dẹp lộn xộn).


Khách hàng là người am hiểu về kỹ thuật và rất có thể sẽ đảm nhận việc bảo trì và phát triển hơn nữa giải pháp tại một số điểm. Nỗ lực Q & A cho đến nay đã tập trung vào bố cục hình ảnh và không quá nhiều về chức năng. Khi các lỗi chức năng bắt đầu xuất hiện, chúng ta sẽ có cảm giác về việc bảo trì là như thế nào. Tôi nghĩ rằng các đánh giá mã sẽ nhanh hơn với tính nhất quán hơn (giảm các cách mới đáng ngạc nhiên để làm điều tương tự). Khách hàng rõ ràng muốn sự nhất quán tối đa (nhưng có thể không trả thêm tiền cho nó).
Andreas Warberg

2

Các câu trả lời được xếp hạng ở đây lặp lại các thực tiễn tốt nhất về mặt lý thuyết dễ dàng chi tiết về cách tất cả chúng ta sẽ thích các cơ sở mã của mình. Nhưng mã thực sự bằng cách nào đó không bao giờ trông như thế. Nếu bạn cố gắng tạo ra cơ sở mã hoàn hảo đó, bạn gần như chắc chắn sẽ thất bại. Điều đó không có nghĩa là chúng ta không nên cố gắng làm tốt hơn, nhưng phải có giới hạn cho việc chúng ta đặt mục tiêu thực tế đến mức nào.

Quá tập trung vào những thứ nhỏ nhặt có nguy cơ mất tập trung vào những vấn đề quan trọng hơn, như làm thế nào để giải quyết công việc theo cách hiệu quả nhất nói chung.

Tôi sẽ không đề cập đến bạn ví dụ đầu tiên là phong cách, phong cách là những lựa chọn trong đó không có đúng hay sai rõ ràng, trong trường hợp này chức năng bổ sung là mã phình to không có mặt trái. Nó chỉ có 2 dòng phụ, vẫn dễ đọc và dễ sửa, vì vậy bản thân ví dụ này không phải là vấn đề lớn.

Vấn đề lớn hơn nhiều là sự phình to mã. Các hàm bao bọc, phân cấp lớp và tất cả các loại cấu trúc khác, trong đó mã xung quanh đủ phức tạp để không rõ ràng rằng chúng không phục vụ mục đích thực sự. Nếu có sự phình to rõ ràng trong mã, có lẽ có nhiều sự phình to không rõ ràng hơn. Làm điều gì đó khó hơn rất nhiều, và khó phát hiện hơn, nhưng cũng là một vấn đề lớn hơn nhiều.

Về khách hàng

Khách hàng có xu hướng tập trung vào việc có được một sản phẩm làm việc giải quyết nhu cầu của họ. Ngay cả khi bạn có một trong số ít khách hàng lo lắng về chất lượng mã, thì đó sẽ là ưu tiên thứ yếu và ý tưởng về chất lượng mã của họ có thể không hoàn toàn phù hợp với bạn. Công ty khách hàng có thể có các lập trình viên riêng, nhưng chính quản lý sẽ quyết định liệu bạn có làm tốt hay không và quản lý rất có thể thậm chí không biết chất lượng mã có nghĩa là gì.


Khi xem xét mã, tôi tìm kiếm một số thứ mà tôi tin là rất quan trọng như thao tác DOM trực tiếp, chuỗi đối mặt với người dùng không tập trung, cơ hội để sử dụng lại (một thành phần hiện có, trình trợ giúp, thư viện bên thứ 3 đã tải, v.v.), thay đổi không tương thích hoặc không phù hợp để chia sẻ mã, sai lệch so với quy ước của khách hàng và nhóm. Giá trị của tính nhất quán của kiểu và mã mẫu không rõ ràng đối với tôi vì vậy tôi không chắc làm thế nào để trả lời những người trong các bài đánh giá mã.
Andreas Warberg

0

Đó là rất nhiều về mức độ dễ đọc của diffs. Nếu kiểu mã xung quanh, các khác biệt ẩn thay đổi không có ý nghĩa ngữ nghĩa đối với chương trình và có thể làm cho việc hợp nhất trở nên khó khăn hoặc không thể.

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.