취미 프로젝트 발표에 대한 두려움-극복하는 방법? [닫은]


37

이 질문이 소프트웨어 개발과 관련이 있는지는 잘 모르겠지만 여전히 시도해 볼 것입니다.

많은 프로그래머와 마찬가지로 취미 프로젝트도 좋아합니다. 때로는 좋은 아이디어가 그렇게 좋지 않은 것으로 판명되어 프로젝트를 중단합니다. 그러나 때로는 유용한 무언가가 프로젝트에서 나옵니다. 그래서 나는 그것을 풀어서 세상에 선물 할 수 있습니다.

잘못된. 어떻게 든, 나는이 단계를 만들 수없는 것 같습니다. 내 코드가 충분하지 않다는 것을 두려워하며, 차선책, 추가 할 수있는 기능을 항상 생각할 수 있습니다. 그래서 나는 아무것도 발표하지 않고 관심을 잃고 어느 시점에서 프로젝트를 포기합니다.

이것이 정상입니까? 그런 상황을 어떻게 극복합니까?


11
글쎄, 그것은 당신을 위해 충분하고 "그들은"무료로 그것을 얻습니다. 왜 그들은 불평해야합니까?
Joachim Sauer

42
"제 코드가 충분하지 않을까 걱정됩니다."어제 수행 한 내용을 되돌아보고 만족하면 개선되지 않습니다.
Roger Lipscombe 8:25에

9
그것이 작동하고 스파게티의 완전한 혼란이 아닌 경우 그것을 풀어 놓으십시오. 내 경험상 모든 코드가 비판을 받고 익숙해집니다. 마이크로 소프트는 리눅스에 통합 할 수있는 코드를 공개했다. 나는 그것이 정리되어 다시 반 줄로 끝나는 것으로 기억됩니다. 나는 매일 내 코드를보고 "오 신 이시여. 제가 쓰 셨나요? Doh!
Jaydee

4
사람들이 그것을 쓰지 않으면 결코 나아지지 않을 것입니다. 해봐!
Scott C Wilson

4
당신이 원합니다! 누군가가 당신이 어떤 코드를 발표
했다는

답변:


51

우선, 배송은 기능 입니다. 아무것도 공개하지 않는 것보다 불완전한 것을 공개하는 것이 좋습니다.

주목해야 할 또 다른 사항은이 프로젝트가 취미 프로젝트라는 것입니다. 마감일을 지키지 않거나 관심을 잃는 경우 큰 문제는 아닙니다. 당신은 결국 재미를 위해 프로젝트를하고 있습니다.


23

거기 넣어

GitHub 또는 Bitbucket 과 같은 소셜 코딩 사이트에서는이를 수행하는 것이 어렵지 않습니다 . 당신이 내놓을 것들의 대부분은 아마 많이 사용되지는 않지만 괜찮습니다. 이 소셜 코딩 사이트에서는 거의 정상이며 많은 프로젝트 (유용한 프로젝트)가 포기됩니다. 그러나 가장 좋은 점은 남이 남은 것을 다른 사람이 선택할 수 있다는 것입니다 (허가 라이센스가있는 경우).

다른 사람이 물건을 사용하지 않더라도 왜 그것을 꺼내야하는지에 대한 몇 가지 이점이 있습니다.

  • 많은 프로그래머가 어떻게 알지 못하는 버전 관리를 사용하는 법을 배워서 더 행복하게 만듭니다.
  • 사람들은 당신에게 문제를 지적 할 수 있습니다. 일을 다르게하는 법을 배울 수있는 모든 기회
  • 이력서에 대한 보완 자료로 제공 한 훌륭한 온라인 자료 포트폴리오가 제공됩니다.

3
"사람들이 당신에게 문제를 지적 할 수있다" +1- 코드를 오픈 소스로 제공함으로써 얻을 수있는 큰 이점 중 하나입니다.
Andrew Thompson

14

이미 버그가없는 오픈 소스 프로젝트에 기고자를 참여시키는 것은 해결하기 쉬운 버그가 많은 프로젝트보다 어려울 수 있습니다. 이러한 버그는 초기 사용자가 코드에 익숙해 지도록하는 동기가되기 때문입니다.

Linus가 처음 Linux 커널을 도입했을 때는 완전하고 안정적이며 버그가없고 깨끗한 코드가 아니 었습니다. 핀란드어 키보드 로는 불완전하고, 엉터리이고, 휴대 할 수 없으며, 유선으로 연결되었습니다 .


3
나는이 관점을 좋아한다.
TehShrike

Linux 예제의 경우 +1
Calmarius

6

기본적으로 사람들이 내 코드를 좋아하는지 아닌지 걱정하지 않습니다. 사람들에게 유용한 경우 무료 라이센스로 배포하지만 버그, 차선책으로 더 많은 기능이 필요하고 더 많은 기능이 필요한 경우 자유롭게 수정할 수 있습니다. GPL 또는 LGPL을 사용하면 이러한 수정 사항을 찾을 수 있으며 유용하거나 적합하다고 생각되면 직접 적용 할 수 있습니다.


5

미안하지만 당신은 당신이 해야하는 것과 정확히 반대입니다!

가능한 빨리 릴리스하고 사람들의 의견을 듣고이를 기반으로 새로운 기능을 구현하십시오. 다른 방법은 아닙니다!


유용성을 최적화하려는 경우에만 해당됩니다. OP는 분명히 거리의 신분을 최대화하거나 당황을 최소화하려고 노력하고 있습니다.
Caleb

2
@ Caleb : 항상 사실입니다. 목표는 항상 제품을 배송하는 것이며 코드를 작성하는 것은 아닙니다!
토마스 보니 니

버전 관리를 통해 사람들은 코드에서 개선 사항을 볼 수 있습니다. 보는 사람이 나쁜 코드로 시작하지만 그들은 배울 수) 예를 들어 쇼를 찾고 벌금, B)가 예전의 코드를 개선하는 대신 그것을 무시하고자하는로를 형성 할 수 있었다
때로 믿을 수

4

무엇을 잃어야합니까?

당신은 또한 그것이 실제로 좋거나 새로운 틈새 시장을 채우지 않는 한 어쨌든 눈에 띄지 않을 것이라는 것을 알고 편안하게 취할 수 있습니다.

그리고 부정적인 피드백을 받으면 배울 수있는 기회입니다. 낭비하지 마십시오.


"어쨌든 눈치 채지 못할 것이다". 불행히도, 매우 사실입니다.
user16764

3

소프트웨어 이외의 모든 도메인에서도 완전히 정상입니다. 몇 가지 다른 환경에서 빌드하고 README를 작성한 다음 github / codeplex / etc에 버리십시오. 이것을 처음으로 극복하는 것이 불안을 극복하는 유일한 방법입니다.

두 번째, 세 번째 및 n 번째 시간은 재미가있는 곳입니다!


1

완료되지 않은 소프트웨어를 출시해야하는 이유 중 하나는 커뮤니티 구축을 시작하는 것입니다. 프로젝트가 유용한 오픈 소스 도구가 되려면 다른 개발자가 필요합니다. 그들을 끌어들이는 한 가지 방법은 그것을 일찍 발표 한 다음 (공개적으로) 계속 개선하는 것입니다. 이러한 기능을 비밀리에 추가하지 마십시오. 공개적으로, Github 페이지 또는 어디에서나 수행하십시오. 그것은 역사에서 활동을 생성합니다.

다른 개발자들은 분명히 버려진 프로젝트에서 일하고 싶지 않습니다. 따라서 공공 장소에서 개발 작업을 수행하는 것은 적극적이고 지속적인 관심을 보여줍니다. 의도적으로 몇 가지 기능을 소매에 유지하여 공개적으로 추가 할 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.