Trong trường hợp nào ít mã không tốt hơn? [đóng cửa]

Tôi đã cấu trúc lại một số mã trong công việc gần đây và tôi nghĩ rằng tôi đã làm một công việc tốt. Tôi đã giảm 980 dòng mã xuống 450 và giảm một nửa số lớp.

Khi thể hiện điều này với các đồng nghiệp của tôi, một số người đã không đồng ý rằng đây là một sự cải tiến.

Họ nói - "ít dòng mã hơn không nhất thiết phải tốt hơn"

Tôi có thể thấy rằng có thể có những trường hợp cực đoan khi mọi người viết những dòng thực sự dài và / hoặc đặt mọi thứ trong một phương thức duy nhất để lưu một vài dòng, nhưng đó không phải là những gì tôi đã làm. Theo tôi, mã được cấu trúc tốt và đơn giản hơn để hiểu / duy trì do nó có kích thước bằng một nửa.

Tôi đang đấu tranh để xem tại sao mọi người muốn làm việc với gấp đôi mã được yêu cầu để hoàn thành công việc và tôi tự hỏi liệu có ai cảm thấy giống như các đồng nghiệp của tôi không và có thể tạo ra một số trường hợp tốt để có nhiều mã hơn ít hơn ?

Một người gầy không nhất thiết phải khỏe mạnh hơn người thừa cân.

Một câu chuyện trẻ em 980 dòng dễ đọc hơn một luận án vật lý 450 dòng.

Có nhiều thuộc tính xác định chất lượng mã của bạn. Một số chỉ đơn giản là tính toán, như Cyclomatic phức tạp , và Halstead phức tạp . Những người khác được xác định một cách lỏng lẻo hơn, chẳng hạn như sự gắn kết , dễ đọc, dễ hiểu, khả năng mở rộng, mạnh mẽ, chính xác, tự tài liệu, sạch sẽ, kiểm tra và nhiều hơn nữa.

Chẳng hạn, có thể là trong khi bạn giảm độ dài tổng thể của mã - bạn đã giới thiệu thêm độ phức tạp không chính đáng và làm cho mã trở nên khó hiểu hơn.

Việc tách một đoạn mã dài thành các phương thức nhỏ có thể có hại như nó có thể có lợi .

Yêu cầu các đồng nghiệp của bạn cung cấp cho bạn thông tin phản hồi cụ thể về lý do tại sao họ nghĩ rằng các nỗ lực tái cấu trúc của bạn tạo ra một kết quả không mong muốn.

Thật thú vị, một đồng nghiệp và tôi hiện đang ở giữa một công cụ tái cấu trúc sẽ tăng số lượng lớp và hàm ít hơn gấp đôi, mặc dù các dòng mã sẽ giữ nguyên. Vì vậy, tôi tình cờ có một ví dụ tốt.

Trong trường hợp của chúng tôi, chúng tôi đã có một lớp trừu tượng mà thực sự nên có hai. Mọi thứ đã được nhồi nhét vào lớp ui. Bằng cách chia nó thành hai lớp, mọi thứ trở nên gắn kết hơn, và việc kiểm tra và duy trì các phần riêng lẻ trở nên đơn giản hơn nhiều.

Đó không phải là kích thước của mã làm phiền các đồng nghiệp của bạn, đó là một thứ khác. Nếu họ không thể nói rõ nó, hãy thử tự mình xem mã như thể bạn chưa bao giờ thấy cách triển khai cũ và đánh giá nó theo giá trị riêng của nó thay vì chỉ so sánh. Đôi khi khi tôi thực hiện một công cụ tái cấu trúc dài, tôi sẽ mất tầm nhìn về mục tiêu ban đầu và đưa mọi thứ đi quá xa. Hãy xem "bức tranh lớn" quan trọng và đưa nó trở lại đúng hướng, có thể với sự giúp đỡ của một lập trình viên cặp đôi có lời khuyên mà bạn coi trọng.

Một trích dẫn, thường được gán cho Albert Einstein, đến với tâm trí:

Làm cho mọi thứ đơn giản nhất có thể, nhưng không đơn giản.

Khi bạn quá nhiệt tình trong việc cắt xén mọi thứ, nó có thể làm cho mã khó đọc hơn. Vì "dễ / khó đọc" có thể là một thuật ngữ rất chủ quan, tôi sẽ giải thích chính xác ý tôi là gì: thước đo mức độ khó mà một nhà phát triển lành nghề sẽ có trong việc xác định "mã này làm gì?" chỉ cần nhìn vào nguồn, mà không cần sự trợ giúp của các công cụ chuyên dụng.

Các ngôn ngữ như Java và Pascal nổi tiếng về tính dài dòng của chúng. Mọi người thường chỉ ra một số yếu tố cú pháp nhất định và nói một cách chế giễu rằng "họ chỉ ở đó để làm cho công việc của nhà biên dịch dễ dàng hơn". Điều này ít nhiều đúng, ngoại trừ phần "chỉ". Càng có nhiều thông tin rõ ràng, mã càng dễ đọc và dễ hiểu, không chỉ bởi một trình biên dịch mà còn bởi một con người.

Nếu tôi nói var x = 2 + 2;, nó rõ ràng ngay lập tức xđược coi là một số nguyên. Nhưng nếu tôi nói var foo = value.Response;, nó hoàn toàn không rõ ràng những gì foothể hiện hoặc tính chất và khả năng của nó là gì. Ngay cả khi trình biên dịch có thể dễ dàng suy ra nó, nó đặt nỗ lực nhận thức nhiều hơn cho một người.

Hãy nhớ rằng các chương trình phải được viết để mọi người đọc và chỉ tình cờ cho các máy thực thi. (Trớ trêu thay, trích dẫn này xuất phát từ một cuốn sách giáo khoa dành cho một ngôn ngữ khét tiếng vì cực kỳ khó đọc!) Đó là một ý tưởng tốt để loại bỏ những thứ dư thừa, nhưng đừng lấy đi mã giúp cho đồng loại của bạn dễ dàng hơn tìm hiểu những gì đang xảy ra, ngay cả khi nó không thực sự cần thiết cho chương trình được viết.

Mã dài hơn có thể có thể dễ đọc hơn. Nó thường ngược lại, nhưng có rất nhiều trường hợp ngoại lệ - một số trong số chúng được nêu trong các câu trả lời khác.

Nhưng hãy nhìn từ một góc độ khác. Chúng tôi cho rằng mã mới sẽ được xem là vượt trội bởi hầu hết các lập trình viên lành nghề, những người nhìn thấy 2 đoạn mã mà không có kiến ​​thức bổ sung về văn hóa, cơ sở mã hoặc lộ trình của công ty. Thậm chí sau đó, có rất nhiều lý do để phản đối mã mới. Để cho ngắn gọn, tôi sẽ gọi "Mọi người phê phán mã mới" Pecritenc :

• Ổn định. Nếu mã cũ được biết là ổn định, thì độ ổn định của mã mới là không xác định. Trước khi mã mới có thể được sử dụng, nó vẫn cần phải được kiểm tra. Nếu vì lý do nào đó, kiểm tra thích hợp không có sẵn, sự thay đổi là một vấn đề khá lớn. Ngay cả khi thử nghiệm có sẵn, Pecritenc có thể nghĩ rằng nỗ lực này không xứng đáng với sự cải tiến (nhỏ) của mã.
• Hiệu suất / nhân rộng. Mã cũ có thể đã mở rộng tốt hơn và Pecritenc giả định rằng hiệu suất sẽ trở thành một vấn đề khi các khách hàng và các tính năng sớm * chồng chất.
• Khả năng mở rộng. Mã cũ có thể đã cho phép dễ dàng giới thiệu một số tính năng mà Pecritenc giả định sẽ sớm được thêm vào *.
• Quen thuộc. Mã cũ có thể đã sử dụng lại các mẫu được sử dụng ở 5 vị trí khác của cơ sở mã của công ty. Đồng thời mã mới sử dụng một mẫu lạ mắt mà chỉ một nửa công ty đã từng nghe nói đến vào thời điểm này.
• Son môi trên heo. Pecritenc có thể nghĩ rằng cả mã cũ và mã mới là rác rưởi, hoặc không liên quan, do đó làm cho bất kỳ so sánh giữa chúng là vô nghĩa.
• Tự hào. Pecritenc có thể là tác giả ban đầu của mã và không thích mọi người thực hiện thay đổi lớn đối với mã của mình. Anh ta thậm chí có thể coi những cải tiến là một sự xúc phạm nhẹ, bởi vì chúng ngụ ý rằng anh ta nên làm tốt hơn.

Loại mã nào tốt hơn có thể phụ thuộc vào chuyên môn của lập trình viên và cả vào các công cụ họ sử dụng. Ví dụ, đây là lý do tại sao những gì thường được coi là mã được viết kém có thể hiệu quả hơn trong một số trường hợp so với mã hướng đối tượng được viết tốt sử dụng đầy đủ tính kế thừa:

(1) Một số lập trình viên không nắm bắt trực quan về lập trình hướng đối tượng. Nếu phép ẩn dụ của bạn cho một dự án phần mềm là một mạch điện, thì bạn sẽ mong đợi rất nhiều sự sao chép mã. Bạn sẽ muốn thấy nhiều hơn hoặc ít hơn các phương thức tương tự trong nhiều lớp. Họ sẽ làm cho bạn cảm thấy như ở nhà. Và một dự án mà bạn phải tìm kiếm các phương thức trong các lớp cha hoặc thậm chí trong các lớp ông bà để xem những gì đang diễn ra có thể cảm thấy thù địch. Bạn không muốn hiểu cách lớp cha mẹ hoạt động và sau đó hiểu lớp hiện tại khác nhau như thế nào. Bạn muốn hiểu trực tiếp cách lớp hiện tại hoạt động và bạn thấy thực tế là thông tin được lan truyền trên một số tệp khó hiểu.

Ngoài ra, khi bạn chỉ muốn khắc phục một sự cố cụ thể trong một lớp cụ thể, bạn có thể không muốn phải suy nghĩ về việc có nên khắc phục sự cố trực tiếp trong lớp cơ sở hay ghi đè phương thức trong lớp quan tâm hiện tại của bạn không. (Không có sự kế thừa, bạn sẽ không phải đưa ra quyết định có ý thức. Mặc định là bỏ qua các vấn đề tương tự trong các lớp tương tự cho đến khi chúng được báo cáo là lỗi.) Khía cạnh cuối cùng này không thực sự là một đối số hợp lệ, mặc dù nó có thể giải thích một số Sự đối lập.

(2) Một số lập trình viên sử dụng trình gỡ lỗi rất nhiều. Mặc dù nói chung, bản thân tôi chắc chắn về mặt kế thừa mã và ngăn ngừa sự trùng lặp, tôi chia sẻ một số sự thất vọng mà tôi đã mô tả trong (1) khi gỡ lỗi mã hướng đối tượng. Khi bạn theo dõi thực thi mã, đôi khi nó tiếp tục nhảy xung quanh giữa các lớp (tổ tiên) mặc dù nó vẫn ở trong cùng một đối tượng. Ngoài ra, khi đặt điểm dừng trong mã được viết tốt, nó sẽ có khả năng kích hoạt khi nó không hữu ích, vì vậy bạn có thể phải nỗ lực để làm cho nó có điều kiện (khi thực tế) hoặc thậm chí tiếp tục thủ công nhiều lần trước khi kích hoạt có liên quan.

Nó hoàn toàn phụ thuộc. Tôi đã làm việc trên một dự án không cho phép các biến boolean làm tham số hàm, nhưng thay vào đó yêu cầu dành riêng enumcho từng tùy chọn.

Vì thế,

enum OPTION1 { OPTION1_OFF, OPTION1_ON };
enum OPTION2 { OPTION2_OFF, OPTION2_ON };

void doSomething(OPTION1, OPTION2);

dài dòng hơn nhiều

void doSomething(bool, bool);

Tuy nhiên,

doSomething(OPTION1_ON, OPTION2_OFF);

dễ đọc hơn rất nhiều

doSomething(true, false);

Trình biên dịch sẽ tạo cùng một mã cho cả hai, vì vậy không có gì đạt được bằng cách sử dụng dạng ngắn hơn.

Tôi muốn nói rằng sự gắn kết có thể là một vấn đề.

Ví dụ: trong một ứng dụng web, Hãy nói rằng bạn có một trang Quản trị, trong đó bạn lập chỉ mục tất cả các sản phẩm, về cơ bản là cùng một mã (chỉ mục) như bạn sử dụng trong tình huống trang chủ, để .. chỉ mục các sản phẩm.

Nếu bạn quyết định chia phần mọi thứ để bạn có thể giữ DRY và kiểu dáng đẹp, bạn sẽ phải thêm rất nhiều điều kiện liên quan đến việc người dùng duyệt có phải là quản trị viên hay không và làm lộn xộn mã với những thứ không cần thiết sẽ khiến nó không thể đọc được một nhà thiết kế!

Vì vậy, trong một tình huống như thế này ngay cả khi mã khá giống nhau, chỉ vì nó có thể mở rộng sang thứ khác và các trường hợp sử dụng có thể thay đổi một chút, sẽ rất tệ nếu theo dõi từng điều kiện bằng cách thêm điều kiện và if. Vì vậy, một chiến lược tốt sẽ là bỏ khái niệm DRY và phá mã thành các phần có thể bảo trì.

• Khi ít mã hơn không làm công việc tương tự như nhiều mã hơn. Tái cấu trúc cho đơn giản là tốt, nhưng bạn phải cẩn thận không quá đơn giản hóa không gian vấn đề mà giải pháp này đáp ứng. 980 dòng mã có thể xử lý nhiều trường hợp góc hơn 450.
• Khi ít mã hơn không thất bại một cách duyên dáng như nhiều mã hơn. Tôi đã thấy một vài công việc "ref *** tored" được thực hiện trên mã để loại bỏ bắt lỗi "không cần thiết" và xử lý trường hợp lỗi khác. Kết quả không thể tránh khỏi là thay vì hiển thị một hộp thoại với thông báo hay về lỗi và những gì người dùng có thể làm, ứng dụng bị sập hoặc YSODed.

• Khi ít mã hơn thì có thể duy trì / mở rộng hơn mã nhiều hơn. Tái cấu trúc cho tính đồng nhất của mã thường loại bỏ các cấu trúc mã "không cần thiết" vì lợi ích của LoC. Rắc rối là, các cấu trúc mã đó, như khai báo giao diện song song, các phương thức / lớp con được trích xuất, v.v ... là cần thiết nếu mã này cần phải làm nhiều hơn hiện tại hoặc làm khác đi. Trong trường hợp cực đoan, một số giải pháp được tùy chỉnh tùy chỉnh cho vấn đề cụ thể có thể không hoạt động nếu định nghĩa vấn đề chỉ thay đổi một chút.

  Một ví dụ; bạn có một danh sách các số nguyên. Mỗi số nguyên này có một giá trị trùng lặp trong danh sách, ngoại trừ một giá trị. Thuật toán của bạn phải tìm giá trị không ghép đôi đó. Giải pháp cho trường hợp chung là so sánh mọi số với mọi số khác cho đến khi bạn tìm thấy một số không có bản sao trong danh sách, đó là thao tác N ^ 2 lần. Bạn cũng có thể xây dựng biểu đồ bằng cách sử dụng hàm băm, nhưng điều đó rất không hiệu quả. Tuy nhiên, bạn có thể biến nó thành thời gian tuyến tính và không gian không đổi bằng cách sử dụng thao tác XOR bitwise; XOR mỗi số nguyên so với "tổng" đang chạy (bắt đầu bằng 0) và khi kết thúc, tổng chạy sẽ là giá trị của số nguyên không ghép cặp của bạn. Rất thanh lịch. Cho đến khi các yêu cầu thay đổi và nhiều hơn một số trong danh sách có thể được ghép cặp hoặc các số nguyên bao gồm 0. Bây giờ chương trình của bạn trả về rác hoặc kết quả không rõ ràng (nếu nó trả về 0, điều đó có nghĩa là tất cả các phần tử được ghép nối, hoặc phần tử không ghép đôi là 0?). Đó là vấn đề của việc triển khai "thông minh" trong lập trình trong thế giới thực.

• Khi ít mã hơn sẽ ít tự ghi lại hơn nhiều mã. Có thể tự đọc mã và xác định những gì nó đang làm là rất quan trọng để phát triển nhóm. Đưa ra thuật toán Brain-f *** mà bạn đã viết có hiệu năng tuyệt vời cho một nhà phát triển cơ sở và yêu cầu anh ta điều chỉnh nó để sửa đổi đầu ra một chút sẽ không giúp bạn tiến xa. Rất nhiều nhà phát triển cấp cao cũng sẽ gặp rắc rối với tình huống đó. Có thể hiểu bất cứ lúc nào mã đang làm gì và điều gì có thể xảy ra với nó, là chìa khóa cho môi trường phát triển nhóm làm việc (và thậm chí là độc tấu; tôi đảm bảo với bạn rằng đèn flash thiên tài bạn có khi bạn viết 5 -Phương pháp chữa ung thư sẽ không còn lâu nữa khi bạn quay trở lại với chức năng đó để tìm cách chữa trị bệnh Parkinson.)

Mã máy tính cần phải làm một số điều. Mã "tối giản" không làm những điều này không phải là mã tốt.

Ví dụ, một chương trình máy tính sẽ bao gồm tất cả các khả năng có thể (hoặc ở mức tối thiểu, tất cả các trường hợp có thể xảy ra). Nếu một đoạn mã chỉ bao gồm một "trường hợp cơ sở" và bỏ qua các mã khác, thì đó không phải là mã tốt, ngay cả khi nó ngắn gọn.

Mã máy tính phải là "có thể mở rộng." Mã mật mã có thể chỉ hoạt động cho một ứng dụng chuyên biệt, trong khi chương trình dài hơn nhưng kết thúc mở hơn có thể giúp dễ dàng thêm vào các ứng dụng mới.

Mã máy tính phải rõ ràng. Như một người trả lời khác đã chứng minh, một lập trình viên lõi cứng có thể tạo ra một loại hàm "thuật toán" một dòng thực hiện công việc. Nhưng một lớp lót phải được chia thành năm "câu" khác nhau trước khi rõ ràng với các lập trình viên trung bình.

Hiệu suất tính toán. Khi tối ưu hóa song song đường ống hoặc chạy các phần mã của bạn, điều đó có thể có ích, ví dụ không phải vòng lặp từ 1 đến 400, mà từ 1 đến 50 và đặt 8 trường hợp mã tương tự vào mỗi vòng lặp. Tôi không cho rằng đây là trường hợp của bạn, nhưng nó là một ví dụ trong đó nhiều dòng tốt hơn (hiệu năng-khôn ngoan).