TD; DR:
Có một số nhầm lẫn về những gì tôi đã hỏi, vì vậy đây là ý tưởng lái xe đằng sau câu hỏi:
Tôi luôn dự định câu hỏi là gì Tôi có thể không nói rõ nó ban đầu. Nhưng mục đích luôn luôn là " là mô-đun, tách rời, ghép lỏng, tách rời, mã tái cấu trúc " chậm hơn rõ rệt bởi bản chất của nó so với " đơn vị nguyên khối, làm mọi thứ ở một nơi, một tệp, được ghép chặt chẽ ". Phần còn lại chỉ là chi tiết và các biểu hiện khác nhau về điều này mà tôi đã gặp sau đó hoặc bây giờ hoặc sẽ sau này. Đó là chậm hơn cho chắc chắn trên một số quy mô. Giống như một đĩa không phân mảnh, bạn phải nhặt các mảnh từ khắp mọi nơi. Nó chậm hơn. Chắc chắn. Nhưng tôi có nên quan tâm?
Và câu hỏi không phải là về ...
không phải về tối ưu hóa vi mô, tối ưu hóa sớm, v.v. Nó không phải là "tối ưu hóa phần này hay phần kia cho đến chết".
Sau đó là gì?
Đó là về phương pháp tổng thể và các kỹ thuật và cách suy nghĩ về việc viết mã xuất hiện theo thời gian:
- "tiêm mã này vào lớp của bạn như là một phụ thuộc"
- "viết một tệp cho mỗi lớp"
- "tách quan điểm của bạn khỏi cơ sở dữ liệu, bộ điều khiển, tên miền của bạn".
- không viết speblock đồng nhất spaghetti, nhưng viết nhiều thành phần mô-đun riêng biệt làm việc cùng nhau
Đó là về cách thức và phong cách của mã hiện tại - trong thập kỷ này - được thấy và ủng hộ trong hầu hết các khuôn khổ, được ủng hộ tại các công ước, được truyền qua cộng đồng. Đó là một sự thay đổi trong suy nghĩ từ 'khối nguyên khối' sang 'microservice'. Và cùng với đó là giá cả về hiệu năng và chi phí cấp máy, và một số chi phí cấp lập trình viên là tốt.
Câu hỏi gốc sau:
Trong lĩnh vực Khoa học Máy tính, tôi đã nhận thấy một sự thay đổi đáng chú ý trong suy nghĩ khi nói đến lập trình. Tôi bắt gặp những lời khuyên khá thường xuyên như thế này:
- viết mã nhỏ hơn chức năng (có thể kiểm tra và duy trì theo cách này)
- tái cấu trúc mã hiện có thành các đoạn mã nhỏ hơn và nhỏ hơn cho đến khi hầu hết các phương thức / hàm của bạn chỉ dài vài dòng và rõ ràng mục đích của chúng là gì (tạo ra nhiều hàm hơn, so với khối nguyên khối lớn hơn)
- viết các hàm chỉ làm một việc - tách các mối quan tâm, v.v (thường tạo ra nhiều hàm hơn và nhiều khung hơn trên một ngăn xếp)
- tạo nhiều tệp hơn (một lớp trên mỗi tệp, nhiều lớp hơn cho mục đích phân tách, cho các mục đích lớp như MVC, kiến trúc miền, mẫu thiết kế, OO, v.v., tạo ra nhiều lệnh gọi hệ thống tệp hơn)
Đây là một sự thay đổi so với các thực hành mã hóa "cũ" hoặc "lỗi thời" hoặc "spaghetti" trong đó bạn có các phương thức trải dài 2500 dòng, và các lớp lớn và các đối tượng thần làm mọi thứ.
Câu hỏi của tôi là:
khi nó gọi đến mã máy, đến 1 và 0, để hướng dẫn lắp ráp, cho các đĩa cứng, tôi nên lo lắng rằng mã OO được phân tách hoàn hảo của lớp tôi với nhiều hàm và phương thức từ nhỏ đến nhỏ được tái cấu trúc thêm nhiều chi phí?
Chi tiết
Mặc dù tôi không quen thuộc lắm với cách mã OO và các lệnh gọi phương thức của nó được xử lý trong ASM cuối cùng, và cách các cuộc gọi và trình biên dịch DB gọi dịch chuyển sang cánh tay truyền động trên đĩa cứng, tôi có một số ý tưởng. Tôi giả sử rằng mỗi cuộc gọi chức năng bổ sung, cuộc gọi đối tượng hoặc cuộc gọi "#include" (trong một số ngôn ngữ), tạo ra một bộ hướng dẫn bổ sung, từ đó tăng âm lượng mã và thêm các chi phí "nối dây mã" khác nhau, mà không cần thêm mã "hữu ích" thực tế . Tôi cũng tưởng tượng rằng tối ưu hóa tốt có thể được thực hiện cho ASM trước khi nó thực sự được chạy trên phần cứng, nhưng tối ưu hóa đó chỉ có thể làm được rất nhiều.
Do đó, câu hỏi của tôi - bao nhiêu chi phí (trong không gian và tốc độ) không phân tách tốt mã (mã được phân chia trên hàng trăm tệp, lớp và mẫu thiết kế, v.v.) thực sự giới thiệu so với "một phương thức lớn có chứa tất cả mọi thứ trong một tập tin nguyên khối ", do chi phí này?
CẬP NHẬT cho rõ ràng:
Tôi giả định rằng việc lấy cùng một mã và tách nó, tái cấu trúc nó ra, tách nó thành ngày càng nhiều hàm và các đối tượng và các phương thức và các lớp sẽ dẫn đến ngày càng nhiều tham số truyền giữa các đoạn mã nhỏ hơn. Bởi vì chắc chắn, mã tái cấu trúc phải giữ cho luồng hoạt động và điều đó đòi hỏi phải truyền tham số. Nhiều phương thức hoặc nhiều lớp hơn hoặc nhiều mẫu thiết kế Phương thức nhà máy hơn, dẫn đến việc truyền nhiều thông tin khác nhau nhiều hơn so với trường hợp trong một lớp hoặc phương thức nguyên khối duy nhất.
Người ta đã nói ở đâu đó (trích dẫn TBD) rằng có tới 70% tất cả mã được tạo thành từ lệnh MOV của ASM - tải các thanh ghi CPU với các biến thích hợp, chứ không phải tính toán thực tế. Trong trường hợp của tôi, bạn tải lên thời gian của CPU bằng các hướng dẫn PUSH / POP để cung cấp liên kết và tham số truyền giữa các đoạn mã khác nhau. Bạn càng tạo ra các đoạn mã càng nhỏ thì càng cần nhiều "liên kết". Tôi lo ngại rằng mối liên kết này làm tăng sự phình to và chậm chạp của phần mềm và tôi tự hỏi liệu tôi có nên lo lắng về điều này không, và bao nhiêu, nếu có, bởi vì các thế hệ lập trình viên hiện tại và tương lai đang xây dựng phần mềm cho thế kỷ tiếp theo , sẽ phải sống với và tiêu thụ phần mềm được xây dựng bằng cách sử dụng các thực tiễn này.
CẬP NHẬT: Nhiều tập tin
Tôi đang viết mã mới bây giờ đang dần thay thế mã cũ. Đặc biệt tôi đã lưu ý rằng một trong các lớp cũ là tệp dòng ~ 3000 (như đã đề cập trước đó). Bây giờ nó đang trở thành một tập hợp 15-20 tệp nằm trên các thư mục khác nhau, bao gồm các tệp thử nghiệm và không bao gồm khung PHP mà tôi đang sử dụng để liên kết một số thứ với nhau. Nhiều tập tin đang đến là tốt. Khi nói đến I / O đĩa, tải nhiều tệp chậm hơn tải một tệp lớn. Tất nhiên không phải tất cả các tệp đều được tải, chúng được tải khi cần, và các tùy chọn bộ nhớ đệm và bộ nhớ đệm tồn tại, nhưng tôi vẫn tin rằng loading multiple filescần nhiều xử lý hơn loading a single filevào bộ nhớ. Tôi đang thêm điều đó vào mối quan tâm của tôi.
CẬP NHẬT: Phụ thuộc Tiêm mọi thứ
Trở lại vấn đề này sau một thời gian .. Tôi nghĩ rằng câu hỏi của tôi đã bị hiểu lầm. Hoặc có thể tôi đã chọn để hiểu sai một số câu trả lời. Tôi không nói về tối ưu hóa vi mô vì một số câu trả lời đã được nêu ra, (ít nhất tôi nghĩ gọi những gì tôi đang nói về tối ưu hóa vi mô là một cách hiểu sai), nhưng về sự chuyển động của "Mã tái cấu trúc để nới lỏng khớp nối" , ở mọi cấp độ của mã. Tôi đến từ Zend Con gần đây, nơi phong cách mã này là một trong những điểm cốt lõi và trung tâm của hội nghị. Phân tách logic từ chế độ xem, chế độ xem từ mô hình, mô hình từ cơ sở dữ liệu và nếu bạn có thể, hãy tách dữ liệu khỏi cơ sở dữ liệu. Sự phụ thuộc - Tiêm mọi thứ, đôi khi có nghĩa là chỉ cần thêm mã dây (chức năng, lớp, bản tóm tắt) mà không làm gì cả, nhưng phục vụ như một điểm nối / móc, dễ dàng nhân đôi kích thước mã trong hầu hết các trường hợp.
CẬP NHẬT 2: Việc "tách mã thành nhiều tệp" có ảnh hưởng đáng kể đến hiệu suất (ở tất cả các cấp độ tính toán)
Làm thế nào để triết lý compartmentalize your code into multiple filestác động của điện toán ngày nay (hiệu suất, sử dụng đĩa, quản lý bộ nhớ, xử lý CPU)?
tôi đang nói về
Trước...
Trong một quá khứ giả định nhưng khá thực tế không quá xa, bạn có thể dễ dàng viết một khối đơn của một tệp có mô hình và chế độ xem và điều khiển spaghetti hoặc không mã hóa spaghetti, nhưng nó chạy mọi thứ một khi nó đã được tải. Thực hiện một số điểm chuẩn trong quá khứ bằng cách sử dụng mã C Tôi phát hiện ra rằng việc tải một tệp 900Mb vào bộ nhớ và xử lý nó thành nhiều phần lớn hơn so với tải các tệp nhỏ hơn và xử lý chúng trong một bữa ăn nhỏ hơn nhanh hơn chunk làm cùng một công việc cuối cùng.
.. Và bây giờ*
Hôm nay tôi thấy mình đang xem mã hiển thị một sổ cái, có các tính năng như .. nếu một mục là "đơn hàng", hãy hiển thị khối HTML đơn hàng. Nếu một mục hàng có thể được sao chép, hãy in khối HTML hiển thị biểu tượng và tham số HTML phía sau nó cho phép bạn tạo bản sao. Nếu mục có thể được di chuyển lên hoặc xuống, hiển thị các mũi tên HTML thích hợp. V.v. Tôi có thể, thông qua Zend Framework tạopartial()các cuộc gọi, về cơ bản có nghĩa là "gọi một hàm lấy tham số của bạn và chèn chúng vào một tệp HTML riêng mà nó cũng gọi". Tùy thuộc vào mức độ chi tiết tôi muốn nhận, tôi có thể tạo các hàm HTML riêng cho các phần nhỏ nhất của sổ cái. Một cho mũi tên lên, mũi tên xuống, một cho "tôi có thể sao chép mục này", v.v ... Dễ dàng tạo một số tệp chỉ để hiển thị một phần nhỏ của trang web. Lấy mã của tôi và mã Zend Framework phía sau hậu trường, hệ thống / ngăn xếp có thể gọi gần 20-30 tệp khác nhau.
Gì?
Tôi quan tâm đến các khía cạnh, sự hao mòn trên máy được tạo ra bằng cách sắp xếp mã thành nhiều tệp riêng biệt nhỏ hơn.
Ví dụ, tải nhiều tệp hơn có nghĩa là đặt chúng ở nhiều vị trí khác nhau của hệ thống tệp và ở nhiều nơi khác nhau của ổ cứng vật lý, điều đó có nghĩa là thời gian tìm và đọc nhiều ổ cứng hơn.
Đối với CPU, nó có thể có nghĩa là chuyển đổi ngữ cảnh nhiều hơn và tải các thanh ghi khác nhau.
Trong khối phụ này (bản cập nhật # 2) tôi quan tâm nghiêm ngặt hơn về cách sử dụng nhiều tệp để thực hiện cùng một tác vụ có thể được thực hiện trong một tệp duy nhất, ảnh hưởng đến hiệu suất hệ thống.
Sử dụng API biểu mẫu Zend so với HTML đơn giản
Tôi đã sử dụng API biểu mẫu Zend với các thực tiễn OO hiện đại và mới nhất, để xây dựng một biểu mẫu HTML có xác thực, chuyển đổi POSTthành các đối tượng miền.
Tôi phải mất 35 tập tin để thực hiện.
35 files =
= 10 fieldsets x {programmatic fieldset + fieldset manager + view template}
+ a few supporting files
Tất cả có thể được thay thế bằng một vài tệp HTML + PHP + JS + CSS đơn giản, có thể có tổng cộng 4 tệp trọng lượng nhẹ.
Có tốt hơn không Có đáng không? ... Hãy tưởng tượng tải 35 tệp + nhiều tệp thư viện Zend Zramework làm cho chúng hoạt động, so với 4 tệp đơn giản.