Tôi liên tục bị choáng ngợp bởi các dự án lớn, một khi chúng đạt đến một mức độ phức tạp nhất định. Khi tôi đạt đến một điểm nhất định trong một dự án, tiến độ của tôi chậm lại khi bò và tôi thấy mình liên tục lùi bước và loại bỏ tất cả các loại nhầm lẫn.

Tôi đã thực sự giỏi trong việc tái cấu trúc do điểm yếu này của tôi. Và tôi luôn cố gắng phân rã các đối tượng của mình thành những đối tượng nhỏ hơn, dễ quản lý hơn. Điểm yếu này có lẽ cũng khiến tôi phải chú ý quá nhiều đến việc thiết kế mọi thứ đúng cách.

Tôi biết nếu tôi có thể chia nhỏ vấn đề của mình thành những vấn đề nhỏ hơn, tôi sẽ có thể hoàn thành suôn sẻ. Một chiến lược xuất hiện trong tâm trí là phát triển dựa trên thử nghiệm. Tôi có thể làm gì nữa?

ngừng suy nghĩ về mã

bắt đầu suy nghĩ về các lớp, tính năng, mô-đun, dịch vụ và các khái niệm trừu tượng cấp cao hơn khác

bạn đang bị choáng ngợp bởi vì bạn đang suy nghĩ ở mức quá thấp

Làm cho phức tạp đơn giản là dễ dàng ; chờ đợi nghĩ rằng đó là cách khác.

Mọi người đấu tranh với điều này, không có giải pháp đơn giản nào có hiệu quả cao.

Vì bạn không liệt kê điều này trong các câu hỏi của mình, nên đề xuất của tôi sẽ là:

Tập trung vào sự gắn kết chức năng thông qua:

Nguyên tắc trách nhiệm duy nhất quy định rằng mọi đối tượng nên có một trách nhiệm duy nhất và trách nhiệm đó phải được gói gọn trong lớp. Tất cả các dịch vụ của nó nên được liên kết hẹp với trách nhiệm đó.

Nếu bạn Google nó trong số các kết quả trên trang đầu tiên, bạn sẽ tìm thấy hai tài nguyên tuyệt vời:

• " Nguyên tắc trách nhiệm duy nhất " của Robert C. Martin (Tháng 2/2002): Nguyên tắc này thảo luận về sự cần thiết phải đặt những thứ thay đổi vì những lý do khác nhau trong các lớp khác nhau.
• " Luật xoăn: Làm một điều " của Jeff Atwood (Mar / 2007): Nguyên tắc trách nhiệm duy nhất nói rằng một lớp nên có một, và chỉ một, lý do để thay đổi.

Sự gắn kết trong khoa học máy tính là gì?

Sự gắn kết là thước đo mức độ liên quan hoặc tập trung mạnh mẽ vào trách nhiệm của một mô-đun. Khi được áp dụng cho lập trình hướng đối tượng, nếu các phương thức phục vụ lớp đã cho có xu hướng giống nhau về nhiều mặt, thì lớp được cho là có độ gắn kết cao. Trong một hệ thống có tính gắn kết cao, khả năng đọc mã và khả năng tái sử dụng được tăng lên, trong khi độ phức tạp được giữ ở mức có thể quản lý được.

Sự gắn kết bị giảm nếu : - Các chức năng được nhúng trong một lớp, được truy cập thông qua các phương thức của nó, có ít điểm chung. - Phương pháp thực hiện nhiều hoạt động khác nhau, thường sử dụng các bộ dữ liệu thô hoặc không liên quan.

Nhược điểm của độ gắn kết thấp (hoặc độ kết dính yếu kém) là: - Tăng độ khó trong việc hiểu các mô-đun. - Gia tăng khó khăn trong việc duy trì một hệ thống, bởi vì những thay đổi logic trong miền ảnh hưởng đến nhiều mô-đun và vì những thay đổi trong một mô-đun yêu cầu thay đổi trong các mô-đun liên quan. - Gia tăng khó khăn trong việc sử dụng lại một mô-đun vì hầu hết các ứng dụng sẽ không cần bộ hoạt động ngẫu nhiên do mô-đun cung cấp.

Nếu bạn có bất kỳ câu hỏi cho tôi biết.

Phân hủy các tính năng thành các mục nhỏ nhất có thể. Ví dụ: một trường duy nhất trên một biểu mẫu. Chọn một ưu tiên rủi ro hoặc ưu tiên cao nhất và tiến về phía trước như đó là một sửa lỗi đơn giản, không phải là một dự án lớn. Đúng là bạn sẽ kết thúc với một số tái cấu trúc sau này, nhưng ít nhất bạn sẽ tiến về phía trước.

Từ kinh nghiệm của tôi, bạn đã trả lời câu hỏi của riêng bạn với nhận xét về TDD. Đối với tôi, tôi thường cảm thấy giống như bạn, thành công nhanh chóng nhanh chóng biến thành bị sa lầy vào các chi tiết nhỏ một khi hệ thống đạt đến một kích thước nhất định. Tôi thấy với TDD nó hữu ích vì bạn có thể giải quyết từng phần của hệ thống như những phần nhỏ, biết rằng phần còn lại của hệ thống sẽ hoặc sẽ tiếp tục hoạt động khi bạn rời khỏi nó. Tôi cũng nghĩ rằng, với TDD, nó giúp đảm bảo hệ thống của bạn được phân chia rõ ràng thành các phần nhỏ hơn có thể kiểm tra độc lập.

Một số người giỏi thiết kế các chương trình mô-đun, dễ hiểu, nhưng phần lớn các lập trình viên thiếu cơ sở này, ở mức độ thấp hơn hoặc lớn hơn. Tôi biết rằng không có cuốn sách, thủ tục hoặc thực hành nào có thể biến một trong những loại lập trình viên đầu tiên thành thứ hai, ngoại trừ có thể có nhiều kinh nghiệm. Nhưng tôi thậm chí không chắc chắn về điều đó.

Điểm mấu chốt là hầu hết các lập trình viên sẽ đấu tranh để vượt lên trên tầm thường, một số ít sẽ xoay sở để ổn (đó là nơi tôi sẽ đặt bản thân mình và có lẽ 50% các lập trình viên chuyên nghiệp vào (nói) ngành IB), và rất thiểu số nhỏ sẽ là tuyệt vời. Tôi nên nói rằng tôi chưa bao giờ trong sự nghiệp lâu dài của mình gặp một trong những người xuất sắc này :-)

Tôi nghĩ rằng rất nhiều người cố gắng để giải pháp quá kỹ sư. Họ thực hiện phương pháp "Adam & Eve" khi chỉ cần thực tế hơn một chút sẽ đơn giản hóa mọi thứ rất nhiều.

Các lớp chuyên biệt không phải là xấu, chúng là hệ quả tự nhiên của thiết kế phần mềm âm thanh.

Theo tôi, nhiều lập trình viên không hiểu điều này và không có cuốn sách nào tôi biết để làm cho điều này rõ ràng.

Một điều khác chắc chắn có ích là TDD, cho phép bạn hiểu "cách" bạn sẽ sử dụng lớp trong thực tế và trong nhiều trường hợp có thể tiết kiệm được một ngày, bởi vì nó cho thấy những vấn đề / hạn chế cuối cùng vào đầu ngày.

Cuối cùng, một điều quan trọng RẤT khác tôi sẽ tìm kiếm nếu tôi là bạn là các mẫu thiết kế. Các mẫu thiết kế là cách mọi người thông minh hơn bạn hoặc tôi giải quyết các vấn đề lập trình. Ý tưởng đằng sau các mẫu, đoán xem, đó là chúng không được sử dụng làm sách dạy nấu ăn, công thức nấu ăn mà bạn chỉ cần đặt ở đó, nhưng suy nghĩ và hiểu rõ về miền ứng dụng của bạn trước hết.

Việc sử dụng mô hình một cách khôn ngoan sẽ làm giảm đáng kể số lượng chi tiết bạn phải quản lý.

Một thư viện mẫu thiết kế tốt được thiết kế xung quanh nhu cầu của bạn, sẽ chứng minh vô giá. Chúng ta hãy xem một ví dụ rất đơn giản chỉ để đặt mọi thứ trong bối cảnh:

hãy tưởng tượng bạn có một biểu mẫu trong đó, khi nhấn nút, các biểu mẫu khác phải tự cập nhật. Đây là một mẫu "quan sát viên" điển hình. Bạn có một chủ đề và một số người quan sát, đăng ký chúng với chủ đề đó. Tại sao bạn cần phải thực hiện một giao diện? Bạn chỉ có thể thêm các phương thức hoặc tốt hơn là sử dụng giao diện cho người quan sát và danh sách chung cho chủ đề. Bây giờ bạn đã có những điều tốt nhất của cả hai thế giới: sự độc lập cho những người quan sát và không có những điều kỳ quặc về chủ đề này.

Hy vọng nó có ý nghĩa với bạn!

Andrea

Vấn đề về tốc độ dev và khả năng đọc có thể đến khi chúng ta bỏ qua nhu cầu trừu tượng hóa. Trong một số cơ sở mã lớn mà tôi đã làm việc, kẻ thù phổ biến nhất là số lượng lớn các lớp chuyên biệt có chức năng rất giống nhau khiến mã bị phình to. Nếu chúng ta lùi một bước và hiểu toàn bộ các yêu cầu không phải là một phần của ứng dụng, thì rất nhiều điều trừu tượng sẽ xuất hiện trong đầu chúng ta.

Một số bước đơn giản đã giúp tôi

• Sử dụng trình phân tích tương tự (như Simian) để tìm các khối mã trùng lặp trên cơ sở mã. Rất nhiều mã trùng lặp có nghĩa là ít trừu tượng hơn.
• Giám sát kích thước của các lớp và phương thức, các lớp và phương thức lớn có nghĩa là một vài dịch vụ hoặc bộ điều khiển trở thành các vị thần.
• Làm cho các bài kiểm tra đơn vị / tích hợp là bắt buộc, mang lại cho bạn sự tự tin để tái cấu trúc và cũng hoạt động như một đặc điểm kỹ thuật.
• Hồi tưởng nửa đêm với doanh nghiệp để hiểu nếu các thuật ngữ kỹ thuật / kinh doanh / tên miền họ sử dụng được phản ánh trong tên lớp. Điều này giúp hiểu và nhận tên cho các bộ sưu tập hạng nhất thay vì đại diện như các bộ và danh sách đơn giản. Một số trừu tượng mà chúng tôi không bao giờ nghĩ đến cũng sẽ nổi lên khi chúng tôi ngồi xuống với những người kinh doanh.