DAU Library

// 이 서평은 클린 코드의 원칙을 지키기 위해 부단히 노력했습니다. public class 같이 일하고 싶은, 매력적인 개발자를 위한 레시피 { public void 들어가며() { 처음 코딩을 공부하는 어떤 친구가 있습니다. 방구석에서 혼자 머리를 싸매다 보니 마침내 처음으로 자신만의 프로그램을 만들게 됐군요. 자신감이 차오릅니다. 그러다 보니 어느새 주변 사람들과 협업을 할 기회가 생겼습니다. 열정 넘치는 팀원들과 야심 찬 계획을 구상하고, 회의에 회의를 거듭하며 여물지 않은 아이디어들을 구체화합니다. 지금까지 고생하면서 터득한 지식이 빛을 발하기 시작하네요. 괜스레 뿌듯         해집니다. 그들과 코드를 섞기 전까지는 말입니다. } public void 개발자의 본분() { 지금까지 여러 협업을 진행하면서 가장 어려웠던 것은 기술적인 문제가 아니라 팀원 간의 의사소통이었습니다. 아무런 소통 없이 무아지경으로 작성했던 코드는 개발 기간이 길어지고 서비스가 확장될수록 원인 불명의 무수한 에러를 비바람처럼 몰고 왔습니다. 여러 시행착오 끝에 이러한 생각에 도달했습니다. 개발자는 무언가를 구현하여 문제를 해결하는 사람이기 이전에, 어쨌든 다른 사람들과 함께 일하는 사람이라는 사실을요. 그러므로 저는 좋은 팀원이 되고 싶었고, 그것을 위해 좋은 코드를 작성할 수 있는 능력부터 길러야 한다는 생각으로 이 책을 공부하게 되었습니다. } public void 좋은 코드 작성의 어려움() { “좋은 코드”란 무엇일까요? 이것은 저마다 다른 경험에 기반한 기준이 있기에 단칼에 정의 내리기가 힘든 부분입니다. 하지만 무수한 의견들에서 엑기스를 뽑아본다면, 누가 보더라도 화가 나지 않는 코드 두 번 일하게 만들지 않는 코드 명확하고 쉬운 코드 …로 정리할 수 있겠습니다. if (“좋은 코드”.equals(”좋은 소설”)) { 저자는 좋은 코드는 술술 읽히는 좋은 소설과 같다고 주장합니다. 좋은 코드는 가독성이 좋은 소설처럼 짜임새가 있고 쉽게 읽을 수 있기 때문이죠. 따라서 저자가 코드 작성에 가장 중요시하는 키워드는 가독성이라 할 수 있습니다. 소설의 기-승-전-결 구조처럼, ‘원칙’-’패턴’-’코드에 적용’ 전개 방식을 통해 나쁜 코드를 좋은 코드로 개선하는 방법을 안내합니다. 이러한 형식들은 개발자들에게 어떠한 규칙을 적용함으로써 프로젝트의 무질서함을 방지하고 개발자가 자신의 역할에 집중할 수 있도록 도움을 줍니다. } else { 하지만 “좋은 코드”를 확실하게 정의하기 힘이 들듯이, 책에서 안내하는 방식을 그대로 적용하기에는 어려운 부분이 많았습니다. 스파게티처럼 얽혀진 코드를 유연하게 풀어내는데 좋은 길잡이가 될 수는 있지만, 개발 요구 사항의 잦은 변경과 서비스 확장 과정에서 아래와 같은 문제가 발생했습니다. 코드 원칙에 집착하여 생산성 저하 코드 유지보수와 테스트에 대한 부담 팀원들에게 학습 요구량 증가 경직된 분위기로 인한 창의성 감소와 의욕 저하 형식에 대한 지나친 집착이 오히려 팀원들의 사기를 저해하는 역효과로 이어진 것입니다. } } public void 마치며() {         \”Leblance’s Law 나중은 절대 오지 않는다. 한번 작성한 쓰레기 코드를 나중에 수정하는 일은 결코 없다.\” 그러나 이러한 과정에서 분명히 알 수 있었던 것은, 적어도 우리가 좋은 코드를 작성하기 위한 상호 간의 노력을 했다는 점입니다. 나만 보는 코드가 아닌, 남이 봐도 좋은 코드를 만들기 위한 배려의 시작으로써 큰 의미가 있었다고 생각합니다. 개발자들이 좋은 코드로의 개선을 위한 습관을 들이는 것은 팀뿐만 아니라 개발자 생태계에도 좋은 문화를 가져올 것이라고 믿습니다. 언젠가 업무를 하다 보면 그동안 쌓아왔던 지식과 비즈니스적 요구가 충돌하는 상황을 분명히 맞이하게 될 것입니다. 형식과 현실 사이에서 어느 것을 어느 정도까지 취할지 판단할 수 있는 유연한 사고를 기르기 위해, 여러 방법론을 도입해보는 것은 결코 나쁘지 않은 선택이었습니다. } /** 추천 대상: 협업 프로젝트를 진행하고자 하는 개발자, 코드 개선 방법의 지침서가 필요한 개발자.     주의 사항: Java 관례에 의존성이 커서 다른 언어의 코드 원칙과 일치하지 않을 수 있음. 1~14장까지만 읽어보는 것을 권장함. */ }