detected dubious ownership in repository at ‘경로’ ‘경로’ is on a file system that does not record ownership To add an exception for this directory, call:
git config --global --add safe.directory 경로
detected dubious ownership in repository at ‘경로’ ‘경로’ is on a file system that does not record ownership To add an exception for this directory, call:
git config --global --add safe.directory 경로
읽기 쉬운 코드를 길벗 리뷰어에 당첨되어 읽기 쉬운 코드를 읽어봤습니다.
내용이 재미있어 총 3번 정도 읽었는데, 소설책을 읽는 것처럼 쓱쓱 읽혀졌습니다.
예제 샘플은 C# 으로 되어있지만,
C# 은 자바와 비슷한 문법과 코드 형태를 가지고 있어,
코드 읽는데는 큰 문제는 없었습니다.
『읽기 쉬운 코드』라는 책 제목은 개발자라면 꼭 한번 읽어야할 듯한 제목을 가지고 있습니다.
자기의 코드 조차도 읽기 어려워 하는 사람도 만나봤고,
남의 코드는 절대 못읽는 사람도 개발을 하다보면 경험해봤습니다.
이 사람은 남의 코드를 자신의 코드를
그리고 나의 코드가 과연 다른 사람에게 읽기 쉬울까? 라는 고민은 개발을 좋아하는 코더라면 자주 생각하는 영역일겁니다.
(코더라는 말을 비하의 언어로 쓰지 않는다면 말이죠. )
이 책은 코드의 가독성과 유지 보수성을 높이기 위한 다양한 방법을 제시하고 있습니다.
이 책을 통해 저자는 코드의 품질을 높이는 것이 얼마나 중요한지,
그리고 이를 위해 개발자가 어떤 노력을 기울여야 하는지를 명확하게 전달합니다.
책은 소설책을 읽는 듯 본인의 경험담과,
개발자의 실수,
본인이 그래서 어떻게 그걸 해결하기 위해 노력했는지 순으로,
독자에게 친근하게 설명합니다.
코드는 작성하는 것보다 읽는 경우가 더 많다라는 부분에서
사람의 뇌는 컴퓨터가 가진 한계와는 완전히 다른 인지적 한계를 가지고 있다고 설명합니다.
컴퓨터는 프로그래머가 참조하도록 만든 정보만 사용해서 결정을 내리지만,
우리의 뇌는 성급하게 결론을 내리는 경향이 있습니다.
눈에 보이는 것이 전부인 사람이, 그런 개발자가 소프트웨어가 원하는 대로 동작하게 만들려면 당연히 코드를 작성해야 합니다.
그러므로 코드는 우리 뇌에 맞게 구조화해야하며, 코드는 반드시 인간 친화적이어야 합니다.
예전에는 메모리를 위해 어떻게 코드를 짧게 작성해야하는지를 고민했다면,
이제는 컴퓨터 성능이 좋아졌으니, 얼만큼 가독성을 높게 작성해야할지를 고민해야할 시대라는 생각이 들었습니다.
이해하기 어려운 코드는 작업 속도를 느리게 만듭니다.
반면 코드를 이해하기 쉽게 만드는 데 투자한 시간은 나중에 10배 이상으로 보상받게 됩니다.
책은 기존 코드베이스에서 지속적 배포를 다시 적용하는 어려움을 강조합니다.
코드는 작지만, 그 안에서 발생할 수 있는 문제들은 무궁무진하고,
보통 사이드 이펙트라고 한 가지 문제를 해결하면 다른 곳의 2개의 문제가 생기거나,
모든 문제가 해결된 것은 아니기 때문에 지속적인 개선과 유지 보수가 필요합니다.
이는 개발 현장에서 발생하는 다양한 문제들을 해결하는 데 있어 지속적인 노력이 필요하다는 점을 상기시켜 줍니다.
『읽기 쉬운 코드』는 읽기 쉽고 유지 보수하기 쉬운 코드를 작성하는 것이 얼마나 중요한지를 강조합니다.
책은 프로그래밍 언어의 기본적인 구조와 속성을 다루며,
객체지향형 프로그래밍 언어의 강점을 최대화하는 방법을 소개합니다.
이 과정에서 개발자 간의 협업이 필수적이며, 컴파일, 테스트, 디버깅,
배포 과정에서 발생하는 여러 가지 오류들을 체크하고 문제를 해결하는 것이 중요하다는 다시한번 고민해봅니다.
책은 코드의 가독성과 유지 보수성을 높이기 위해 다양한 팁과 방법을 제시합니다.
예를 들어, 코드를 작성할 때 좋은 작명 규칙을 따르고,
코드 리뷰를 통해 문제를 조기에 발견하며, 버전 관리 시스템을 효과적으로 사용하는 방법 등에 대해서도 간략하게나마 설명합니다.
저자는 코드가 단순히 실행되는 것을 넘어서, 사람이 쉽게 이해할 수 있도록 작성되어야 한다고 강조합니다.
이는 특히 팀으로 협업할 때 중요한데,
새로운 팀원이 기존의 코드를 빠르게 이해할 수 있어야 새로운 기능을 추가하거나 기존 코드를 수정하는 데 어려움이 없기 때문입니다.
책은 이론적인 설명뿐만 아니라, 실제 예제를 통해 개념을 적용하는 방법을 보여줍니다.
이 과정에서 코드의 가독성을 높이는 다양한 방법을 직접 경험할 수 있을거라 기대하였습니다.
책은 또한 유지 보수와 버그 관리를 어떻게 효과적으로 할 수 있는지에 대해서도 다룹니다.
예를 들어, 버그가 발생했을 때 이를 우선적으로 해결하고, 결함을 쌓아두지 말 것을 권장합니다.
이는 린 소프트웨어 개발의 품질 내재화 원칙과도 일맥상통합니다.
저자는 코드가 제대로 동작하지 않는 이유를 이해하고, 이를 해결하는 과정을 통해 새로운 통찰력을 얻을 수 있다고 설명합니다.
이 책은 프론트, 백엔드 가리지 말고 한번 읽어보면 생각을 많이 하게 되네요.
특히 팀으로 협업하며 개발을 진행하는 실무자들에게 큰 도움이 될 것입니다.
또한 예비 개발자들에게도 읽기 쉬운 코드의 중요성을 깨닫게 하고, 더 나은 개발자가 되는 데 큰 도움이 될 것입니다.
너무 많은 내용을 담으려다보니, 내용이 요약되거나 함축적으로 처리되는 부분이 많습니다.
예를 들어 저는 린 소프트웨어에 대해서는 잘 모르지만,
린 소프트웨어와 일맥상통한 부분이 있습니다와 같이 비교대상으로 사용되었을 때,
린소프트웨어에 대한 추가공부가 필요했습니다. 그게 나쁘다는 것보다는,
코드리뷰, 깃 사용법 등 하나하나만으로도 책이 나올 이야기를 다 담으려다보니,
경력자에게는 읽기 쉬운 내용이나, 초급자에게는 추후 경력이 쌓이면 다시 한번 읽어보면 다른 느낌이 들 책으로 느껴졌습니다.
또한 콘웨이의 법칙을 엄청 좋아하는 저에게 콘웨이의 법칙을 설명할때,
시스템을 설계하는 조직은 필연적으로 해당 조직의 커뮤니케이션 구조를 복제한 설계 구조를 만들어낼 수 밖에 없다.
라는 번역이 되어있었는데, 조금 난해하게 설명한(번역된) 부분이 있다고 생각합니다.
아마 논문 그대로를 번역하기 위해서라고 생각하겠지만,
시스템을 설계하는 조직은 그 조직의 커뮤니케이션 구조를 반영한 설계를 하게 됩니다로 외우고 있는 저도 몇번을 읽어봐야 뜻이 이해가 되었습니다.
그럼에도 이 책이 좋다고 생각이 든 이유는,
왜 제대로 동작하지 않는지 이해하지 못한다면,
일단 그 이유를 이해하는 데 주력해야 해야하며,
‘우연에 맡기는 프로그래밍’이 진행되는 것을 막자는 저자의 의도가 너무 명확했습니다.
코드가 왜 동작하는지 이해하지 못하거나, 실제로는 제대로 동작하지 않는다는 것을 진짜로 이해하지 못하는 개발자들을 많이 봐와서,
처음부터 코드를 이해한다면 문제를 더욱 쉽게 해결하자는 강한 의지가 느껴졌습니다.
문제를 설명하는 것만으로도 새로운 통찰력을 얻을 수 있습니다.
동료가 없다면 고무 오리에게 문제를 설명해보는 것도 좋다는 글도 재미있게 읽었습니다.
한 프로그래머가 고무 오리를 사용했기 때문에 이 기법은 고무 오리 디버깅이란 이름으로 알려져 있으며,
저는 요즘은 제가 정리하거나 궁금한 부분을 ChatGPT에 물어보게 됩니다.
그래서 이 책이 좋다고 느껴졌습니다.
코드를 작성하는 접근 방식을 다시 한번 생각해보았고,
더 나은 코드를 작성하기 위해 노력해야겠습니다.
당신의 코드는 생각보다 많이 죽어있다.
라는 제목으로 Naver Deview 2023 발표가 있었습니다.
요약된 내용은 아래와 같습니다.
시스템이 나이를 먹어갈수록 API client들이 서비스를 중단하거나,
기획 스펙 아웃 등의 여러 사유로 인하여 더 이상 사용되지 않는 코드(이하 데드 코드)가 늘어갑니다.
내 API를 사용하던 client들이 사용 중단을 알려주면 좋겠지만,
대부분 사용을 하지 않게 되었다는 사실을 API 제공자에게 알려주지 않습니다.
이런 데드 코드를 주기적으로 확인하고,
청소해 주면 시스템을 쌩쌩하게 유지할 수 있겠지만,
혹시나 이 API를 호출하는 클라이언트가 남아 있을지 모른다는 공포감이 데드 코드를 방치하게 하고,
방치된 데드 코드는 암덩어리처럼 자라게 됩니다.
이 암덩어리는 컴파일과 부팅 속도를 지연시키며,
테스트를 느리게 하고,
리팩토링을 힘들게 하는 등, 두고두고 개발자를 괴롭힙니다.
Scavenger는 이런 문제를 해결하고자 만들어진 DevOps 플랫폼이고
이미 70여 개의 크고 작은 네이버 서비스에 적용되어 있습니다.
네이버가 오픈소스로 공개하고 있는 Pinpoint와 유사한 방식으로 시스템 부팅 시에 Java agent만 설정해 주면, 자동으로 어떤 메서드가 언제 마지막으로 호출이 되었고,
어떤 메서드가 더 이상 호출되지 않는 것인지 기록합니다.
그리고 이를 UI를 통해 쉽게 확인할 수 있습니다.
이 발표에서는 이번 DEVIEW를 통해 오픈소스로 공개하는 Scavenger라는 런타임 데드 코드 분석 도구를 소개하고,
네이버 페이 등의 신규 시스템으로 재개발하는 중에 Scavenger를 활용하여 어떻게 몇십만 라인의 데드 코드를 제거했는지 설명합니다.
또한 Scavenger을 구현하는 데 사용한 bytecode instrumentation 등의 기술적 백그라운드에 대해서도 살펴봅니다.
Scavenger를 사용하면 여러분의 Java 코드가 날씬해집니다!
위의 내용에 대한 동영상은 아래와 같습니다.
요약 내용 : https://news.hada.io/topic?id=8610
pdf 문서 링크 : https://deview.kr/data/deview/session/attach/%5B225%5D%EB%9F%B0%ED%83%80%EC%9E%84+%EB%8D%B0%EB%93%9C%EC%BD%94%EB%93%9C+%EB%B6%84%EC%84%9D+Scavenger+-+%EB%8B%B9%EC%8B%A0%EC%9D%98+%EC%BD%94%EB%93%9C%EB%8A%94+%EC%83%9D%EA%B0%81%EB%B3%B4%EB%8B%A4+%EB%A7%8E%EC%9D%B4+%EC%A3%BD%EC%96%B4%EC%9E%88%EB%8B%A4..pdf
github opensource 위치 : https://github.com/naver/scavenger
관련 블로그 등을 검색해봤을 때,
package 또는 class 단위에서 어느 정도의 method가 호출되었는지 확인할 수 있으며,
controller 에 사용하지 않는 API 파악에 매우 도움이 될 것이라고 판단합니다.