Làm thế nào lớn cơ sở mã không OO được quản lý?

Tôi luôn thấy sự trừu tượng là một tính năng rất hữu ích mà OO cung cấp để quản lý cơ sở mã. Nhưng làm thế nào các cơ sở mã không OO lớn được quản lý? Hay cuối cùng chúng trở thành một " Quả bóng lớn "?

Cập nhật:
Dường như mọi người đều nghĩ 'trừu tượng' chỉ là mô đun hóa hoặc ẩn dữ liệu. Nhưng IMHO, điều đó cũng có nghĩa là việc sử dụng 'Các lớp trừu tượng' hoặc 'Các giao diện' là điều bắt buộc để tiêm phụ thuộc và do đó thử nghiệm. Làm thế nào các cơ sở mã không OO quản lý điều này? Ngoài ra, ngoài việc trừu tượng hóa, việc đóng gói còn giúp quản lý rất nhiều cơ sở mã lớn vì nó xác định và hạn chế mối quan hệ giữa dữ liệu và hàm.

Với C, rất có thể viết mã giả OO. Tôi không biết nhiều về các ngôn ngữ không phải OO khác. Vì vậy, nó là cách để quản lý các cơ sở mã C lớn?

Bạn dường như nghĩ rằng OOP là phương tiện duy nhất để đạt được sự trừu tượng.

Mặc dù OOP chắc chắn rất giỏi trong việc đó, nhưng đó không phải là cách duy nhất. Các dự án lớn cũng có thể được quản lý bằng cách mô đun hóa không thỏa hiệp (chỉ cần nhìn vào Perl hoặc Python, cả hai đều xuất sắc về điều đó, và các ngôn ngữ chức năng như ML và Haskell cũng vậy) và bằng cách sử dụng các cơ chế như mẫu (trong C ++).

Các mô-đun, chức năng (bên ngoài / bên trong), chương trình con ...

như Konrad đã nói, OOP không phải là cách duy nhất để quản lý các cơ sở mã lớn. Như một vấn đề thực tế, khá nhiều phần mềm đã được viết trước nó (trước C ++ *).

Nguyên tắc mô đun không bị giới hạn trong các ngôn ngữ hướng đối tượng.

Thực tế hoặc là những thay đổi không thường xuyên (nghĩ rằng tính toán hưu trí An sinh xã hội) và / hoặc kiến ​​thức ăn sâu vì những người duy trì như hệ thống đã làm như vậy trong một thời gian (mất kiểm soát là bảo mật công việc).

Các giải pháp tốt hơn là xác nhận lặp lại, theo ý tôi là kiểm tra tự động (ví dụ kiểm thử đơn vị) và kiểm tra con người tuân theo các bước đã đăng ký (ví dụ: kiểm tra hồi quy) "trái ngược với nhấp chuột xung quanh và xem những gì phá vỡ".

Để bắt đầu chuyển sang một loại thử nghiệm tự động nào đó với một cơ sở mã hiện tại, tôi khuyên bạn nên đọc Hiệu quả làm việc của Michael Feather với Legacy Code , trong đó nêu chi tiết các cách tiếp cận để đưa các cơ sở mã hiện tại cho đến khi một loại khung thử nghiệm lặp lại OO hoặc không. Điều này dẫn đến các loại ý tưởng mà người khác đã trả lời như mô đun hóa, nhưng cuốn sách mô tả cách tiếp cận đúng để làm như vậy trong khi không phá vỡ mọi thứ.

Mặc dù tiêm phụ thuộc dựa trên giao diện hoặc các lớp trừu tượng là một cách rất hay để thực hiện kiểm tra, nhưng nó không cần thiết. Đừng quên rằng hầu như bất kỳ ngôn ngữ nào cũng có con trỏ hàm hoặc eval, có thể làm bất cứ điều gì bạn có thể làm với giao diện hoặc lớp trừu tượng (vấn đề là chúng có thể làm được nhiều hơn , bao gồm nhiều điều xấu và chúng không ' t tự cung cấp siêu dữ liệu). Một chương trình như vậy thực sự có thể đạt được tiêm phụ thuộc với các cơ chế này.

Tôi thấy việc nghiêm ngặt với siêu dữ liệu là rất hữu ích. Trong các ngôn ngữ OO, mối quan hệ giữa các bit của mã được xác định (theo một mức độ) theo cấu trúc lớp, theo cách được chuẩn hóa đủ để có những thứ như API phản chiếu. Trong các ngôn ngữ thủ tục, có thể hữu ích để tự phát minh ra chúng.

Tôi cũng thấy việc tạo mã hữu ích hơn nhiều trong ngôn ngữ thủ tục (so với ngôn ngữ hướng đối tượng). Điều này đảm bảo dữ liệu meta được đồng bộ với mã (vì nó được sử dụng để tạo ra nó) và cung cấp cho bạn một cái gì đó giống như các điểm cắt của lập trình hướng theo khía cạnh - một nơi bạn có thể tiêm mã khi bạn cần. Đôi khi, đó là cách duy nhất để lập trình DRY trong một môi trường như vậy mà tôi có thể tìm ra.

Trên thực tế, như bạn đã phát hiện ra gần đây , các hàm thứ tự đầu tiên là tất cả những gì bạn cần cho đảo ngược phụ thuộc.

C hỗ trợ các chức năng đặt hàng đầu tiên và thậm chí đóng cửa ở một mức độ nào đó . Và macro C là một tính năng mạnh mẽ cho lập trình chung, nếu được xử lý cẩn thận.

Tất cả đều ở đó. SGLIB là một ví dụ điển hình về cách C có thể được sử dụng để viết mã có thể tái sử dụng cao. Và tôi tin rằng có rất nhiều ngoài kia.

Ngay cả khi không có sự trừu tượng, hầu hết các chương trình được chia thành các phần của một số loại. Các phần đó thường liên quan đến các nhiệm vụ hoặc hoạt động cụ thể và bạn làm việc trên các phần giống như cách bạn sẽ làm việc trên các bit cụ thể nhất của các chương trình được trừu tượng hóa.

Trong các dự án vừa và nhỏ, điều này thực sự dễ thực hiện hơn với việc thực hiện OO thuần túy đôi khi.

Trừu tượng hóa, các lớp trừu tượng, tiêm phụ thuộc, đóng gói, giao diện, v.v., không phải là cách duy nhất để kiểm soát các cơ sở mã lớn; Đây là cách chính đáng và hướng đối tượng.

Bí quyết chính là tránh suy nghĩ OOP khi mã hóa không phải OOP.

Tính mô đun là chìa khóa trong các ngôn ngữ không phải OO. Trong C điều này đạt được giống như David Thornley vừa đề cập trong một bình luận:

Giao diện đi vào tệp .h, các chức năng có sẵn công khai trong tệp .c và các biến và chức năng riêng tư có được bộ sửa đổi truy cập tĩnh được đính kèm.

Một cách để quản lý mã là phân tách nó thành các loại mã sau, dọc theo các dòng của kiến ​​trúc MVC (model-view-controller).

• Trình xử lý đầu vào - Mã này xử lý các thiết bị đầu vào như chuột, bàn phím, cổng mạng hoặc trừu tượng cấp cao hơn như các sự kiện hệ thống.
• Trình xử lý đầu ra - Mã này liên quan đến việc sử dụng dữ liệu để thao tác với các thiết bị bên ngoài như màn hình, đèn, cổng mạng, v.v.
• Mô hình - Mã này liên quan đến việc khai báo cấu trúc dữ liệu liên tục của bạn, quy tắc xác thực dữ liệu liên tục và lưu dữ liệu liên tục vào đĩa (hoặc thiết bị dữ liệu liên tục khác).
• Lượt xem - Mã này xử lý dữ liệu định dạng để đáp ứng các yêu cầu của các phương thức xem khác nhau, chẳng hạn như trình duyệt web (HTML / CSS), GUI, dòng lệnh, định dạng dữ liệu giao thức truyền thông (ví dụ: JSON, XML, ASN.1, v.v.).
• Thuật toán - Mã này lặp lại chuyển đổi một tập dữ liệu đầu vào thành tập dữ liệu đầu ra càng nhanh càng tốt.
• Bộ điều khiển - Mã này nhận đầu vào thông qua các trình xử lý đầu vào, phân tích cú pháp đầu vào bằng thuật toán và sau đó chuyển đổi dữ liệu với các thuật toán khác bằng cách kết hợp tùy chọn đầu vào với dữ liệu liên tục hoặc chỉ chuyển đổi đầu vào, sau đó tùy ý lưu dữ liệu được chuyển đổi liên tục qua mô hình phần mềm và tùy ý chuyển đổi dữ liệu qua phần mềm xem để hiển thị trên thiết bị đầu ra.

Phương pháp tổ chức mã này hoạt động tốt cho phần mềm được viết bằng bất kỳ ngôn ngữ OO hoặc không phải OO nào vì các mẫu thiết kế phổ biến thường phổ biến cho từng khu vực. Ngoài ra, các loại ranh giới mã này thường được kết hợp lỏng lẻo nhất, ngoại trừ các thuật toán vì chúng liên kết các định dạng dữ liệu từ đầu vào đến mô hình và sau đó đến đầu ra.

Sự phát triển hệ thống thường ở dạng phần mềm của bạn xử lý nhiều loại đầu vào hơn hoặc nhiều loại đầu ra hơn, nhưng các mô hình và khung nhìn giống nhau và các bộ điều khiển hoạt động rất giống nhau. Hoặc một hệ thống có thể theo thời gian cần phải hỗ trợ ngày càng nhiều loại đầu ra khác nhau mặc dù đầu vào, mô hình, thuật toán là như nhau, và bộ điều khiển và khung nhìn tương tự nhau. Hoặc một hệ thống có thể được tăng cường để thêm các mô hình và thuật toán mới cho cùng một bộ đầu vào, đầu ra tương tự và các khung nhìn tương tự.

Một cách lập trình OO làm cho tổ chức mã trở nên khó khăn là vì một số lớp gắn chặt với cấu trúc dữ liệu liên tục và một số thì không. Nếu các cấu trúc dữ liệu liên tục có liên quan mật thiết với những thứ như xếp tầng 1: N mối quan hệ hoặc mối quan hệ m: n, thì rất khó để quyết định ranh giới lớp cho đến khi bạn đã mã hóa một phần quan trọng và có ý nghĩa trong hệ thống của bạn trước khi bạn biết bạn hiểu đúng . Bất kỳ lớp nào được gắn với các cấu trúc dữ liệu liên tục sẽ khó phát triển khi lược đồ của dữ liệu liên tục thay đổi. Các lớp xử lý các thuật toán, định dạng và phân tích cú pháp ít có khả năng dễ bị tổn thương trước các thay đổi trong lược đồ của các cấu trúc dữ liệu liên tục. Sử dụng một loại tổ chức mã MVC để cách ly tốt hơn các thay đổi mã lộn xộn nhất với mã mô hình.

Khi làm việc trong các ngôn ngữ thiếu các tính năng tổ chức và cấu trúc sẵn có (ví dụ: nếu nó không có không gian tên, gói, cụm, v.v.) hoặc trong trường hợp không đủ để giữ một cơ sở mã có kích thước đó trong tầm kiểm soát, phản ứng tự nhiên sẽ phát triển chiến lược riêng của chúng tôi để tổ chức mã.

Chiến lược tổ chức này có thể bao gồm các tiêu chuẩn liên quan đến nơi lưu giữ các tệp khác nhau, những điều cần xảy ra trước / sau một số loại hoạt động nhất định và quy ước đặt tên và các tiêu chuẩn mã hóa khác, cũng như rất nhiều "đây là cách nó được thiết lập - đừng gây rối với nó! " loại bình luận - có giá trị miễn là họ giải thích tại sao!

Bởi vì chiến lược rất có thể sẽ được điều chỉnh theo nhu cầu cụ thể của dự án (con người, công nghệ, môi trường, v.v.), thật khó để đưa ra giải pháp một kích cỡ phù hợp cho tất cả các cơ sở mã lớn.

Do đó, tôi tin rằng lời khuyên tốt nhất là nắm lấy chiến lược dành riêng cho dự án và đặt việc quản lý nó thành ưu tiên chính: ghi lại cấu trúc, tại sao lại như vậy, các quy trình để thực hiện thay đổi, kiểm toán để đảm bảo rằng nó được tuân thủ, và chủ yếu: thay đổi nó khi cần thay đổi.

Chúng ta hầu như quen thuộc với các lớp và phương thức tái cấu trúc, nhưng với một cơ sở mã lớn bằng ngôn ngữ như vậy, chính chiến lược tổ chức (hoàn chỉnh với tài liệu) cần được tái cấu trúc khi cần thiết.

Lý do cũng giống như khi tái cấu trúc: bạn sẽ phát triển một khối tinh thần để làm việc trên các phần nhỏ của hệ thống nếu bạn cảm thấy rằng tổ chức tổng thể của nó là một mớ hỗn độn, và cuối cùng sẽ cho phép nó xuống cấp (ít nhất là do tôi đảm nhận nó).

Các cảnh báo cũng giống nhau: sử dụng kiểm tra hồi quy, đảm bảo bạn có thể dễ dàng hoàn nguyên nếu việc tái cấu trúc bị sai và thiết kế để tạo điều kiện tái cấu trúc ở nơi đầu tiên (hoặc bạn sẽ không làm điều đó!).

Tôi đồng ý rằng điều đó khó hơn nhiều so với tái cấu trúc mã trực tiếp và việc xác thực / che giấu thời gian từ những người quản lý / khách hàng có thể không hiểu tại sao nó cần phải được thực hiện, nhưng đây cũng là những loại dự án dễ bị thối phần mềm nhất gây ra bởi các thiết kế cấp cao không linh hoạt ...

Nếu bạn đang hỏi về việc quản lý một cơ sở mã lớn, bạn đang hỏi làm thế nào để giữ cho cơ sở mã của bạn được cấu trúc tốt ở mức tương đối thô (thư viện / mô-đun / xây dựng hệ thống con / sử dụng không gian tên / có đúng tài liệu ở đúng nơi v.v.) Các nguyên tắc OO, đặc biệt là 'các lớp trừu tượng' hoặc 'giao diện', là các nguyên tắc để giữ cho mã của bạn sạch sẽ bên trong, ở mức độ rất chi tiết. Do đó, các kỹ thuật để giữ một cơ sở mã lớn có thể quản lý được không khác nhau đối với mã OO hoặc không mã OO.

Cách xử lý là bạn tìm ra đường viền của các yếu tố bạn sử dụng. Ví dụ, các yếu tố sau trong C ++ có đường viền rõ ràng và mọi phụ thuộc bên ngoài đường viền phải được suy nghĩ cẩn thận:

1. chức năng miễn phí
2. chức năng thành viên
3. lớp học
4. vật
5. giao diện
6. biểu hiện
7. constructor gọi / tạo đối tượng
8. chức năng gọi
9. kiểu tham số mẫu

Kết hợp các yếu tố này và nhận ra đường viền của chúng, bạn có thể tạo hầu hết mọi kiểu lập trình bạn muốn trong c ++.

Ví dụ về điều này là cho một hàm sẽ nhận ra rằng thật tệ khi gọi các hàm khác từ một hàm, vì nó gây ra sự phụ thuộc, thay vào đó, bạn chỉ nên gọi các hàm thành viên của các tham số của hàm ban đầu.

Thách thức kỹ thuật lớn nhất là vấn đề không gian tên. Liên kết một phần có thể được sử dụng để làm việc xung quanh này. Cách tiếp cận tốt hơn là thiết kế bằng cách sử dụng các tiêu chuẩn mã hóa. Nếu không, tất cả các biểu tượng trở thành một mớ hỗn độn.

Emacs là một ví dụ tốt về điều này:

Emacs Lisp kiểm tra sử dụng skip-unlessvà let-bindđể làm tính năng phát hiện và kiểm tra đồ đạc:

Đôi khi, không có ý nghĩa gì khi chạy thử nghiệm do thiếu các điều kiện tiên quyết. Một tính năng Emacs bắt buộc có thể không được biên dịch, chức năng được kiểm tra có thể gọi một nhị phân bên ngoài có thể không có sẵn trên máy thử nghiệm, bạn đặt tên cho nó. Trong trường hợp này, macro skip-unlesscó thể được sử dụng để bỏ qua bài kiểm tra:

 (ert-deftest test-dbus ()
   "A test that checks D-BUS functionality."
   (skip-unless (featurep 'dbusbind))
   ...)

Kết quả của việc chạy thử nghiệm không nên phụ thuộc vào trạng thái hiện tại của môi trường và mỗi thử nghiệm phải để môi trường của nó ở cùng trạng thái mà nó tìm thấy. Đặc biệt, thử nghiệm không nên phụ thuộc vào bất kỳ biến hoặc móc tùy chỉnh Emacs nào, và nếu nó phải thực hiện bất kỳ thay đổi nào đối với trạng thái của Emacs hoặc trạng thái bên ngoài đối với Emacs (chẳng hạn như hệ thống tệp), thì nó sẽ hoàn tác các thay đổi này trước khi trả về, bất kể nó đã vượt qua hay thất bại.

Các xét nghiệm không nên phụ thuộc vào môi trường bởi vì bất kỳ sự phụ thuộc nào như vậy có thể làm cho thử nghiệm trở nên giòn hoặc dẫn đến những thất bại chỉ xảy ra trong một số trường hợp nhất định và khó có thể sao chép. Tất nhiên, mã được kiểm tra có thể có các cài đặt ảnh hưởng đến hành vi của nó. Trong trường hợp đó, tốt nhất là thực hiện kiểm tra let-bindtất cả các biến cài đặt như vậy để thiết lập một cấu hình cụ thể trong thời gian thử nghiệm. Thử nghiệm cũng có thể thiết lập một số cấu hình khác nhau và chạy mã được thử nghiệm với từng cấu hình.

Như là SQLite. Đây là thiết kế:

1. sqlite3_open () → Mở kết nối đến cơ sở dữ liệu SQLite mới hoặc hiện có. Các nhà xây dựng cho sqlite3.

2. sqlite3 → Đối tượng kết nối cơ sở dữ liệu. Được tạo bởi sqlite3_open () và bị phá hủy bởi sqlite3_close ().

3. sqlite3_stmt → Đối tượng câu lệnh đã chuẩn bị. Được tạo bởi sqlite3_prepare () và bị phá hủy bởi sqlite3_finalize ().

4. sqlite3_prepare () → Biên dịch văn bản SQL thành mã byte sẽ thực hiện công việc truy vấn hoặc cập nhật cơ sở dữ liệu. Hàm tạo cho sqlite3_stmt.

5. sqlite3_bind () → Lưu trữ dữ liệu ứng dụng vào các tham số của SQL gốc.

6. sqlite3_step () → Chuyển một sqlite3_stmt sang hàng kết quả tiếp theo hoặc hoàn thành.

7. sqlite3_column () → Các giá trị cột trong hàng kết quả hiện tại cho một sqlite3_stmt.

8. sqlite3_finalize () → Destructor cho sqlite3_stmt.

9. sqlite3_exec () → Hàm bao bọc thực hiện sqlite3_prepare (), sqlite3_step (), sqlite3_column () và sqlite3_finalize () cho một chuỗi của một hoặc nhiều câu lệnh SQL.

10. sqlite3_close () → Destructor cho sqlite3.

Các thành phần Tokenizer, Parser và Code Generator được sử dụng để xử lý các câu lệnh SQL và chuyển đổi chúng thành các chương trình thực thi bằng ngôn ngữ máy ảo hoặc mã byte. Nói một cách đơn giản, ba lớp trên cùng thực hiện sqlite3_prepare_v2 () . Mã byte được tạo bởi ba lớp trên cùng là một câu lệnh được chuẩn bị. Mô-đun Máy ảo chịu trách nhiệm chạy mã byte câu lệnh SQL. Mô-đun B-Tree tổ chức một tệp cơ sở dữ liệu thành nhiều kho lưu trữ khóa / giá trị với các khóa được sắp xếp và hiệu suất logarit. Mô-đun Pager chịu trách nhiệm tải các trang của tệp cơ sở dữ liệu vào bộ nhớ, để thực hiện và kiểm soát các giao dịch cũng như tạo và duy trì các tệp nhật ký ngăn chặn hỏng hóc cơ sở dữ liệu sau sự cố hoặc mất điện. Giao diện hệ điều hành là một bản tóm tắt mỏng cung cấp một tập các thói quen chung để điều chỉnh SQLite để chạy trên các hệ điều hành khác nhau. Nói một cách đơn giản, bốn lớp dưới cùng thực hiện sqlite3_step () .

Bảng ảo là một đối tượng được đăng ký với kết nối cơ sở dữ liệu SQLite mở. Từ phối cảnh của một câu lệnh SQL, đối tượng bảng ảo trông giống như bất kỳ bảng hoặc khung nhìn nào khác. Nhưng đằng sau hậu trường, các truy vấn và cập nhật trên một bảng ảo gọi các phương thức gọi lại của đối tượng bảng ảo thay vì đọc và ghi trên tệp cơ sở dữ liệu.

Một bảng ảo có thể biểu thị cấu trúc dữ liệu trong bộ nhớ. Hoặc nó có thể đại diện cho chế độ xem dữ liệu trên đĩa không ở định dạng SQLite. Hoặc ứng dụng có thể tính toán nội dung của bảng ảo theo yêu cầu.

Dưới đây là một số cách sử dụng hiện có và được quy định cho các bảng ảo:

Giao diện tìm kiếm toàn văn
Chỉ số không gian sử dụng R-Plants
Hướng nội dung đĩa của tệp cơ sở dữ liệu SQLite (bảng ảo dbstat)
Đọc và / hoặc viết nội dung của tệp giá trị được phân tách bằng dấu phẩy (CSV)
Truy cập hệ thống tập tin của máy tính chủ như thể nó là một bảng cơ sở dữ liệu
Kích hoạt thao tác SQL của dữ liệu trong các gói thống kê như R

SQLite sử dụng một loạt các kỹ thuật kiểm tra bao gồm:

Ba khai thác thử nghiệm được phát triển độc lập
Phạm vi kiểm tra chi nhánh 100% trong cấu hình được triển khai
Hàng triệu và hàng triệu trường hợp thử nghiệm
Kiểm tra hết bộ nhớ
Kiểm tra lỗi I / O
Kiểm tra sự cố và mất điện
Kiểm tra Fuzz
Kiểm tra giá trị biên
Kiểm tra tối ưu hóa bị vô hiệu hóa
Kiểm tra hồi quy
Kiểm tra cơ sở dữ liệu không đúng
Sử dụng rộng rãi các kiểm tra assert () và thời gian chạy
Phân tích giá trị
Kiểm tra hành vi không xác định
Danh sách kiểm tra

Tài liệu tham khảo

• Quan điểm khái niệm về kiến ​​trúc của Emacs (pdf)

• Giao diện hệ điều hành SQLite hoặc "VFS"

• Cơ chế bảng ảo của SQLite

• Giới thiệu về giao diện SQLite C / C ++

• Emacs-Elisp-Lập trình · GitHub

• Các thử nghiệm và môi trường của chúng - Thử nghiệm hồi quy Emps Lisp

• Cách kiểm tra SQLite