쿼리를 검색할때마다 창을 계속 띄우도록 하는 데이타그립 설정

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에 물어보게 됩니다.

그래서 이 책이 좋다고 느껴졌습니다. 코드를 작성하는 접근 방식을 다시 한번 생각해보았고,
더 나은 코드를 작성하기 위해 노력해야겠습니다.