오픈 소스 에티켓

Codeplex에서 첫 번째 오픈 소스 프로젝트를 시작했으며 끔찍한 코드를 발견했습니다. (C #에 여전히 "goto"문이 있다는 것을 알게되었습니다.) "owner"가 원했던 기능을 추가하기 시작했으며 코드베이스를 탐색하고 그 혼란을 확인한 후 (예 : "goto"사용) 정리하고 싶었습니다. 약간. 그러나 나는 약간 우려하고 있으며 이것이 내가 여러분 모두에게 돌이키는 이유입니다. "나쁜 코드"를 "고정"하는 것이 적절한 예절입니까, 아니면 새로운 기능을 사용하도록해야합니까? 내가 전에 말했듯이, 나는 전체 OSS 장면에 익숙하지 않으며 일반적으로 팀에서 일하기 때문에 그것을 엉망으로 만들고 싶지 않습니다.

당신이 그것에 대해 겸손하고 아무것도 깨지지 않으면 이 작업을 수행해도 괜찮습니다 . 코드를 다시 포맷하고 버그를 도입 할 수는 없습니다. 좋은 단위 테스트가 있습니까? 그렇지 않다면 단위 테스트를 추가하여 기여를 시작한 다음 나중에 구조를 수정하십시오.

오픈 소스의 목적은 프로젝트에 더 많은 관심을 갖고 개선하는 것입니다. 여기에는 코드를 개선하는 것이 포함됩니다. 즉, 당신이하고 싶은 일을 목록에 광고하는 것이 좋습니다. 약간의 푸시 백을 받거나 +1을 얻을 수 있습니다. goto원래의 저자는 작업을 수행하는 더 좋은 방법을 생각할 수 없었기 때문에 그러한 진술이있을 수 있습니다. 뒤로 밀면 압력이 어디에서 오는지 알아보기 위해 대화 상자에 들어가는 것이 좋습니다. 개인적으로 생각하지 말고 문제를 해결하려고 노력하십시오.

결론적으로, 단위 테스트는 교리보다 더 크게 말합니다. 특정 상황에서 코드가 현재와 같이 작동하지 않을 수 있음을 증명할 수 있으면 엄지 손가락을 올리거나 원래 작성자가 들어 와서 문제를 해결합니다.

오픈 소스에서 커뮤니티는 코드보다 중요합니다. 커뮤니티 (사용자 및 개발자 모두)가 없으면 프로젝트가 없습니다.

자신의 코드에 대해 질투심이 많은 사람들은 일반적으로 세상을 면밀히 조사하기 위해 코드를 게시하지 않으며, 그렇게 할 경우 그 커뮤니티는 오래 지속되지 않습니다. 재치가 있지만 감정을 상하게 할 것이라고 걱정하지 마십시오.

너무 많은 시간을 투자하기 전에 무엇을하고 싶은지 알려주십시오. 때로는 명백하지 않은 것들에 대한 역사적 이유가 있습니다. gotos를 피하는 이유는 코드를 통해 예기치 않은 경로를 생성 할 수 있기 때문입니다. 따라서 고토 제거의 위험은 유익한 경로 중 하나를 발견하지 못하고 실수로 리 팩터에서 생략한다는 것입니다.

반면에, 원저자는 당시에 그것을 쓸 수있는 더 깔끔한 방법을 생각할 수 없었을 것입니다. 이것은 코드가 단어보다 더 크게 말하는 곳입니다. 필자의 첫 번째 오픈 소스 기여 중 하나는 성능을 크게 개선 한 실행 취소 스택 수정이지만 일부 핵심 개발자는 처음 설명 할 때 너무 복잡하다고 말했다. 짧은 코드 샘플이 그것들을 가져 왔습니다.

그것이 실제로 떠날만한 좋은 이유가 있다면, 나는 그 이유를 설명하는 의견을 적어도 푸시 할 것입니다.

경험에서 말하면 ...

내가 기여한 첫 번째 오픈 소스 프로젝트는 처음 시작했을 때 오줌과 식초로 가득했습니다.

내가 즉시 한 일은 많은 소스 파일을 살펴보고 개인 취향에 맞게 스타일을 지정하고 대규모 패치를 만들어 제출 한 것입니다.

당신이 '좋은'누군가와 같이 일하고 있다면 (그처럼) 패치를 즉시 거부 할 것입니다. 대부분 오픈 소스 프로젝트에 기여할 때 수정 사항을 단일 문제를 해결하는 한 입 크기의 덩어리로 분류해야하기 때문입니다. '모든 고토를 제거했습니다'는 원자 적 커밋의 좋은 예가 아닙니다. 더 작고 잘 문서화 된 커밋으로 분류하더라도 거부 될 수 있습니다.

그 이유는 시간이 지남에 따라 여러 사람이 다른 스타일로 코드를 작성했기 때문에 전체 라이브러리에서 한 개발자의 스타일에 맞게 변경 사항을 적용하는 것은 실제로 불가능합니다. 스타일을 위해 스타일을 변경할 수 있다면 모든 오픈 소스 프로젝트는 다른 개발 스타일에 맞게 코드가 지속적으로 편집되기 때문에 앞으로 나아갈 수 없습니다.

코드 리팩토링 및 기능 추가 (또는 더 이상 사용되지 않는 크래프트 제거)는 일반적으로 '클리닝'코드보다 우선합니다.

오픈 소스 프로젝트 작업에서 가장 어렵고 보람있는 부분 은 제출하는 변경을 제안하는 이유 를 묻는 것 입니다. 정당한 이유를 제시 할 수 있다면 패치가 제출 될 가능성이 높아집니다.

내 조언은 하나의 소스 파일에서 이러한 변경 사항 중 일부를 수행하여 먼저 수행하려는 작업을 맛보는 것입니다. 변경 사항이 정당하고 수용된 경우 프로젝트의 품질을 향상시킬 수있는 변경 사항이 더 있는지 묻습니다. 이렇게하면 향후 패치가 거부 될 경우 아무런 노력을 기울이지 않아도됩니다.

오픈 소스 개발은 코드 작성 그 이상입니다. 게이트 키퍼 (푸시 액세스를 제어하는 ​​개발자) 가 프로젝트의 무결성을 보호하기 위해해야 ​​할 일을하기 때문에 신뢰 관계를 구축하려고 노력 하고 있습니다. 더 많은 패치를 제출할 때 게이트 키퍼는 스타일에 대한 느낌이 좋아지고 변경 사항을 정당화 할 필요가 없습니다.

시간이 걸리지 만 매우 보람있는 과정입니다. 당신 은 다른 사람의 코드를보고 비판하는 것으로부터 많은 것을 배울뿐만 아니라 자신의 스타일에 비판을 받을 것 입니다.

'다른 코딩 스타일의 오류에 대한 불의를 바로 잡기'위해 많은 시간을 허비하기 전에 다음과 같이 자문 해보십시오.

프로젝트에 가치를 더할 때 제안하는 변경 사항입니까, 아니면 자신의 내부 스타일 종교에 기반한 변경 사항입니까?

스택 오버플로 (및 관련 스택 교환 사이트) 에는 많은 종교가 있습니다. 나는 많은 것을 의미합니다 . 사람들은 스타일에 대해 끝없이 생각하고 이야기합니다. 스타일에 대해 더 많이 이야기할수록 '완벽하고, 이상적이며, 파괴 할 수없고, 빠질 수없는'코딩 스타일에 가까워집니다. 나는 그것이 재미 있기 때문에 그것에 대해 너무 많이 이야기합니다.

오픈 소스 세계에서 스타일은 그리 중요하지 않습니다. 기능 은 입니다.

참고 :이 모든 조언은 게이트 키퍼가 합리적이고 재능있는 프로그래머라고 가정합니다. 그가 자신이라면, 자신이 '아기'를 보호하는 데 관심이있는 엉뚱한 b @ & # & es 중 하나에 갇히지 않았다는 것을 행운으로 생각하십시오. 그것들 은 야생에 존재하므로 하나라도 만나더라도 놀라지 마십시오.

품질> 에티켓

내 의견으로는 다른 사람들의 코드가 품질이 좋지 않다는 것을 알게되면 걱정하지 않아도됩니다. 좋은 소프트웨어 품질을 얻으려면 깨끗한 코드를 관리하면됩니다. 다른 사람들의 코드를 개선하는 데 아무런 문제가 없습니다. 다른 사람들은 코드를 작성하는 코더가 있다는 것을 알고 감사해야합니다.

"goto"를 사용하지 않고 문제를 해결하는 더 좋은 방법을 알아낼 수 있다면 그렇게하자. 오늘날 코드를 개선하기 위해 조금만 노력하면 앞으로 더 많은 노력을 아낄 수 있습니다.

원저자와 의사 소통하는 것도 좋은 생각입니다.

에 아무런 문제가 없습니다 goto. 곳곳에있는 어셈블리 코드 (많은 고토 (점프 및 브랜치))를보십시오.

goto요즘 이름이 나쁜 이유 는 Dijkstra 논문 Go to 선언문이 유해한 것으로 간주 되어 Goto 선언문을 매우 나쁜 것으로 지적 했기 때문입니다 .

소프트웨어 엔지니어링의 이름이 아직 정립되지 않은 50 년 전이었으며, 대부분의 프로그래밍 언어는 기본적으로 기계 언어가 포함 된 기본 기계를 추상화 한 것입니다. 마이크로 소프트 베이직 (애플의 오리지널 애플 [[Comdome 64])에서 프로그래밍을 시도하여 그 사고 방식에 대한 아이디어를 얻을 수있다.

Dijkstra가 주장한 것은 일을 단순하게 유지하는 것이 모든 곳을 뛰어 넘지 않고 대신 일반적인 결말로 더 간단한 프로그램 경로를 유지한다는 것입니다. 예를 들어 메소드에서 리턴합니다. 다시 말해, 글로벌 점프가 아닌 로컬 점프 만합니다.

이것은 인수로 메소드 호출, 코드 모듈화, 패키지 등 소프트웨어 개발의 복잡성을 해소하기 위해 도입 된 것들을 도입하는 단계였습니다. 고토 성명은 그 전쟁에서 처음으로 방관자였습니다.