Lie 2: Code nên được thiết kế xung quanh một mô hình của thế giới? [đóng cửa]

Gần đây tôi đã đọc bài đăng trên blog của Three Big Lies và tôi đang gặp khó khăn trong việc biện minh cho lời nói dối thứ hai, được trích dẫn ở đây:

(LIE # 2) MÃ SỐ NÊN ĐƯỢC THIẾT KẾ MỘT MÔ HÌNH CỦA THẾ GIỚI

Không có giá trị trong mã là một loại mô hình hoặc bản đồ của một thế giới tưởng tượng. Tôi không biết tại sao cái này lại hấp dẫn đối với một số lập trình viên, nhưng nó cực kỳ phổ biến. Nếu có một tên lửa trong trò chơi, hãy yên tâm rằng có một lớp "Tên lửa" (Giả sử mã là C ++) chứa dữ liệu cho chính xác một tên lửa và thực hiện công cụ rockety. Hoàn toàn không quan tâm đến việc thông tin dữ liệu đang thực sự được thực hiện hay bố trí dữ liệu. Hoặc cho vấn đề đó, không có sự hiểu biết cơ bản rằng ở đâu có một thứ, có lẽ có nhiều hơn một.

Mặc dù có rất nhiều hình phạt về hiệu suất cho loại thiết kế này, nhưng điều quan trọng nhất là nó không có tỷ lệ. Ở tất cả. Một trăm tên lửa có giá gấp một trăm lần so với một tên lửa. Và nó cực kỳ có khả năng nó có giá cao hơn thế! Ngay cả với một người không lập trình, điều đó cũng không có ý nghĩa gì. Quy mô nền kinh tế. Nếu bạn có nhiều thứ hơn, nó sẽ rẻ hơn, không đắt hơn. Và cách để làm điều đó là thiết kế dữ liệu đúng cách và nhóm các thứ bằng các phép biến đổi tương tự.

Dưới đây là những vấn đề của tôi với lời nói dối này nói riêng.

1. Có giá trị trong mã là một mô hình / bản đồ của một thế giới tưởng tượng khi mô hình hóa thế giới tưởng tượng giúp (ít nhất là tôi, cá nhân) hình dung và sắp xếp mã.

2. Đối với tôi, có một lớp "Rocket" là một lựa chọn hoàn toàn hợp lệ cho một lớp. Có lẽ "Tên lửa" có thể được chia thành các loại Tên lửa như AGM-114 Hellfire, v.v ... có chứa cường độ tải trọng, vận tốc tối đa, bán kính quay tối đa, loại nhắm mục tiêu, v.v., nhưng mọi tên lửa được bắn sẽ cần phải có vị trí và một vận tốc.

3. Tất nhiên có 100 tên lửa có giá hơn 1 Rocket. Nếu có 100 tên lửa trên màn hình thì phải có 100 tính toán khác nhau để cập nhật vị trí của chúng. Đoạn thứ hai nghe có vẻ như đang đưa ra tuyên bố rằng nếu có 100 Tên lửa, thì có nên tốn ít hơn 100 phép tính để cập nhật trạng thái?

Vấn đề của tôi ở đây là tác giả trình bày một mô hình lập trình "thiếu sót" nhưng không trình bày cách "sửa" nó. Có lẽ tôi đang vấp phải sự tương tự của lớp Rocket, nhưng tôi thực sự muốn hiểu lý do đằng sau lời nói dối này. Sự thay thế là gì?

Đầu tiên, chúng ta hãy xem xét một số bối cảnh: đây là một nhà thiết kế trò chơi viết trên blog có chủ đề đang lấy ra hiệu suất cuối cùng từ CPU Cell BE. Nói cách khác: đó là về lập trình trò chơi console, cụ thể hơn là lập trình trò chơi console cho PlayStation 3.

Giờ đây, các lập trình viên trò chơi là một nhóm tò mò, các lập trình viên điều khiển trò chơi thậm chí còn hơn thế, và Cell BE là một CPU khá lạ. (Có một lý do Sony đã đi với một thiết kế thông thường hơn cho PlayStation 4!)

Vì vậy, chúng ta phải xem xét những tuyên bố đó trong bối cảnh này.

Cũng có một số đơn giản hóa trong bài viết blog đó. Đặc biệt, Lie # 2 này được trình bày kém.

Tôi sẽ lập luận rằng mọi thứ trừu tượng từ thế giới thực là một mô hình theo một nghĩa nào đó. Và vì phần mềm không có thật, nhưng ảo, nó luôn là một sự trừu tượng và do đó luôn là một mô hình. Nhưng! Một mô hình không cần phải có ánh xạ 1: 1 rõ ràng vào thế giới thực. Đó là, sau tất cả, những gì làm cho nó một mô hình ở nơi đầu tiên.

Vì vậy, trong một số ý nghĩa, tác giả rõ ràng sai: phần mềm là một mô hình. Giai đoạn. Theo một nghĩa khác, anh ta đã đúng: mô hình đó thực sự không phải giống với thế giới thực.

Tôi sẽ đưa ra một ví dụ mà tôi đã đưa ra một số câu trả lời khác trong nhiều năm qua, ví dụ Giới thiệu nổi tiếng về tài khoản ngân hàng OO 101. Đây là giao diện của Tài khoản Ngân hàng trong hầu hết mọi lớp OO từ trước đến nay:

class Account {
  var balance: Decimal
  def transfer(amount: Decimal, target: Account) = {
    balance -= amount
    target.balance += amount
  }
}

So: balancelà dữ liệu , và transferlà một hoạt động .

Nhưng! Đây là những gì một Tài khoản Ngân hàng trông giống như trong hầu hết mọi phần mềm ngân hàng:

class TransactionSlip {
  val transfer(amount: Decimal, from: Account, to: Account)
}

class Account {
  def balance = 
    TransactionLog.filter(t => t.to == this).map(_.amount).sum - 
    TransactionLog.filter(t => t.from == this).map(_.amount).sum
}

Vì vậy, bây giờ transferlà dữ liệu và balancelà một hoạt động (gấp bên trái nhật ký giao dịch). (Bạn cũng sẽ nhận thấy rằng đó TransactionSliplà bất biến, balancelà một hàm thuần túy, TransactionLogcó thể là một cơ sở dữ liệu bất biến "gần như" chỉ có thể bổ sung. Tôi chắc chắn rằng nhiều bạn đã phát hiện ra các lỗi đồng thời lóa trong lần triển khai đầu tiên, giờ đây đã biến mất một cách kỳ diệu .)

Lưu ý rằng cả hai đều là mô hình. Cả hai đều có giá trị như nhau. Cả hai điều này đều đúng. Cả hai mô hình này đều giống nhau. Tuy nhiên, chúng hoàn toàn kép với nhau: mọi thứ là dữ liệu trong một mô hình là một hoạt động trong mô hình kia và mọi thứ hoạt động trong một mô hình đều là dữ liệu trong mô hình khác.

Vì vậy, câu hỏi không phải là liệu bạn mô hình hóa "thế giới thực" trong mã của bạn, mà là cách bạn mô hình hóa nó.

Hóa ra, mô hình thứ hai thực sự cũng là cách hoạt động của ngân hàng trong thế giới thực. Như tôi đã nói ở trên, mô hình thứ hai này hầu như không thay đổi và thuần túy và miễn dịch với các lỗi đồng thời, điều này thực sự rất quan trọng nếu bạn nghĩ rằng có một thời gian cách đây không lâu, trong TransactionSlipđó có những mẩu giấy thực sự được gửi xung quanh thông qua ngựa và xe ngựa.

Tuy nhiên, thực tế là mô hình thứ hai này thực sự phù hợp với cả cách thức hoạt động của ngân hàng thế giới thực và cách phần mềm ngân hàng thế giới thực hoạt động, không tự động làm cho nó trở nên "đúng" hơn. Bởi vì, trên thực tế, mô hình đầu tiên ("sai") gần đúng với cách khách hàng ngân hàng xem ngân hàng của họ. Đối với họ , transferlà một hoạt động (họ phải điền vào một biểu mẫu) và balancelà một phần dữ liệu ở cuối bảng sao kê tài khoản của họ.

Vì vậy, rất có thể đúng là trong mã công cụ trò chơi cốt lõi của một game bắn súng PS3 hiệu năng cao, sẽ không có Rocketloại, nhưng vẫn sẽ có một số mô hình của thế giới đang diễn ra, ngay cả khi mô hình trông kỳ lạ cho một người không phải là chuyên gia trong lĩnh vực lập trình công cụ vật lý trò chơi console.

Tôi không đồng ý với mọi "lời nói dối" mà anh ấy đề xuất.

TL; DR Tác giả của bài viết này đã cố gắng gây tranh cãi để làm cho bài viết của họ thú vị hơn, nhưng cái gọi là "lời nói dối" được các nhà phát triển phần mềm chấp nhận vì những lý do chính đáng.

Lie # 1 - Big O quan trọng cho mục đích mở rộng. Không ai quan tâm nếu một ứng dụng nhỏ bé mất nhiều thời gian hơn, đó là thời gian duy nhất quan trọng, họ quan tâm rằng khi chúng tăng gấp đôi kích thước đầu vào, nó sẽ không nhân thời gian thực hiện lên gấp 10 lần.

Lie # 2 - Mô hình hóa các chương trình sau thế giới thực cho phép một lập trình viên nhìn vào mã của bạn 3 năm sau để dễ dàng hiểu những gì nó đang làm. Mã cần phải được duy trì hoặc bạn sẽ cần dành hàng giờ chỉ để cố gắng hiểu chương trình đang cố gắng làm gì. Một câu trả lời khác gợi ý rằng bạn có thể có nhiều lớp chung hơn như LaunchPadvà MassiveDeviceMover. Đây không phải là lớp xấu nhất định phải có, nhưng bạn vẫn sẽ cần Rocketlớp. Làm thế nào là bất cứ ai phải biết những gì a MassiveDeviceMoverlàm hoặc những gì nó di chuyển? Có phải nó đang di chuyển núi, tàu vũ trụ, hoặc các hành tinh? Điều này về cơ bản có nghĩa là việc thêm vào các lớp như MassiveDeviceMoverlàm cho chương trình của bạn kém hiệu quả hơn (nhưng có thể dễ đọc và dễ hiểu hơn).

Ngoài ra, chi phí thời gian của nhà phát triển đã bắt đầu vượt quá chi phí phần cứng từ lâu. Đó là một ý tưởng khủng khiếp để bắt đầu cố gắng thiết kế với tối ưu hóa ở phía trước suy nghĩ của bạn. Bạn lập trình nó theo cách dễ hiểu và dễ hiểu, sau đó điều chỉnh chương trình của bạn sau khi tìm ra phần nào trong chương trình của bạn đang mất nhiều thời gian để chạy. Đừng quên: 80% thời gian thực hiện đang được sử dụng bởi 20% chương trình.

Lie # 3 - Mã là vô cùng quan trọng. Mã được viết tốt (Và mô-đun) cho phép tái sử dụng (tiết kiệm vô số giờ làm việc). Nó cũng cho phép bạn sàng lọc và nhận ra dữ liệu xấu để có thể xử lý. Dữ liệu là tuyệt vời, nhưng không có mã, sẽ không thể phân tích và nhận thông tin hữu ích từ nó.

Trong một hệ thống thương mại điện tử, bạn không giao dịch với "tên lửa" ở cấp độ, bạn giao dịch với "sản phẩm". Vì vậy, nó phụ thuộc vào những gì bạn đang cố gắng thực hiện và mức độ trừu tượng mong muốn của bạn.

Trong một trò chơi, có thể lập luận rằng tên lửa chỉ là một trong nhiều loại "vật thể chuyển động". Vật lý tương tự áp dụng cho chúng như với tất cả các vật thể chuyển động khác. Vì vậy, ít nhất, "tên lửa" sẽ được kế thừa từ một số lớp cơ sở "đối tượng chuyển động" tổng quát hơn.

Trong mọi trường hợp, tác giả của đoạn văn bạn trích dẫn dường như đã phóng đại trường hợp của mình một chút. Tên lửa vẫn có thể có các đặc điểm độc đáo, như "lượng nhiên liệu còn lại" và "lực đẩy" và bạn không cần một trăm lớp để thể hiện điều này cho một trăm tên lửa, bạn chỉ cần một. Tạo đối tượng có chi phí khá thấp trong hầu hết các ngôn ngữ lập trình đàng hoàng, vì vậy nếu bạn cần theo dõi những thứ giống như tên lửa, quan niệm rằng bạn không nên tạo đối tượng Rocket vì nó có thể quá đắt không có ý nghĩa gì.

Vấn đề với thế giới thực là tất cả những vật lý đáng nguyền rủa đó. Chúng tôi phân tách mọi thứ thành các vật thể trong thế giới thực bởi vì chúng dễ di chuyển hơn các nguyên tử riêng lẻ, hoặc một khối khổng lồ nóng chảy của thứ gì đó có khả năng là một tên lửa.

Tương tự như vậy, thế giới thực cung cấp một số tính năng hữu ích mà chúng ta dựa vào. Thật dễ dàng để tạo ra ngoại lệ Penguin - "tất cả các loài chim bay, ngoại trừ ...". Và thật dễ dàng để gắn nhãn mọi thứ là tên lửa, ý tôi là nếu tôi gọi chú chim cánh cụt đó là một tên lửa và thắp sáng nó ... nó không hoạt động.

Vì vậy, làm thế nào chúng ta tách những thứ trong thế giới thực hoạt động theo khái niệm dưới những ràng buộc đó. Khi chúng ta thực hiện mọi thứ trong mã, chúng ta nên tách biệt mọi thứ để hoạt động tốt dưới những ràng buộc đó, chúng khác nhau một cách quyết định.

Sự thay thế là gì?

Hãy suy nghĩ về các mạng. Chúng tôi không mô hình cổng và dây và bộ định tuyến trong mã. Thay vào đó chúng tôi trừu tượng truyền thông mạng vào các kết nối và giao thức. Chúng tôi làm điều đó bởi vì nó là một sự trừu tượng hữu ích bất kể việc thực hiện trong thế giới thực. Và nó đặt các ràng buộc hữu ích (ví dụ: bạn không thể giao tiếp cho đến khi kết nối được mở) chỉ quan trọng trong mã .

Vì vậy, có, đôi khi mô hình mã sau khi thế giới thực hoạt động, nhưng đó là một sự trùng hợp ngẫu nhiên . Khi mọi người nói về OOP, các đối tượng không phải là đối tượng trong thế giới thực. Các trường học và hướng dẫn nói khác là một thảm kịch kéo dài hàng thập kỷ.

Thay thế là mô hình hóa những điều mà chương trình của bạn quan tâm. Ngay cả khi chương trình của bạn liên quan đến tên lửa, bạn có thể không cần phải có một thực thể gọi là a Rocket. Chẳng hạn, bạn có thể có một LaunchPadthực thể và một LaunchSchedulethực thể và một MassiveDeviceMoverthực thể. Thực tế là tất cả những thứ này đều hỗ trợ cho việc phóng tên lửa không có nghĩa là bạn đang tự xử lý tên lửa.

Vấn đề của tôi ở đây là tác giả trình bày một mô hình lập trình "thiếu sót" nhưng không trình bày cách "sửa" nó. Có lẽ tôi đang vấp phải sự tương tự của lớp Rocket, nhưng tôi thực sự muốn hiểu lý do đằng sau lời nói dối này. Sự thay thế là gì?

Đây là vấn đề thực sự, nhưng tôi sẽ cung cấp cho bạn vai trò là nhà phát triển, có thể điều đó sẽ giúp ích.

Đầu tiên, tôi sẽ không gọi bất kỳ lời nói dối nào, như những quan niệm sai lầm phổ biến. Gọi nó là dối trá.

Một ông nói đúng, theo một số cách. Sẽ không dành nhiều thời gian cho việc này, vì nó không phải là một phần của câu hỏi. Nhưng thực chất anh ấy đúng. Tôi có thể nói lại điều này là "Những gì hoạt động trong phòng thí nghiệm có thể không hoạt động trong cuộc sống thực". Quá nhiều lần các nhà phát triển gắn bó với một thiết kế hoạt động trong một "phòng thí nghiệm" nhưng thất bại trong các ứng dụng trong thế giới thực.

Ba Âm thanh hơi xà phòng với tôi, nhưng về cơ bản, anh ấy lại đúng. Nhưng điều này có thể được viết lại để "viết mã xung quanh nhu cầu của bạn, đừng cố gắng phù hợp với nhu cầu với mã của bạn."

Hai lần nữa, ở đây anh đúng. Tôi đã thấy các nhà phát triển dành hàng tuần hoặc lâu hơn để phát triển một lớp "tên lửa" khi một lớp "phương tiện" đơn giản sẽ hoạt động hoặc một lớp "di chuyển" thậm chí đơn giản hơn. Nếu tất cả tên lửa của bạn cần làm là di chuyển từ bên trái màn hình sang bên phải và phát ra âm thanh, thì bạn có thể sử dụng cùng loại bạn đã làm cho ô tô, tàu hỏa, thuyền và ruồi. Đối số 100 nên chi phí ít hơn thì 1 * 100 dường như đã hết thời gian để phát triển và không quá nhiều trong chi phí tính toán. Mặc dù gắn bó với các lớp ít chung hơn mà được sử dụng lại là "rẻ hơn", nhưng nhiều lớp cụ thể không thể được sử dụng lại. Điều này có thể được viết lại là "các lớp chung tốt hơn các lớp cụ thể,"

Về bản chất, toàn bộ bài viết có thể được viết lại, với ít từ thông dụng hơn và nó sẽ chỉ là một đoạn văn dài nhất. Điều đó nói rằng, đó là một bài viết blog tập trung vào một lĩnh vực lập trình hẹp. Tôi đã thực hiện một số chương trình nhúng và tôi có thể đồng ý, với ý tưởng chung đằng sau những tuyên bố này, mặc dù có khá nhiều "lông tơ" xung quanh chúng để làm cho nó phù hợp cho bài thuyết trình tại GDC.

Một lưu ý cuối cùng, bài báo được viết vào năm 2008 (tốt nhất tôi có thể nói). Mọi thứ thay đổi nhanh chóng. Các tuyên bố là đúng ngày hôm nay, nhưng các hệ thống nhúng ngày nay phổ biến hơn nhiều và sau đó các mô hình phát triển thay đổi. Có lẽ ngay cả trong phản ứng với bài viết / nói chuyện này.

Tôi thấy thú vị khi những điều dối trá này xoay quanh mối quan tâm học thuật: Nền tảng, hiệu quả sử dụng bộ nhớ và dữ liệu. Nhưng nó hoàn toàn bỏ qua yếu tố con người.

Phần mềm là để đáp ứng nhu cầu của mọi người. Thông thường, điều này được định lượng trong các điều khoản kinh doanh - có những khách hàng muốn một cái gì đó và những người ủng hộ sẵn sàng trả tiền để thực hiện nó. Nếu phần mềm đang được viết theo cách đáp ứng nhu cầu của cả hai mặt của phương trình, thì đó là phần mềm tốt, nếu không, nó là phần mềm xấu.

Nếu nền tảng không quan trọng đối với khách hàng, thì nền tảng không quan trọng. Nếu hiệu quả bộ nhớ không quan trọng đối với khách hàng, thì nó không quan trọng. Nếu dữ liệu không quan trọng đối với khách hàng, thì dữ liệu không quan trọng. Nếu mã hoạt động, nhưng không thể đọc hoặc duy trì và khách hàng muốn thay đổi nhanh chóng và đáng tin cậy ở một mức giá hợp lý, thì mã được viết kém là một điều tồi tệ. Nếu mã hoạt động, nhưng không thể đọc hoặc duy trì và khách hàng không quan tâm hoặc sẵn sàng trả tiền cho các nhà tái cấu trúc đắt tiền, thì mã được viết kém là một điều tốt.

Lời nói dối lớn là bất cứ điều gì ngoại trừ yếu tố con người. Tại sao dữ liệu quan trọng? Bởi vì có một số khách hàng hoặc các bên liên quan cần nó. Đó là "sự thật lớn".

IMHO Nếu mã được "thiết kế theo mô hình của thế giới" thì dễ hiểu hơn, cho cả nhà thiết kế và nhà phát triển và cho người bảo trì. Nhưng tôi nghĩ không chỉ riêng tôi, và không chỉ phần mềm. Từ Wikipedia: Mô hình khoa học là một hoạt động khoa học, mục đích là làm cho một phần hoặc tính năng cụ thể của thế giới dễ hiểu, định nghĩa, định lượng, trực quan hóa hoặc mô phỏng bằng cách tham chiếu đến kiến ​​thức hiện có và thường được chấp nhận