Viết phần mềm có dễ hơn đọc và hiểu nó từ đầu không? [đóng cửa]

Tôi và một người bạn của tôi đã thảo luận về ngày hôm qua về sự khác biệt giữa việc viết một phần mềm C ++ lớn và hiểu nó như là một tuyển dụng mới.

Có thể vì một phần mềm được thực hiện từng dòng một và quá trình này giống như cách chúng ta (con người) học hỏi mọi thứ và xây dựng một thứ trên một phần mềm khác, viết một phần mềm lớn thực sự dễ hơn đọc và hiểu nó làm gì (bước qua mã giúp nhưng bạn cần nhớ nhiều lớp / tệp nguồn cùng nhau, bạn thậm chí không biết chúng được viết để làm gì, mã đa luồng có thêm điểm malus)?

Điều này thoạt nghe có vẻ kỳ lạ nhưng sau khi chúng tôi nghĩ một chút thì có vẻ hợp lý

Dựa trên kinh nghiệm của tôi, tôi sẽ xếp hạng các hoạt động sau theo thứ tự từ dễ nhất đến khó nhất.

1. Đọc mã tốt
2. Viết mã xấu
3. Viết mã tốt
4. Đọc mã xấu

Bảng xếp hạng trên dẫn đến 2 kết luận

1. Mặc dù viết mã dễ hơn đọc mã xấu, nhưng đọc mã tốt sẽ dễ hơn viết mã của riêng bạn
2. Viết mã xấu dễ hơn viết mã tốt, nhưng viết mã xấu sẽ khiến bạn đọc mã xấu, đây là điều khó nhất trong tất cả. Đặc biệt là vì mã xấu được đọc nhiều hơn nó được viết.

Tất nhiên, mã tốt và mã xấu là khái quát rộng. Tôi khuyên bạn nên Code Complete và Clean Code để biết thêm chi tiết về mã tốt.

Câu hỏi này hấp dẫn một sự đồng thuận sai. http://en.wikipedia.org/wiki/False-consallel_effect

Những người khác nhau học hỏi và tiếp thu thông tin khác nhau. Nó gần giống với người học thính giác, người học thị giác và người học động học. Đối với một số người, đọc mã dễ dàng hơn, đối với những người khác, việc tạo mã dễ dàng hơn. Đối với tôi, nó là cái sau. Đối với những người khác trong nhóm của tôi, nó là trước đây. Tôi không tin rằng việc tìm kiếm một số loại đồng thuận hoặc đa số là hữu ích. Tốt hơn là nên hiểu cách bộ não của bạn hấp thụ và học thông tin và sử dụng kiến ​​thức đó để làm cho bản thân tốt hơn và học cách chấp nhận những người khác.

sự khác biệt giữa việc viết một phần mềm C ++ lớn và hiểu nó như là một tuyển dụng mới

Điều này không giống với sự khác biệt giữa phần mềm đọc và viết. Khi bạn mới tham gia một dự án (và đặc biệt là khi bạn mới vào một công ty), bạn có nhiều thứ để học hơn là những gì mã làm. Hiểu lý do tại sao mã làm những gì nó thường đòi hỏi sự hiểu biết về cách thức hoạt động của doanh nghiệp và dự án liên quan đến phần còn lại của tổ chức như thế nào. Nói tóm lại, đọc mã mà không có lợi ích về kiến ​​thức nền là một nhiệm vụ chậm hơn, khó hơn so với đọc mã khi bạn hoàn toàn hiểu ngữ cảnh mà mã hoạt động.

Có là một sự khác biệt giữa văn bản thương hiệu mã mới trên một dự án greenfield và đọc và sửa đổi mã hiện tại, nhưng tôi sẽ không nói rằng một là nhất thiết phải dễ dàng hơn so với người kia, chỉ khác nhau. Khi bạn đang tạo một cái gì đó mới, bạn không phải lo lắng về cách làm cho mã của bạn hoạt động với những gì đã có, nhưng bạn phải lo lắng về việc làm cho dự án của bạn đủ khả năng mở rộng và thích nghi rằng nó sẽ hữu ích trong tương lai . Khi bạn đang làm việc trên một dự án hiện có, bạn thường có thể sử dụng những gì đã có như một hướng dẫn, nhưng trước tiên bạn phải hiểu những gì ở đó.

Là một "tuyển dụng mới", tốt hơn hết là làm việc với một dự án hiện tại vì nó giúp bạn tìm hiểu tất cả những điều bạn chưa biết: cách thức kinh doanh, cách các dự án khác nhau làm việc cùng nhau, tiêu chuẩn và thực hành mã hóa, và thậm chí (đặc biệt) những gì có thể được cải thiện.

Đó là một câu hỏi thú vị, nhưng tôi sẽ có xu hướng nghiêng về phía dễ đọc và dễ hiểu hơn là tạo ra nó.

Nếu bạn là một lập trình viên kỳ cựu, dày dạn kinh nghiệm, thì bạn có khả năng đọc qua mã và đi "Vâng, lựa chọn tốt, kiểm tra, ồ, tôi có thể đã thực hiện X thay vì Y", v.v. Bạn có thể sửa đổi hoặc điều chỉnh, nhưng điều đó sẽ tiết kiệm thời gian lớn hơn viết từ đầu (Trừ khi có lý do để làm như vậy).

Nếu bạn là một lập trình viên mới hơn, thì "bạn không biết những gì bạn không biết", và vì vậy bạn sẽ phải phát minh / học tất cả những điều nhỏ nhặt, và rất có thể bạn sẽ có một số sự thiếu hiệu quả trong mã. Tuy nhiên, bạn có thể sẽ phát triển sự hiểu biết lớn hơn về ngôn ngữ.

Nhưng trong cả hai trường hợp đó, việc đọc mã và đi từ đó sẽ dễ dàng hơn so với việc viết nó hoàn toàn từ đầu.

Hầu hết các lập trình viên thấy dễ hiểu mã hơn họ tự viết so với mã người khác viết. Điều này là do cả việc học từng dòng mà bạn đề cập, cũng như chỉ là vấn đề về phong cách và tài năng cá nhân. Đó là lý do tại sao rất nhiều sự tái tạo bánh xe xảy ra.

Tuy nhiên, đó là quan điểm của cây. Quan điểm về rừng là việc đọc mã dễ dàng hơn nhiều so với viết từ đầu. Ví dụ, việc viết một trình xử lý văn bản mới từ đầu dễ dàng hơn hay tìm hiểu một cơ sở mã hiện có đủ tốt để thực hiện các cải tiến?

Khi bạn bắt đầu đọc mã, bạn có thể nghĩ ra một số cách để giúp mã dễ đọc hơn. Bạn chi tiêu đầu tiên trong khi chỉ truy tìm mã xung quanh, cố gắng tìm ra vị trí của mảnh đất, đôi khi trong một kiến ​​trúc hoàn toàn không phù hợp với cách bạn muốn làm điều đó. Nhưng ngay cả trong các cơ sở mã thực sự lớn, bạn sẽ mất khoảng 40-80 giờ để quay bánh xe của mình, so với hàng trăm ngàn giờ đã đầu tư để tạo ra ứng dụng đó.

Người viết phần mềm hầu như sẽ luôn có sự hiểu biết tốt nhất về chương trình chỉ đơn giản là do biết logic và quá trình suy nghĩ của anh ấy / cô ấy trong khi viết nó.

Tôi không nghĩ rằng việc viết mã hoàn toàn có thể được so sánh với việc đọc mã về mặt dễ hiểu. Một mặt, phần mềm viết đơn giản cung cấp sự hiểu biết nhiều hơn về phần mềm cụ thể đó do kiến ​​thức về bối cảnh liên quan đến từng phần mã, thư viện được sử dụng, v.v. Tuy nhiên, việc đọc mã mà người khác đã viết có thể khó hiểu về mặt phần mềm thực tế, nhưng về mặt hiểu ngôn ngữ, nó có thể cung cấp cái nhìn sâu sắc về cách thức mới để sử dụng hoặc sử dụng thư viện mà bạn có thể không cân nhắc sử dụng, điều này có thể giúp bạn viết mã cuộc sống dễ dàng hơn.

Về kiến ​​thức xây dựng, tôi nghĩ rằng đọc mã và viết mã rất liên kết với nhau và theo nhiều cách xây dựng lẫn nhau. Kinh nghiệm viết mã cung cấp dễ hiểu mã người khác và đọc mã cho phép bạn có thời gian viết mã dễ dàng hơn (thông qua các khái niệm logic mới, sử dụng thư viện, v.v.).

Đây là điều mà cá nhân tôi cảm thấy là hiển nhiên, nhưng tôi chưa bao giờ hoàn toàn chắc chắn rằng nó phù hợp với toàn bộ dân số lập trình. Ví dụ, tôi đã biết một số lập trình viên rất tài năng, thay vì đọc tài liệu, có thể vui vẻ chọn mã của người khác và hiểu nó như thể đó là của riêng họ.

Điều này dẫn đến câu hỏi: điều này có quan trọng không?

Nếu bạn đang đọc mã, thì rất có thể bạn đang thực hiện thay đổi thay vì viết lại. Ngay cả khi bạn đang viết lại nó, bạn vẫn có khả năng viết nó bằng ngôn ngữ / phiên bản mới và do đó bạn không nhất thiết phải tạo mã theo cùng một cách. Điểm tôi đang đưa ra là không phải lúc nào cũng cần phải hiểu tất cả các mã.

Tất cả điều này là đúng, các phương pháp phát triển mới hơn, ví dụ như BDD nhận ra rằng điều quan trọng là logic nghiệp vụ phải rõ ràng khỏi mã hơn là mã đơn giản là phương tiện để điều khiển máy. Điều này tất nhiên không có gì mới - khái niệm đã xuất hiện kể từ khi tác phẩm nổi bật của Donald Knuth: Lập trình văn học .

Tôi tham gia câu trả lời của StMotorSpark, chỉ cần thêm:
Nó phụ thuộc vào rất nhiều yếu tố, ví dụ: không thể là câu hỏi có hay không:

• Là mã hiện có được ghi chép tốt và được viết tốt hoặc nó trông giống như một spaghetti mà không có bất kỳ ý nghĩa hoặc ý kiến?
• Đây có phải là một ứng dụng nhỏ với các tình huống rất hiếm khiến bạn mất thời gian vô tận để tìm ra cách giải quyết, hoặc một ứng dụng lớn hơn nhưng đơn giản?
• Vân vân.