Development/Study

[개발서적] Clean Architecture 정리

Clean Code, The Pragmatic Programmer에 이어 Clean Architecture를 읽었다. Clean Architecture는 처음부터 끝까지 의존관계를 줄이는 방법을 소개하며 이를 통해 Open Closed Principle을 만족하는 유연한 프로그램을 작성하는 방법을 알려준다. 아직까지 느낀 점은 결국 중복을 없애고 DIP를 통해 추상화에 의존하게 작성하면 그것이 좋은 구조다는 것이다. 처음부터 끝까지 dependency에 관해 일관성 있게 이야기하기 때문에 하나 이상의 개발 프로젝트를 진행했던 개발자라면 자신이 진행했던 프로젝트의 구조와 dependency를 생각해 보는 계기가 될 것이다. 앞선 포스팅과 마찬가지로 감명깊게 읽은 부분, 필요하다고 생각하는 부분, 중요하다고..

[개발서적] The Pragmatic Programmer 정리

Clean Code에 이어 The Pragmatic Programmer를 읽었다. 이 책은 개발자로써 어떠한 마음가짐을 가져야 하는지, 어떠한 방법을 사용해야 하는지에 대해 매우 개략적으로만 다룬다. 주변에서 이제 막 프로젝트를 하나 끝낸 개발자 지망생들에게 한 번씩 읽어보라고 추천하고 싶은 책이다. 현대 개발론에서 사용하는 agile, prototype, CICD, TDD, DDD 등에 대한 내용을 한 단락으로 정리하기 때문에 개발하면서 불편했던 점을 이렇게 해결할 수 있구나, 하는 큰 방향성을 제시해 주기 때문이다. Clean Code 포스팅과 마찬가지로 감명깊게 읽은 부분, 내게 필요하다고 생각하는 부분만 간단하게 정리했다. 그 중에서도 중요하다고 느낀 문장은 *를 쳐서 표기했다. 서문 개발자는, ..

[개발서적] 다시 쓰는 Clean Code 정리

개발에 대해 아무것도 모를 때 읽었던 Clean Code와 어느 정도 경험을 쌓고 나서 다시 보는 Clean Code는 느낌이 달랐다. 직접 프로그램을 유지보수하지 않고 개발만 했던 시절에는 모든 내용이 내 머리속에 있었기 때문에 "대체 왜 interface를 사용하는 거지? 굳이? 그냥 수정하면 되는 거 아닌가?"라고 생각했다. 지나고 보니 우매한 생각이었다. 여러 프로그램을 유지보수하다보니 요구사항을 반영할 때 기존 코드를 최소한으로 만져야 하고, dependency가 꼬여있지 않아 추가하고 싶은 기능만 추가하는 것의 중요성을 깨달았다. 기존 코드가 난잡하면 유지보수 하는데는 훨씬 많은 cost가 든다는 걸 개발병을 하면서 너무 많이 겪었다. 나는 소스 코드는 하나의 글이라 생각한다. 잘 쓴 글은 서..

[개발서적] Clean Code 정리

1. 의미 있는 이름을 작성하자 누가 보든 알아보기 쉽게 변수명과 함수명을 작성하자 읽기 쉽고, 직관적인 단어를 사용하자(줄임말 말고) 코드 길이가 조금 길어지더라도 상수를 변수로 사용하자(검색의 편의를 위해) 클래스 이름 : 명사/명사구 메소드 이름 : 동사/동사구 한 개념에 한 단어(동의어를 사용하지 말 것)​ 2. 함수는 작게 작성하자 ​최대한 짧게 작성하자. indent는 1-2개 정도로 두자. 함수 이름을 서술어로 잘 설정해서 코드만 읽어도 이해되게 해 보자. 함수는 1가지 역할만 하자. (추상화 수준을 1개로 만들자는 것) 함수 인수는 최대한 적게 두자. 3. 주석은 최대한 없애자 주석이 필요없을 정도로 깔끔한 코드를 짜면 된다. 필요하다면, 의도와 의미를 명확하게 설명하자. 필요한 주석은, ..