당황하게도 저는 수십 년 전 팀 환경에서 "공통"라이브러리를 소개했습니다. 나는 몇 개월 만에 느슨하게 조정 된 팀 환경에서 일어날 수있는 역학을 실제로 이해하지 못했습니다.
내가 그것을 소개했을 때 나는 그것을 명확하게 생각하고 또한 우리가 매일 우리가 유용하다고 생각하는 것들, 그것이 미니멀리스트 도서관이되도록 의도되어 있으며, 도서관은 도서관 이외의 다른 것에 의존해서는 안된다는 것을 문서화했다 새로운 프로젝트에서 가능한 한 쉽게 배포 할 수 있도록 표준 라이브러리. 당시 제 생각은 그것이 특정 영역에서 우리가 매일 유용하다고 생각한 것들에 대한 표준 라이브러리에 대한 우리의 작은 확장이었습니다.
그리고 그것은 충분히 시작되었습니다. 우리 common/math*는 선형 대수학에서 종종 무거운 컴퓨터 그래픽 작업을하고 있었기 때문에 우리 모두가 일상적으로 사용 하는 수학 라이브러리 ( )로 시작했습니다 . 그리고 우리는 종종 C 코드로 interoping 된 이후, 우리는 몇 가지 유용한 유틸리티 기능에 합의처럼 find_index하는 달리std::findC ++에서는 C 함수의 작동 방식을 모방 한 반복자 대신 시퀀스에서 찾은 요소에 색인을 반환합니다.이 종류의 것들은 약간 절충 적이지만 미니멀하고 널리 사용되어 모든 사람에게 친숙하고 실용적입니다. , "공통"또는 "표준"을 만들려고 할 때 즉각적인 친숙 함은 매우 중요한 기준입니다. 왜냐하면 그것이 "공통적"이라면, 그 결과에 대해 친숙한 품질을 가져야하기 때문입니다. 채택 및 일일 사용.
그러나 시간이 지남에 따라 사람들이 개인적으로 사용하는 것을 추가하기 시작하면서 다른 사람이 사용할 수 없다고 생각하면서 라이브러리를 사용하려는 사람을 찾기 위해 라이브러리의 디자인 의도가 손가락에서 벗어났습니다. 그리고 나중에 누군가는 일반적인 GL 관련 루틴을 위해 OpenGL에 의존하는 기능을 추가하기 시작했습니다. 또한 우리는 Qt를 채택했고 사람들은 Qt에 의존하는 코드를 추가하기 시작했습니다. 그래서 이미 공통 라이브러리는 두 개의 외부 라이브러리에 의존했습니다. 어느 시점에서 누군가는 응용 프로그램 특정 셰이더 라이브러리에 의존하는 일반적인 셰이더 루틴을 추가했으며 그 시점에서 Qt, OGL 및 응용 프로그램 별 셰이더 라이브러리를 가져 와서 작성하지 않고 새 프로젝트에 배포 할 수도 없었습니다. 프로젝트를위한 사소한 빌드 스크립트 그래서이 절충되고 상호 의존적 인 혼란으로 바뀌 었습니다.
그러나이 라이브러리에 들어가야 할 것과 그렇지 말아야 할 것에 대해 토론함으로써 "공통"으로 간주되는 것이 "공통"이 무엇인지에 대한 엄격한 규칙을 설정하지 않으면 매우 주관적인 아이디어로 쉽게 변할 수 있다는 것을 발견했습니다. 모두가 매일 유용하다고 생각하는 것. 표준이 느슨해지면 모든 사람이 매일 유용하다고 생각하는 것에서 다른 개발자에게 도움이 될 가능성이 있는 단일 개발자가 유용하다고 생각하는 것까지 신속하게 저하되며 , 그 시점에서 라이브러리는 매우 빠른 절충안으로 분해됩니다. .
그러나 그 시점에 도달하면 일부 개발자는 프로그래밍 언어가 마음에 들지 않는 간단한 이유로 추가를 시작할 수 있습니다. 그들은 for 루프 또는 함수 호출의 구문을 좋아하지 않을 수 있습니다.이 시점에서 라이브러리는 언어의 기본 구문과 싸우는 것들로 가득 차기 시작하여 실제로는 그렇지 않은 몇 줄의 간단한 코드 줄을 대체합니다. 이러한 속기를 소개 한 개발자에게만 익숙한 하나의 이국적인 코드로 로직을 복제합니다. 그런 개발자는 그러한 속기를 사용하여 구현 된 공통 라이브러리에 더 많은 기능을 추가하기 시작할 수 있습니다. 이 시점에서 공통 라이브러리의 중요한 부분은이 이국적인 속기들과 짜여져 있습니다.이 속기들을 소개 한 개발자에게는 아름답고 직관적으로 보일 수 있지만, 추악하고 외국적이고 다른 사람들에게는 이해하기 어렵습니다. 그리고 그 시점에서 나는 "공통"과 "낯선"이 정반대의 아이디어이기 때문에 진정으로 "공통"을 만드는 것에 대한 희망이 사라진다는 것을 알고 있다고 생각합니다.
최소한 느슨하게 조율 된 팀 환경에는 모든 종류의 웜 캔이 있습니다. 라이브러리는 "일반적으로 사용하는 것"만큼 광범위하고 일반화 된 야망을 가진 라이브러리가 있습니다. 그리고 근본적인 문제는 다른 무엇보다도 느슨한 조정 이었을지 모르지만, 수학 루틴을 제공하기위한 라이브러리와 다른 어떤 것보다 더 특이한 목적을 제공하기위한 적어도 여러 라이브러리는 아마도 그것의 관점에서 크게 저하되지 않을 것입니다 순도 및 종속성을 "공통"라이브러리로 디자인합니다. 그래서 돌이켜 보면 훨씬 더 명확한 디자인 의도를 가진 라이브러리 측면에서 잘못하는 것이 훨씬 낫다고 생각합니다. 또한 수년에 걸쳐 목적이 좁고 적용 가능성이 좁다는 것은 근본적으로 다른 아이디어라는 것을 알았습니다.
또한 나는 적어도 약간 비현실적이며, 미학에 대해 너무 많은 관심을 기울이고 있지만, 도서관의 질 (그리고 아마도 "아름다움")에 대한 내 생각을 인식하는 경향은 그것의 가장 강한, 비슷한 방식으로 당신이 나에게 세상에서 가장 맛있는 음식을 선물했지만 같은 접시에 썩은 냄새가 나는 것을 바르면 전체 접시를 거부하는 경향이 있습니다. 그리고 당신이 저와 같은 점에서 모든 종류의 추가를 "공통"이라고 부르는 것을 만들면, 측면에 썩은 것이있는 그 유사 판을 볼 수 있습니다. 마찬가지로 도서관이 구성되고 이름이 지정되고 문서화되는 것이 좋을 것 같습니다. 시간이 지남에 따라 점점 더 많은 추가를 초대하지 마십시오. 그리고 여기저기서 썩은 것들을 만들었 기 때문에 개인 창작물에도 적용 할 수 있으며, 그것이 가장 큰 접시에 추가되지 않으면 훨씬 덜 오염됩니다. 사물을 작고 매우 특이한 라이브러리로 분리하면 코드를 더 잘 분리하는 경향이 있습니다. 단순히 모든 것을 결합하는 것이 훨씬 편리하지 않다는 장점 때문입니다.
코드 중복 제거 기술은 수년에 걸쳐 나에게 몰려 들었지만 이번에는 시도해보아야 할 것 같습니다.
귀하의 경우에 제안 할 수있는 것은 코드 중복 제거를 쉽게 시작하는 것입니다. 나는 잘 테스트되지 않았고 오류가 발생하기 쉬운 코드의 큰 조각을 복사하여 붙여 넣거나 붙여 넣을 것이라고 말하지 않으며, 미래에 변경이 필요할 확률이 높은 사소한 코드를 복제합니다.
그러나 특히 "공통"라이브러리를 만들려는 마음가짐이 있다면, 여러분이 원하는 것은 광범위하게 적용 가능하고 재사용 성이 높으며 아마도 10 년 전과 마찬가지로 오늘날에도 유용한 것으로 생각되는 것을 만들고자합니다. , 때로는이 어려운 품질을 달성하기 위해 복제가 필요하거나 원하는 경우도 있습니다. 복제가 실제로 디커플링 메커니즘으로 사용될 수 있기 때문입니다. 비디오 플레이어를 MP3 플레이어와 분리하려면 배터리와 하드 드라이브와 같은 것을 복제해야합니다. 그들은 이러한 것들을 공유 할 수 없거나 서로 분리되어 서로 독립적으로 사용될 수 없으며, 그 시점에서 사람들이 MP3 재생 만하면 더 이상 장치에 관심이 없을 수 있습니다. 그러나이 두 장치를 분리 한 후 얼마 지나지 않아 MP3 플레이어는 비디오 플레이어와는 다른 배터리 디자인이나 작은 하드 드라이브의 이점을 누릴 수 있습니다.이 시점에서 더 이상 아무것도 복제하지 않습니다. 이 상호 의존적 장치를 두 개의 독립된 독립 장치로 분리 할 수 있도록하기 위해 처음에 복제로 시작한 것은 나중에 더 이상 중복되지 않는 설계 및 구현을 산출 할 수 있습니다.
라이브러리를 사용하는 관점에서 사물을 고려해 볼 가치가 있습니다. 실제로 사용 하시겠습니까?코드 중복을 최소화하는 라이브러리? 자연스럽게 다른 라이브러리에 의존하기 때문에 그렇지 않을 가능성이 있습니다. 그리고 다른 라이브러리는 코드 복제를 피하기 위해 다른 라이브러리에 의존 할 수 있습니다. 오디오 파일로드 및 재생과 같은 기본 기능을 얻기 위해 50 개의 서로 다른 라이브러리를 가져 오거나 링크해야 할 때까지 매우 까다로워집니다. . 한편, 그러한 오디오 라이브러리가 의도적으로 독립성을 달성하기 위해 여기저기서 일부를 복제하기로 선택한 경우, 새로운 프로젝트에서 사용하기가 훨씬 쉬워지고, 그 이후로 거의 자주 업데이트 할 필요가 없을 가능성이 있습니다. ' 종속 외부 라이브러리가 변경되어 오디오 라이브러리에 필요한 것보다 훨씬 일반적인 목적을 달성하려고 시도 할 수 있으므로 변경해야합니다.
따라서 때로는 라이브러리를 분리하고 독립적으로 만들기 위해 라이브러리를 분리하고 독립적으로 만들기 위해 의도적으로 약간 복제 (의식적으로, 게으름에서 벗어나지 않음-실제로는 부지런함에서 벗어나지 않음)를 선택하는 것이 좋습니다. 심지어 안정성 (심각한 커플 링이 더 이상 없음). 하나의 프로젝트에서 다음과 몇 년 동안 지속될 수있는 가장 재사용 가능한 라이브러리를 디자인하려면 범위를 최소로 좁히는 것 외에도 실제로 여기에 약간의 복제를 고려하는 것이 좋습니다. 또한 자연스럽게 단위 테스트를 작성하고 수행중인 작업에서 철저하게 테스트되고 신뢰할 수 있는지 확인하십시오. 이것은 단지 하나의 프로젝트를 넘어서는 지점으로 일반화하기를 정말로 원하는 라이브러리에만 해당됩니다.