6 bài học tôi học được từ việc phát triển Dự án nguồn mở

Quan điểm của một nhà khoa học dữ liệu

Nguồn mở là một khái niệm tuyệt vời! Bằng cách tập hợp các nguồn, kỹ năng và kiến ​​thức của toàn bộ cộng đồng, chúng ta có thể tạo ra các công cụ mà chúng ta không thể tạo ra một cách riêng lẻ. Các công cụ tạo ra từ sự hợp tác này thực sự mang lại nhiều lợi ích hơn là tổng các bộ phận của chúng.

Do đó, các nhà khoa học dữ liệu của chúng tôi sử dụng phần mềm có sẵn miễn phí này, phần mềm đang thúc đẩy rất nhiều công nghệ trong khi vẫn có cơ hội tham gia vào quá trình phát triển của nó.

Trong vài năm qua, tôi đã may mắn được tham gia vào lĩnh vực nguồn mở và có cơ hội phát triển và quản lý một số gói!

Phát triển nguồn mở không chỉ là mã hóa

Trong thời gian này, có rất nhiều trở ngại phải vượt qua và những bài học cần rút ra. Từ các phần phụ thuộc phức tạp và các lựa chọn thiết kế API cho đến giao tiếp với cơ sở người dùng.

Làm việc trên nguồn mở, dù với tư cách là tác giả, người bảo trì hay nhà phát triển, có thể khá khó khăn! Với bài viết này, tôi chia sẻ một số kinh nghiệm của mình trong lĩnh vực này, hy vọng sẽ giúp ích cho những ai muốn phát triển nguồn mở.

Khi bạn tạo phần mềm nguồn mở, bạn thường không tạo gói dành riêng cho chính mình. Người dùng, từ mọi nguồn gốc khác nhau, sẽ sử dụng phần mềm của bạn. Tài liệu phù hợp sẽ giúp ích rất nhiều cho những người dùng đó khi bắt đầu.

Tuy nhiên, đừng đánh giá thấp tác động của tài liệu đối với khả năng sử dụng gói hàng của bạn! Bạn có thể sử dụng nó để giải thích các thuật toán phức tạp, đưa ra hướng dẫn mở rộng, hiển thị các trường hợp sử dụng và thậm chí cho phép đưa ra các ví dụ tương tác.

Đặc biệt là phần mềm liên quan đến khoa học dữ liệu có thể khó hiểu khi liên quan đến các thuật toán phức tạp. Việc tiếp cận những lời giải thích này như một câu chuyện thường giúp tôi làm cho chúng trở nên trực quan hơn.

Hãy tin tôi, viết tài liệu tốt bản thân nó đã là một kỹ năng.

Một lợi ích khác là việc viết tài liệu chắc chắn sẽ giảm thời gian dành cho các vấn đề. Sẽ có ít lý do hơn để người dùng đặt câu hỏi nếu họ có thể tìm thấy câu trả lời trong tài liệu của bạn.

Tuy nhiên, việc tạo tài liệu không chỉ đơn thuần là viết nó. Trực quan hóa thuật toán hoặc phần mềm của bạn sẽ giúp ích rất nhiều trong việc làm cho nó trở nên trực quan. Bạn có thể học được khá nhiều điều từ Jay Alammar khi bạn muốn trực quan hóa các nguyên tắc thuật toán trong tài liệu của mình. Hình dung của anh ấy thậm chí còn xuất hiện trong chính thức numpy tài liệu!

Cơ sở người dùng của bạn, cộng đồng, là một thành phần quan trọng trong phần mềm của bạn. Vì chúng tôi đang phát triển nguồn mở nên có thể nói rằng chúng tôi muốn họ tham gia vào quá trình phát triển.

Bằng cách tương tác với cộng đồng, bạn lôi kéo họ chia sẻ các vấn đề và lỗi, đồng thời đưa ra các yêu cầu và ý tưởng tuyệt vời để phát triển hơn nữa! Tất cả những điều này giúp ích trong việc tạo ra thứ gì đó cho họ.

Cộng đồng nguồn mở thực sự không chỉ là tổng số các phần của nó

Nhiều tính năng cốt lõi trong BERTopic, như mô hình chủ đề trực tuyến, đã được triển khai vì chúng được người dùng yêu cầu cao. Do đó, cộng đồng này khá tích cực và đã giúp ích rất nhiều trong việc phát hiện các vấn đề và phát triển các tính năng mới.

Cho dù gói của bạn sẽ được sử dụng hàng triệu lần hay chỉ một vài lần thì việc tạo một gói là cơ hội tuyệt vời để tìm hiểu thêm về nguồn mở, MLOps, thử nghiệm đơn vị, thiết kế API, v.v. Tôi đã học được nhiều hơn về những kỹ năng này trong việc phát triển nguồn mở hơn những gì tôi có thể làm trong công việc hàng ngày của mình.

Ngoài ra còn có cơ hội học hỏi rất lớn từ việc tương tác với chính cộng đồng. Họ là những người cho bạn biết họ thích hay không thích thiết kế nào. Đôi khi, tôi đã thấy vấn đề tương tự xuất hiện nhiều lần trong vài tháng. Điều này cho thấy tôi nên suy nghĩ lại về thiết kế vì nó không thân thiện với người dùng như tôi mong đợi!

Hơn hết, việc phát triển các dự án nguồn mở đã cho tôi cơ hội cộng tác với các nhà phát triển khác.

Làm việc trên các dự án nguồn mở của riêng bạn ngoài công việc sẽ có những nhược điểm. Đối với tôi, điều quan trọng nhất là việc duy trì gói, trả lời các câu hỏi và tham gia thảo luận có thể tốn khá nhiều công sức.

Nó chắc chắn sẽ hữu ích nếu bạn có động lực nội tại nhưng vẫn mất khá nhiều thời gian để đảm bảo mọi thứ được gắn kết với nhau.

May mắn thay, bạn có thể nhờ cộng đồng của mình trợ giúp khi trả lời các câu hỏi, giới thiệu các trường hợp sử dụng, v.v.

Trong vài năm qua, tôi đã học được cách thoải mái hơn một chút khi nói đến những thay đổi đột phá. Đặc biệt là khi liên quan đến sự phụ thuộc, đôi khi bạn có thể làm được rất nhiều việc!

Biết tần suất sử dụng gói của bạn sẽ giúp ích rất nhiều trong việc hiểu mức độ phổ biến của nó. Tuy nhiên, nhiều người vẫn đang sử dụng sao Github để đánh giá chất lượng và mức độ phổ biến của một gói.

Với tư cách là nhà khoa học dữ liệu, trước tiên chúng ta phải hiểu chính xác những gì chúng ta đang đo lường. Các ngôi sao GitHub không gì khác hơn là một người dùng tặng một ngôi sao cho một gói hàng. Điều đó thậm chí không có nghĩa là họ đã sử dụng phần mềm hoặc nó thực sự đang hoạt động!

Về mặt kỹ thuật, tôi có thể trả tiền cho hàng nghìn người để bắt đầu các repo của mình. Thay vào đó, tôi tập trung vào nhiều số liệu thống kê khác nhau, như lượt tải xuống và lượt chia sẻ, cũng như số lượng vấn đề tôi gặp phải hàng ngày.

Ví dụ: thật tuyệt nếu gói hàng của bạn được giới thiệu trên Hacker Tin tức nhưng nó không cho bạn biết liệu nó có được sử dụng nhất quán hay không.

Là một nhà tâm lý học, tôi có xu hướng tập trung nhiều vào việc thiết kế bao bì của mình. Điều này bao gồm những thứ như tài liệu và hướng dẫn nhưng nó thậm chí còn dịch sang cách tôi viết mã.

Việc đảm bảo rằng gói dễ sử dụng và cài đặt sẽ giúp việc áp dụng đơn giản hơn nhiều. Đặc biệt là khi bạn tập trung vào các triết lý thiết kế như tính mô-đun và tính minh bạch, một số gói sẽ trở thành một lựa chọn tuyệt vời để sử dụng.

Sử dụng quan điểm của một nhà tâm lý học trong khi phát triển các tính năng mới đã giúp việc biết cần tập trung vào điều gì trở nên dễ dàng hơn nhiều. Người dùng đang tìm kiếm điều gì? Làm cách nào tôi có thể viết mã theo cách giải thích thuật toán? Tại sao người dùng thực sự sử dụng gói này? Nhược điểm chính của mã của tôi là gì?

Dành thời gian để hiểu mức độ chấp nhận của người dùng trung bình

Tất cả những điều trên thường dẫn đến một quy tắc cơ bản nhưng quan trọng;
Giữ nó siêu đơn giản

Cá nhân tôi, nếu tôi thấy một gói mới khó cài đặt và sử dụng, tôi sẽ ít có khả năng áp dụng gói đó vào quy trình làm việc của mình.

Nếu bạn cũng giống tôi, đam mê AI, Khoa học dữ liệu hoặc Tâm lý học, vui lòng thêm tôi vào LinkedIn hoặc theo dõi tôi trên Twitter. Bạn cũng có thể tìm thấy một số nội dung của tôi trên Trang web cá nhân.

Tất cả hình ảnh không ghi nguồn đều do tác giả tạo ra

6 bài học tôi học được từ việc phát triển các Dự án nguồn mở được xuất bản lại từ nguồn https://towardsdatascience.com/6-lessons-i-learned-from-developing-open-source-projects-4617e26f247c?source=rss—-7f60cf5620c9—4 qua https://towardsdatascience.com/feed

<!–

->