Làm thế nào để thực sự tìm ra những gì phải được thực hiện trong thiết kế hướng đối tượng?

Đầu tiên là từ chối trách nhiệm: Tôi thực sự không biết câu hỏi này có phù hợp với trang web này không, nhưng tôi vẫn thấy đây là một câu hỏi có liên quan không chỉ với tôi mà còn cho những người mới bắt đầu. Nếu câu hỏi có thể được cải thiện để phù hợp ở đây, vui lòng chỉ ra ý kiến ​​int. Nếu nó không phù hợp, hãy cho tôi biết và nếu có thể hãy cho tôi biết nơi này có thể được thảo luận vì tôi không tìm thấy bất kỳ diễn đàn tốt nào cho việc này.

Tôi đã học lập trình năm 2009 khi tôi học PHP. Cuối năm 2012, tôi chuyển sang C # và .NET. Dù sao, mã hóa không phải là vấn đề, viết ra các thuật toán không phải là vấn đề của tôi. Vấn đề thực tế của tôi là phải biết những gì phải được mã hóa để đạt được một yêu cầu và nơi nó phải được mã hóa.

Hầu hết các khóa học có sẵn trên web đều giải quyết cách thức - cách viết mã bằng một ngôn ngữ nhất định, cách sử dụng một số bộ API, v.v. Đó không phải là quan điểm của tôi ở đây.

Trong những năm này, tôi đã đọc rất nhiều về một loạt điều: phân tích và thiết kế hướng đối tượng, các mẫu thiết kế, thiết kế hướng tên miền, v.v. Tôi hiểu ví dụ như các nguyên tắc RẮN, một số ý tưởng chính của DDD như sự cần thiết phải có sự tham gia của các chuyên gia tên miền, phát triển ngôn ngữ phổ biến, v.v. Tôi dám nói tôi một nền tảng lý thuyết ít nhất là hợp lý.

Nhưng khi đi vào thực tế tôi cảm thấy như mình là một thảm họa. Cách đây một thời gian, tôi cần tiếp tục phát triển một hệ thống tài chính đã được phát triển bởi một người khác. Đó là loại "hệ thống cũ" được phát triển với C # và WinForms. Đó là lần đầu tiên tôi chọn một dự án có độ phức tạp miền thực, với rất nhiều quy tắc kinh doanh, v.v.

Tôi thú nhận rằng khi tôi nhận được các yêu cầu hầu hết thời gian tôi nghĩ rằng "làm thế nào điều này có thể được thực hiện?" - Tôi không biết làm thế nào để bắt đầu làm việc với các yêu cầu để tìm ra những gì phải được thực hiện. Những nhầm lẫn chính của tôi Tôi tin là những gì tôi phải viết mã, các lớp, giao diện và nơi mỗi phần logic đi, lớp nào mỗi thứ phải có. Vấn đề là tôi không biết bắt đầu từ đâu.

Hầu hết thời gian, với khá nhiều suy nghĩ tôi kết thúc với một số ý tưởng, nhưng tôi không bao giờ biết cách đánh giá xem ý tưởng của tôi có đúng hay không.

Ý tôi là tôi không nghĩ rằng đây là một lý thuyết thiếu, vì tôi đã nói rằng tôi đã đọc về một loạt điều về kiến ​​trúc phần mềm và hướng đối tượng mà tôi đã đề xuất nhưng nó không giúp ích nhiều trong việc xác định những gì phải làm trong thực tế .

Vì vậy, làm thế nào tôi có thể học hỏi để thực sự làm thiết kế hướng đối tượng? Điều tôi muốn học là: các yêu cầu được đưa ra biết cách bắt đầu làm việc với chúng trong một quy trình dẫn đến việc tìm ra những gì phải được thực hiện và nơi mỗi đoạn mã thuộc về. Làm thế nào tôi cũng có thể học cách đánh giá nếu ý tưởng của tôi là chính xác hay không?

Tôi tin rằng giải thích đầy đủ điều này như một câu trả lời ở đây sẽ không thể thực hiện được. Tuy nhiên, điều tôi đang tìm kiếm có thể theo phong cách trang web là câu trả lời chỉ đưa ra một cái nhìn tổng quan và chỉ ra một số tài liệu tham khảo (sách, khóa học trực tuyến, v.v.) có thể được sử dụng để mở rộng ý tưởng và thực sự học những điều này.

Vì vậy, làm thế nào tôi có thể học để thực sự thiết kế hướng đối tượng? Điều tôi muốn học là: các yêu cầu được đưa ra biết cách bắt đầu làm việc với chúng trong một quy trình dẫn đến việc tìm ra những gì phải được thực hiện và nơi mỗi đoạn mã thuộc về. Làm thế nào tôi cũng có thể học cách đánh giá nếu ý tưởng của tôi là chính xác hay không?

Vâng, trước hết, ngừng nghĩ về thiết kế hướng đối tượng là chính xác. Điều đó giống như nghĩ về tiếng Anh là chính xác.

Mô hình hướng đối tượng không chính xác. Nó có những ưu điểm và nhược điểm nhất định. Đó là một lý tưởng. Đó không phải là người duy nhất của chúng tôi. Nó tốt hơn không có gì nhưng chắc chắn không phải là tất cả.

Tôi đã mã hóa trong nhiều thập kỷ nay. Tôi đã nghiên cứu công cụ này gần như miễn là ý tưởng của nó tồn tại. Tôi vẫn đang học ý nghĩa của nó. Các chuyên gia vẫn đang tìm hiểu ý nghĩa của nó. Toàn bộ lĩnh vực của chúng tôi là ít hơn 100 tuổi.

Vì vậy, khi bạn lấy một đống yêu cầu và bật ra mã thỏa mãn chúng nhưng cảm giác như mã bạn đã viết là một mớ hỗn độn bi thảm, bạn không đơn độc. Mã làm việc chỉ đơn giản là bước đầu tiên để mã tuyệt vời. Mã không chỉ hoạt động mà người khác có thể đọc và hiểu dễ dàng. Mã có thể được điều chỉnh nhanh chóng khi yêu cầu thay đổi. Mã khiến bạn muốn ngồi lại và nói "Wow, thật đơn giản".

Vấn đề là chúng ta không được trả tiền để làm tất cả điều đó. Chúng tôi làm tất cả điều đó bởi vì chúng tôi là chuyên gia. Chúng tôi phải làm tất cả những điều đó khi ông chủ không tìm kiếm vì luôn có thời hạn. Nhưng chúng tôi muốn quay lại sau 5 năm và nói với những người mới: "Ồ vâng, tôi đã viết nó. Vẫn hoạt động hả? Tuyệt."

Làm thế nào để bạn đạt được điều đó? Thực hành. Đừng chấp nhận bất kỳ ý tưởng thiết kế nào về đức tin. Ai đó sẽ không im lặng về cách thiết kế hướng sự kiện sẽ đơn giản hóa thiết kế này? Không chắc họ có đúng không? Xây dựng dự án đồ chơi của riêng bạn tại nhà sử dụng mô hình quan sát viên. Lộn xộn với nó. Cố gắng tìm những thứ mà nó KHÔNG giúp được.

Đọc. Câu hỏi. Kiểm tra. Nói lại.

Khi bạn đạt đến điểm mà bạn đã làm điều đó trong 80% cuộc sống của bạn, bạn sẽ bối rối như tôi.

Tôi thú nhận rằng khi tôi nhận được các yêu cầu hầu hết thời gian tôi nghĩ rằng "làm thế nào điều này có thể được thực hiện?" - Tôi không biết làm thế nào để bắt đầu làm việc với các yêu cầu để tìm ra những gì phải được thực hiện. Những nhầm lẫn chính của tôi Tôi tin là những gì tôi phải viết mã, các lớp, giao diện và nơi mỗi phần logic đi, lớp nào mỗi thứ phải có. Vấn đề là tôi không biết bắt đầu từ đâu.

Tôi đã từng cảm thấy như vậy. Sau đó, tôi phát hiện ra niềm vui của tái cấu trúc. Hãy sẵn sàng để thích ứng thiết kế khi bạn mã. Cố gắng làm việc mọi thứ trên giấy trước thời hạn là cách khó để làm điều đó. Viết mã có thể được chứng minh là sai, chứng minh nó sai và sửa nó.

Phát triển phần mềm tập trung vào việc phân phối phần mềm làm việc, đúng thời gian, ngân sách trong khi đáp ứng tất cả các tiêu chí chấp nhận của bạn. Giả sử bạn đã quản lý để làm điều đó, chất lượng cảm nhận của mã hoặc cấu trúc của nó là mối quan tâm thứ yếu.

Tất nhiên, vấn đề là việc viết mã trường xanh mới có xu hướng rẻ hơn và dễ dàng hơn nhiều so với việc duy trì mã kế thừa, vì vậy thay vì quá bận tâm về chất lượng mã hoặc kiến ​​trúc, hãy nhớ rằng vấn đề thực sự của bạn là khả năng duy trì.

Thông thường mã được coi là có thể duy trì khi chi phí, thời gian và rủi ro liên quan đến việc thay đổi mã đó đủ thấp để sửa lỗi hoặc thực hiện các thay đổi đối với các yêu cầu vẫn có hiệu quả về chi phí và bằng cách thực hiện những thay đổi đó bạn không thực hiện được "vòng xoáy tử thần" "Của entropy mã.

Ngược lại, mã được coi là không thể duy trì khi bạn không thể tự tin thay đổi hoặc tái cấu trúc mà không có rủi ro nghiêm trọng về việc phá vỡ thứ gì đó hoặc tiêu tốn quá nhiều thời gian / tiền bạc để đảm bảo không có gì bị phá vỡ - tức là khi thời gian, chi phí và rủi ro liên quan đến việc làm việc với mã đó là cao không tương xứng so với lợi ích của việc thay đổi (ví dụ: chủ nhân hoặc khách hàng của bạn sẽ không mất tiền khi thêm các tính năng mới, sửa lỗi, v.v.)

Hãy nhớ rằng ngay cả mớ spaghetti hỗn độn nhất có thể có khả năng duy trì nếu bạn có đủ các điều khoản xung quanh mớ hỗn độn để bảo vệ bản thân trước những thay đổi phá vỡ (mặc dù những trường hợp như vậy rất hiếm). Vấn đề với mớ hỗn độn spaghetti là việc bảo vệ nó chống lại các thay đổi có xu hướng khá tốn kém và không hiệu quả - đặc biệt là nếu bạn đang thực hiện nó.

Có lẽ cách đáng tin cậy nhất để đảm bảo bạn đã viết mã có thể duy trì là viết (trong trường hợp có thể) một bộ kiểm tra tự động đầy đủ cùng một lúc (đồng thời tận dụng tối đa mọi công cụ phân tích tĩnh khác có thể có).

Bạn đặc biệt không cần phải tuân theo một phương pháp phát triển nghiêm ngặt như TDD / BDD để kết thúc với các thử nghiệm tự động đủ để cho phép bạn tái cấu trúc; bạn chỉ cần đủ để bảo vệ mã chống lại các thay đổi vi phạm trong tương lai.

Nếu mã của bạn được bao phủ bởi các thử nghiệm tự động, thì bạn có thể thư giãn về thiết kế và cấu trúc của nó khi biết rằng bạn được bảo vệ bởi các thử nghiệm đó; bạn có thể tích cực tái cấu trúc vào một ngày sau đó, hoặc thậm chí vứt nó đi và bắt đầu lại.

Điều này đặt ra câu hỏi làm thế nào để viết mã dễ kiểm tra; đây thường là đối số chính để tuân theo các nguyên tắc RẮN; trong thực tế, đặc điểm nổi bật của mã tuân thủ các nguyên tắc RẮN là nó dễ dàng và hiệu quả về thời gian / chi phí để viết các bài kiểm tra đơn vị.

Tất nhiên, đôi khi bạn cũng không có thời gian để viết bài kiểm tra đơn vị; tuy nhiên nếu bạn đã viết tất cả mã của mình trong khi ghi nhớ câu hỏi "Làm thế nào để tôi viết bài kiểm tra tự động cho việc này?" (ngay cả khi bạn không thực sự thực hiện các thử nghiệm đó), có lẽ bạn cũng đã tìm được một thiết kế có thể bảo trì hợp lý.