Điểm phức tạp không có lợi nhuận. Bạn gọi nó là gì?

Là một nhà phát triển phần mềm, một trong những nhiệm vụ chính của tôi là kiểm soát sự phức tạp.

Tuy nhiên, trong một số dự án, có một thời điểm mức độ phức tạp tăng cao đến mức nó đạt đến một điểm nào đó "không quay trở lại". Quá thời điểm này, bạn không bao giờ có thể đưa dự án về mức độ phức tạp chấp nhận được trong thời gian ngắn hơn bạn sẽ cần phải viết lại mọi thứ từ đầu.

Có phải khoảnh khắc đặc biệt này có một tên trong phương ngữ lập trình viên (một cái gì đó tương tự như định luật troll của Godwin)?

--biên tập--

Xin lỗi nếu tôi không rõ ràng. Tôi không nghĩ rằng "khoảnh khắc" này có tên chính thức hoặc là một số liệu nghiêm túc. Tôi đã suy nghĩ về một cái gì đó theo tinh thần của "Đỉnh Ballmer" trong xkcd .

Đây là một vấn đề về khả năng bảo trì hơn là sự phức tạp.

Hiện tượng này được gọi là "nợ kỹ thuật", và một khi nó đạt đến mức nghiêm trọng, dự án đang trên đường phá sản.

Đó có phải ý của bạn?

"Điểm phức tạp quá mức" được gọi bằng tiếng Anh là:

OH MY THIÊN CHÚA LÀ GÌ NÀY.

Vấn đề là, điều này có thể áp dụng cho một cái gì đó thực sự đơn giản, nhưng được thực hiện theo cách khủng khiếp đến mức bạn có phản ứng tương tự.

Vì vậy, phân biệt một cái gì đó rất phức tạp từ một cái gì đó rất kinh khủng có thể khó khăn.

TUY NHIÊN: Điều thực sự có xu hướng xảy ra với tất cả các phần mềm là xử lý một chút như thế này:

Bước 1: Có một thông số kỹ thuật đẹp, làm một thiết kế đẹp, thực hiện những thứ tốt đẹp. Mọi người vui vẻ.

Ở cuối bước 1: các nhà phát triển tự chúc mừng cho sự thanh lịch tuyệt vời của thiết kế của họ và bỏ đi suy nghĩ hạnh phúc "Tôi có một di sản tuyệt vời ở đây để những người khác thêm vào trong tương lai, nó sẽ rất tuyệt vời và thế giới sẽ là một nơi tốt hơn."

Bước 2: Một số thay đổi được thực hiện, mọi thứ được thêm vào, các chức năng mới được bao gồm. Kiến trúc và cấu trúc từ Bước 1 đã khiến đây là một quá trình khá đau đớn. [Nhưng oops, "yếu tố cruft" chỉ tăng lên một chút.]

Ở cuối bước 2: các nhà phát triển tự chúc mừng cho sự thanh lịch tuyệt vời của thiết kế của họ và bỏ đi suy nghĩ hạnh phúc "Gee Tôi rất thông minh khi thực hiện tất cả các khoản trợ cấp đó trong Bước 1. Điều này rất tốt. Tôi có một di sản tuyệt vời. ở đây để những người khác thêm vào những thứ trong tương lai, nó sẽ rất tuyệt vời và thế giới sẽ là một nơi tốt đẹp hơn. "

Bước 3: Nhiều thay đổi được thực hiện, nhiều thứ được thêm vào, nhiều chức năng mới hơn, một loạt các công cụ được thay đổi, phản hồi của người dùng thực sự đang được lắng nghe.

Ở cuối bước 3: các nhà phát triển tự chúc mừng cho sự thanh lịch tuyệt vời của thiết kế của họ và nghĩ rằng "Kiến trúc này khá tốt khi cho phép rất nhiều thay đổi để chỉ vào vị trí một cách dễ dàng. Nhưng tôi hơi không vui về X và Y và Z. Bây giờ họ có thể được dọn dẹp một chút. Nhưng !!! Ahhh !!! Tôi thật thông minh khi thực hiện tất cả các khoản trợ cấp đó trong Bước 1. Điều này rất tốt. Tôi có một di sản tuyệt vời ở đây cho những thứ khác để thêm vào trong tương lai, nó sẽ rất tuyệt vời và thế giới sẽ là một nơi tốt đẹp hơn. "

Bước 4: giống như bước 3. Ngoại trừ:

Ở cuối bước 4: các nhà phát triển nghĩ: "Công cụ này rất tốt để duy trì UGLY. Nó thực sự cần một số thay đổi nghiêm trọng. Tôi không thực sự thích làm việc này. Nó cần tái cấu trúc. Tôi tự hỏi ông chủ là gì sẽ nói khi tôi nói với anh ta rằng nó cần 6 tuần và sẽ không có gì cho người dùng thấy ở cuối này ... nhưng tôi sẽ có thêm 5 năm phạm vi sửa đổi tương lai tốt bằng cách làm điều này .... hmmm .. thời gian để đến quán rượu để uống bia. "

Bước 5: Một loạt các thay đổi cần phải được thực hiện.

Và DURING bước 5, các nhà phát triển nói với nhau: "Mã này thật tệ. Ai đã viết cái này? Họ nên bị bắn. Thật kinh khủng. Chúng tôi PHẢI TẠO RA NÓ."

Bước 5 gây tử vong. Đây là nơi mà yếu tố cruft trở nên tồi tệ đến mức mã không thể có thêm một vài thay đổi, nó cần phải có một số thay đổi LỚN.

Rắc rối ở Bước 5 là mong muốn vứt nó đi và bắt đầu lại. Lý do này gây tử vong là "Yếu tố Netscape". Lên google nó. Các công ty DIE tại thời điểm này, bởi vì bắt đầu lại có nghĩa là bạn bắt đầu với khoảng 50% giả định thay vì sự thật, 150% nhiệt tình thay vì kiến ​​thức, 200% kiêu ngạo thay vì khiêm tốn ("Những kẻ đó quá khờ khạo!"). Và bạn giới thiệu một loạt các lỗi mới.

Điều tốt nhất để làm là tái cấu trúc. Thay đổi một chút tại một thời điểm. Nếu kiến ​​trúc đang hơi mệt, hãy sửa nó. Thêm, mở rộng, cải thiện. Dần dần. Tại mỗi bước trên đường đi, kiểm tra, thử nghiệm và kiểm tra thêm một số. Những thay đổi tăng dần như thế này có nghĩa là 10 năm sau, mã hiện tại và mã gốc giống như rìu của ông nội ("nó có 10 đầu mới và 3 tay cầm mới nhưng nó vẫn là rìu của ông nội"). Nói cách khác, không có nhiều điểm chung. Nhưng bạn đã chuyển từ cũ sang mới dần dần và cẩn thận. Điều này làm giảm rủi ro và đối với khách hàng, nó làm giảm yếu tố tức giận.

Tôi đồng ý rằng khoảnh khắc này rất khó nhận ra và có thể tránh được bằng các quy trình thích hợp. Tuy nhiên, câu hỏi là về những gì để gọi nó. Trong kinh tế thực tế, có khái niệm "lợi nhuận giảm dần": điểm tăng đầu vào cho một tài nguyên trong một quy trình làm giảm lợi nhuận chung của bạn trên mỗi đơn vị. Điều này chắc chắn áp dụng cho mã hóa, và thậm chí những thứ tốt như trừu tượng hóa, tái sử dụng, v.v ... có một điểm giảm lợi nhuận như vậy. Thuật ngữ chung dành riêng cho lập trình là "đại diện". Đối với một người có xu hướng làm việc này, tôi thích thuật ngữ " phi hành gia kiến ​​trúc " của Joel .

Quá thường xuyên mã tốt bị loại bỏ dưới ấn tượng sai lầm rằng nhóm mới với các công cụ mới có thể làm điều đó rẻ hơn, nhanh hơn với độ tin cậy cao hơn, chỉ để thấy rằng

• Sự phức tạp là trong các yêu cầu tài liệu
• Các công cụ mới khó sử dụng hơn thì trang web flash đã hứa
• Đội bóng mới không 'nóng' như họ nghĩ

Có thể thời gian bạn đã mô tả không đến với một số cơ sở mã (tôi đã từng nghĩ như vậy). Cá nhân tôi chưa bao giờ trải nghiệm một trường hợp mã cũ khiến dự án bị hỏng, hoặc viết lại mã lưu một dự án.

Tôi không bao gồm trong trường hợp này khi các số liệu đã được sử dụng để xác định các mô-đun hoặc thiết kế có vấn đề cụ thể, sau đó được loại bỏ và thay thế.

Vấn đề thực sự với "khoảnh khắc" lý thuyết này là nó chỉ được công nhận sau khi thực tế. Trừ khi các đồng nghiệp của bạn là những kẻ thái nhân cách, mọi cam kết vào cơ sở mã đều được thực hiện với niềm tin rằng đó là một cải tiến trên cơ sở mã đó. Chỉ nhìn lại mớ hỗn độn sau đó mà bạn có thể thấy bạn đã vượt qua "khoảnh khắc" đó.

Nhưng tôi thích điều đó chúng ta có thể đặt tên cho nó. "Gents", bạn có thể nói, kéo các nhà phát triển đồng nghiệp của bạn xung quanh bạn, "Chúng tôi đã vượt qua Hellespont Bảo trì. Nhắn tin cho vợ bạn và cho cô ấy biết rằng bạn sẽ không gặp cô ấy trong một thời gian."

Tôi không biết có tên hay không nhưng nếu không có thì tôi sẽ đề xuất gọi nó là "điểm meltdown"

Đây không phải là một câu hỏi rất thú vị.

Quả thực đó là chuyện nhỏ.

Thật tầm thường khi chúng tôi đã phát triển nhiều cách để đối phó.

1. Phương pháp thác nước. Rất nhiều người dành nhiều thời gian để xem xét các yêu cầu và tài liệu thiết kế để đảm bảo rằng sự phức tạp được quản lý.

2. Phương pháp Agile. Ít người dành ít thời gian hơn để thảo luận về những gì có thể áp dụng ngay lập tức để giải quyết vấn đề của ai đó và phát hành phần mềm cho họ. Sự phức tạp được quản lý bởi vì tất cả mọi người tập trung vào việc phát hành một cái gì đó.

Lần duy nhất bất cứ ai vật lộn với "sự phức tạp" là do không tuân theo phương pháp và quản lý thời gian của họ đúng cách.

• Không có giám sát chi tiết trong một phương pháp thác nước. Họ không bị buộc phải xem xét các sản phẩm công việc trung gian theo yêu cầu, kiến ​​trúc, thiết kế cấp cao hoặc đánh giá thiết kế chi tiết.

• Không có thời hạn nước rút hoặc ưu tiên trường hợp sử dụng thích hợp trong phương pháp Agile. Họ không tập trung vào việc phát hành thứ gì đó cho người dùng càng nhanh càng tốt.

Sự phức tạp nên được giới hạn bằng cách thiết lập mục tiêu.

Đấu vật với sự phức tạp có nghĩa là các mục tiêu không được đặt ra hoặc không được khen thưởng xứng đáng.

Không có "bước ngoặt". Nếu quản lý phức tạp bằng cách nào đó là một vấn đề, một cái gì đó đã sai về mặt tổ chức.

Có các phương pháp để trực quan hóa và giám sát nguy cơ tăng độ phức tạp cho các dự án và mã (lớn). Khi chúng được áp dụng một cách hợp lý hy vọng một tên mới cho điểm không thể quay lại là không cần thiết. (Có một MOOC liên quan tại openHPI: https://open.hpi.de/cifts/softwareanalytics2015/ )

Cấu trúc phức tạp là một vấn đề thiết kế chung - không chỉ đối với thiết kế phần mềm trong các nhóm lớn. Hình dung là bước đầu tiên trong quản lý phức tạp cấu trúc. Ma trận và đồ thị có hướng cũng có thể được sử dụng cho mục đích này.

Một số phương pháp để giảm độ phức tạp của cấu trúc là http://www.buch.de/shop/home/suche/?fq=3540878890 :

• mô đun hóa
• tránh các vòng phản hồi
• tam giác

Hơn nữa, có khái niệm về thiết kế tiên đề: https: \ en.wikipedia.org \ wiki \ Axiomatic_design \ Với khái niệm này có thể tránh được các vấn đề đáng tin cậy do sự phức tạp không cần thiết.

Do đó, có một loạt các phương pháp có sẵn. Cuối cùng, luôn luôn là về quyết định nghĩ về họ bởi vì một dự án đủ lớn.