Đôi khi một lập trình viên không có sự rõ ràng 100% so với mã của họ? [đóng cửa]

Tôi không phải là một lập trình viên chuyên gia nên đây có thể là lý do, nhưng tôi nhận thấy rằng bất cứ khi nào tôi tạo mã phức tạp (như trò chơi Cờ vua tôi mới thực hiện), tôi có thể viết mã chính xác để chương trình hoạt động, mặc dù tôi thấy rằng sau này - hoặc thậm chí vài giây sau! - Tôi thường phải tạm dừng và nghĩ, làm thế nào để nó hoạt động?

Không chỉ vậy, nhưng tôi cũng có xu hướng không nghĩ về mã, và thay vào đó tôi chỉ gõ đi. Ví dụ, trong trò chơi Cờ vua của tôi, tôi đã quyết định sử dụng một mảng năm chiều để xử lý các động tác và tôi thấy tôi có thể làm điều này mà không cần suy nghĩ quá nhiều. Tuy nhiên, khi tôi dừng lại và đọc nó, tôi thấy thật khó khăn khi phải xoay quanh toàn bộ khái niệm năm chiều, và tôi phải mất vài phút để hiểu đầy đủ những gì tôi đã làm và cách thức hoạt động của mã.

Có phải bình thường cho các lập trình viên khi viết mã phức tạp để không hiểu những gì họ đang làm một nửa thời gian?

Không, nó không bình thường ¹ . Ít nhất, nó không bình thường đối với các lập trình viên giỏi. Nó có lẽ là bình thường đối với một người học lập trình.

Viết phần mềm không chỉ là vỗ các dòng mã với nhau cho đến khi nó hoạt động. Bạn cần có ý thức làm việc để làm cho mã dễ hiểu. Một lập trình viên mà tôi rất tôn trọng đã từng nói với tôi "mã được đọc nhiều lần hơn so với nó được viết" . Trong khi điều đó là hoàn toàn rõ ràng, đó là một thực tế mà tôi đã không nhận thức được cho đến khi anh ấy nói với tôi. Phần lớn mã của bạn chỉ được viết một lần, có thể viết lại một hoặc hai lần nữa, nhưng cuối cùng bạn sẽ đọc mã thường xuyên trong suốt vòng đời của phần mềm.

Nếu bạn đang tìm mã khó hiểu vài phút sau khi viết mã, đó là tín hiệu cho thấy mã của bạn quá phức tạp. Dừng thêm mã, và tìm ra một cách tốt hơn. Ví dụ, một mảng năm chiều gần như không bao giờ là một ý tưởng tốt. Ngay cả những lập trình viên thực sự thông minh thực sự cũng khó hiểu được cấu trúc dữ liệu phức tạp như vậy.

Chính lập trình viên đã nói với tôi về khả năng đọc mã cũng nói "hãy cho tôi xem cấu trúc dữ liệu của bạn và tôi có thể cho bạn biết mã của bạn hoạt động như thế nào" . Có nghĩa là, mã tốt bắt đầu với các cấu trúc dữ liệu sạch, dễ hiểu. Nếu bạn thiết kế dữ liệu của mình đúng, mã gần như là mối quan tâm thứ yếu. Phải thừa nhận rằng, tuyên bố này là một chút cường điệu vì phần mềm rõ ràng không chỉ là dữ liệu, mà nó bắt đầu bằng dữ liệu. Vì vậy, làm việc về việc tạo các cấu trúc dữ liệu sạch, dễ nắm bắt và mã sẽ dễ hiểu hơn đáng kể.

¹ Chắc chắn có mã ngoài đó rất phức tạp và khó hiểu ngay cả bởi những lập trình viên thông minh nhất. Một số vấn đề vốn đã phức tạp. Tuy nhiên, tôi sẽ mạo hiểm nói rằng phần lớn mã được viết bởi đại đa số các lập trình viên không phải là loại mã đó.

Có hai loại này: 1.) nhầm lẫn 2.) vô minh phúc lạc

Cái đầu tiên là xấu và có thể biến mất theo thời gian và kinh nghiệm.

Thứ hai là một điều tốt nếu các dự án trở nên lớn hơn: Nếu bạn phải nhớ mọi chi tiết triển khai chỉ để có thể làm việc với mã của mình, có điều gì đó không ổn với nó (xem "ẩn thông tin").

Mọi nhà phát triển sẽ quên cách mã hoạt động, vì vậy anh ta viết nó theo cách mà một nhà phát triển mới khác sẽ hiểu và có thể duy trì nó mà không phá vỡ các phần khác của chương trình mà anh ta không biết.

Vì vậy, "không biết" thực sự là một hằng số trong phát triển phần mềm - đó là cách bạn quản lý nó.

Tôi muốn nói rằng nó phổ biến hơn mọi người quan tâm thừa nhận. Ngay cả Brian Kernighan cũng ám chỉ:

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.

Khi chúng tôi lái xe đến cửa hàng, chúng tôi thực hiện một chuỗi các điều chỉnh chi tiết cho các vị trí của bàn đạp và tay lái. Điều này là rất dễ dàng trong thời điểm này. Bây giờ, hãy tưởng tượng nếu bạn ghi lại những điều chỉnh đó vào giấy và đưa chúng cho một người bạn cần chỉ đường đến cửa hàng.

Tương tự, chúng tôi muốn viết mã ở một mức độ trừu tượng, nhưng chúng tôi thích đọc nó ở nhiều lớp trừu tượng cao hơn. Do đó, cách viết và đọc mã ưa thích của chúng tôi là xung đột. Điều đó có nghĩa là làm cho mã dễ đọc thường là một bước riêng biệt, có ý thức, với một bộ kỹ năng khác nhau.

Điều làm cho một lập trình viên giỏi là khi họ gặp khó khăn khi đọc những gì họ vừa viết, họ tạo ra một sự trừu tượng tại thời điểm đó. Một lập trình viên tốt hơn làm điều đó nhiều lần, mỗi lần trở nên kén chọn hơn. Cuối cùng, các lập trình viên có kinh nghiệm bắt đầu tiến xa hơn trong quá trình, nhưng họ thường vẫn có thể thấy chỗ để cải thiện sau khi đọc những gì họ vừa viết.

Tôi nghĩ rằng đây là một cái gì đó sẽ biến mất với kinh nghiệm.

Nếu bạn đang viết các hệ thống phức tạp, bạn cần có khả năng viết mã sạch, có thể duy trì mà cả bạn trong tương lai và người khác trong tương lai đều có thể hiểu được. Vì vậy, về bản chất, việc bạn đang làm bây giờ không thể mở rộng được.

Bạn sẽ có nhiều khoảnh khắc khi bạn nhìn vào một số mã bạn đã viết 6 tháng trước và nghĩ rằng "cái quái gì đang diễn ra ở đây?", Nhưng nếu nó xảy ra một ngày sau khi bạn viết mã, bạn phải nghĩ 'sạch mã 'hơn.

Nguồn: không bao giờ sử dụng mảng 5 chiều :)

"Bình thường" là rất chủ quan, vì vậy tôi nói: nó rất phổ biến, nhưng nên tránh.

Một trong những tính năng của "mã tốt" (tôi nghe thấy điều đó tồn tại) là sự rõ ràng: nó phải rõ ràng như các vấn đề tiềm ẩn cho phép nó xảy ra. Nếu vấn đề phức tạp, mã cũng sẽ phức tạp, nhưng đó là sự phức tạp vốn có , trái ngược với sự phức tạp ngẫu nhiên (lần đầu tiên tôi nghe về sự khác biệt này trong bài nói chuyện của Rich Hickey ) được giới thiệu bởi hoặc không sử dụng đúng công cụ, mô hình, kỹ thuật và thực hành.

Có những trường hợp khi sự thiếu rõ ràng có thể chấp nhận được ngay cả khi vấn đề không quá phức tạp, ví dụ nếu bạn viết một trang web quảng cáo mà bạn biết sẽ tồn tại chừng nào chiến dịch tiếp thị diễn ra. Đó là một mã vứt đi không thể duy trì được. Đối với các trường hợp khác (và hầu hết), không thể chấp nhận được, vì việc duy trì mã như vậy sẽ tốn rất nhiều chi phí. Tuy nhiên, nó là phổ biến.

Liên quan:

• Khi Hiểu nghĩa là Viết lại - bài viết về vấn đề hiểu mã.
• ML hiệu quả - một cuộc nói chuyện dài, giữa ML / OCaml, cách viết mã cho "người đọc" (tức là người duy trì): "Người đọc ủng hộ nhà văn hơn." Tôi khuyên bạn nên xem rằng bất kể bạn sử dụng ngôn ngữ nào.

Tôi không nghĩ đó là bình thường, nhưng đối với các chương trình rất phức tạp, như chương trình cờ vua mà bạn đề cập, tôi nghĩ chắc chắn là có thể.

Nhiều năm trước, khi tôi vừa mới ra trường (vì vậy tôi vẫn còn khá thiếu kinh nghiệm khi viết các chương trình lớn), tôi đã viết trình biên dịch thực sự đầu tiên của mình. Việc phân tích cú pháp rất đơn giản, nhưng sau đó tôi cần nhắm mục tiêu nó cho bốn bộ hướng dẫn vi xử lý khác nhau. Tôi dự định viết trình biên dịch bằng ngôn ngữ riêng của mình, vì vậy trước tiên tôi chỉ sử dụng các tính năng của ngôn ngữ mà tôi thực sự cần, đã viết trình tạo mã đầu tiên bằng ngôn ngữ hợp ngữ và kiểm tra rằng nó đã tạo mã chính xác cho tập hợp con của ngôn ngữ. Sau đó tôi đã có thể sử dụng trình biên dịch để tự biên dịch, và thêm các tính năng còn lại và cũng sử dụng chúng trong trình biên dịch

Sau đó tôi đã viết các trình tạo mã phụ trợ cho mỗi bộ vi xử lý và kiểm tra rằng tất cả chúng đều tạo mã chính xác, nhưng trong khi chính xác thì nó không tối ưu lắm. Vì vậy, sau đó tôi đã tiến hành viết trình tối ưu hóa cho mỗi trình tạo mã.

Khi tôi đang kiểm tra đầu ra của các trình tạo mã sau khi thêm tất cả tối ưu hóa, tôi thường ngạc nhiên về mã mà trình biên dịch tạo ra. Nó thường không phải là cách tôi sẽ viết mã bằng tay, nhưng nó chính xác và khá súc tích.

Khi tôi không rõ ràng về cách mà trình tạo mã tạo ra một số mã mà nó đã làm, tôi đã cố gắng làm theo logic bằng tay nhưng có những lúc tôi đã từ bỏ. Nếu tôi đã thêm rất nhiều đầu ra theo dõi, tôi sẽ có thể theo dõi nó, nhưng tôi không bận tâm vì mã được tạo là thỏa đáng và tôi cần phải tiếp tục với các dự án khác.

Có rất nhiều câu trả lời đàng hoàng ở đây.

Tôi có một vài mất về điều này.

Một là nếu bạn không hiểu tại sao mã của bạn có vẻ hoạt động, thì a) nó có thể không (có lẽ nó chỉ có vẻ như nó hoạt động) và b) bạn không hiểu rõ về miền vấn đề khi bạn bắt đầu mã hóa hoặc không chia miền vấn đề thành các đơn vị nhỏ hơn, đơn giản hóa trước khi bạn bắt đầu.

Điều khác của tôi về điều này là chìa khóa thực sự là sử dụng các mẫu và quy ước thông thường trong mã của bạn. Đó là một chủ đề lớn hơn nhiều so với một bài viết nhỏ có thể giải quyết. Nhưng hãy tìm những tài liệu hay về chủ đề này, bao gồm một số standbys cũ như các cuốn sách "Code Complete" và "Writing Solid Code".

Chi tiết thực hiện thay đổi. Hằng số thực duy nhất là mục tiêu chức năng của mã. Nếu bạn từng viết nhiều hơn một chức năng, bạn sẽ quên chi tiết triển khai chi tiết, cụ thể theo thời gian. Nhưng bạn chắc chắn nên hiểu làm thế nào các mảnh hoạt động khi bạn xây dựng chúng, và bạn sẽ có thể vẽ một sơ đồ của tổng thể và hiểu làm thế nào các mảnh làm việc với nhau.

Nếu bạn sử dụng các mẫu và tuân theo các quy ước thông thường, sẽ dễ dàng hơn nhiều để chọn các chi tiết triển khai cụ thể sao lưu khi bạn nhìn lại mã. Hoặc khi ai đó chưa bao giờ nhìn thấy mã trước khi nhìn vào nó lần đầu tiên. Ngoài ra, tuân theo các quy ước và các mẫu đó theo thời gian sẽ có nghĩa là các chi tiết triển khai sẽ nổi bật so với các quy ước và các mẫu, đó là một yếu tố khác giúp mã dễ hiểu hơn.

Hầu hết các vấn đề mà chúng tôi giải quyết với phần mềm rất phức tạp. Thiết kế phần mềm là một bài tập trong việc quản lý sự phức tạp.

Tôi sẽ không gọi nó là bình thường , nhưng nó chắc chắn có thể xảy ra. Nếu điều đó xảy ra với bạn ngay sau khi bạn viết đoạn mã được đề cập, tôi đoán rằng mã của bạn rất phức tạp và cần được đơn giản hóa, hoặc bạn chỉ dễ bị phân tâm. :)

Nhưng nếu bạn đặt mã của mình đi, tập trung vào các dự án khác và quay lại mã đó sau nhiều tuần, vài tháng hoặc thậm chí nhiều năm, sẽ không có gì đáng ngạc nhiên khi bạn sẽ phải tìm lại tất cả.

Nhưng có điều gì đó bạn có thể làm về điều này. Từ những gì bạn nói, có vẻ như bạn không nghĩ đủ về mã của mình khi bạn đang viết nó, và do đó bạn đang gây khó khăn cho bản thân trong tương lai để hiểu những gì đang diễn ra. Sử dụng kiến ​​thức đó để lợi thế của bạn: Đây là động lực tốt nhất để sản xuất mã có cấu trúc tốt, tài liệu tốt, dễ hiểu. Bạn biết từ trải nghiệm đầu tiên những gì xảy ra khi bạn không quan tâm đến chất lượng mã của mình. Biết rằng sẽ làm cho bạn một lập trình viên tốt hơn trong thời gian dài. Khi bạn hợp tác trong các dự án phần mềm, đồng nghiệp của bạn sẽ cảm ơn bạn vì đã tạo ra mã dễ hiểu. Và tỷ lệ lỗi của mã của bạn cũng sẽ được cải thiện.