2003년 .NET Framework 1.1로 시작해서 올해로 14년 정도 C#을 사용하여 개발해왔다. 물론 지난 기간 동안 C# 만을 사용해서 개발한 것은 아니다. 14년이면 짦은 시간은 아니지만, 아직도 C#에 대해 모르는 것들이 많다. 문법이나 SDK 에 관한 문제도 있지만, 특히 C#을 효율적으로 사용하는 방법이라든가 적절하면서도 정확하게 사용하는 방법 등이다.

Framework에는 다양한 클래스와 메소드 그리고 옵션들이 존재하는데, 이런 옵션들을 정확하게 다 알고 사용하기란 쉽지 않은 일이다. 기억력이 좋지 않는 나로써는 이전에 익혔던 것들도 간혹 잊어버리는 경우가 허다한 지라 어려움이 많다.

그래서 "C# 코딩의 기술 기본편 : 똑똑하게 코딩하는 방법" 같은 제목을 가진 책들은 구매하고 싶은 유혹에 쉽게 빠진다.

이 책은 래머군, 천사양, 악마씨 3명이 코딩에 대한 대화 형식으로 구성되어 있다. 먼저 래머군이 특정 주제에 대해 자기가 작성한 코딩을 제시하고 천사양과 악마씨가 각각 작성한 코드를 제시하고 티격태격되며 서로의 코드를 설명한다. 거의 천사양 코드가 추천 코드, 악마씨 코드는 완성도가 떨어지거나 좋지 않은 코드로 설정된다.

전반적으로 책에서 서술하는 코딩 기법 자체가 입문자 수준이긴 한데, 이 내용들이 입문자들이 이해하기 쉽게 서술됐는냐로 따진다면 물음표다.

일단 문제 제기에 대한 해결책으로 나온 코드나 방법이 납득할만한 수준의 최적의 솔루션이 아니며, 왜 그렇게 코딩해야 하는가에 대한 의문점을 깔끔하게 해결해주지 못한다. C#을 처음 접하는 개발자들이 이 채을 보고 왜 이렇게 코딩해야하는지에 대한 정확한 이해없이 관습적으로 코딩하지 않을까 하는 걱정이 든다.

예를 들어 예전에 컬렉션을 IEnumerable 인터페이스로 캐스팅하여 MoveNext() 메소드로 값을 가져오는 개발자를 봤다. 그런데 왜 IEnumerable로 캐스팅해서 사용하냐고 물어보면, 다른 소스에서 봤는데요라는 답변이였다. IEnumerable은 Iterator 패턴 인터페이스이다. 따라서 IEnumerable이 구현된 컬렉션은 foreah를 사용하여 값을 가져오면 된다. 구지 IEnumerable로 가져올 필요가 없다.

또 다른 예로 String 형식의 개체에 ToString()를 습관적으로 붙이는 경우도 봤다. 예제 소스에서 ToString()을 쓰니까 그냥 사용한다.  String 형인데 다시 ToString() 메소드 호출은 비효율적일 뿐만 아니라, Primitive 타입이 아니기 때문이 널(null)을 항상 체크하여 한다. 따라서 이 경우처럼 ToString()을 호출하는 것은 NullReferenceException을 불필요하게 발생시킬수 있다는 것이다. 이런 실수를 의외로 많이 봤다.

그리고 또 다른 예로 XSLT를 설명하면서, 스펙이 맞지 않고 최신 구현체가 .NET에 없다는 설명은 좋다. 그래서 XSLT를 사용하지 말것을 권고하는 것도 좋다. 그러면, 다른 해결책은?

필요한 문서를 생성할 때 마다 빌더 클래스를 만들란 건지, 아니면 오픈소스나 상용 리포팅 도구를 사용하란 건지? 사용한다면 레퍼런스 제품은 뭐가 있는지 정도는 알려줘야 하지 않을까?

개인적으로 간단한 문서 변환의 경우 XSLT를 사용한다. 1.0 스펙으로도 왠만한 것들은 구현이 가능하기 때문에 어렵다거나 귀찮은 적은 없다. 내부용을 쓸건데 XSLT를 아예 쓰지 말란 것도 좀 우습다.

yield 키워드를 사용하는 부분도 신중이 결정해야 하는 부분이다. yield 키워드가 지연 처리를 하기 때문에 메모리 관리 부분에서는 좋을 수 있다. 하지만 yield는 느리다. 그리고 yield 가장 적절한 용도는 데이터 무한 공급이 필요한 곳에 가장 적합한 키워드이다. 잘못 사용하면 지옥적인 성능을 맞볼것이다.

코딩에 대한 올바른 길을 제시하려면, 이 코드가 왜 다른 코드보다 나은지에 대한 좀더 깉은 통찰력과 이해력을 증진해야 하고 이를 응용해서 여러 유사 코드를 자유자재로 작성할 수 있도록 도와야 한다. 그런데 이 책은 그런 점에서 만족스럽지 못하다. 대화식으로 그런지 너무 쓸데없는 내용들이 많고 실제 건져야 할 내용이 상대적으로 적다.

항상 장점이 있으면 단점도 있는 법이고 이런 부분을 충분히 설명해야 하는데, 이 책은 그런 부분이 부족하다. 솔직히 예전에 조금 어렵지만, Effective C#이라는 책이 휠씬 좋았던 것 같다.  원서로는 계속 판올림을 하고 있지만, 번역서는 1판에서 나오지 않기 때문에 아쉽다.

총평하자면, 내용이 충분하지 않아 오용의 소지가 있고 해결책이 항상 최적도 아니며, 항상 솔루션이 있는 것도 아니라 입문자에게도 비추. 또한 내용이 깊이 있는 것도 아니라 중급 이상에게도 비추.
그냥 읽어보면 이런 내용이 있구나 정도로만 보면 딱일듯한 책이다.

일단 이 책을 보기 전에 c#에 대해서 어느정도 기초 문법을 알고 보면 편할 것 같습니다.

몰라도 그만? 이라고 생각할 수 있지만
그로 인해서 상당한 성능상의 패널티를 볼 수도 있고, 버그가 생길 수 있는 가능성을 만드는 코딩 습관을 한번 돌아 보게 해주는 책 같다.

전문서적이라 보통 크기의 책을 상상했는데 크기도 일반 소설책 크기이고 내용도 코드를 나열한 일반적인 도서와는 달리 대화형으로 시작해서 문제를 인지하고 그 문제를 해결 하는 간단하는 예제...로 이루어져 있어서

출퇴근 혹은 통학하면서 가볍게 볼 수 있어서 좋았다.

정리하자면 책 내용은 어렵지 않고 간단하면서 몰라도 되지만 알면 나의 가치를 올릴 수 있는 꿀팁을 알 수 있는 책인 듯하다.

평소 elegant 한 코드를 작성하기 위해서 고민을 많이 하는 편입니다.

귀차니스트 개발자로서 코딩 한 줄 덜 하고 싶고, 잘 읽히는 코드를 쓰고 싶습니다.

동료들과 술 한잔 기울일 때는 이런 얘기들을 종종 나누기도 합니다.

다만, 이러한 소통이 제한된 사람들 사이에서만 이뤄지다 보니 '우물안의 개구리'는 아닐까 하는 걱정이 늘 마음 한 켠에 있었습니다.

이 책은 다른 사람의 이야기를 들어 볼 수 있는 기회로 생각했습니다.

나와 어떻게 다른 생각을 하는 지, 어떤 고급진 기술을 사용하는 지 호기심을 해결할 수 있었습니다.

책의 구성

작은 사례들을 기준으로 악마와 천사의 가이드를 받는 주인공이 나옵니다.

악마가 단편적인 해결책을 제시하면, 천사가 원론적인 문제 해결책을 제시하면서 각각의 작은 챕터들이 마무리 됩니다.

주인공 래머군은 실력이 그리 뛰어나지는 않으나, 근본적인 원인 해결 및 재발 방지 대책에 대해서 꼼꼼하게 따집니다.

그래서 늘 악마의 해결책에 만족을 하지 못하죠.

평가

초~초중급의 C# 개발자에게는 꽤 유용할 거라고 보입니다.

책 제목 그대로 '기본편' 인 거죠.

저는 일부 신선한 내용이 있었지만, 대부분은 공감하는 정도로 읽은 것 같습니다.

(개발 경력이 벌써 12년이네요...) 

기본편이라는 서브타이틀을 달고 나온 만큼 '중급편', '고급편'으로 시리즈가 이어진 다면 꼭 또 읽게 될 것 같습니다.

다만 두어건의 사례는 100% 공감하기 어려운 부분이 있습니다. 이건 관점의 차이일 것 같습니다.

일례로, 동료들에게 들었던 제 코드의 문제는 '유지보수가 어렵다'라는 것이 었습니다.

지금은 얘기를 많이 수용하여, 코드의 아름다움이나 간결성을 다소 포기하더라도 Debugging 시의 용이성 등을 고려하고 있습니다.

코드는 개발자의 개성이 드러나는 부분이기 때문에 모두가 공감할 수 있는 Best practice는 없는 거겠죠.