전체글149 [클린코드] 4장. 주석 4장. 주석 나쁜 코드에 주석을 달지 마라. 새로 짜라. 경솔하고 근거없는 주석은 코드를 이해하기 더 어렵게 만들지만, 잘 달린 주석을 그 어떤 정보보다 유용하다. 주석은 오래될수록 코드에서 멀어진다. 그 이유는 주석까지 유지보수하기란 현실적으로 불가능하다. 즉, 코드는 변화하지만 주석은 변화하는 코드를 따라가지 못한다. 주석은 나쁜 코드를 보완하지 못한다. 코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문이다. 코드를 알아보기 힘드니 주석으로 대체하는 것이다. 코드로 의도를 표현하라 좋은 코드일수록 주석은 줄어든다. 좋은 주석 그렇다면 주석이 필요한 경우는 언제일까? 법적인 주석: ex) 저작권 정보 or 소유권 정보, 라이센스 정보를 제공하는 주석: 기본적인 정보를 주석으로 제공하면 펀.. 2024. 4. 16. [클린코드] 3장. 함수 3장. 함수 어떤 프로그램이든 가장 기본적인 단위가 함수다. 이해할 수 없는 함수 추상화 수준이 다양하고, 코드가 길다. 두 겹으로 중첩된 if 문은 이상한 플래그를 사용 플래그는 사용하지 말아야 한다. 작게 만들어라 함수는 작을수록 좋다. 참고로 전 회사에서는 한 메서드에 700줄이 넘었다. 메서드만 보고 너무 길어서 한숨부터 나왔던 기억이 있다. 이를 인터페이스를 활용하여 단 10줄 안으로 만들어서 뿌듯했던 기억이 있다. 한 가지만 해라 메서드 안에 기능을 여러 개 사용하는 것은 좋지 않다. 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. 여기서 한 가지라는 건 추상화 수준이 하나인 단계만 수행하는 것을 말한다. 즉, 비슷한 기능 여러가지를 한 메서드 안에 작.. 2024. 4. 15. [클린코드] 2장. 의미 있는 이름 2장. 의미 있는 이름 SW에서 이름은 변수, 함수, 인수, 클래스, 패키지 거의 모든 곳에서 쓰인다. 이렇듯 많이 사용하므로 이름을 잘 지으면 여러모로 편하다. 의도를 분명히 밝혀라 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다. public class Sample1 { public List getThem() { List list1 = new ArrayList(); for (int[] x : list1) { if (x[0] == 4) { list1.add(x); } } return list1; } } list1 getThem 값 4 theList x 위의 이름들을 보고 어떤 로직인지 파악할 수 있을까? 이름만 제대로 지어도 많이 개선된다. public class Sa.. 2024. 4. 14. [클린코드] 1장. 깨끗한 코드 1장. 깨끗한 코드 이 책을 읽는 이유 프로그래머라서 더 나은 프로그래머가 되기 위해 코드가 존재하리라 코드를 자동으로 생성하는 시대가 다가온다. 그때가 되면 프로그래머는 필요가 없다. 그렇지 않다! 코드는 요구사항을 상세히 표현하는 수단으로, 어느 수준에 이르면 코드의 도움 없이 요구사항을 상세하게 표현하기란 불가능하다. 나쁜 코드 그들은 출시에 바빠 코드를 마구 짰다. 기능을 추가할수록 코드는 엉망이 되어갔고, 결국은 감당이 불가능한 수준에 이르렀다. 회사가 망한 원인은 바로 나쁜 코드 탓이었다. 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. 나중에 정리하겠다고 다짐하지만 결코 나중은 돌아오지 않는다. 나쁜 코드로 치르는 대가 나쁜 코드가 쌓일수록 팀 생산성은 떨어진다. (.. 2024. 4. 13. [리팩토링 1판] 마지막 챕터 마무리 챕터 Chapter 13. 리팩토링, 재사용, 현실성 리팩토링은 프로그램 구조를 수정해서 설계를 더 이해하기 쉽게 만든다. 프레임워크를 개발하고 재사용 가능한 구성 요소를 뺴낸다. 프로그램 구조를 단순화한다. 나중에 손쉽게 기능을 추가할 수 있게 하는 방편이다. 이처럼 리팩토링을 실시하면 과거에 시간과 비용을 투자해 만든 코드를 활용하고, 중복 코드를 줄이며, 프로그램을 간소화할 수 있다. 리팩토링 왜 안할까? 위의 장점에도 불구하고 왜 리팩토링을 하지 않을까? 리팩토링 방법을 몰라서 리팩토링의 장점은 오랜 시간이 흘러야 가시화될테고, 그때가 되면 프로젝트 팀원도 아닐텐데 공연히 리팩토링에 힘 뺄 필요 없어서 코드를 리팩토링하는 일을 추가적인 부담인데다, 월급은 새 기능을 추가하라고 주는거지 리팩.. 2024. 4. 12. [리팩토링 1판] Chapter 12. 복합 리팩토링 Chapter 12. 복합 리팩토링 리팩토링은 개발 작업을 지연시키려고 하는 게 아니라 어떤 목적이 있어서 하는 것이다. 시스템이 제품화 단계에 들어간 상태에서 기능을 추가해야 할 때, 2개월간 코드를 정리해야 해서 작업을 중단해야 한다고 팀장을 설득하기란 무리다. 따라서 리팩토링은 주변 정리부터 매일 조금씩 해나가야 한다. 리팩토링은 기능을 추가할 때나 버그를 수정할 때 실시하자. 리팩포링은 시작했을 때 끝을 봐야하는건 아니다. 실제 작업을 수행하는데 필요한 만큼 하자. 필요하다면 나중에 언제든지 되돌릴 수 있다. 복잡 리팩토링은 단순 리팩토링 기법과 달리 개발팀 전원의 합의 하에 실시해야 한다. 팀 전원은 복합 리팩토링 중 하나가 현재 진행 중임을 알고 그에 따라 움직여야 한다. 이는 사공이 많아 배.. 2024. 4. 11. 이전 1 2 3 4 5 6 ··· 25 다음
