우리 직업에서는 익숙하지 않은 코드베이스로 작업하는 것이 일반적입니다. 새 프로젝트에 참여하거나 대규모 프로젝트에서 이전에 손대지 않은 부분을 작업해야 할 때마다 이런 일이 발생합니다.  이러한 현상은 개발자가 버그를 수정해야 하는 경우에만 국한되지 않습니다. 새로운 기능을 디자인해야 하는 솔루션 설계자일 수도 있고, 자유 시간에 GitHub 문제를 작업하는 OpenSource 기여자일 수도 있습니다. 그러므로 나는 다른 사람들에게 도움이 될 수 있도록 상황에 어떻게 접근하는지 설명하고 싶습니다.  예시 문제  요점을 설명하기 위해 오픈 소스 프로젝트에서 새로운 기능을 요청하는 일반적인 GitHub 문제를 사용하겠습니다.  Hazelcast에서 일하는 동안 저는 해커톤에서 작업하기 위해 소위 "좋은 첫 번째 이슈"를 정기적으로 스캔했습니다. 나는 결코 그런 해커톤을 운영할 수 없지만 그것은 요점을 벗어난 것입니다. 내 생각은 오픈 소스에 기여하는 데 관심이 있는 사람들이 코드 기반에 익숙해지도록 돕는 것이었습니다.  당시 저는 다음과 같은 흥미로운 문제를 발견했습니다.  getQuiet 작업   에 대한 지원을 추가하시겠습니까? http://ehcache.org/apidocs/net/sf/ehcache/Cache.html#getQuiet(java.lang.Object)  아이디어는 항목을 건드리지 않고도 항목을 얻을 수 있다는 것입니다. 즉, 마지막으로 액세스한 타임 스탬프를 업데이트하지 않는다는 의미입니다.  그 뒤에 있는 사용 사례는 해당 키의 제거를 변경하지 않고 키의 존재를 모니터링할 수 있는 것입니다.  --  분산 맵: getQuiet 작업에 대한 지원 추가  OpenSource 기여자로서 작업에 어떻게 접근해야 합니까?  다이어그램 작성이 핵심입니다  문서화는 새로운 프로젝트를 시작하기 위한 첫 번째 단계입니다. 일반 프로젝트에서는 문서가 누락되거나 불완전하거나 부분적으로(전체는 아니더라도) 오해의 소지가 있을 수 있습니다. 해커톤에서는 자세히 읽어보기에는 시간이 너무 짧을 수 있습니다.  성공적인 오픈 소스 프로젝트에는 일반적으로 좋은 문서가 있습니다. 그러나 문서는 주로 사용자를 대상으로 하며 개발자를 대상으로 하는 경우는 거의 없습니다. 그러한 경우에도 문서에서 문제를 해결할 가능성은 낮습니다.  이러한 이유로 나의 진입점은 다이어그램을 그리는 것입니다. 일부 도구는 코드를 리버스 엔지니어링하고 자동으로 다이어그램을 그릴 수 있지만 일부러 사용하지는 않습니다. 수동으로 다이어그램을 그리면 자동으로 생성된 다이어그램에 비해 많은 이점이 있습니다.  당면한 문제와 관련된 코드 영역에 중점을 둡니다.  이는 서랍자가 유일한 진실의 원천인 코드를 읽고 이해하도록 강제합니다.  이는 코드의 정신적 모델을 구축합니다.  나중에 액세스할 수 있도록 조사 결과를 문서화합니다. 그러나 기본 코드가 발전함에 따라 문서화 가치는 시간이 지남에 따라 감소합니다.  문제의 코드에 대한 다이어그램을 만들어 보겠습니다. 먼저 리포지토리를 로컬로 복제하여 선호하는 IDE에서 엽니다. 유일하게 필요한 기능은 메서드 호출을 클릭하면 해당 메서드로 연결된다는 것입니다.  다이어그램 자체에 대해서는 구식이라고 부르지만 다음 두 가지 이유로 여전히   선호합니다. UML 시퀀스 다이어그램을  나는 그들에 대한 경험이 있습니다.  의미론은   것이 아니라 UML을 아는 사람들 사이에서 어느 정도 공유됩니다. 임시적인  더 이상 고민하지 않고 다음과 같습니다.   다이어그램을 그리면 문제가 있는 위치를 매우 빠르게 찾을 수 있습니다.   public abstract class AbstractCacheRecordStore<R extends CacheRecord, CRM extends SampleableCacheRecordMap<Data, R>> implements ICacheRecordStore, EvictionListener<Data, R> { protected long onRecordAccess(Data key, R record, ExpiryPolicy expiryPolicy, long now) { record.setAccessTime(now); // 1 record.incrementAccessHit(); return updateAccessDuration(key, record, expiryPolicy, now); } //... }    는 마지막 액세스 시간의 업데이트를 트리거하는   읽습니다. DefaultRecordStore Record  문제 해결은 이 게시물의 범위를 벗어납니다. 최상의 솔루션을 개발하려면 전반적인 디자인에 더 익숙한 사람들과 대화해야 합니다. 해커톤의 좋은 접근 방식은 먼저 최소한 두 가지 대안을 제공하고 각각의 장단점을 문서화하는 것입니다.  툴링의 경우 다양한 대안을 사용할 수 있습니다. 내 기본 설정은   로 이동합니다. PlantUML    과   제공합니다. 웹 앱 Docker 컨테이너를  SVG 또는 PNG 이미지를 생성합니다.  스킨 가능해요  오픈 소스이며 무료입니다.  정기적으로 관리되고 있어요  결론  기존 코드베이스를 이해하는 것은 자신의 정확한 기술적 역할에 관계없이 중요한 기술입니다. 다이어그램을 만드는 것은 문서화의 추가적인 이점과 함께 이 목표를 달성하는 데 큰 도움이 됩니다.  나는 UML 다이어그램에 익숙하고 공유 의미 체계를 제공하기 때문에 UML 다이어그램을 좋아합니다.  따라서 코드베이스를 더 잘 이해하려면 단순히 코드를 읽는 것 이상이 필요합니다. 다이어그램을 그려야합니다.   원래 2023년 5월 14일   에 게시되었습니다. A Java Geek

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

이 오디오는 이야기의 원래 언어로 제작되었습니다!

익숙하지 않은 코드베이스에서 작업하는 방법

About Author

코멘트

태그 걸기

이 기사는 다음에서 발표되었습니다.

Related Stories

성공적인 클라우드 마이그레이션을 위한 전체 가이드: 전략 및 모범 사례

볼츠만 뇌 이론에 대한 간략한 소개

이 18가지 개발자 도구로 생산성을 높이세요 🚀🔥

Floki의 Valhalla가 인도 스리랑카 투어의 보조 후원자로 합류

성공적인 클라우드 마이그레이션을 위한 전체 가이드: 전략 및 모범 사례

볼츠만 뇌 이론에 대한 간략한 소개

이 18가지 개발자 도구로 생산성을 높이세요 🚀🔥

Floki의 Valhalla가 인도 스리랑카 투어의 보조 후원자로 합류

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps