B_log

1. 오류 코드보다 예외를 사용하라 얼마 전까지만 해도 예외를 지원하지 않는 프로그래밍 언어가 많았어요. 오류 플래그를 설정하거나 호출자에게 오류 코드를 반환하는 방법이 전부였어요. 하지만 이렇게 코드를 작성하면 호출자 코드가 복잡해지고 코드 블록 depth가 깊어져요. 그래서 try / catch 등의 예외 처리를 하는 것이 더 깔끔해요. 오류 발생시 처리하는 코드와 예외 처리가 분리되기 때문이에요. 나의 생각: 사실 Swift는 Optional의 존재로 오류 처리가 한결 더 수월한 것 같아요. 현업 코드에서 오히려 try / catch를 거의 못 봤던 것 같아요. 오류가 발생하기 가장 쉬운 부분 중 하나가 네트워킹일 텐데 그 부분마저도 Optional 처리가 되기 때문에 오류 처리 대응이 쉽게 되었던..

1. 자료 추상화 수많은 개발자가 아무 생각 없이 변수를 get / set 하는 메서드를 생성해 외부로 노출해요. 하지만 경우에 따라서 객체가 포함하는 자료를 표현할 때 더 좋은 방법이 있을 수 있어요. 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 해요. 아무 생각 없이 조회/설정 함수를 추가하는 것이 가장 나빠요. 2. 자료/객체 비대칭 객체 지향 코드에서 어려운 변경은 절차적인 코드에서 쉬우며, 절차적인 코드에서 어려운 변경은 객체 지향 코드에서 쉬워요. 복잡한 시스템을 짜다 보면 새로운 함수가 아니라 새로운 자료 타입이 필요한 경우가 생기는 데, 이때는 클래스와 객체 지향 기법이 가장 적합해요. 반면, 새로운 자료 타입이 아니라 새로운 함수가 필요한 경우도 생길 경우에는 절차적인 코드와 자료구..

5장은 팀에서 정할 컨벤션을 만들 때 유용한 주제라고 생각해요. 또한 현재 저는 개인 작업을 하고 있는데, 혼자 하는 작업이더라도 형식을 정해놓는 것이 좋은 것 같아요. 저자가 말하는 원활한 소통을 장려하는 코드 형식에 대해서 이야기 해볼게요. 1. 적절한 행 길이를 유지하라 세로 길이부터 살펴보면, 자바에서 파일 크기는 클래스 크기와 밀접해요. 클래스 크기는 이후 다른 챕터에서 다루고 여기서는 파일 크기만 논해요. JUnit 등의 프로젝트 7개를 봤을 때 평균 파일 크기는 65줄이에요. JUnit에서 가장 긴 파일은 400줄 정도예요. 대다수가 200줄 미만이죠. 반면에 Tomcat과 Ant는 절반 이상이 200줄을 넘고 수천 줄을 넘는 경우도 있어요. 일반적으로 한 파일에서 줄 수가 적은 것이 많은 ..

나쁜 코드에 주석을 달지 마라. 새로 짜라 - 브라이언 W. 커니핸, P.J. 플라우거 잘 달린 주석은 유용하지만 경솔하고 근거 없는 주석은 코드를 이해하기 어렵게 만들어요. 주석은 '순수하게 선하지' 못해요. 프로그래밍 언어 자체가 표현력이 충분하다면 주석은 전혀 필요하지 않아요. 그래서 주석이 필요한 상황에 처하면 곰곰이 생각해야 해요. 상황을 역전해 코드로 의도를 표현할 방법은 없을지. 주석을 달 때마다 자신에게 표현력이 없다는 사실을 푸념해야 해요. 나의 생각: 코드로 표현할 수 있는 것을 주석으로 표현하려고 시도하는 것은 문제가 있을 수 있어요. 하지만 현업 코드를 작성하며 분명히 도움 받았던 주석들도 있었어요. 네트워킹 시 받아올 JSON의 형태를 Entity에 주석으로 마킹할 경우 코드를 ..

1. 작게 만들어라! 함수를 만드는 첫 번째 규칙은 '작게!'이고, 두 번째 규칙은 '더 작게!'에요. 하나의 함수는 하나의 역할을 하면서 동시에 명료하게 보여야 해요. 그래서 하나의 함수는 10줄을 넘기지 않도록 노력해야 해요. if, while과 같은 블록은 한 줄이어야해요. 블록 안의 구조를 새로운 메서드로 추출하면 복잡도와 코드 길이를 낮출 수 있어요. 중첩 구조는 depth 2를 넘어가면 안 돼요. 이렇게 해야 함수의 이해가 쉬워져요. 나의 생각: 이 생각을 간단한 앱을 구현할 때에는 쉽게 지킬 수 있었어요. 당연하고 지켜야하는 이 규칙을 현업에서 코드의 복잡성이 올라가고 구현해야 하는 목표가 복잡해질수록 간과하기 쉬웠던 것 같아요. 새로운 피쳐를 전체 설계할 때에도 힘들 수 있지만 특히 기존 ..

개발뿐만 아니라 다른 분야에서도 전문 용어를 사용하는 이유는 한 단어로 많은 뜻을 전달하기 위해서예요. 있는 용어를 사용하는 것이 아니라 이름을 직접 명명해서 사용할 일이 많은 개발에서는 이름을 잘 짓는 것이 중요해요. 다른 사람이 내 코드를 읽을 때 이름 하나로 역할을 보다 쉽게 이해할 수 있을지, 없을지가 결정되기 때문이죠. 애플의 경우 Swift 네이밍 규칙을 API Design Guidelines(https://www.swift.org/documentation/api-design-guidelines/#naming)에 만들어 두었어요. 클린 코드 2장에서는 Swift에 한정된 네이밍이 아니라 일반적으로 코딩에서 좋은 명명법에 대해 이야기 해요. 다른 글과 다르게 번호가 길어져 나의 생각을 다홍색으로..

르블랑의 법칙(Leblanc's Law) - 나중은 결코 오지 않는다. 클린 코드의 필요성을 부정하는 사람은 없을 것 같아요. 는 첫 장으로 왜 클린 코드가 필요한지 설명하고 있어요. 클린 코드가 필요하고 깨끗하지 못한 코드가 나쁘다는 말을 부정할 사람은 없을 것 같아요. 이왕이면 깨끗한 코드가 더 좋은 결과물이겠죠. 문제는 이 깨끗한 코드를 어떻게 정의할까에요. 저명한 개발자들은 깨끗한 코드를 다음과 같이 정의했어요. 1. 비야네 스트롭스트룹(Bjarne Stroupstrup) - 보기에 즐거운 효율적인 코드 우아하고 효율적인 코드 논리가 간단 ➡️ 버그 발생 감소 의존성을 줄여야 함 ➡️ 유지보수가 쉬워짐 오류는 명백한 전략에 의거해 철저히 처리 한 가지를 제대로 함 2. 그래디 부치(Grady Bo..