Những phần nào của Code Complete chưa đứng trước thử thách của thời gian? [đóng cửa]


14

Tôi đang xem Code Complete trên kệ, nghĩ, "Bên ngoài Tháng của Người đàn ông huyền thoại, đây có thể là một trong số ít những cuốn sách Kỹ thuật phần mềm thị trường đại chúng đứng trước thử thách của thời gian." Vì lý do này, tôi nghĩ đến việc nhảy vào để đọc lại nó.

Tôi tò mò - có ai khác cho nó một cái nhìn thứ hai gần đây không? Tôi như vậy, bạn có thấy bất cứ điều gì anh ấy đã rất sai?

Đây không phải là một cuộc tấn công và không phải là một yêu cầu đánh giá sách - tôi quan tâm hơn đến những ý tưởng đã thay đổi trong những năm qua.

Và xin vui lòng - không có bình luận nào, "Demarco / Spewak / Zachman đứng trước thử thách của thời gian ..." Tôi đặc biệt quan tâm đến Code Complete vì bề rộng của nó bao trùm và bề rộng của tác động trong lĩnh vực này.


1
Một cuộc kiểm tra lại nhanh chóng về nó đã nhắc nhở tôi về những phiền toái khi văn bản xuất hiện mâu thuẫn với các ví dụ và các phần khác nhau của cuốn sách khuyên những điều khác nhau. Ngoài ra, nó vẫn có vẻ khá tốt.
Izkata

@Izkata - ví dụ?
MathAttack

Đã thêm dưới dạng câu trả lời
Izkata

1
Câu hỏi hay, gần đây tôi đã suy nghĩ có nên đọc lại nó không. Tôi tự hỏi nếu có kế hoạch cho một phiên bản mới?
Antonio2011a

2
Tôi đã học Code Complete (Phiên bản 2) vào mùa hè năm ngoái và không có gì cảm thấy lỗi thời ở đó. Trừ khi sẽ có những thay đổi đột ngột trong phát triển phần mềm, tôi nghĩ tôi sẽ cảm thấy an toàn khi giới thiệu cuốn sách này trong ít nhất năm năm kể từ bây giờ.
gnat

Câu trả lời:


11

Code Complete bao gồm rất nhiều khái niệm vượt thời gian như:

  • sự gắn kết mạnh mẽ
  • khớp nối lỏng lẻo
  • tên thường xuyên tốt
  • lập trình phòng thủ
  • mã tự ghi
  • đánh giá phần mềm
  • kiểm tra đơn vị

mà chắc chắn có liên quan ngày hôm nay.

Một số khái niệm được bảo vệ trong CC hiện được thi hành bằng các ngôn ngữ mới hơn, ví dụ C # không cho phép biến trong phạm vi phụ được định nghĩa theo cách ẩn một định nghĩa siêu phạm vi.

Các khái niệm khác, chẳng hạn như ký hiệu Hungary cho các tên biến đã bị loại bỏ trong quá trình lập trình chính thống (mặc dù bất cứ ai vẫn làm việc với API Win32 sẽ tranh luận kịch liệt rằng chúng vẫn còn sống và tốt). Tuy nhiên, khái niệm thực sự đằng sau quy ước đặt tên biến là truyền đạt ý nghĩa cần thiết và làm rõ mã, các khái niệm mà tôi sẽ tranh luận cũng là vô tận.

Tất cả đã nói, từ những gì tôi có thể nhớ lại (và một cái nhìn nhanh bên trong bản sao CC đáng kính của tôi), tôi sẽ nói rằng nó chắc chắn đáng để xem xét.

Tuy nhiên, tôi không nghĩ rằng nó tăng đến bản chất thực sự vượt thời gian của Tháng người đàn ông huyền thoại. MMM giải quyết các vấn đề về ai đang thực hiện công việc, làm thế nào và tại sao họ làm việc đó; cũng như các chi phí và sự phức tạp của truyền thông (con người). MMM giải quyết các vấn đề cơ bản cho mọi thứ chúng tôi làm. CC, so sánh, tập trung vào các vấn đề thực tế và thực tế về cách chúng tôi làm điều đó. Nói cách khác, nếu một dự án chậm tiến độ và người quản lý quyết định thêm 100 người vào nhóm, viết mã dễ hiểu sẽ không thực sự tạo ra sự khác biệt.

CC không thực sự giải quyết các vấn đề quan trọng gây khó khăn cho ngành công nghiệp của chúng tôi; nhưng nó cung cấp một nền tảng tốt để phấn đấu cho kết quả tốt nhất trong một tình huống thường không thể.

Tôi chắc chắn sẽ xem xét cả hai yêu cầu đọc cho bất cứ ai quan tâm đến phát triển phần mềm; và tôi khuyên bạn nên đọc lại MM bất cứ khi nào bạn cần ôn lại. CC đáng để đọc lại nếu bạn đang lãnh đạo một nhóm phát triển, thiết lập các tiêu chuẩn nhóm hoặc đào tạo các nhà phát triển mới hơn; bên ngoài đó, cá nhân tôi thấy rằng từ lâu tôi đã nội hóa tài liệu trong CC và thực hành nó hàng ngày.

Hy vọng rằng sẽ giúp. Họ chắc chắn là hai trong số yêu thích của tôi.


Có lẽ tôi nên tạo một Q tương tự cho MM. Có lẽ Brooks đã dễ dàng hơn kể từ khi ông viết một cuốn sách quản lý.
MathAttack

CC không giải quyết vấn đề "ai đang làm việc" trong chương 33: Tính cách cá nhân?
mg1075

4

Nhìn chung, cuốn sách vẫn còn tốt. Tuy nhiên, tôi có một vài vấn đề nhỏ với nó:

  • Chương 17 ( "bất thường cấu trúc điều khiển") thực hiện báo cáo bảo vệ đề cập đến như trở về từ một hàm sớm, nhưng các ví dụ được đưa ra trong Chương 15 về "nếu" báo cáo tham mưu chống lại câu lệnh bảo vệ. (Được gọi là mệnh đề bảo vệ / trả lại sớm trong sách)
  • Ví dụ trong phần 14.2 dường như mâu thuẫn với chính nó. Đầu tiên, nó đưa ra một ví dụ về mã "xấu" và cách làm cho nó "tốt". Sau đó, tuyên bố rằng, khi nhóm các câu lệnh liên quan lại với nhau, theo dữ liệu hoặc theo độ tương tự của tác vụ sẽ là "tốt". Ví dụ "xấu" sau đó cũng nên được coi là "tốt" - và, tôi nghĩ, dễ đọc hơn nhiều so với ví dụ "tốt", bởi vì tất cả dữ liệu đang được tính ở cùng một tỷ lệ - có ít trạng thái giữ trong đầu bạn .
  • Chương 23, Gỡ lỗi, trong đó các câu lệnh in được phân biệt thành dấu đầu dòng. Mặc dù tôi đồng ý rằng chúng không nên là công cụ duy nhất, nhưng chúng rất hữu ích trong việc giảm phạm vi mã nơi xảy ra lỗi. Rắc một ít trong suốt để xem dữ liệu đột nhiên không như bạn mong đợi, đưa ra một điểm khởi đầu tốt để gỡ lỗi, tùy thuộc vào mã bạn đang làm việc.

Tôi có một ký ức mơ hồ về một đối số khác liên quan đến các đối số chức năng, nhưng không thể tìm thấy nó vào lúc này. Nó có thể là một cuốn sách khác.


6
Vâng, anh ấy đã sai về báo cáo in và bây giờ anh ấy vẫn sai. Khi gặp lỗi ở một vị trí không xác định, bản in và nhật ký nói chung là công cụ tôi chọn.
Loren Pechtel
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.