Làm thế nào để mọi người quản lý để viết và duy trì mã cực kỳ phức tạp và khó đọc? [đóng cửa]

Đọc mã nguồn SQLite là nhiệm vụ IMO không thể. Tuy nhiên, đây là một phần mềm khá phức tạp có thể sử dụng được (tất cả đều là cơ sở dữ liệu nhúng đầy đủ) có thể được tải xuống, biên dịch và sử dụng từ mã khác và nó được cập nhật liên tục.

Làm thế nào để mọi người quản lý để viết và duy trì mã cực kỳ phức tạp và khó đọc như vậy?

Có một sự khác biệt lớn giữa Phức tạp và phức tạp. Các liên kết sau đây về tổng hợp nó lên. :)

http://codebetter.com/bloss/dru.seller/archive/2009/09/25/complex-vs-complicated.aspx

Trên một ghi chú cá nhân hơn, tôi làm việc trên cơ sở mã gồm hơn 1 triệu dòng mã. Tôi đã ở trong đó từ dòng 1 đến trạng thái hiện tại của nó. Bạn càng nông dân (đọc mã trong thời gian dài hơn), nó càng trở nên dễ dàng hơn. Tôi không thể nói cho bạn biết mỗi dòng làm gì, nhưng tôi có thể nói với bạn là bắt đầu tìm kiếm một nhiệm vụ hoặc lỗi cụ thể. Nó chỉ đến một cách tự nhiên.

Đạo đức của câu chuyện là giống như bất kỳ điều gì trong thế giới lập trình, nó cần có thời gian. Nếu bạn mong đợi nhìn vào SQLite và chỉ cần biết và hiểu nó, bạn đang tự đùa. Sẽ mất thời gian để tìm ra cách mọi thứ hoạt động cùng nhau. Sự khác biệt giữa mã tốt và mã xấu là quá trình đó mất bao lâu.

Cuối cùng, một số nhà phát triển không có khả năng nhảy vào một cơ sở mã và bắt đầu tìm ra nó. Nhiều người sẽ cảm thấy choáng ngợp ở kích thước tuyệt đối hoặc kiến ​​trúc của cơ sở mã. Những người khác sẽ không có vấn đề chỉ cần nhảy vào nó. Tất cả phụ thuộc vào thế mạnh của các nhà phát triển.

Trong trường hợp cụ thể của SQLite, công cụ chính mà họ đã chọn sử dụng để phát triển và bảo trì là kiểm tra tự động. Họ tự hào về phạm vi bảo hiểm 100% (bảo hiểm chi nhánh, không bảo hiểm tuyên bố) trong bộ thử nghiệm của họ. Theo họ, đây là một trong những sản phẩm phần mềm được thử nghiệm tốt nhất trên thế giới. Vì vậy, họ biết ngay khi một thứ gì đó họ đã thêm hoặc thay đổi gây ra hồi quy và có thể phát triển khá đáng sợ do kết quả của điều đó.

http://sqlite.org/testing.html

Những con số đáng kinh ngạc - chúng có số dòng mã thử nghiệm gấp 640 lần so với mã sản xuất.

EDIT: Có vẻ như câu hỏi này đã được đưa ra từ cõi chết! Và hơn một năm sau, cùng một trang báo cáo họ có số lượng mã thử nghiệm gấp 1177 lần so với sản xuất!

• chức năng phát triển theo thời gian.
  • chức năng mới được thúc đẩy bởi các yêu cầu mới của khách hàng.
  • Mã cũ được viết theo cách cho phép các chức năng chưa được triển khai trong tương lai được thêm vào mà không phá vỡ mã cũ.
• chuyên gia tên miền (trong trường hợp này, cơ sở dữ liệu là một miền nổi tiếng trong Khoa học máy tính.)
• phản hồi của cộng đồng
  • lỗi
• đường cong học tập dốc không phải là một vấn đề cho sự chuẩn bị tốt và kiên trì. Có thể mất 6 tháng, 1 năm hoặc thậm chí lâu hơn để trở nên thoải mái, và đó là điều mà một số người có thể đưa ra.
• động lực thương mại. không có hỗ trợ tiền tệ, rất ít người có thể đầu tư thời gian và sức lực vào đường cong học tập dốc.

Bạn không cần phải có sự hiểu biết sâu sắc về toàn bộ dự án để có thể duy trì nó. Thông thường với phần mềm lớn, phức tạp, mọi người sẽ có "khu vực" riêng mà họ chăm sóc và họ chỉ có kiến ​​thức 'vượt qua' về phần còn lại của hệ thống.

SQLite thực sự tương đối nhỏ trên quy mô của "các dự án phần mềm lớn" nhưng nếu bạn nhìn vào một cái gì đó giống như hệ điều hành Windows, bạn sẽ có những người chỉ làm việc trên kernel, những người chỉ làm việc trên shell, những người chỉ làm việc trên Internet Explorer, những người chỉ làm việc với Trình quản lý cửa sổ, v.v. Ai đó làm việc trong "trình bao" sẽ không thể sửa lỗi trong kernel khi thả mũ.

Cũng có lợi ích mà các dự án này phát triển theo thời gian: chúng không phải lúc nào cũng bắt đầu phức tạp này. Điều đó có nghĩa là một nhà phát triển mới thường có thể được "đào tạo" bởi các nhà phát triển có kinh nghiệm hơn.

Khi bạn tham gia vào một nhóm lớn các nhà phát triển, bạn sẽ được cung cấp một khía cạnh cụ thể của dự án để làm việc (có thể là một lỗi hoặc tính năng mới) và bạn sẽ có một nhà phát triển khác trở thành "bạn thân" trong vài lần lặp đầu tiên. Bạn thân của bạn sẽ hiểu rõ về khu vực bạn đang làm việc và có thể giúp bạn tìm đường.

Đối với các dự án nguồn mở như SQLite, thực sự khó hơn một chút vì không có động lực cho các nhà phát triển hiện tại "đào tạo" các nhà phát triển mới. Vì vậy, bạn sẽ thấy bạn một mình nhiều hơn một chút. Nhưng bạn vẫn có thể tìm thấy trợ giúp trên các diễn đàn dành cho nhà phát triển hoặc danh sách gửi thư (ví dụ: chỉ đăng một câu hỏi như "Tôi muốn triển khai tính năng như vậy" hoặc "Tôi đã tìm thấy lỗi XYZ, tôi sẽ bắt đầu tìm kiếm ở đâu?" một số hình thức giúp đỡ.

Có một sự khác biệt giữa dự án khó đọc và phức tạp. Nếu một người không hiểu sâu về ngôn ngữ mà dự án được viết hoặc tên miền của dự án thì điều đó không có nghĩa là mã được viết xấu.

Lời khuyên của tôi:

• Có chắc chắn bạn hiểu ngôn ngữ của dự án. Nó không đủ để biết ngôn ngữ.
• Tìm hiểu mọi chi tiết về tên miền trước khi đặt tay vào mã.

Đối với tôi SQLite là rất phức tạp và không có gì phức tạp. Các lĩnh vực của dự án này đòi hỏi sự hiểu biết sâu sắc về các khái niệm rộng.

Một điều không được đề cập trong các câu trả lời khác là "Nó tự nhiên đến với họ". Hầu hết mọi người muốn viết mã tốt nhưng họ được điều chỉnh để viết mã xấu. Một số lập trình viên mà tôi đã gặp là những người suy nghĩ LINEAR một cách tự nhiên + đôi khi rất khôn ngoan họ đưa ra các giải pháp phức tạp. Hầu hết những người như vậy không dành thời gian đọc hoặc học từ cuốn sách họ học và khi công việc yêu cầu.

Làm thế nào để mọi người quản lý để viết và duy trì mã cực kỳ phức tạp và khó đọc như vậy?

Nếu họ là những lập trình viên gốc và họ tiếp tục duy trì nó, họ sẽ không thấy nó là "phức tạp và khó đọc". Có lẽ họ thấy nó là "đơn giản và dễ đọc", vì họ đã tự viết nó.

Bất kỳ mã nào cũng cần thời gian để hiểu nó. Chỉ là một số mất nhiều thời gian hơn những người khác :)

Bạn có thể quấn đầu quanh bất kỳ cơ sở mã nào nếu bạn có - sự kiên trì, kiên nhẫn và cách tiếp cận có phương pháp - nhưng chủ yếu là sự kiên trì :-)

Quản lý trở nên dễ dàng hơn rất nhiều nếu có những việc được thực hiện luôn theo cùng một cách. Tôi không biết mã SQLite, nhưng tôi đang làm việc trong một môi trường có nhiều dự án. Bên cạnh việc hiểu trường hợp kinh doanh (logic eq), vì mọi thứ về cơ bản đều được thực hiện theo cùng một cách ở mọi nơi (truy cập cơ sở dữ liệu, v.v.), việc bắt đầu làm việc trên một dự án khác là tương đối dễ dàng. Văn bản dài ngắn: Hướng dẫn mã hóa - theo cách phù hợp - làm cho cuộc sống và mã như vậy dễ dàng hơn nhiều. Đây có thể là một trong những trợ giúp cho các lập trình viên SQLite.

• Nếu bạn là tác giả chính của phần mềm và bạn đã làm việc với nó trong hơn 10 năm và bạn là một thiên tài, thì có thể hiểu toàn bộ vấn đề. Phần lớn các phần mềm phức tạp (như SQLite hoặc nhân Linux) thực sự thường có chính xác một tác giả gốc có sự hiểu biết sâu sắc về nó, ngay cả khi những người khác đã đóng góp.
• Nếu kiến ​​trúc phần mềm là lành mạnh (độ gắn kết cao, khớp nối thấp), hiểu toàn bộ điều này không phải là điều kiện tiên quyết để thực hiện các bổ sung và sửa đổi hữu ích cho nó.
• Hiểu RDBMS hoặc HĐH là một số trường hợp đặc biệt, đòi hỏi sự hiểu biết sâu sắc về các nguyên tắc CS cơ bản. Không như vậy với các ứng dụng phần mềm "thông thường".

Họ cố gắng viết nó theo cách đơn giản nhưng không phải là cách đơn giản.

Đi đơn giản như bạn có thể làm cho mọi thứ nhanh hơn để hiểu / đọc, ngay cả khi nó có thể mất một thời gian.

Thuật toán đang được triển khai đặt giới hạn thấp hơn về mức độ đơn giản để thực hiện mã. Nếu một mô tả trừu tượng về thuật toán được triển khai là cực kỳ phức tạp và đòi hỏi hàng tấn dữ liệu khác nhau được ghép với nhau, thì thuật toán thực thi mã không thể đơn giản cho dù ai viết nó.

Nói cách khác, một lý do tại sao đôi khi tôi viết mã không thể hiểu được là bởi vì, với thuật toán tôi muốn thực hiện, tôi không có lựa chọn nào khác.