Phần mềm khám phá: Đạt được sự cân bằng trong khám phá

Tôi đã làm việc trong lĩnh vực nghiên cứu cả đời nên tôi biết có khuôn mẫu cho rằng các nhà nghiên cứu viết mã xấu (ví dụ: xem tại đây , tại đây hoặc tại đây ). Nhưng tôi nghĩ: chúng ta có thể sửa nó, phải không? Vì vậy, nhiều lần tôi đã cố gắng thiết kế các khuôn khổ nghiên cứu tốt đẹp. Tôi đã cố gắng đưa vào các giao diện và tạo ra những hình ảnh trừu tượng đẹp mắt bằng cách sử dụng các sách và blog về kỹ thuật phần mềm mà tôi thích đọc.

Nhưng hết lần này đến lần khác, mọi nỗ lực đó đều vô ích. Phần lớn phần mềm nghiên cứu mà tôi làm chưa bao giờ được đưa vào sản xuất (mặc dù một số đã làm được). Sẽ rất tốt cho sức khỏe tinh thần của tôi nếu ai đó nói với tôi một sự thật đơn giản: việc chết mã nghiên cứu thực sự là điều đáng lẽ phải xảy ra . Các nhà nghiên cứu không nên dành nhiều thời gian để thiết kế nó ngay từ đầu.

Các kỹ sư phần mềm chuyên nghiệp luôn coi thường những nhà nghiên cứu không sử dụng các phương pháp thực hành phần mềm tốt nhất. Có một số bài đăng đang cố gắng nâng cao tiêu chuẩn mã nghiên cứu (ví dụ: bài đăng tuyệt vời này và sổ tay mã nghiên cứu ). Nhưng bài đăng này lại đi ngược lại: nó lập luận cách không lạm dụng các phương pháp thực hành phần mềm tốt nhất và thay vào đó chỉ đầu tư vào việc khám phá nhanh. Nó được nhắm mục tiêu cho các công ty định hướng nghiên cứu, nơi mục tiêu của bạn là thử nghiệm nhiều ý tưởng một cách nhanh chóng.

1. Nhận một số khoản nợ công nghệ chiến lược

Một dự án nghiên cứu thành công tại một công ty có hai giai đoạn: thăm dò và khai thác. Trong quá trình “khám phá”, bạn muốn thử càng nhiều giải pháp đa dạng càng tốt. Trong quá trình “khai thác”, bạn phải củng cố giải pháp tốt nhất và biến nó thành một sản phẩm hữu ích.

Thực hành phần mềm tối ưu khá khác nhau giữa hai loại này. Đó là lý do tại sao các công ty thường có bộ phận nghiên cứu và sản phẩm riêng biệt. Tất cả những cuốn sách bạn thường đọc về thiết kế phần mềm chủ yếu nói về giai đoạn "khai thác" thứ hai. Trong giai đoạn này, bạn đang xây dựng nền tảng cho một sản phẩm có thể mở rộng. Đây là nơi chứa tất cả các mẫu thiết kế: API đẹp, ghi nhật ký, xử lý lỗi, v.v.

Nhưng trong giai đoạn “thăm dò” đầu tiên, bạn không xây dựng những nền móng tồn tại mãi mãi. Trên thực tế, nếu phần lớn nỗ lực của bạn vẫn tồn tại thì bạn (theo định nghĩa) đã chưa khám phá đủ.

Nhiều thực tiễn trong bài đăng này là ví dụ về những gì thường trở thành “nợ công nghệ”. Đó là những gì bạn nhận được bằng cách không viết mã trừu tượng rõ ràng có thể tái sử dụng. Nợ có phải lúc nào cũng xấu không? Chúng ta không bao giờ muốn vay tiền hay thế chấp, nhưng vay tiền thường là một chiến lược tốt trong cuộc sống. Bạn có thể mắc nợ để đi nhanh và thu lợi nhuận sau này.

Tương tự, nếu không mắc nợ kỹ thuật, bạn có thể đang làm chậm quá trình nghiên cứu của mình. Tin tốt là phần lớn thời gian bạn không phải trả lại. Hầu hết mã nghiên cứu của bạn đều có khả năng bị chết. Vì vậy, trung bình, bạn sẽ không phải gánh toàn bộ khoản nợ công nghệ mà mình đã gánh.

Trường hợp chống lại việc sử dụng lại mã

Nhiều kiến trúc phần mềm và kỹ thuật tái cấu trúc được định hướng cụ thể để cải thiện khả năng sử dụng lại mã. Có những nhược điểm chung đối với việc sử dụng lại mã. Nhưng trong sản xuất, chúng lại bị đánh giá cao bởi những lợi ích nổi tiếng (ví dụ: xem bài đăng điển hình này ). Trong các dự án nghiên cứu, phần lớn mã sẽ chìm vào quên lãng. Việc cố gắng sử dụng lại mã thực sự có thể làm bạn chậm lại.

Hạn chế sử dụng lại mã là loại nợ kỹ thuật được phép thực hiện trong nghiên cứu. Có một số kiểu tái sử dụng mã mà tôi muốn thảo luận: thêm phần phụ thuộc không cần thiết, sao chép mã, duy trì nhiều mã nghiên cứu được chia sẻ, đầu tư thiết kế sớm.

Hãy suy nghĩ kỹ trước khi nhập một cái gì đó mới

Nếu bạn biết một thư viện phiên bản được bảo trì tốt sẽ giúp bạn tăng tốc - hãy sử dụng nó! Nhưng trước khi bắt đầu một sự phụ thuộc mới, hãy thử đưa ra đánh giá xem liệu điều đó có xứng đáng hay không. Mỗi cái bổ sung sẽ đưa bạn đến gần hơn với địa ngục phụ thuộc. Nó khiến bạn phải đầu tư thời gian vào việc học và khắc phục sự cố. Xem thêm những cạm bẫy của sự phụ thuộc trong bài viết ngắn gọn này.

Có lẽ sẽ ổn nếu phụ thuộc vào điều gì đó nếu:

• bạn đã sử dụng nó rồi, không có gì nhiều để tìm hiểu, nó có cộng đồng lớn, tài liệu và bài kiểm tra tốt
• nó được phiên bản, dễ cài đặt
• và cuối cùng, không có cách nào bạn có thể tự mình thực hiện được.

• 
  

Nhưng hãy cảnh giác với sự phụ thuộc nếu:

• bạn không thể tìm ra cách sử dụng nó một cách nhanh chóng, nó rất mới (hoặc rất cũ) hoặc dường như không ai biết về nó; không có tài liệu hay bài kiểm tra nào

• nó là từ monorepo của bạn và liên tục được các nhóm khác thay đổi

• nó kéo theo nhiều phụ thuộc và công cụ khác; hoặc nó khó cài đặt

• và cuối cùng, bạn cảm thấy rằng bạn (hoặc một số LLM) có thể viết mã này sau vài giờ.

  
  

Thay vì phụ thuộc rõ ràng, bạn có thể làm theo một câu tục ngữ hay về cờ vây: “ sao chép một chút vẫn tốt hơn phụ thuộc một chút ", đó là chủ đề tiếp theo của chúng ta.

Copypaste cho phép bạn tự do thử nghiệm

Một số người nói rằng “ sao chép-dán là bất hợp pháp ”. Nhưng thật ngạc nhiên, tôi thấy mình thường xuyên tranh luận ủng hộ nó. Copypaste có thể là lựa chọn tối ưu trong giai đoạn thăm dò.

Nếu bạn phụ thuộc vào một hàm được sử dụng nhiều từ một phần khác của cơ sở mã, bạn có thể quên việc dễ dàng thay đổi nó. Bạn có thể làm hỏng thứ gì đó cho ai đó và phải dành thời gian quý báu để xem xét và sửa lỗi mã. Nhưng nếu bạn sao chép và dán mã cần thiết vào thư mục của mình, bạn có thể tự do làm bất cứ điều gì bạn muốn với nó. Đây là một vấn đề lớn trong các dự án nghiên cứu nơi thử nghiệm là một chuẩn mực chứ không phải là một ngoại lệ. Đặc biệt nếu bạn không chắc chắn liệu những thay đổi có hữu ích cho mọi người hay không.

Tôi thấy rằng các cơ sở mã deep learning phù hợp nhất cho việc sao chép. Thông thường, số lượng mã cần thiết để mô tả một mô hình và quá trình đào tạo của nó không quá lớn. Nhưng đồng thời nó có thể rất sắc thái và khó khái quát hóa. Các tập lệnh đào tạo có thể chia sẻ có xu hướng phát triển đến kích thước không thể quản lý được: ví dụ: Huấn luyện viên transformers Ôm mặt có +4k dòng. Điều thú vị là các máy biến áp đã chọn sao chép ở cấp độ mô hình. Vui lòng xem bài đăng của họ để biết lý do đằng sau chính sách "mô hình tệp đơn" của họ. Xem thêm tài nguyên về vẻ đẹp của copypaste ở cuối.

Một giải pháp thay thế cho copypaste là ở trên một nhánh. Nhưng tôi cảm thấy nó mang lại quá nhiều gánh nặng cho tinh thần đồng đội. Ngoài ra, tôi còn tìm thấy thêm một số bài viết về vẻ đẹp của copypaste - xem thêm các bài viết ở phần kết luận.

Duy trì mã nghiên cứu được chia sẻ là khó

Việc duy trì mã chia sẻ được sử dụng nhiều đòi hỏi rất nhiều công việc. Hãy xem số dòng tệp torch.nn.Module được vẽ dựa trên phiên bản Pytorch . Bạn có thể thấy rằng ngay cả những nhóm nghiên cứu tiên tiến nhất cũng phải vật lộn để kiểm soát sự phức tạp.

Đừng đánh giá thấp thời gian và nguồn lực cần thiết để duy trì mã nghiên cứu được chia sẻ lớn. Thư viện nghiên cứu càng được sử dụng nhiều thì nó càng trở nên phức tạp. Quá trình này diễn ra nhanh hơn so với một thư viện thông thường vì mỗi hướng nghiên cứu đều có cách sử dụng hơi khác nhau. Thiết lập các quy tắc rất nghiêm ngặt về những gì có thể được đóng góp trở lại. Nếu không, mã chia sẻ sẽ trở nên mỏng manh và phát triển quá mức với hàng loạt tùy chọn, tối ưu hóa nhiều lỗi và các trường hợp biên. Vì phần lớn mã nghiên cứu đã hết nên tất cả sự phức tạp tăng thêm này sẽ không bao giờ được sử dụng nữa. Việc bỏ đi một số mã được chia sẻ của bạn sẽ giúp bạn có thêm thời gian để thực hiện nghiên cứu thực tế.

Thiết kế để khám phá, không phải để tái sử dụng mã

Có một phần sự thật là bạn không muốn chứng minh mã của mình quá nhiều trong tương lai ngay cả trong quá trình sản xuất. Cố gắng thực hiện giải pháp đơn giản nhất có thể đáp ứng được yêu cầu. Nhưng trong mã sản xuất luôn có các khía cạnh về khả năng bảo trì cần được xem xét. Ví dụ: xử lý lỗi, tốc độ, ghi nhật ký, mô-đun hóa là những gì bạn thường cần nghĩ tới.

Trong mã nghiên cứu, không có vấn đề nào trong số đó. Bạn chỉ muốn nhanh chóng chứng minh rằng một ý tưởng là tốt hay xấu theo cách nhanh nhất có thể và tiếp tục. Vì vậy, sự đơn giản khó đạt được mà không cần bất kỳ mô-đun hoặc API nào là hoàn toàn ổn!

Đừng lãng phí thời gian quý báu vào việc đầu tư phần mềm sớm như:

• tạo giao diện thành phần quá sớm trong dự án. Bạn sẽ mất quá nhiều thời gian để phù hợp với những ràng buộc nhân tạo tự tạo
• tối ưu hóa cơ sở hạ tầng đào tạo deep learning trước khi cam kết sử dụng giải pháp deep learning
• sử dụng hệ thống cấu hình/nhà máy/tuần tự hóa sản xuất hoặc các lớp cơ sở. Thông thường, bạn không cần chức năng của chúng trong quá trình tạo mẫu
• hệ thống kiểm tra kiểu và linting quá nghiêm ngặt. Không có lý do gì để làm chậm lại mã nghiên cứu vứt đi đang thay đổi nhanh chóng.

2. Đầu tư vào thăm dò nhanh

Mục tiêu của một dự án nghiên cứu là tìm ra một giải pháp mới. Không ai biết (theo định nghĩa) nó trông như thế nào. Nó giống như một quá trình tối ưu hóa trong bối cảnh nghiên cứu phức tạp với lượng thông tin hạn chế. Để tìm mức tối thiểu tốt, bạn cần thử nhiều đường đi, nhận ra đường đi tốt và xấu và không bị mắc kẹt trong cực tiểu cục bộ. Để thực hiện tất cả những việc đó một cách nhanh chóng, đôi khi bạn cần đầu tư vào phần mềm thay vì vay nợ công nghệ.

Tăng tốc các đường dẫn chung

Có một số con đường nghiên cứu khác nhau mà bạn muốn thử. Có thiết kế, thư viện hoặc sự tối ưu hóa nào có thể giảm bớt thời gian cho phần lớn các đường dẫn không? Bạn nên cẩn thận để không thiết kế quá kỹ bất cứ thứ gì vì không phải lúc nào bạn cũng biết tất cả các ý tưởng mình sắp thử. Điều này rất tùy chỉnh đối với mọi dự án, nhưng đây là một số ví dụ:

• nếu bạn đào tạo mạng lưới sâu, hãy đầu tư vào cơ sở hạ tầng đào tạo. Tìm ra các siêu tham số cho phép bạn hội tụ trong quá trình đào tạo một cách nhanh chóng và đáng tin cậy
• nếu mỗi thử nghiệm yêu cầu bạn sử dụng một mô hình khác nhau, hãy tìm ra cách bạn có thể nhanh chóng hoán đổi chúng (ví dụ: bằng cách sử dụng hệ thống nhà máy đơn giản hoặc chỉ cần sao chép)
• nếu mọi thử nghiệm có quá nhiều tham số và khó quản lý, hãy đầu tư vào thư viện cấu hình đẹp.

Phân nhánh nhanh chóng

Các nhà nghiên cứu phải có khả năng đề xuất những ý tưởng đa dạng mới một cách nhanh chóng. Nó có vẻ dễ dàng khi bắt đầu dự án. Nhưng sau đó nó dần dần trở nên khó khăn hơn khi mọi người cố thủ trong con đường nghiên cứu yêu thích của họ. Để giải quyết vấn đề này, những thay đổi về văn hóa và tổ chức là điều cần thiết. Cần có một quá trình dừng những nghiên cứu không hứa hẹn trước khi đổ quá nhiều tiền bạc và cảm xúc vào đó. Những ngày giới thiệu thường xuyên và các buổi đánh giá kỹ thuật ngang hàng có thể đóng vai trò là chiến lược hiệu quả cho mục đích này. Điều quan trọng nữa là tìm được sự cân bằng giữa việc mọi người thực hiện một ý tưởng mới và việc hoàn tất các dự án hiện tại một cách hợp lý.

Nhưng đây là một bài viết về phần mềm, vì vậy đây là một số cách thực hành để giúp việc phân nhánh các dự án mới trở nên dễ dàng:

• giữ cho mã đánh giá không bị vướng vào các thuật toán. Đánh giá thường ổn định hơn hướng nghiên cứu
• hãy bắt đầu một dự án mới từ một bảng trống, nhưng sau đó hãy chú ý xem thành phần nào được sử dụng lại. Mô-đun hóa và dọn dẹp chúng là một khoản đầu tư tốt
• trong một dự án nghiên cứu mới, trước tiên hãy triển khai thành phần sáng tạo và rủi ro nhất. Làm như vậy sẽ xác định được phần lớn các vướng mắc trong thiết kế phần mềm trong tương lai.

Tăng tỷ lệ tín hiệu trên nhiễu

Mã ồn ào và nhiều lỗi khiến kết quả trở nên mơ hồ và không có tính thuyết phục đến mức toàn bộ dự án sẽ lãng phí thời gian. Mặc dù không nên thiết kế kỹ lưỡng mọi thứ, nhưng bạn có thể dễ dàng làm theo các quy tắc kinh nghiệm đơn giản sau để tránh mã lộn xộn:

• 
  

• tránh mã có tác dụng phụ

• mặc định cho các hàm hơn là các lớp; và với các lớp, thích đóng gói hơn là kế thừa

• giảm thiểu độ dài của các hàm/lớp/mô-đun; giảm thiểu số lượng câu lệnh if

• biết rõ về python nhưng sử dụng các kỹ thuật đơn giản. Chống lại sự cám dỗ đi sâu vào trí tuệ của siêu lớp, trang trí và lập trình chức năng.

  
  

Phần mềm tạo ra các kết quả khác nhau trong các lần chạy khác nhau rất khó sử dụng. Nếu bạn đưa ra một quyết định quan trọng nhưng sai lầm dựa trên một hạt giống không may mắn, bạn sẽ lãng phí rất nhiều thời gian để phục hồi. Dưới đây là một số mẹo khi xử lý phần mềm không xác định:

• hiểu liệu tiếng ồn đến từ thuật toán hay do đánh giá. Các nguồn tiếng ồn phức tạp và bạn nên cố gắng đánh giá một cách hoàn toàn xác định.
• đừng ngừng tìm kiếm các nguồn ngẫu nhiên cho đến khi bạn thực sự có được một tập lệnh có thể tái tạo. Hãy nhớ rằng sau khi tìm thấy tất cả các hạt giống ngẫu nhiên, nhiễu có thể đến từ dữ liệu hoặc từ các hàm chung có tác dụng phụ.
• thay đổi hạt giống và xác định phương sai cơ bản của kết quả của bạn. Đừng đưa ra quyết định về những kết quả không có ý nghĩa thống kê.

Phần kết luận

Điểm mấu chốt xuất phát từ bài đăng này về mã nghiên cứu:

“Bạn không cần bận tâm đến [thiết kế phần mềm tốt] vì mã không phải là vấn đề. Mã là một công cụ giúp bạn có được câu trả lời mà bạn cần” .

Điều cực kỳ quan trọng là phải có nền tảng mã hóa tuyệt vời. Nhưng suy cho cùng, việc khám phá và sản phẩm thực sự hữu ích mới là điều quan trọng. Nếu bạn sử dụng quá nhiều phần mềm sản xuất trong nghiên cứu, bạn sẽ lãng phí thời gian cần thiết để khám phá điều gì đó mới mẻ. Thay vào đó, hãy tìm xem điều gì đang làm chậm quá trình khám phá của bạn. Tăng tốc quá trình nghiên cứu bằng cách đầu tư vào phân nhánh nhanh, rút ngắn thời gian để đạt được kết quả và làm sạch mã không ồn ào.

Sẽ thật điên rồ nếu tranh luận hoàn toàn về việc sử dụng lại mã. Tôi chỉ muốn chỉ ra rằng việc tái sử dụng mã phải là một hoạt động cân bằng. Trong nghiên cứu, tỷ lệ mã vứt đi lớn hơn trong sản xuất. Cân nghiêng hơn nữa để chống lại việc tái sử dụng. Dưới đây là một số bài viết hay hơn với những cạm bẫy khi sử dụng lại mã:

• Mã có thể tái sử dụng: Tốt, Xấu và Xấu

• Khi việc lặp lại chính mình là điều hợp lý

• StackExchange cân bằng với ưu và nhược điểm của việc tái sử dụng

  
  

Và đây là một số bài viết khác tranh luận về cách thực hành sao chép:

• Copypaste có thực sự là một vấn đề?

• Khi nào bạn nên sao chép-dán mã?

• Mặt tốt và mặt xấu của lập trình sao chép-dán

• "Là học sinh cuối cấp với 5 YOE, tôi cảm thấy một phần tiền lương của mình là biết nên sao chép mã nào haha"

  
  

Cảm ơn bạn đã đọc! Tôi cảm thấy có một số chi tiết gây tranh cãi, vui lòng cho tôi biết trong phần bình luận!