나는 '엔진'이 1.3이 아니라 지금 170 만 줄의 코드라고 언급하는 패널 토론을 듣고있다. 그것은 나를 두렵게한다. 나는 그 라인 수, 모듈의 양 등을 상상할 수 없다. 나는 항상 C++이 다른 언어와 마찬가지로 모듈을 처리하지 못한다고 생각했다. 커다란 프로젝트가 관리하기가 어려우며 코드 라인을 합리적으로 줄이는 것이 더 좋았습니다. 내가 10k 라인을 칠 때 나는 불편 함을 느낀다. 나는 20k, 50k, 500k 또는 1 백만이 어떻게 느끼는지를 상상할 수 없다.코드 작성 : 170 만 LOC 프로젝트에 대한 귀하의 의견은 무엇입니까?
이 크기의 프로젝트를 개발하고 유지 관리하는 동안 어떤 실천 사항이 있습니까?
이 크기의 프로젝트를 개발하고 유지 관리하는 데 어떤 실천이 있습니까?
따라서이 크기의 모 놀리 식 프로젝트가 없습니다.
나를 위해 그것은 라인 수는 아니지만 디자인이 얼마나 모듈인지, 모듈이 얼마나 잘 캡슐화되어 있는지. 특정 시점 이후 모듈에서 말하고, 디자인이 무엇인지 파악하고, 기능을 작성하고 버그를 수정하면 코드 줄 수는 중요하지 않습니다. 거의 틀림없이 나는 1 백만 라인의 코드보다 큰 시스템을 연구했다.
이 크기의 프로젝트를 개발하고 유지 관리하는 데 어떤 실천이 있습니까?
글쎄, 개발자에서 아키텍트로 진화하면됩니다.
대용량 소프트웨어 프로젝트의 경우 프로젝트 리더의 관심이 구현시에는 구조 수준에서 좁혀서는 안됩니다. 적절하게 및은 정확하게 구성 요소/라이브러리를 모듈화하고 잘 분리하고 디자인 패턴을 활용합니다.
어떤 유형의 엔진입니까? 게임 엔진이라면 반드시 그래픽, 사운드, 물리학,지도 처리 및 수십 개의 다른 모듈로 모듈화됩니다. 모든 모듈에는 분명히 여러 하위 모듈이 포함됩니다. 즉, 그래픽은 글꼴 렌더링, 효과, GPU 관련 부품 등으로 나뉩니다.
다를 것 같네요. 나쁜 요리사에게 좋은 요리사와 같은 양의 재료 (즉, 제비)를 줄 수 있으며 나쁜 요리사가 당신에게 던져 줄 수있는 것을 제공 할 것입니다. 반면에 좋은 주방장은 맛이 좋고 쉽게 소화 될 수 있습니다.
나는 프로젝트의 유지 보수성을 (줄을 서지 않았으므로) 줄의 관점에서 생각하지 않는다. 프로젝트가 모듈화되고 잘 리팩터링되는 한 그리 좋지 않을 수도 있습니다.
질문에 답하기 위해 큰 코드베이스를 유지하는 데 사용하는 방법은 크기 코드 기반을 유지하는 것과 동일합니다. 자동화 된 빌드를 높은 코드 적용 범위와 통합하는 것이 좋습니다 (시스템 수준 테스트), 코드 가독성 (예 : checkstyle) 및 복제 된 코드가없는 (예 : simian) 도구가 포함되어 있습니다.
프로젝트가 계속 늘어나고 많은 수의 라인에 도달하고 코드베이스를 올바르게 개발하면 클라이언트가 만족 스러우며 더 많은 기능을 원한다는 것을 의미 할 수 있습니다.
1 백만 줄의 코드가 대부분의 필사자가 머리 속에 모두 보관할 수있는 지점을 지나치게됩니다. 즉, 팀원들이 각각 시스템의 불완전한 정신지도를 가지고 다니기 때문에 설계 논의가 어려워 질 수 있습니다.
여러 가지 불완전한 이해를 완화하려면 적절한 구조 다이어그램 집합의 형태로지도가 필요합니다. 여기에는 일반적으로 시스템 아키텍처에 대한 매우 높은 수준의 블록 다이어그램과 핵심 부품에 대한보다 상세한 하위 레벨 다이어그램, 적절한 세부 수준에서 주요 상호 작용을 설명하기위한 시퀀스 다이어그램이 포함됩니다. 이러한 다이어그램을 통해 시스템을 논의 할 때 팀이 "같은 페이지에"있을 수 있습니다.
'하위 시스템 다이어그램 간의 종속성은 정리해야하는 "지루한 영역 (UI에 종속 된!"유형)의 지저분한 영역을 지적 할 수 있습니다. 이 다이어그램의 생성을 자동화하는 방법을 찾아 낼 수 있다면 가장 좋습니다. Graphviz는 친구가 될 수 있습니다.
이 크기의 프로젝트를 개발하고 유지 관리하는 데 어떤 실천이 있습니까?
큰 소프트웨어 프로젝트를 관리하기위한 생각의 많은 학교가 있으며, 분명히 크게 프로젝트의 유형에 따라 다릅니다
이자금 지원 소프트웨어 개발은 처음부터 정식 프로세스를 사용하는 경향이 있습니다. "애호가"프로젝트는 페인트 포인트를 표시 할 때 필요한 실습 만 채택하는 경향이 있습니다.
다른 사람들에 의해 지적 된 바와 같이 그 규모의 프로젝트는 필연적으로 팀의 노력이며, 직면 한 많은 과제는 활동을 조정하고 혼란을 제한 할 필요성에서 온 것입니다.
그러나 그들은 모두 같은 "전술적"관행을 사용하여 복잡성을 처리하는 경향이 있습니다. 유용한/필수 관행에 대한 이해를 얻으려면 Joel Test에 대한 소개를 읽어 보시기 바랍니다.
그의 엔진 코드는 1.7 줄입니까? 그는 Perl을 사용해야합니다. – rlbond
그 사람이 '엔진'이 ** C++ **의 1.7 줄임을 명시 했습니까? 아니면 토론에 참여한 사람입니까? –
알려진 엔진입니다. 그는 C++ 및 일부 C 언어를 사용했습니다. –