지난주 CppJieba 사용자의 이메일 문의에서 영감을 받아(저도 왜 그렇게 많은 사람들이 여전히 issue가 아닌 이메일로 문의하는지 궁금합니다), CppJieba 코드를 리팩토링하여 각 API를 고도로 통합했습니다. 사용자에게 더 간단하고 쉽게 접근할 수 있게 되었습니다. 그리고 기회를 빌려 CppJieba v3.0.0과 NodeJieba 1.0.0을 모두 발표했습니다.
이 두 가지는 제 GitHub에서 star 수가 가장 많은 두 프로젝트로, 유지 관리한 지도 거의 2년이 되었습니다. 자신의 GitHub를 더 좋게 보이게 하는 것 외에도 수확은 매우 큽니다. GitHub는 전체 IT 업계의 지식 보물창고로, 최근 몇 년간 가장 많은 지식을 배운 것은 거의 모두 GitHub의 오픈소스 프로젝트에서였습니다.
자주 학생들이 오픈소스 프로젝트를 어떻게 배우는지 물어봐서, 마침 블로그 글을 써서 오픈소스 프로젝트를 배우는 몇 가지 방법을 이야기하겠습니다.
처음에는 모두 매우 초라합니다
그날 저는 Node.js 코드 고고학에 대한 웨이보를 올렸습니다:
소프트웨어 고고학은 정말 재미있습니다. 아주 오래된 버전으로 checkout하면, Node가 처음 시작할 때의 Makefile을 볼 수 있고, 갑자기 게임의 간단 모드를 연 것 같은 느낌이 듭니다.
그때 아주 짓궂은 흥분감이 있었습니다. 왜냐하면 Node.js의 처음도 매우 초라하다는 것을 발견했기 때문입니다. 하지만 초라함은 종종 단순함을 의미합니다. 예를 들어, 처음 Node.js는 Makefile로 관리되었습니다. 모든 컴파일 가능한 파일이 명확했습니다. 지금의 node-gyp가 아니라, 소스 코드 덩어리가 많아서, 이 파일들 사이의 관계를 이해하는 데만 오래 걸립니다.
이것은 제가 처음 CppJieba를 쓸 때와 같습니다. C++ 언어 표준 라이브러리의 결함 때문에, C++11 보급이 잘 안 되고, 많은 일반적인 기능 라이브러리를 모두 boost 같은 라이브러리를 사용합니다. 저와 같은 느낌을 받는 사람이 많은지 모르겠습니다. C++ 코드를 사용할 때마다 가장 짜증나는 것은 다양한 의존 코드를 설치해야 한다는 것입니다. 그리고 의존 코드의 버전 문제로 설치가 실패하는 경우도 많습니다. 이런 상황은 Linux에서 특히 심각해서, vczh가 심지어 linux에서 소프트웨어 설치를 풍자했습니다. “보는 것은 사용 설명서가 아니라 사용 공략입니다.”
그래서 저는 처음부터 어떤 제3자 라이브러리에도 의존하지 않기로 결정했습니다. 필요한 함수는 모두 직접 작성했습니다. 그래서 제가 자주 사용하는 C++ 라이브러리 limonp가 탄생했습니다. 처음에는 코드가 매우 초라했지만, 적어도 제 프로그램은 어떤 의존 라이브러리도 설치하지 않고 실행할 수 있어 초경량이었습니다. 물론 단위 테스트는 gtest에 의존했지만, gtest 소스 코드를 자신의 프로젝트 코드에 병합했습니다.
사실 이것이 매우 중요하다는 것이 증명되었습니다. 여전히 그 말입니다. 의존이 없으면 상처도 없습니다. 그리고 나중에 ideawu의 SSDB도 마찬가지였습니다. 이런 오픈소스 프로젝트야말로 사용자 경험을 중시하는 오픈소스 프로젝트입니다.
자신의 코드 조각을 축적하는 데 능숙하세요
저는 practice라는 프로젝트가 있어, 자신의 코드 조각을 축적합니다. 새로운 기술을 접할 때 작은 연습 코드를 작성해야 하면, 연습 코드를 이 저장소에 넣습니다. 사실 때로는 이런 작은 조각이 큰 프로젝트의 씨앗입니다. Node.js 코드 고고학에서 볼 수 있듯이, 처음 Node.js도 저자의 실험적 코드였습니다. JavaScript로 비동기 IO 서비스를 작성하는 실험적 코드의 일종이었습니다. (처음에는 서비스가 요청을 받으면 js 소스 파일을 읽고, 실행 결과를 반환하는 것만 구현했습니다.)
예를 들어 제가 작성한 간단한 HTTP 서버도 작은 실험적 코드로 조립되었습니다. 예를 들어 socket 송수신, HTTP 헤더 파싱, BlockingQueue로 스레드 풀 구성 등입니다. 이것은 모두 일반적인 코드지만, 조립하면 하나의 프로젝트가 됩니다. 그리고 이런 코드 조각을 작성하는 것은 새로운 기술을 배우는 데 매우 도움이 됩니다. 나중에 다시 볼 수도 있고, 지금 GitHub라는 좋은 커뮤니티가 있어 예전에 프로그래밍을 배울 때보다 훨씬 편리합니다.
선인의 어깨 위에 서는 데 능숙하세요
이것은 잘 이해할 수 있습니다. 다른 사람의 분석 문서를 잘 활용하는 것입니다. 예를 들어 Redis 소스 코드를 깊이 읽으려면, 먼저 《Redis 설계와 구현》을 읽고 소스 코드를 보는 것이 좋습니다. 마치 미로를 걸을 때 다른 사람이 지도를 준 것과 같아서 훨씬 쉬워지고, 길을 따라 풍경도 감상할 수 있습니다.
하지만 이해가 안 되는 것은 왜 많은 사람들이 굳이 읽는 것을 좋아하는지 모르겠습니다. 저는 아주 새로운 오픈소스 프로젝트를 만나서 관련 선인의 문서를 검색할 수 없을 때만 어쩔 수 없이 읽습니다. 하지만 지금은 오픈소스 프로젝트 저자들이 모두 문서를 중시해서, 일반적으로 소스 코드 문서를 자발적으로 작성합니다.
학습 관점에서 볼 때, 오픈소스 프로젝트는 star 수가 많을수록 좋은 것이 아닙니다
오픈소스 프로젝트는 star 수가 많을수록 좋은 것이 아니라, 당신에게 더 읽기 쉬울수록 좋습니다. 일반적으로 현재 하는 업무와 가장 가까울수록 읽기 쉽습니다. 하는 업무와 가까울 때, 소스 코드를 읽으면 개발이나 리팩토링 영감을 얻을 수 있습니다. 심지어 파일 이름, 클래스 이름, 소스 코드 주석만 봐도 어떤 기술을 사용했는지 알 수 있고, 관련 기술의 논문 등을 검색하여 자세히 연구할 수 있습니다. 이것은 모두 매우 도움이 됩니다.
읽는 소스 코드가 자신의 업무 내용과 전혀 관련이 없으면, 이해도 불충분하고, 며칠 지나면 잊어버립니다. 기본적으로 자랑할 때 과시용으로만 남습니다.
일방적으로 고성능 코드를 보는 것은 사실 좋지 않습니다. “코드는 사람이 보기 위해 작성되고, 부수적으로 기계에서 실행될 수 있을 뿐입니다.” 하지만 많은 스타 오픈소스 프로젝트는 성능이 너무 중요해서, 때로는 고성능을 실현하기 위해 가독성을 약간 희생해야 합니다. 그리고 star 수가 많은 스타 프로젝트는 고려해야 할 것이 많고, 호환성, 운영 용이성 등 모두 적지 않은 코드량입니다. 그리고 이것은 사실 프로젝트의 핵심이 아닙니다. 소스 코드를 읽을 때는 핵심을 더 읽기 쉬울수록 좋습니다.
약간의 생각
최근 오픈소스 프로젝트 저자가 점점 더 인기를 끌어, 오픈소스 프로젝트가 점점 더 공리적으로 변하고 있다고 느낍니다.
오픈소스 프로젝트의 취지를 잊지 않기를 바랍니다. 지식의 더 나은 공유와 전파를 위한 것입니다.
재게시 출처: 개발자 관계 »
