작심삼일 개발이야기

이 글은 클린 코드를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. 8장. 경계 개발을 하다 보면 모든 기능들을 직접 구현하지는 않는다. 때로는 무료로 공개된 라이브러리들을 사용하거나 돈을 내고 사용하는 경우도 있다. 라이브러리를 사용하는 사용자들은 자신들의 요구에 딱 맞는 기능을 기대하고, 라이브러리를 만드는 개발자들은 최대한 범용적으로 사용할 수 있게 만들고 싶어 한다. 이러한 경우 때문에 문제가 생길 소지가 많다. 라이브러리를 사용하면 적은 시간에 더 많은 기능을 출시할 수 있어진다. 하지만 그 코드를 익히기 어렵다. 어떤 식으로든 나의 코드에 깔끔하게 통합해야한다. 무작정 라이브러리를 사용하기보단 간단한 테스트 케이스를 작성해서 라이브러리를 익히는 방법을 추천한다. 이를 학습 테스트..

이 글은 클린 코드를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. "오류 처리는 프로그램에 반드시 필요한 요소 중 하나일 뿐이다. 입력이 이상하거나 디바이스가 실패할지도 모르기 때문이다." 맞는 말이다...사용자들은 개발자가 원하는 입력 값만 입력하지 않기 때문이다. 그렇기 때문에 예외처리는 필수다. 오류 코드보다 예외를 사용하라 책에서는 if문을 사용하는 것보다 try catch문을 사용하라고 한다. public void Person() { if (mycar != stop) { // 자동차가 멈춰있으면 걸어간다. walk(); if (trafficLight !=green) { // 보행자 신호등이 초록색이면 길을 건넌다. crossTheRoad(); } else { stop(); } }..

이 글은 클린 코드를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. 디미터 법칙 모듈은 자신이 조작하는 개체의 속사정을 몰라야 한다는 법칙 객체는 자료를 숨기고 동작을 공개한다. 그래서 기존 동작을 변경하지 않으면서 새 객체 타입을 추가하기는 쉬운 반면, 기존 객체에 새 동작을 추가하기는 어렵다. 자료구조에 새 동작을 추가하기는 쉬우나, 기존 함수에 새 자료 구조를 추가하기는 어렵다 그래서 새로운 자료 타입 추가가 필요하면 객체가 더 적합하다. 이번 파트는 이해가 잘 가지 않는다. 어렵다..

이 글은 클린 코드를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. 프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야한다. 간단한 규칙을 정하고 모두가 그 규칙을 따라야 한다. 필요하다면 규칙을 자동으로 적용하는 도구를 활용한다. 나는 개발할 때 vscode를 사용하며 extension(확장) 도구로서 eslint, prettier 등 여러 확장 도구를 사용한다. 이런 도구를 사용하면 설정해둔 설정 값으로 파일을 저장할 때마다 자동으로 정렬을 해주기 때문이다. 그래서 그런지 이번 5장은 크게 와닿는 게 없게 느껴졌다. 글을 이해하지 못한 걸까? 그건 아니었으면 좋겠다. 한마디로 정리하자면 규칙을 정해 코드를 알아보기 쉽게 작성하자 인 것 같다. 맞는 말이다. 따닥따닥 붙어있는 코드를 보면 어..

이 글은 클린 코드를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. 주석은 나쁜 코드를 보완하지 못한다. 코드를 작성하다 주석을 사용할 때는 다른 사람 또는 내가 코드를 볼 때 알아보기 힘들 거 같다고 예상이 들면 주로 주석을 작성한다. 사실 이건 주석으로 때우려고 하지 말고 코드를 고쳐야 하는 것이 맞다 하지만 역시 주석을 달고 도망가버리곤 했다.. 좋은 주석 TODO 주석 가끔 코드를 보다보면 //TODO 주석을 본 적이 있다. 말 그대로 필요하지만 당장 구현하기 어려운 일들을 기술하는 주석이다. 더 이상 필요 없는 기능을 삭제하라거나 더 좋은 이름을 생각해달라는 부탁 앞으로 어떻게 고쳐야 한다는 주의 등에 유용하다. 나쁜 주석 대다수의 주석들이 나쁜 주석들이다. 물론 아닌 사람도 있겠..

이 글은 클린 코드를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. 작게 만들어라 함수를 만드는 첫째 규칙은 작게 만드는 것이다. 책에서는 이 말에 대한 증거나 자료를 제시하기 어렵다고 했다. 작가의 지금까지 경험과 시행착오를 바탕으로 작은 함수가 좋다고 말한다. 물론 나도 이 말에 동의한다. 함수가 길어지고 커지면 파악하는데 많은 시간이 걸리고 크기가 크다는 건 여러 동작을 하는 확률이 높아지기 때문에 작게 만드는 것이 좋다고 생각한다. 한 가지만 해라 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. 함수 당 추상화 수준은 하나로 한 함수에서 추상화 수준을 섞으면 코드를 일는 사람이 헷갈린다. 하지만 더 심각한 것은 근본 개념과 세부사항을 뒤섞기 ..

이 글은 클린 코드를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. 의도를 분명히 밝혀라 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다. 개발을 하다 보면 함수의 이름이나 변수의 이름만 보고 어떤 동작을 할 것인지 예측을 할 수 있을 때가 종종 있다. 이런 상황에서는 코드를 읽는 것이 즐거워지지만 반대의 상황이 생긴다면 이름만 봐도 코드를 읽고 싶어지지 않는다. 한 번 겪어보면 변수 명의 중요성을 깨달을 수 있는 것 같다. 자신의 기억력을 자랑하지 마라 개발하는 순간에는 모두 좋은 이름이라고 생각해서 사용하지만 시간이 흐른 뒤 다시 코드를 보게 되었을 때 한참을 생각했던 경험들이 다들 있을 것이다. 분명 작명할 때는 절대 까먹지 않겠지 라는 생각으로 만들..

이 글은 클린 코드를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. 깨끗한 코드란? 비야네 스트롭스트룹 (C++ 창시자이자 The C++ Programming Language저자) 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못하며 의존성을 최대한 줄여야 유지보수가 쉬워진다. 그래디 부치 (Object Oriented Analysis and Disign with Application 저자) 깨끗한 코드는 단순하고 직접적이다. 잘 쓴 문장처럼 읽힌다. 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순 하한 제어문으로 가득하다. 데이브 토마스 (OTI창립자이자 이클립스 전략의 대부) 깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다. 깨끗한 코드..