Sợ phát hành một dự án sở thích - làm thế nào để vượt qua? [đóng cửa]


37

Tôi không biết câu hỏi này có liên quan chặt chẽ đến phát triển phần mềm hay không, nhưng tôi vẫn sẽ thử:

Giống như nhiều lập trình viên, tôi thích làm việc trong các dự án sở thích. Đôi khi, những ý tưởng tốt dường như không tốt lắm, vì vậy tôi bỏ dự án. Nhưng đôi khi, một cái gì đó hữu ích ra khỏi dự án. Vì vậy, tôi có thể phát hành nó, giới thiệu nó với thế giới, phải không?

Sai rồi. Bằng cách nào đó, tôi dường như không thể thực hiện bước này. Tôi sợ rằng mã của tôi không đủ tốt, tôi luôn có thể nghĩ về những thứ không tối ưu, các tính năng có thể được thêm vào. Vì vậy, tôi không tiết lộ bất cứ điều gì, tôi mất hứng thú và đến một lúc từ bỏ dự án.

Điều này có bình thường không? Làm thế nào để bạn vượt qua tình huống như vậy?


11
Chà, nó đủ tốt cho bạn và "họ" nhận nó miễn phí, vậy tại sao họ phải phàn nàn?
Joachim Sauer

42
"Tôi sợ rằng mã của tôi không đủ tốt" - nếu bạn nhìn lại những gì bạn đã làm ngày hôm qua và bạn hài lòng với nó, thì bạn không tiến bộ.
Roger Lipscombe

9
Nếu nó hoạt động và không phải là một mớ hỗn độn của spaghetti phát hành nó. Theo kinh nghiệm của tôi, tất cả các mã bị chỉ trích, làm quen với nó. Microsoft đã phát hành toàn bộ tải mã để kết hợp vào Linux. Tôi dường như nhớ lại rằng nó đã được gửi trở lại để được dọn dẹp và kết thúc với một nửa số dòng. Tôi nhìn vào mã của mình mỗi ngày và nghĩ "Ôi Chúa ơi. Tôi đã viết nó phải không? Doh!
Jaydee

4
Nó sẽ không bao giờ tốt hơn nếu không có người đập vào nó. Đi cho nó!
Scott C Wilson

4
Bạn ước! Bạn nên xem xét bản thân mình may mắn nếu có bất kỳ ai thông báo bạn đã phát hành một số mã :)
Stewol

Câu trả lời:


51

Trước hết, hãy nhớ: vận chuyển là một tính năng . Tốt hơn là phát hành một cái gì đó không hoàn hảo hơn là không phát hành gì cả.

Một điều khác cần lưu ý là đây là những dự án Sở thích. Nếu bạn không đáp ứng thời hạn hoặc mất hứng thú thì đó không phải là vấn đề lớn. Rốt cuộc bạn đang làm dự án cho vui.


23

Đặt nó ra khỏi đó.

Không khó để làm điều này với một trang web mã hóa xã hội như GitHub hoặc Bitbucket . Hầu hết những thứ bạn sẽ đưa ra có lẽ sẽ không được sử dụng nhiều, nhưng điều đó không sao cả. Điều đó là khá bình thường trong các trang web mã hóa xã hội này, và rất nhiều dự án bị bỏ rơi (thậm chí một số dự án hữu ích). Nhưng điều tuyệt vời nhất là những người khác có thể chọn ra những gì bạn đã để lại (với điều kiện bạn phải có giấy phép cho phép).

Mặc dù công cụ của bạn có thể sẽ không được sử dụng bởi bất kỳ ai khác, có một số lợi ích về lý do tại sao bạn vẫn nên đưa nó ra:

  • Bạn học cách sử dụng kiểm soát phiên bản, điều mà rất nhiều lập trình viên không biết làm thế nào, khiến bạn trở nên hấp dẫn hơn
  • Mọi người có thể chỉ ra vấn đề cho bạn; tất cả các cơ hội để bạn học cách làm những điều khác biệt
  • Bạn sẽ có một danh mục đầu tư trực tuyến gồm những thứ bạn đã thực hiện, thật tuyệt vời khi có sự bổ sung cho hồ sơ của bạn

3
+1 cho "Mọi người có thể chỉ ra vấn đề cho bạn" - đó là một lợi ích to lớn cần có từ việc cung cấp mã dưới dạng nguồn mở.
Andrew Thompson

14

Đưa những người đóng góp vào một dự án nguồn mở đã không có lỗi có lẽ khó hơn những người có nhiều lỗi dễ giải quyết, vì những lỗi này là một động lực để người dùng sớm làm quen với mã.

Khi Linus lần đầu tiên giới thiệu nhân Linux, nó không phải là một mã hoàn chỉnh, ổn định, không có lỗi và sạch; nó là một bàn phím không hoàn chỉnh, nhảm nhí, không thể di chuyển và cứng cáp cho bàn phím Phần Lan .


3
Tôi thích quan điểm này.
TehShrike

+1 cho ví dụ Linux.
Calmarius

6

Về cơ bản, tôi sẽ không lo lắng về việc mọi người có thích mã của tôi hay không. Phát hành nó theo giấy phép miễn phí, nếu nó hữu ích cho mọi người, nhưng họ tìm thấy lỗi, giải pháp tối ưu và yêu cầu nhiều tính năng hơn, họ có thể tự sửa nó. Sử dụng GPL hoặc LGPL cũng sẽ giúp bạn có thể tìm thấy các bản sửa lỗi này và bạn có thể tự áp dụng chúng nếu bạn thấy chúng hữu ích / phù hợp.


5

Tôi xin lỗi nhưng bạn đang làm ngược lại chính xác những gì bạn nên làm!

Phát hành nó càng sớm càng tốt, lắng nghe phản hồi của mọi người, và sau đó thực hiện chức năng mới dựa trên đó. Không phải hướng ngược lại!


Điều đó chỉ đúng khi bạn đang cố gắng tối ưu hóa khả năng sử dụng. OP rõ ràng đang cố gắng tối đa hóa tín dụng đường phố, hoặc ít nhất là giảm thiểu sự bối rối.
Caleb

2
@Caleb: điều đó luôn luôn đúng. Mục tiêu là luôn luôn vận chuyển một sản phẩm và không bao giờ viết mã!
Thomas Bonini

Đừng quên, kiểm soát phiên bản cho phép mọi người nhìn thấy CẢI TIẾN trong mã. Thấy ai đó bắt đầu với mã xấu nhưng có thể định hình nó thành một ví dụ đẹp mắt cho thấy a) Họ có thể học, b) họ sẵn sàng cải thiện mã cũ thay vì bỏ qua nó
Aren

4

Bạn có gì để mất ?

Bạn cũng có thể thoải mái khi biết rằng có lẽ nó sẽ không được chú ý, trừ khi nó thực sự tốt hoặc lấp đầy một phân khúc mới.

Và, nếu bạn nhận được phản hồi tiêu cực - đó là cơ hội để tìm hiểu .. Đừng lãng phí nó.


"Có lẽ nó sẽ không được chú ý nào". Thật không may, rất đúng.
dùng16764

3

Hoàn toàn bình thường, trong bất kỳ miền nào ngoài phần mềm là tốt. Hãy chắc chắn rằng nó được xây dựng trong một vài môi trường khác nhau, viết README và ném nó vào github / codeplex / vv. Vượt qua điều này lần đầu tiên là cách duy nhất để vượt qua sự lo lắng.

Lần thứ hai, thứ ba và lần thứ n là nơi niềm vui nằm!


1

Đây là một lý do để phát hành phần mềm chưa hoàn thành: bắt đầu xây dựng một cộng đồng. Nếu bạn muốn dự án của bạn trở thành một công cụ nguồn mở hữu ích, bạn cần các nhà phát triển khác. Một cách để thu hút họ là phát hành sớm, và sau đó tiếp tục (công khai) thực hiện các cải tiến. Không thêm các tính năng đó một cách bí mật - thực hiện chúng công khai, trên trang Github hoặc bất cứ nơi nào. Điều đó tạo ra hoạt động trong lịch sử.

Các nhà phát triển khác không muốn làm việc trên một dự án bị bỏ rơi rõ ràng. Vì vậy, làm công việc phát triển của bạn ở nơi công cộng thể hiện sự quan tâm tích cực, liên tục. Bạn nên cố tình giữ một vài tính năng trong tay áo để bạn có thể thêm chúng ở nơi công cộng.

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.