당황하지 않고 오픈 소스 프로젝트 공개 [닫기]

나는 꽤 오랫동안 오픈 소스 프로젝트를 꽤 많이 진행해 왔으며 그것을 발표하려는 시점에 가까워지고 있습니다. 그러나 나는 독학을 잘하며 내 프로젝트를 적절하게 검토 할 수있는 사람을 모른다.

몇 년 전, 나는 그것을 공개 한 포럼에서 (비판적인 의미로) 찢어 졌던 작은 코드를 공개했다. 코드가 작동했지만 비판은 정확했지만 잔인했습니다. 모든 것에 대한 모범 사례를 찾기 시작했으며 결국 더 나은 개발자가되었다고 생각합니다. 나는 내 프로젝트의 모든 것을 너무나 많이 넘겨서 완벽하게 만들려고 노력했다.

나는 내 프로젝트를 믿고 많은 사람들을 도울 잠재력이 있다고 생각하며 재미있는 방법으로 멋진 일을 한 것처럼 느낍니다. 그럼에도 불구하고, 나는 자아를 가르치기 때문에 자아 교육에 어떤 차이가 있는지 궁금해 할 수 없습니다. 지난 번에 코드를 찢어 버린 방식은 반복하고 싶지 않습니다. 수많은 시간을 투자 한 프로젝트를 발표 할 때의 가장 큰 두 가지 두려움은 자기 교육 때문에 특허 적으로 명백한 것을 놓쳤거나, 더 나쁜 것은 귀뚜라미 소리로 풀어 놓았 기 때문에 당황 스러웠습니다.

비슷한 상황에 처한 사람이 있습니까? 나는 건설적인 비판을 두려워하지 않습니다. 건설적인 비판은 물론 내가 망쳐 놓은 방법에 대한 열렬한 것이 아닙니다. StackExchange에 코드 검토 사이트가 있다는 것을 알고 있지만 실제로는 대규모 프로젝트를 위해 설정되지 않았으며 커뮤니티가 프로젝트 단편의 일부를 게시 할 때 아직 좋은 피드백을 얻을만큼 큰 느낌이 들지 않았습니다. 하나의 파일로 시도). 프로세스에 당황하거나 투자하지 않고 프로젝트에 최소한의 성공 척도를 제공하려면 어떻게해야합니까?

프로젝트가 개발자를 대상으로하지 않는 한 (예 : 개발 프레임 워크, 더 많은 학습을하게되면 비난을 원할 경우) 걱정하지 않아도됩니다. 그러나 그럼에도 불구하고 허약 한 개발자를 대상으로하는 오픈 소스 프로젝트가 많이 있지만 사람들은 요점에 도달하기 때문에 프로젝트를 좋아합니다 (Codeigniter는 매우 잘 설계되지 않았지만 가장 인기있는 PHP 프레임 워크라고 생각합니다)

일반 인간을위한 응용 프로그램 인 경우 결과에만 관심이있을 것입니다.

코드에 문제가 있습니다. 나도 그래 이 질문에 다른 사람이 있습니까? 그들의 코드에도 문제가 있습니다.

예를 들어 10 줄 이하이면 결함이있는 것입니다. 어쩌면 비극적으로

개발자가되는 것은 자신의 능력과 이해의 한계에 맞서 자신을 깨뜨리는 것입니다. 모든 개발자에게는 그렇지 않을 수도 있지만 저와 제가 아는 개발자에게는 항상 역량의 가장자리에서 거의 일을합니다. 그리고 당신은 그것을 반복해서 직면하고, 즐거운 주말을 보내고, 월요일로 돌아와서 또 다시 반복해서하세요.

15 년 동안 그 일을 해왔지만, 내가 정한 것은 바로이 사실입니다. 당신은 코드가 아닙니다 . 당신은 코드를 작성합니다. 규범의 판단은 당신의 판단이 아닙니다 . 코드에는 문제가 있습니다. 일부는 알고 있지만 일부는 그렇지 않습니다. 당신이 할 수있는 모든 일이 나쁘지 않다면, 주의를 기울이는 것이 도움이됩니다 . 기분이 나쁘다고해서 코드가 향상되지는 않으며 기분이 나빠집니다.

코드를 작성하고 방법을 아는 것뿐만 아니라 코드를 작성합니다. 어쩌면 내일은 오늘보다 더 많은 것을 알게 될지 모르지만 오늘은 당신이 알고있는 것만 큼 잘했습니다. 내 충고는 : 오늘 코드를 작성하고 내일 코드를 작성하십시오. 그런 다음 좋은 주말을 보내고 월요일에 돌아와 월요일의 코드를 작성하십시오.

일반적으로 오픈 소스 프로그램에는 소스 코드를 보는 세 그룹의 사람들이 있습니다.

1. 코드를 수정하여 프로그램이 약간 다르게 작동하도록하거나 다른 플랫폼으로 포팅하거나 자체 프로그램의 시작점으로 생각하는 사람들. 코드가 마음에 들지 않으면 일반적으로 코드를 사용하지 않으므로 코드를들을 수 없습니다.
2. 사용하는 언어로 코딩하는 방법을 배우려는 학생들. 이것들은 거의 당신에게 연락하지 않지만 때때로 어떤 방법으로 다른 방법으로 행동했는지 묻는 전자 메일을받을 수도 있습니다. (공평하게 말하면, 실제로 몇 년 동안 이러한 전자 메일 중 하나가 없었습니다. StackExchange와 같은 웹 사이트가이 상호 작용을 대체했을 수 있습니다.)
3. OpenBSD 직원과 같은 보안 연구원은 도구가 배포에 포함되기에 충분히 안전한지 결정하려고합니다. 그렇지 않은 경우에도 여전히 프로그램을 포함하고 싶다면 보안을 유지하는 방법을 찾아야합니다. (귀하의 프로그램이 인기를 얻는다면, 블랙 햇 연구원들도 관심을 가질 것이라고 생각합니다.

현실에서는 사람들이 소스 코드를 읽을 필요가 없기 때문에 소스 코드를 읽을 수 없습니다. 포럼에 코드를 게시 했으므로 코드에 대한 피드백을 받기를 원했기 때문에 이전에는 그러한 피드백이 많았습니다.

나는 당신이 학대의 급류에 대해 정말로 걱정할 필요가 없다고 생각합니다. 기능을 추가하거나 버그를 수정하려는 사람들은 이미 코드베이스를 탐색하고 언덕을 향해 비명을 지르지 않은 사람들입니다. ;)

나는 정말로이 질문 뒤에 심리학을 얻지 못한다. 스스로에게 물어 보는 더 좋은 질문은 "이 소프트웨어를 발표함으로써 무엇을 잃어야 하는가"일 것이다.

프로젝트에 코드 냄새가 가득 차더라도 잃어버린 것이 있습니까?

코드가 끔찍하고 누군가가 당신에게 불꽃 메일을 쓰는 데 시간이 걸리더라도, 그 코드를 약간 변경하고 더 좋게 만들고 싶을 정도로 소프트웨어를 사용했을 것입니다.

당신은 그것에 대해 행복해야합니다! 비판을 받아들이고 코드를 향상 시키려면 시간을내어 화난 사람에게 편지를 쓰십시오. 그는 걱정한다!

잠시 후 화염 메일이 중단되고 사람들이 소프트웨어를 계속 사용하게되므로 실수를 통해 배우게되며 교육에서 알지 못한 격차는 더 이상 존재하지 않게됩니다.

나는 기꺼이 무언가를하고 싶어하는 사람과 실수를 인정하고, 실수를 고치고 , 기꺼이 아무것도하지 않는 사람보다 계속 일하고 싶습니다 .

귀하의 이름으로 소프트웨어를 공개하는 것이 불편한 경우에는 별명으로 소프트웨어를 해제하십시오. 성공하면 닉네임을 변경하지 않으면 자신의 것으로 주장하십시오 :)

나는 사람들이 코드의 완전한 진화를 볼 수 있는 오픈 소스뿐만 아니라 오픈 개발에 대한 확고한 신자 입니다. 머리가 두근 거리는 프로토 타입에서 작업 코드까지 ... 당황스럽지 않아야합니다. 당신은 거기에 자신을 내놓고 있습니다-용기가 필요합니다. 그것을 소유하고 자랑스러워하십시오. 누구도 완벽하지 않다.

이 게임에 오래 참여할수록 코드 품질의 유일한 척도는 클라이언트 경험이라는 것을 깨닫게되었습니다. 함수를 작성하는 경우 해당 함수의 호출자입니다. 도서관? 해당 라이브러리를 작성하는 개발자 프레임 워크? 그것의 채택 자. 독립형? 프로그램을 시작한 사람 또는 데몬.

좋은 코드는 장점이 있습니다. 틀리지 말아주세요. 그러나 말하고 행할 때 유일한 조치는 "작동합니까?"입니다. 나는 버그가 많은 엉망인 많은 깨끗한 코드와 완전히 신뢰할 수있는 많은 체계적으로 정렬 된 코드를 보았습니다.

그래서 비평가들이 당신의 코드가 못 생겼다면 누가 걱정하는지 말입니다. 그들이 효과가 없다고 말하면 그것은 프로그램을 개선하고자하는 유용한 비평 (테스트 데이터!)입니다. 인터넷에 트롤 인구를 피하고 프로젝트를 즐기십시오!

나는 다른 포스터가 말한 것에 강력히 동의합니다. 코드가 고르지 않고 품질이 좋지 않더라도 대부분의 사람들은 신경 쓰지 않습니다. 언젠가 OpenSource 코드에 들어간 사람은 누구나 "WTF가 여기에서 일어났다"고 생각했을 것입니다.

그러나 나는 "친구, 당신의 코드가 끔찍해 보인다"고 말하는 목적으로 프로젝트의 코드베이스를 비판 하려는 동기 를 가진 사람을 모른다 . 우리는 모두 거기에 있었고 우리는 지금 우리가 작성하는 모든 코드가 몇 번의 비용으로 자신을 위해 절름발이가 될 것임을 알고 있습니다.

따라서 걱정하지 마십시오. 사람들은 여가 시간에 OpenSource 프로젝트 코드를 짜는 것보다 훨씬 더 잘 할 수 있습니다.

실제 코드는 항상 썩고 더러워지고 서로 찰칵 소리를 내며 거의 특별하게 유지됩니다. 정리는 특수 사례 및 특수 상수를 문서화하는 것으로 제한됩니다. 깨끗한 코드와 실제 세계에는 임피던스 불일치가 있습니다.

또한 유능한 엔지니어가 다른 사람의 코드를 찢어 버릴 수 있음을 알았습니다.

(1) 테스트를 통과하고 실패하지 않고 목적을 달성하면 AND (2) 사소한 재 작성만으로 사소한 변경을 할 수 있으면 좋은 코드입니다.

LinkedIn 공동 창립자 인 Reid Hoffman의 현명한 말 :

"첫 번째 제품 출시로 당황하지 않으면 너무 늦게 출시 된 것입니다."

"회원과의 교류를 통해 실제로 중요한 것이 무엇인지 파악하는 것이 가장 중요합니다. 따라서 가능한 한 빨리 최소한의 실행 가능한 제품을 얻을 수 있습니다."

나는 이것이 유망한 출발을 가진 훌륭한 아이디어를 갖는 것이 사람들이 기여하고 참여하도록 장려하는 오픈 소스 프로젝트에 특히 적용된다고 생각합니다. 너무 세련되어 선글라스를 착용하면 그런 느낌이 들지 않을 수 있습니다. 그러나 조기 출시에있어 가장 중요한 것은해야 할 일에 대한 모든 선입견을 깨뜨리고 올바른 방향으로 나아 가기 시작하는 것입니다.

누구세요? 당신은 사람들이 신 프로그래머라고 알고 당신의 명성이 떨어질 까 걱정합니까? 당신은 직업을 신청할 사람이고 고용주가이 비판을 읽고 당신이 나쁜 프로그래머라고 생각 할까 걱정하고 있습니까? 내가 묻는 것은 왜 당신이 망쳐 놓는 지에 대한 비판을 두려워하는 것입니다. 당신은 어느 것이 진실한 의견이고 어떤 것이 야담한지를 결정할 수 있습니다. 좋은 것을 결함으로 생각하고 다음 버전에서 수정하십시오. 난 당신이 비판에 대해 불필요한 걱정을 느끼고 있습니다. 오픈 소스 커뮤니티를 돕고 있습니다. 그 자체가 매우 좋은 원인입니다. 좋은 일을 계속하십시오.

정말로 걱정이된다면 소프트웨어를 배포 할 때 온라인 가명을 사용하십시오. 그러면 실제 평판에 영향을 줄 방법이 없습니다.

공개 비평을받는 경우 /면 코드가 개선되고 개발자로 성장하는 데 도움이됩니다. 좋은 것입니다.

내 프로젝트에서 대부분의 건설적인 비판 / 제안은 공개적으로 방송되는 것이 아니라 개인적으로 전송되며, 그럼에도 불구하고 많은 의견을들을 가능성이 낮습니다. 따라서 나는 그것을 위해가는 것이 좋습니다!

행운을 빕니다.

자체 학습 자체에는 아무런 문제가 없습니다. 격리 할 수 ​​없으며 피어 코드 검토가 도움이 될 수 있습니다.

또한하고있는 일에 집중해야합니다. 업무에 대해 부정적인 피드백을 받으면 왜 신경 쓰나요? 비판을받는다면 코드가 나쁘거나 프로그래밍에 능숙하지 않기 때문이라고 가정하기 때문일 수 있습니다.

노력의 목적은 코드가 작동하고 가능한 한 최상의 코드를 얻는 것이지만 실제 경험을 통해 모든 상용 코드가 스텔라가 아니라는 것입니다. 때로는 나쁜 요구 사항을 얻거나 때로는 제대로 할 시간이 없습니다. 때때로 개발자들은 다른 사람들을 나쁘게 보이게함으로써 천재로서오고 싶어합니다.

나는 실수를하지 않고 배울 수 있다고 생각하지 않습니다. 특히 실제 훈련과 노력이 필요한 경우라면 더욱 그렇습니다. 쉬웠다면 모두가 그렇게 할 것입니다. 확립 된 모범 사례를 사용하여 실수를 사소한 것으로 제한하십시오. 항상 가능하지는 않다는 것을 알고 있습니다!

다른 사람들이 나를 프로그래머로 생각한 것에 대해 걱정한다면, 처음에는 현장에 가지 않았을 것입니다. 즉, 코드에 대한 첫 비판은 코드를 객관적으로 다루고 배우는 것입니다.