Làm thế nào để quản lý sự phức tạp tình cờ trong các dự án phần mềm

Khi Murray Gell-Mann được hỏi làm thế nào Richard Feynman quản lý để giải quyết rất nhiều vấn đề khó khăn, Gell-Mann trả lời rằng Feynman có một thuật toán:

1. Viết ra vấn đề.
2. Nghĩ thật khó.
3. Viết ra lời giải.

Gell-Mann đang cố gắng giải thích rằng Feynman là một loại người giải quyết vấn đề khác và không có cái nhìn sâu sắc nào có được từ việc nghiên cứu các phương pháp của anh ta. Tôi cảm thấy giống như cách quản lý sự phức tạp trong các dự án phần mềm trung bình / lớn. Những người giỏi thực sự chỉ giỏi về nó và bằng cách nào đó quản lý để xếp lớp và xếp chồng các khái niệm trừu tượng khác nhau để làm cho toàn bộ mọi thứ có thể quản lý được mà không cần đưa ra bất kỳ hành trình ngoại lai nào.

Vì vậy, thuật toán Feynman là cách duy nhất để quản lý độ phức tạp ngẫu nhiên hay có phương pháp thực tế nào mà các kỹ sư phần mềm có thể áp dụng nhất quán để chế ngự độ phức tạp tình cờ?

Khi bạn thấy một động thái tốt, tìm kiếm một tốt hơn.
VẹtEmanuel Lasker, nhà vô địch cờ vua thế giới 27 năm

Theo kinh nghiệm của tôi, động lực lớn nhất của sự phức tạp tình cờ là các lập trình viên gắn bó với bản thảo đầu tiên, chỉ vì nó xảy ra để làm việc. Đây là một cái gì đó chúng ta có thể học hỏi từ các lớp sáng tác tiếng Anh của chúng tôi. Họ xây dựng kịp thời để trải qua một số dự thảo trong bài tập của mình, kết hợp với phản hồi của giáo viên. Các lớp lập trình, vì một số lý do, không.

Có những cuốn sách đầy đủ các cách cụ thể và khách quan để nhận biết, phát biểu và sửa mã tối ưu: Mã sạch , Làm việc hiệu quả với Mã kế thừa và nhiều cách khác. Nhiều lập trình viên quen thuộc với các kỹ thuật này, nhưng không phải lúc nào cũng dành thời gian để áp dụng chúng. Chúng hoàn toàn có khả năng làm giảm sự phức tạp tình cờ, chúng chỉ không tạo thói quen để thử .

Một phần của vấn đề là chúng ta thường không thấy sự phức tạp trung gian của mã người khác, trừ khi nó đã trải qua đánh giá ngang hàng ở giai đoạn đầu. Mã sạch trông có vẻ dễ viết, trong khi thực tế nó thường liên quan đến một số bản nháp. Ban đầu, bạn viết cách tốt nhất xuất hiện trong đầu, nhận thấy những phức tạp không cần thiết mà nó đưa ra, sau đó "tìm kiếm một bước đi tốt hơn" và tái cấu trúc để loại bỏ những phức tạp đó. Sau đó, bạn tiếp tục "tìm kiếm một động thái tốt hơn" cho đến khi bạn không thể tìm thấy một.

Tuy nhiên, bạn không đưa mã ra để xem xét cho đến khi hết thời gian đó, vì vậy bên ngoài có vẻ như đó cũng có thể là một quá trình giống như Feynman. Bạn có xu hướng nghĩ rằng bạn không thể làm tất cả một đoạn như vậy, vì vậy bạn không cần cố gắng, nhưng sự thật là tác giả của mã đơn giản mà bạn chỉ đọc thường không thể viết tất cả trong một đoạn như vậy, hoặc nếu họ có thể, chỉ bởi vì họ có kinh nghiệm viết mã tương tự nhiều lần trước đây và bây giờ có thể thấy mẫu mà không cần các giai đoạn trung gian. Dù bằng cách nào, bạn không thể tránh được bản nháp.

"Kỹ năng kiến ​​trúc phần mềm không thể được dạy" là một ngụy biện phổ biến.

Thật dễ hiểu tại sao nhiều người tin điều đó (những người giỏi về điều đó muốn tin rằng họ đặc biệt bí ẩn và những người không muốn tin rằng đó không phải là lỗi của họ mà họ không phải là họ.) tuy nhiên là sai; kỹ năng này chỉ cần thực hành nhiều hơn một chút so với các kỹ năng phần mềm khác (ví dụ: hiểu các vòng lặp, xử lý các con trỏ, v.v.)

Tôi tin chắc rằng việc xây dựng các hệ thống lớn dễ bị thực hành và học hỏi kinh nghiệm nhiều lần giống như cách trở thành một nhạc sĩ hay diễn giả đại chúng là: một lượng tài năng tối thiểu là điều kiện tiên quyết, nhưng nó không phải là một mức tối thiểu quá lớn tầm với của hầu hết các học viên.

Đối phó với sự phức tạp là một kỹ năng bạn có được phần lớn bằng cách thử và thất bại một vài lần. Chỉ là nhiều hướng dẫn chung mà cộng đồng đã phát hiện ra để lập trình trên diện rộng (sử dụng các lớp, chống trùng lặp bất cứ nơi nào nó cầm đầu, tuân thủ tôn giáo 0/1 / vô cùng ...) rõ ràng là không chính xác và cần thiết đối với người mới bắt đầu cho đến khi họ thực sự làm chương trình một cái gì đó lớn. Cho đến khi bạn thực sự bị cắn bởi sự trùng lặp gây ra vấn đề chỉ vài tháng sau đó, bạn chỉ đơn giản là không thể 'hiểu' tầm quan trọng của các nguyên tắc đó.

Tư duy thực dụng của Andy Hunt giải quyết vấn đề này. Nó đề cập đến mô hình Dreyfus, theo đó có 5 giai đoạn thành thạo các kỹ năng khác nhau. Người mới (giai đoạn 1) cần hướng dẫn chính xác để có thể làm điều gì đó chính xác. Các chuyên gia (giai đoạn 5), ngược lại, có thể áp dụng các mô hình chung cho một vấn đề nhất định. Trích dẫn cuốn sách,

Các chuyên gia thường rất khó để giải thích hành động của họ đến một mức độ chi tiết tốt; nhiều phản ứng của họ được thực hành tốt đến mức chúng trở thành hành động vô thức. Kinh nghiệm rộng lớn của họ được khai thác bởi các khu vực không có tiền sử, không có não, khiến chúng ta khó quan sát và khó có thể nói rõ.

Khi các chuyên gia làm việc của họ, nó dường như rất kỳ diệu đối với phần còn lại của chúng ta. về câu hỏi Tất nhiên, đó không phải là phép thuật, mà là cách các chuyên gia nhận thức thế giới, cách họ giải quyết vấn đề, mô hình tinh thần họ sử dụng, v.v., tất cả đều khác biệt rõ rệt so với không ai.

Quy tắc chung này về việc nhìn thấy (và kết quả là tránh) các vấn đề khác nhau có thể được áp dụng để cụ thể là vấn đề phức tạp ngẫu nhiên. Có một bộ quy tắc nhất định là không đủ để tránh vấn đề này. Sẽ luôn có một tình huống không được quy định trong các quy tắc đó. Chúng ta cần tích lũy kinh nghiệm để có thể thấy trước các vấn đề hoặc xác định các giải pháp. Kinh nghiệm là thứ không thể dạy, nó chỉ có thể có được bằng cách không ngừng cố gắng, thất bại hoặc thành công và học hỏi từ những sai lầm.

Câu hỏi này từ Workplace có liên quan và IMHO sẽ rất thú vị khi đọc trong bối cảnh này.

Bạn không đánh vần nó ra, nhưng sự phức tạp tình cờ của người Hồi giáo được định nghĩa là sự phức tạp không phải là vấn đề cố hữu, so với sự phức tạp của Essential Essential. Các kỹ thuật cần thiết cho "thuần hóa" sẽ phụ thuộc vào nơi bạn bắt đầu. Sau đây chủ yếu đề cập đến các hệ thống đã có được sự phức tạp không cần thiết.

Tôi có kinh nghiệm trong một số dự án lớn trong nhiều năm là thành phần tình cờ trên phạm vi cao hơn nhiều so với khía cạnh thiết yếu của Cameron, và cả những dự án không thành công.

Trên thực tế, thuật toán Feynman áp dụng ở một mức độ nào đó, nhưng điều đó không có nghĩa là mà Nghĩ rằng Hard cứng thực sự chỉ có nghĩa là ma thuật không thể được mã hóa.

Tôi thấy có hai cách tiếp cận cần phải được thực hiện. Lấy cả hai - chúng không phải là lựa chọn thay thế. Một là để giải quyết nó từng phần và hai là làm một việc lớn. Vì vậy, chắc chắn, Viết ra vấn đề. Điều này có thể ở dạng kiểm toán hệ thống - các mô-đun mã, trạng thái của chúng (mùi, mức độ kiểm tra tự động, có bao nhiêu nhân viên tuyên bố hiểu nó), kiến ​​trúc tổng thể (có một, ngay cả khi nó có vấn đề ), trạng thái của các yêu cầu, vv

Đó là bản chất của sự phức tạp của tình cờ, mà không có vấn đề nào cần giải quyết. Vì vậy, bạn cần phải phân loại. Nó bị tổn thương ở đâu - về khả năng duy trì hệ thống và phát triển nó? Có thể một số mã thực sự có mùi, nhưng không phải là ưu tiên hàng đầu và việc sửa lỗi có thể được thực hiện để chờ đợi. Mặt khác, có thể có một số mã sẽ nhanh chóng trả lại thời gian tái cấu trúc.

Xác định một kế hoạch cho một kiến ​​trúc tốt hơn sẽ là gì và cố gắng đảm bảo công việc mới phù hợp với kế hoạch đó - đây là cách tiếp cận gia tăng.

Ngoài ra, nêu rõ chi phí của các vấn đề và sử dụng điều đó để xây dựng một trường hợp kinh doanh để biện minh cho một người tái cấu trúc. Điều quan trọng ở đây là một hệ thống được kiến ​​trúc tốt có thể mạnh mẽ hơn và có thể kiểm tra được dẫn đến thời gian (chi phí và lịch trình) ngắn hơn nhiều để thực hiện thay đổi - điều này có giá trị thực sự.

Một công việc chính được thực hiện trong danh mục đầu tư thực sự khó khăn - bạn cần phải làm cho đúng. Đây là nơi có một "Feynman" (tốt, một phần nhỏ của một người sẽ ổn) sẽ được đền đáp xứng đáng. Một công việc chính mà không dẫn đến một kiến ​​trúc tốt hơn có thể là một thảm họa. Toàn bộ hệ thống viết lại là nổi tiếng cho việc này.

Tiềm ẩn trong bất kỳ cách tiếp cận nào là biết cách phân biệt sự tình cờ của người khác với người thiết yếu - nghĩa là bạn cần phải có một kiến ​​trúc sư (hoặc đội ngũ kiến ​​trúc sư) thực sự hiểu hệ thống và mục đích của nó.

Đã nói tất cả, điều quan trọng đối với tôi là kiểm tra tự động . Nếu bạn có đủ của nó, hệ thống của bạn được kiểm soát. Nếu bạn không. . .

" Mọi thứ nên được làm đơn giản nhất có thể, nhưng không đơn giản hơn. "
- quy cho Albert Einstein

Hãy để tôi phác thảo thuật toán cá nhân của tôi để đối phó với sự phức tạp tình cờ.

1. Viết một câu chuyện người dùng hoặc trường hợp sử dụng. Đánh giá với chủ sở hữu sản phẩm.
2. Viết một bài kiểm tra tích hợp không thành công vì tính năng này không có ở đó. Xem lại với QA, hoặc kỹ sư trưởng, nếu có điều đó trong nhóm của bạn.
3. Viết bài kiểm tra đơn vị cho một số lớp có thể vượt qua bài kiểm tra tích hợp.
4. Viết việc thực hiện tối thiểu cho các lớp vượt qua các bài kiểm tra đơn vị.
5. Xem xét các bài kiểm tra đơn vị và thực hiện với một nhà phát triển đồng nghiệp. Chuyển đến Bước 3.

Toàn bộ phép thuật thiết kế sẽ có ở Bước 3: làm thế nào để bạn thiết lập các lớp đó? Điều này biến thành cùng một câu hỏi như: làm thế nào bạn tưởng tượng rằng bạn có một giải pháp cho vấn đề của bạn trước khi bạn có một giải pháp cho vấn đề của bạn?

Đáng chú ý, chỉ tưởng tượng bạn có giải pháp có vẻ là một trong những khuyến nghị chính người đã viết trên giải quyết vấn đề (gọi là "mơ tưởng" bởi Abelson và Sussman trong Cấu trúc và Giải thích chương trình máy tính và "làm việc lạc hậu" trong Polya của Làm thế nào để Giải quyết nó )

Mặt khác, không phải ai cũng có " sở thích về các giải pháp tưởng tượng " giống nhau : có những giải pháp mà chỉ bạn thấy thanh lịch, và có những giải pháp khác dễ hiểu hơn bởi đối tượng rộng hơn. Đó là lý do tại sao bạn cần đánh giá ngang hàng mã của mình với các nhà phát triển đồng nghiệp: không quá nhiều để điều chỉnh hiệu suất, nhưng để đồng ý về các giải pháp đã hiểu. Thông thường, điều này dẫn đến một thiết kế lại và, sau một số lần lặp lại, mã tốt hơn nhiều.

Nếu bạn gắn bó với việc viết các triển khai tối thiểu để vượt qua các bài kiểm tra của mình và viết các bài kiểm tra được nhiều người hiểu, bạn nên kết thúc với một cơ sở mã nơi chỉ còn lại sự phức tạp không thể khắc phục được .

Sự phức tạp tình cờ

Câu hỏi ban đầu (paraphrased) là:

Làm thế nào để các kiến ​​trúc sư quản lý sự phức tạp tình cờ trong các dự án phần mềm?

Sự phức tạp tình cờ phát sinh khi những người có định hướng trong dự án chọn nối thêm các công nghệ và đó là chiến lược tổng thể của các kiến ​​trúc sư ban đầu của dự án không có ý định đưa vào dự án. Vì lý do này, điều quan trọng là ghi lại lý do đằng sau sự lựa chọn trong chiến lược.

Sự phức tạp tình cờ có thể được ngăn chặn bởi sự lãnh đạo bám sát chiến lược ban đầu của họ cho đến khi sự cố tình rời khỏi chiến lược đó rõ ràng là cần thiết.

Tránh sự phức tạp không cần thiết

Dựa vào phần chính của câu hỏi, tôi sẽ viết lại nó như thế này:

Làm thế nào để các kiến ​​trúc sư quản lý sự phức tạp trong các dự án phần mềm?

Sự tái hiện này là phần apropos nhiều hơn cho phần chính của câu hỏi, khi đó thuật toán Feynman được đưa vào, cung cấp bối cảnh đề xuất rằng đối với các kiến ​​trúc sư giỏi nhất, khi gặp vấn đề, họ sẽ khéo léo xây dựng một giải pháp và từ đó họ khéo léo xây dựng một giải pháp và rằng phần còn lại của chúng tôi không thể hy vọng học được điều này. Có một sự hiểu biết phụ thuộc vào trí thông minh của đối tượng và sự sẵn lòng của họ để tìm hiểu các tính năng của các tùy chọn kiến ​​trúc có thể nằm trong phạm vi của họ.

Quá trình lập kế hoạch cho dự án sẽ sử dụng việc học của tổ chức để lập danh sách các yêu cầu của dự án, sau đó cố gắng xây dựng một danh sách tất cả các tùy chọn có thể, sau đó điều chỉnh các tùy chọn với các yêu cầu. Cử chỉ của chuyên gia cho phép anh ta làm điều này một cách nhanh chóng, và có lẽ với rất ít công việc rõ ràng, làm cho nó có vẻ dễ dàng đến với anh ta.

Tôi gửi cho bạn rằng nó đến với anh ta vì sự chuẩn bị của anh ta. Để có được cử chỉ của chuyên gia đòi hỏi phải làm quen với tất cả các lựa chọn của bạn và tầm nhìn xa để cung cấp giải pháp đơn giản cho phép các nhu cầu trong tương lai mà dự án cần xác định, cũng như linh hoạt để thích ứng với nhu cầu thay đổi của dự án. Sự chuẩn bị của Feynman là ông có hiểu biết sâu sắc về các phương pháp khác nhau trong cả toán học lý thuyết và ứng dụng và vật lý. Anh ta tò mò bẩm sinh, và đủ sáng để hiểu được những điều anh ta khám phá về thế giới tự nhiên xung quanh.

Kiến trúc sư công nghệ chuyên gia sẽ có một sự tò mò tương tự, dựa trên sự hiểu biết sâu sắc về các nguyên tắc cơ bản cũng như tiếp xúc rộng rãi với sự đa dạng lớn của công nghệ. Anh ấy (hoặc cô ấy) sẽ có trí tuệ để đưa ra các chiến lược đã thành công trên các lĩnh vực (như Nguyên tắc lập trình Unix ) và các chiến lược áp dụng cho các miền cụ thể (như mẫu thiết kế và hướng dẫn phong cách ). Anh ta có thể không am hiểu sâu sắc về mọi tài nguyên, nhưng anh ta sẽ biết nơi tìm tài nguyên.

Xây dựng giải pháp

Mức độ kiến ​​thức, hiểu biết và trí tuệ này có thể được rút ra từ kinh nghiệm và giáo dục, nhưng đòi hỏi trí thông minh và hoạt động tinh thần để kết hợp một giải pháp chiến lược mang tính kết hợp với nhau theo cách tránh sự phức tạp vô tình và không cần thiết. Nó đòi hỏi chuyên gia để đặt các nguyên tắc cơ bản này với nhau; đây là những công nhân tri thức mà Drucker đã thấy trước khi lần đầu tiên đặt ra thuật ngữ này.

Quay lại các câu hỏi cuối cùng cụ thể:

Các phương pháp cụ thể để chế ngự sự phức tạp tình cờ có thể được tìm thấy trong các loại nguồn sau đây.

• Nguyên tắc lập trình Unix
• Mẫu thiết kế
• và Hướng dẫn về Phong cách ( ví dụ PEP 8 của Python )

Theo nguyên tắc lập trình Unix sẽ giúp bạn tạo các chương trình mô-đun đơn giản hoạt động tốt và mạnh mẽ với các giao diện phổ biến. Các mẫu thiết kế sau sẽ giúp bạn xây dựng các thuật toán phức tạp không phức tạp hơn mức cần thiết. Theo Hướng dẫn về Phong cách sẽ đảm bảo mã của bạn có thể đọc được, có thể duy trì và tối ưu cho ngôn ngữ mà mã của bạn được viết. Các chuyên gia sẽ nội tâm hóa nhiều nguyên tắc được tìm thấy trong các tài nguyên này và sẽ có thể kết hợp chúng lại với nhau theo kiểu liền mạch gắn kết.

Đây có thể là một câu hỏi khó vài năm trước, nhưng IMO không còn khó để loại bỏ sự phức tạp tình cờ ngày nay.

Điều mà Kent Becksaid nói về bản thân, tại một số điểm: "Tôi không phải là một lập trình viên tuyệt vời; tôi chỉ là một lập trình viên giỏi với những thói quen tuyệt vời."

Hai điều đáng chú ý, IMO: anh ta coi mình là một lập trình viên , không phải là một kiến ​​trúc sư, và trọng tâm của anh ta là thói quen, không phải kiến ​​thức.

Cách giải quyết vấn đề khó khăn của Feynman là cách duy nhất để làm điều đó. Mô tả không nhất thiết phải rất dễ hiểu, vì vậy tôi sẽ mổ xẻ nó. Đầu của Feynman không chỉ chứa đầy kiến ​​thức, mà còn chứa đầy kỹ năng để áp dụng kiến ​​thức đó. Khi bạn có cả kiến ​​thức và kỹ năng để sử dụng nó, giải quyết một vấn đề khó không khó cũng không dễ. Đó là kết quả duy nhất có thể.

Có một cách viết mã sạch hoàn toàn phi ma thuật, không chứa sự phức tạp ngẫu nhiên và nó gần giống với những gì Feynman đã làm: thu thập tất cả kiến ​​thức cần thiết, đào tạo để làm quen với việc đưa nó vào hoạt động, thay vì bỏ đi ở một số góc của bộ não của bạn, sau đó viết mã sạch.

Bây giờ, nhiều lập trình viên thậm chí không nhận thức được tất cả các kiến ​​thức cần thiết để viết mã sạch. Các lập trình viên trẻ hơn có xu hướng loại bỏ kiến ​​thức về các thuật toán và cấu trúc dữ liệu và hầu hết các lập trình viên lớn tuổi có xu hướng quên nó. Hoặc ký hiệu O lớn và phân tích phức tạp. Các lập trình viên cũ có xu hướng loại bỏ các mẫu hoặc mùi mã - hoặc thậm chí không biết rằng chúng tồn tại. Hầu hết các lập trình viên thuộc bất kỳ thế hệ nào, ngay cả khi họ biết về các mẫu, không bao giờ nhớ chính xác khi nào nên sử dụng và trình điều khiển các bộ phận. Rất ít lập trình viên thuộc bất kỳ thế hệ nào liên tục đánh giá mã của họ theo các nguyên tắc RẮN. Nhiều lập trình viên trộn tất cả các mức độ trừu tượng có thể ở khắp mọi nơi. Hiện tại, tôi không biết về một lập trình viên đồng nghiệp, liên tục đánh giá mã của anh ta chống lại mùi hôi thối được mô tả bởi Fowler trong cuốn sách tái cấu trúc của anh ta. Mặc dù một số dự án sử dụng một số công cụ số liệu, số liệu được sử dụng nhiều nhất là độ phức tạp, loại này hay loại khác, trong khi hai số liệu khác - khớp nối và gắn kết - phần lớn bị bỏ qua, ngay cả khi chúng rất quan trọng đối với mã sạch. Một khía cạnh khác mà hầu hết mọi người bỏ qua là tải nhận thức. Rất ít lập trình viên coi các bài kiểm tra đơn vị là tài liệu, và thậm chí ít người biết rằng khó viết hoặc đặt tên cho các bài kiểm tra đơn vị là một mùi mã khác, thường chỉ ra bao thanh toán xấu. Một nhóm thiểu số nhỏ bé nhận thức được câu thần chú của thiết kế hướng tên miền để giữ cho mô hình mã và mô hình miền kinh doanh càng gần nhau càng tốt, vì sự khác biệt bị ràng buộc tạo ra vấn đề. Tất cả những điều này cần phải được xem xét, mọi lúc, nếu bạn muốn mã của mình sạch sẽ. Và nhiều hơn nữa mà tôi không thể nhớ ngay bây giờ. số liệu được sử dụng nhiều nhất là độ phức tạp, loại này hay loại khác, trong khi hai số liệu khác - khớp nối và gắn kết - phần lớn bị bỏ qua, ngay cả khi chúng rất quan trọng đối với mã sạch. Một khía cạnh khác mà hầu hết mọi người bỏ qua là tải nhận thức. Rất ít lập trình viên coi các bài kiểm tra đơn vị là tài liệu, và thậm chí ít người biết rằng khó viết hoặc đặt tên cho các bài kiểm tra đơn vị là một mùi mã khác, thường chỉ ra bao thanh toán xấu. Một nhóm thiểu số nhỏ bé nhận thức được câu thần chú của thiết kế hướng tên miền để giữ cho mô hình mã và mô hình miền kinh doanh càng gần nhau càng tốt, vì sự khác biệt bị ràng buộc tạo ra vấn đề. Tất cả những điều này cần phải được xem xét, mọi lúc, nếu bạn muốn mã của mình sạch sẽ. Và nhiều hơn nữa mà tôi không thể nhớ ngay bây giờ. số liệu được sử dụng nhiều nhất là độ phức tạp, loại này hay loại khác, trong khi hai số liệu khác - khớp nối và gắn kết - phần lớn bị bỏ qua, ngay cả khi chúng rất quan trọng đối với mã sạch. Một khía cạnh khác mà hầu hết mọi người bỏ qua là tải nhận thức. Rất ít lập trình viên coi các bài kiểm tra đơn vị là tài liệu, và thậm chí ít người biết rằng khó viết hoặc đặt tên cho các bài kiểm tra đơn vị là một mùi mã khác, thường chỉ ra bao thanh toán xấu. Một nhóm thiểu số nhỏ bé nhận thức được câu thần chú của thiết kế hướng tên miền để giữ cho mô hình mã và mô hình miền kinh doanh càng gần nhau càng tốt, vì sự khác biệt bị ràng buộc tạo ra vấn đề. Tất cả những điều này cần phải được xem xét, mọi lúc, nếu bạn muốn mã của mình sạch sẽ. Và nhiều hơn nữa mà tôi không thể nhớ ngay bây giờ. trong khi hai số liệu khác - khớp nối và gắn kết - ở một mức độ lớn bị bỏ qua, ngay cả khi chúng rất quan trọng đối với mã sạch. Một khía cạnh khác mà hầu hết mọi người bỏ qua là tải nhận thức. Rất ít lập trình viên coi các bài kiểm tra đơn vị là tài liệu, và thậm chí ít người biết rằng khó viết hoặc đặt tên cho các bài kiểm tra đơn vị là một mùi mã khác, thường chỉ ra bao thanh toán xấu. Một nhóm thiểu số nhỏ bé nhận thức được câu thần chú của thiết kế hướng tên miền để giữ cho mô hình mã và mô hình miền kinh doanh càng gần nhau càng tốt, vì sự khác biệt bị ràng buộc tạo ra vấn đề. Tất cả những điều này cần phải được xem xét, mọi lúc, nếu bạn muốn mã của mình sạch sẽ. Và nhiều hơn nữa mà tôi không thể nhớ ngay bây giờ. trong khi hai số liệu khác - khớp nối và gắn kết - ở một mức độ lớn bị bỏ qua, ngay cả khi chúng rất quan trọng đối với mã sạch. Một khía cạnh khác mà hầu hết mọi người bỏ qua là tải nhận thức. Rất ít lập trình viên coi các bài kiểm tra đơn vị là tài liệu, và thậm chí ít người biết rằng khó viết hoặc đặt tên cho các bài kiểm tra đơn vị là một mùi mã khác, thường chỉ ra bao thanh toán xấu. Một nhóm thiểu số nhỏ bé nhận thức được câu thần chú của thiết kế hướng tên miền để giữ cho mô hình mã và mô hình miền doanh nghiệp càng gần nhau càng tốt, vì sự khác biệt bị ràng buộc tạo ra vấn đề. Tất cả những điều này cần phải được xem xét, mọi lúc, nếu bạn muốn mã của mình sạch sẽ. Và nhiều hơn nữa mà tôi không thể nhớ ngay bây giờ. Một khía cạnh khác mà hầu hết mọi người bỏ qua là tải nhận thức. Rất ít lập trình viên coi các bài kiểm tra đơn vị là tài liệu, và thậm chí ít người biết rằng khó viết hoặc đặt tên cho các bài kiểm tra đơn vị là một mùi mã khác, thường chỉ ra bao thanh toán xấu. Một nhóm thiểu số nhỏ bé nhận thức được câu thần chú của thiết kế hướng tên miền để giữ cho mô hình mã và mô hình miền kinh doanh càng gần nhau càng tốt, vì sự khác biệt bị ràng buộc tạo ra vấn đề. Tất cả những điều này cần phải được xem xét, mọi lúc, nếu bạn muốn mã của mình sạch sẽ. Và nhiều hơn nữa mà tôi không thể nhớ ngay bây giờ. Một khía cạnh khác mà hầu hết mọi người bỏ qua là tải nhận thức. Rất ít lập trình viên coi các bài kiểm tra đơn vị là tài liệu, và thậm chí ít người biết rằng khó viết hoặc đặt tên bài kiểm tra đơn vị là một mùi mã khác, thường chỉ ra bao thanh toán xấu. Một nhóm thiểu số nhỏ bé nhận thức được câu thần chú của thiết kế hướng tên miền để giữ cho mô hình mã và mô hình miền doanh nghiệp càng gần nhau càng tốt, vì sự khác biệt bị ràng buộc tạo ra vấn đề. Tất cả những điều này cần phải được xem xét, mọi lúc, nếu bạn muốn mã của mình sạch sẽ. Và nhiều hơn nữa mà tôi không thể nhớ ngay bây giờ. câu thần chú để giữ cho mô hình mã và mô hình miền doanh nghiệp càng gần nhau càng tốt, vì sự khác biệt bị ràng buộc để tạo ra các vấn đề trên đường. Tất cả những điều này cần được xem xét, mọi lúc, nếu bạn muốn mã của mình sạch sẽ. Và nhiều hơn nữa mà tôi không thể nhớ ngay bây giờ. câu thần chú để giữ cho mô hình mã và mô hình miền doanh nghiệp càng gần nhau càng tốt, vì sự khác biệt bị ràng buộc để tạo ra các vấn đề trên đường. Tất cả những điều này cần được xem xét, mọi lúc, nếu bạn muốn mã của mình sạch sẽ. Và nhiều hơn nữa mà tôi không thể nhớ ngay bây giờ.

Bạn muốn viết mã sạch? Không có phép thuật cần thiết. Chỉ cần tìm hiểu tất cả những gì cần thiết, sau đó sử dụng nó để đánh giá mức độ sạch của mã của bạn và tái cấu trúc cho đến khi bạn hài lòng. Và tiếp tục học hỏi - phần mềm vẫn là một lĩnh vực non trẻ, và những hiểu biết và kiến ​​thức mới được tiếp thu với tốc độ nhanh.