Phát hành một dự án nguồn mở mà không bị bối rối [đóng]


51

Tôi đã làm việc một mình trong một dự án nguồn mở khá lớn trong một thời gian dài và nó gần đến điểm mà tôi muốn phát hành nó. Tuy nhiên, tôi tự học và tôi thực sự không biết ai có thể xem xét đầy đủ dự án của tôi.

Một vài năm trước, tôi đã phát hành một đoạn mã nhỏ mà gần như đã bị xé toạc (theo nghĩa quan trọng) trên diễn đàn nơi tôi phát hành nó. Mặc dù mã đã hoạt động, những lời chỉ trích là chính xác nhưng tàn bạo. Nó thôi thúc tôi bắt đầu tìm kiếm các thực tiễn tốt nhất cho mọi thứ và cuối cùng tôi cảm thấy rằng nó làm cho tôi trở thành một nhà phát triển tốt hơn nhiều. Tôi đã đi qua tất cả mọi thứ trong dự án của mình rất nhiều lần cố gắng làm cho nó hoàn hảo đến nỗi tôi đã mất hết tính.

Tôi tin vào dự án của mình và nghĩ rằng nó có khả năng giúp đỡ rất nhiều người và tôi cảm thấy như mình đã thực hiện một số điều thú vị theo những cách thú vị với nó. Tuy nhiên, vì tôi tự học, tôi không thể không tự hỏi những khoảng trống tồn tại trong quá trình tự học của mình. Cách mã của tôi bị xé toạc lần trước không phải là điều tôi muốn lặp lại. Tôi nghĩ rằng hai nỗi sợ hãi lớn nhất của tôi khi phát hành dự án của mình mà tôi đã đổ vô số giờ vào đó là hoàn toàn xấu hổ vì tôi đã bỏ lỡ một số điều rõ ràng rõ ràng vì sự tự học của tôi hoặc tệ hơn là phát hành nó ra tiếng dế.

Có ai đã ở trong một tình huống tương tự? Tôi không sợ những lời chỉ trích mang tính xây dựng, miễn là nó mang tính xây dựng và không chỉ là một lời ca ngợi về cách tôi làm hỏng việc. Tôi biết có một trang web đánh giá mã trên StackExchange, nhưng nó không thực sự được thiết lập cho các dự án lớn và tôi không cảm thấy cộng đồng ở đó đủ lớn để nhận được phản hồi tốt nếu tôi đăng các phần của dự án của tôi (tôi đã thử với một tệp). Tôi có thể làm gì để cung cấp cho dự án của mình ít nhất một số thước đo thành công mà không bị bối rối hoặc bị chệch hướng trong quá trình này?


17
Có một sự khác biệt giữa phát hành mã trên một diễn đàn và phát hành một dự án với nguồn có sẵn cho những người quan tâm. Ngay cả đối với các dự án nguồn mở lớn có nhiều người dùng và nhà phát triển tiềm năng đang xem mã, "Tôi nghĩ rằng mã của bạn có sai sót loại X và Y" dường như rất hiếm.

17
Từ mô tả, những lời chỉ trích bạn nhận được thời gian đó một vài năm trước làm cho bạn trở thành một lập trình viên tốt hơn. Vậy tại sao bạn lại sợ những lời chỉ trích lần này? Bạn có cảm thấy mình không cần phải trở thành một lập trình viên giỏi hơn nữa không? Nếu bạn muốn tốt hơn, bạn phải đặt cái tôi của mình sang một bên và gõ vài cái.
Paul Tomblin

3
Điều thú vị về nguồn mở là nếu mọi người phàn nàn, bạn luôn có thể yêu cầu họ khắc phục các sự cố cho bạn.
blueberryfields

4
Nếu bạn có những khu vực nghi ngờ cụ thể, hãy nâng cao chúng tại codereview.stackexchange.com .
pdr

12
BTW nếu embarrasement là một vấn đề, chúng tôi sẽ không bao giờ có dự án như Wordpress hoặc Joomla ... Hơn một nửa các blog hiện có trên WP, không ai dường như quan tâm về chất lượng của codebase ...
Yannis

Câu trả lời:


35

Trừ khi dự án nhắm đến các nhà phát triển (ví dụ: khung phát triển, trong trường hợp bạn muốn họ chỉ trích nó nếu nó khiến bạn học được nhiều hơn), bạn không nên lo lắng. Nhưng ngay cả sau đó, có nhiều dự án nguồn mở dành cho các nhà phát triển tào lao, nhưng mọi người yêu thích chúng vì họ đi đến điểm (nghĩ về Codeigniter, được kiến ​​trúc rất kém, và đó là khung php phổ biến nhất)

Nếu đó là một ứng dụng cho người thường, có lẽ họ sẽ chỉ quan tâm đến kết quả.


3
+1 Và các nhà phát triển quan trọng thực sự có thể gửi cho bạn một bản vá! Luôn luôn tôn trọng để mở kiến ​​thức và nỗ lực của bạn với thế giới :)
yati sagade

4
Thực sự bất kỳ lời chỉ trích là thông tin phản hồi có giá trị. Ngay cả khi nó khắc nghiệt (bạn có khả năng chỉ xem đó là phản hồi) và đó là một giá trị gia tăng không phải là lý do để bị đe dọa. :-) Hãy tự hào về những nỗ lực của bạn! nếu đó là điều tốt nhất mà bạn có thể làm, với sự giáo dục của bạn, hoặc hiểu rằng đó là TUYỆT VỜI! Bất kỳ Phản hồi nào sau đây sẽ chỉ phục vụ bạn trong việc trở thành nhà phát triển tốt hơn. Thành thật mà nói, mã ngày hôm nay sẽ luôn hút miễn là bạn đang cải thiện và phát triển.
Robert Pháp

+1 - Cảm ơn. Dự án dành cho các nhà phát triển, nhưng bạn đưa ra quan điểm tốt về kết quả.
Hy vọng

1
Mã của mọi người đều tệ, lấy bất kỳ lời phê bình nào làm kinh nghiệm học tập có giá trị. Nếu bất cứ ai xé bạn ra một cách không mang tính xây dựng, hãy bỏ qua họ như những kẻ ngốc mà họ chắc chắn là
David Hayes

25

Mã của bạn có vấn đề. Tôi cũng vậy. Bất cứ ai khác trả lời câu hỏi này? Mã của họ có vấn đề quá.

Trừ khi nó, nói, 10 dòng hoặc ít hơn, nó là thiếu sót. Có lẽ bi thảm như vậy.

Để trở thành một nhà phát triển là phải BẮT ĐẦU TUYỆT VỜI trước những giới hạn về khả năng và sự hiểu biết của bạn. Nó có thể không giống như vậy đối với TẤT CẢ các nhà phát triển, nhưng đối với tôi và đối với những người tôi biết, chúng tôi làm việc ngay ở cạnh của năng lực của chúng tôi mọi lúc. Và bạn phải đối mặt với điều đó nhiều lần, sau đó có một ngày cuối tuần tốt đẹp, sau đó quay lại vào thứ Hai và làm đi làm lại nhiều lần.

Đã làm việc suốt đời trong 15 năm, điều tôi đã giải quyết là một sự thật: Bạn không phải là mã của bạn . Bạn viết mã. Phán quyết của mã KHÔNG phải là phán xét của bạn . Mã của bạn có vấn đề, một số bạn biết, một số bạn không biết. Điều đó mang lại sự chú ý của bạn sẽ giúp bạn , trừ khi tất cả những gì bạn có thể làm về điều đó là cảm thấy tồi tệ. Cảm thấy tồi tệ không cải thiện mã của bạn, nó chỉ làm cho bạn cảm thấy tồi tệ.

Bạn viết mã của bạn, và bạn viết nó cũng như bạn biết làm thế nào. Có thể ngày mai bạn sẽ biết nhiều hơn bạn đã làm hôm nay, nhưng hôm nay bạn đã làm điều đó cũng như bạn đã biết. Lời khuyên của tôi là: viết mã hôm nay và mã ngày mai. Sau đó, có một ngày cuối tuần vui vẻ và quay lại vào thứ Hai để viết mã thứ Hai.


24

Theo nguyên tắc chung, các chương trình nguồn mở có ba nhóm người nhìn vào mã nguồn.

  1. Những người đang xem xét sửa đổi mã để làm cho chương trình hoạt động hơi khác với họ, để chuyển nó sang một nền tảng khác hoặc như một điểm khởi đầu cho các chương trình của riêng họ. Nếu họ không thích mã, họ thường sẽ không sử dụng mã và bạn sẽ không bao giờ nghe thấy từ họ.
  2. Học sinh, cố gắng học cách viết mã bằng ngôn ngữ bạn đã sử dụng. Những thứ này hầu như sẽ không bao giờ liên lạc với bạn, nhưng đôi khi bạn có thể nhận được một e-mail hỏi tại sao bạn lại làm một cách này so với cách khác. (Công bằng mà nói, tôi thực sự đã không có một trong những email này trong nhiều năm. Tôi nghĩ rằng các trang web như StackExchange có thể đã thay thế tương tác này)
  3. Các nhà nghiên cứu bảo mật, chẳng hạn như những kẻ tại OpenBSD, cố gắng quyết định xem công cụ của bạn có đủ an toàn để đưa vào phân phối của họ hay không. Nếu không, nhưng họ vẫn muốn đưa vào chương trình của bạn, thì họ sẽ liên lạc để tìm ra cách bảo mật chương trình. (Và nếu chương trình của bạn trở nên phổ biến, tôi tưởng tượng rằng nó cũng có thể sẽ thu hút các nhà nghiên cứu mũ đen, những người sẽ không liên lạc với bạn cho dù họ tìm thấy gì.)

Trong thế giới thực, mọi người thực sự sẽ không đọc mã nguồn của bạn vì bất kỳ lý do nào khác ngoài những lý do này, vì đơn giản là họ không cần. Bạn chỉ nhận được một khối lượng phản hồi như vậy trước đây vì bạn đã đăng mã lên một diễn đàn, ngụ ý rằng bạn muốn nhận phản hồi về mã.

Tôi không nghĩ rằng bạn thực sự cần phải lo lắng về một sự lạm dụng; những người duy nhất có khả năng liên lạc với bạn là những người muốn thêm tính năng hoặc sửa lỗi, những người đã duyệt qua cơ sở mã và không chạy la hét trên đồi. ;)


5

Tôi thực sự không hiểu tâm lý đằng sau câu hỏi này ... một câu hỏi hay hơn để tự hỏi mình là "tôi phải mất gì khi phát hành phần mềm này"

Ngay cả khi dự án của bạn đầy mùi mã, bạn có phải mất gì không?

Ngay cả khi mã là khủng khiếp và ai đó dành thời gian để viết một ngọn lửa cho bạn, hãy đoán xem, có lẽ anh ta đã sử dụng phần mềm của bạn đủ để thực hiện một số thay đổi cho nó và làm cho nó tốt hơn.

Bạn nên hạnh phúc về điều đó! Chấp nhận những lời chỉ trích và làm cho mã của bạn tốt hơn, hãy hỏi anh chàng tức giận đã dành thời gian để viết thư cho bạn. Anh quan tâm!

Sau một thời gian, các ngọn lửa sẽ dừng lại, mọi người sẽ tiếp tục sử dụng phần mềm của bạn, bạn sẽ học được từ những sai lầm của mình và những lỗ hổng mà bạn không biết đã tồn tại trong giáo dục của bạn sẽ không còn nữa.

Tôi thà làm việc với một người sẵn sàng làm điều gì đó, thừa nhận sai lầm của họ, sửa chữa chúng và tiếp tục hơn là một người không sẵn sàng làm bất cứ điều gì.

Nếu bạn thực sự không thoải mái khi phát hành phần mềm dưới tên của bạn thì hãy phát hành nó dưới một biệt danh. Nếu nó thành công, hãy khẳng định nó là của riêng bạn, nếu không thay đổi tên hiệu của bạn :)


+1 cho câu cuối cùng, mọi người trong ngành công nghiệp âm nhạc luôn làm điều này với các album "thử nghiệm" của họ :)
MattDavey

4

Tôi là một người tin tưởng vững chắc không chỉ trong nguồn mở, mà còn trong sự phát triển mở , nơi mọi người có thể thấy sự phát triển hoàn chỉnh của mã của bạn. Từ nguyên mẫu tóc bện đến mã làm việc ... bạn không bao giờ nên xấu hổ. Bạn đang đặt mình ra khỏi đó - điều đó rất can đảm. Sở hữu nó và tự hào về nó. Không ai là hoàn hảo cả.


3

Càng ở trong trò chơi này, tôi càng nhận ra rằng thước đo duy nhất về chất lượng mã là trải nghiệm của khách hàng. Nếu bạn đang viết một hàm, đó là người gọi hàm đó. Thư viện? Các nhà phát triển viết cho thư viện đó. Một khuôn khổ? Những người áp dụng nó. Một độc lập? Người hoặc daemon người khởi động chương trình.

Mã đẹp có ưu điểm của nó, đừng hiểu sai ý tôi - nhưng khi nó nói và thực hiện biện pháp duy nhất là "Nó có hoạt động không?" Tôi đã thấy rất nhiều mã sạch là một mớ hỗn độn và rất nhiều mã bị loạn trí hoàn toàn đáng tin cậy (cộng với cả sạch tốt và xấu xấu nữa :))

Vì vậy, nếu các nhà phê bình nói rằng mã của bạn là xấu, ai quan tâm. Nếu họ nói rằng nó không hoạt động - đó là lời chỉ trích hữu ích (dữ liệu thử nghiệm!) Mà bạn tìm cách cải thiện chương trình của mình. Đợi ở đó, tránh dân số troll của internet và vui chơi trong dự án của bạn!


2

Tôi hoàn toàn đồng ý với những gì người đăng khác đã nói: Ngay cả khi mã của bạn là xảo quyệt và không có chất lượng cao - hầu hết mọi người chỉ đơn giản là không quan tâm. Mọi người đã sử dụng mã OpenSource lúc này hay lúc khác có thể tự nghĩ rằng "WTF đã xảy ra ở đây".

Nhưng tôi không biết bất cứ ai ở ngoài đó với động lực chỉ trích cơ sở mã của một dự án chỉ với mục đích nói "anh bạn, mã của bạn trông thật tồi tệ!". Tất cả chúng ta đã ở đó và tất cả chúng ta đều biết rằng bất kỳ mã nào chúng ta viết ngay bây giờ sẽ có vẻ khá khập khiễng chỉ trong một vài khoản phí (chắc chắn là của tôi).

Vì vậy, đừng lo lắng nhiều - mọi người chỉ đơn giản là có nhiều việc phải làm trong thời gian rảnh rỗi hơn là việc viết mã trên các dự án OpenSource.


2

Mã thực luôn luôn mục nát và bẩn thỉu, đập vào nhau và được duy trì trong một thời gian gần đúng. Dọn dẹp được giới hạn để ghi lại các trường hợp đặc biệt và hằng số đặc biệt. Có một sự không phù hợp trở kháng giữa mã sạch và thế giới thực.

Tôi cũng nhận thấy rằng bất kỳ kỹ sư có thẩm quyền nào cũng có thể xé mã của người khác.

Nếu (1) nó vượt qua các bài kiểm tra và hoàn thành mục đích mà không thất bại VÀ (2) bạn có thể thực hiện các thay đổi nhỏ chỉ bằng cách viết lại nhỏ, đó là mã tốt.


2

Một số lời khôn ngoan từ Reid Hoffman, đồng sáng lập LinkedIn:

Nếu bạn không cảm thấy xấu hổ vì lần phát hành sản phẩm đầu tiên của mình, bạn đã phát hành quá muộn.

Bạn có thể tham gia với các thành viên và thấy những gì thực sự quan trọng là hoàn toàn quan trọng. Vì vậy, bạn nhận được sản phẩm khả thi tối thiểu ngay khi bạn có thể.

Tôi nghĩ điều này đặc biệt áp dụng cho các dự án nguồn mở, nơi có một ý tưởng tuyệt vời với một khởi đầu đầy hứa hẹn khuyến khích mọi người đóng góp và tham gia. Một cái gì đó quá bóng bẩy khiến bạn đeo kính râm có thể không gợi lên cảm giác như vậy. Nhưng điều quan trọng nhất về việc phát hành sớm là phá vỡ mọi định kiến ​​của bạn về những gì nên làm và bắt đầu đi đúng hướng.


1

Bạn là ai? Bạn có phải là người mà mọi người biết là lập trình viên của Chúa và lo lắng rằng danh tiếng của bạn sẽ đi xuống? Bạn có phải là người sẽ nộp đơn xin việc và lo lắng rằng nhà tuyển dụng có thể đọc những lời chỉ trích này, và nghĩ rằng bạn là lập trình viên tồi? Những gì tôi đang hỏi là tại sao bạn sợ những lời chỉ trích về cách bạn làm hỏng việc. Bạn có thể quyết định đó là những bình luận chân thực và những lời tán dương. Lấy những cái tốt làm khuyết điểm và sửa chúng trong phiên bản tiếp theo. Tôi chỉ cảm thấy rằng bạn đang lo lắng không cần thiết về những lời chỉ trích. Bạn đang giúp cộng đồng nguồn mở, chính nó là một nguyên nhân rất tốt. Hãy tiếp tục công việc tốt.


2
Một lập trình viên của Thiên Chúa là gì?
Hy vọng

1
@ Tuyệt vời. Có một giáo sư tại Đại học IIT Bombay. Tin đồn là anh chàng này viết chương trình, biên dịch nó và điều hành nó. Không có giai đoạn nào được gọi là biên dịch lại hoặc gỡ lỗi. Đây là lập trình viên của Chúa.
Manoj R

Được rồi, tôi khá chắc chắn rằng đó không phải là tôi ... Tôi bị ám ảnh về việc gỡ lỗi. Đó là một cảm giác mát mẻ khi một cái gì đó chỉ hoạt động lần đầu tiên, mặc dù. Thậm chí sau đó, tôi vẫn kiểm tra nó và viết các bài kiểm tra cho nó.
Hy vọng

1

Nếu bạn thực sự lo lắng, chỉ cần sử dụng bút danh trực tuyến khi phát hành phần mềm. Sau đó, không có cách nào nó sẽ ảnh hưởng đến danh tiếng thực tế của bạn.

Khi / Nếu bạn nhận được sự chỉ trích công khai, điều đó sẽ dẫn đến những cải tiến trong mã và sẽ giúp bạn phát triển như một nhà phát triển. Đó là một điều tốt.

Tôi thấy rằng đối với các dự án của tôi, hầu hết các lời chỉ trích / đề xuất mang tính xây dựng đều được gửi riêng tư thay vì phát công khai, và thậm chí sau đó bạn sẽ không thể nhận được vô số bình luận. Vì vậy, tôi khuyên bạn chỉ nên đi cho nó!

Chúc may mắn.


1

Không có gì sai khi tự học trong chính nó. Bạn không thể bị cô lập và đánh giá mã ngang hàng có thể giúp với điều đó.

Bạn cũng cần tập trung vào những gì bạn đang làm. Tại sao bạn quan tâm nếu bạn nhận được phản hồi tiêu cực về công việc của bạn? Nếu đó là vì bạn đang đưa ra giả định rằng nếu bạn bị chỉ trích thì đó là do mã không tốt hoặc bạn không giỏi lập trình, điều đó có thể đúng hoặc không đúng.

Mục đích của nỗ lực là đảm bảo mã hoạt động và lấy mã tốt nhất có thể, nhưng từ kinh nghiệm thực tế, không phải tất cả các mã giao dịch ngoài kia đều có sao. Đôi khi bạn nhận được yêu cầu xấu, đôi khi bạn không có thời gian để làm điều đó đúng. Đôi khi các nhà phát triển muốn đi qua như một thiên tài bằng cách làm cho người khác trông xấu.

Tôi không tin rằng bạn có thể học mà không mắc một số sai lầm, đặc biệt nếu đó là điều cần có kỷ luật và nỗ lực thực sự. Nếu nó dễ dàng, mọi người sẽ làm nó. Chỉ cần cố gắng hạn chế sai lầm cho những người nhỏ, sử dụng các thực tiễn tốt nhất được thiết lập. Tôi nhận ra rằng không phải lúc nào cũng có thể!

Nếu tôi lo lắng về những gì người khác nghĩ về tôi như một lập trình viên, tôi sẽ không đi sâu vào lĩnh vực này ngay từ đầu. Điều đó đang được nói, việc đầu tiên của tôi khi chỉ trích mã là, hãy cố gắng lấy nó một cách khách quan và học hỏi từ nó.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.