Stay hungry, Stay foolish

22.01.26 오늘은 함수다! 😃 책에서 기억하고 싶은 내용을 써보세요. 작게 만들어라! - 함수를 만드는 첫번째 규칙은 '작게' 둘째 규칙은 '더 작게' - if, else, while에 들어가는 블록은 한 줄이어야 한다 - 중첩 구조가 생길만큼 함수가 커져서는 안된다. 그러므로 함수에서 들여쓰기는 1단 or 2단 까지가 적당하다. 이래야 읽고 이해하기 쉬워진다 한 가지만 하라! - 함수 하나에 initializer, rendering, retrieve, post 등 온갖 기능을 넣어서 짜지 말아라 다 쪼개라 함수 하나에는 하나의 기능만 하도록 짜야한다. 그리고 그 하나의 기능만을 잘 해야한다. - 이 함수에서 의미있는 이름으로 다른 함수를 추출할 수 있다면? 그 함수는 여러 작업을 하는 함수다 함수..

2022.01.25 😃 책에서 기억하고 싶은 내용을 써보세요. 클래스 이름 - 클래스, 객체 이름은 명사나 명사구가 적당하다. 메서드 이름 - 메서드 이름은 동사나 동사구가 적당하다. 한 개념에 한 단어 - 똑같은 기능의 메서드가 있는데 클래스마다 retrieve, get, fetch 처럼 서로 다른 이름의 메서드를 사용하면 헷갈린다. 한 개념에는 하나의 이름만 사용하자. 말장난을 하지 마라 - 다른 클래스에 add 라는 메서드가 기존에 존재하고 있는데, 새로운 기능 중 리스트에 값을 하나 추가하는 메서드를 만들었다고 할때 add 라는 명으로 짓지 말아라. 의미 있는 맥락을 추가하라 - firstName, lastName, street, houseNumber, city, state.. 라는 변수 명을 보..

22.01.24 클린코드 2장에서는 변수 즉 좋은 이름을 선택하는 방법들에 대해 설명해준다. 😃 책에서 기억하고 싶은 내용을 써보세요. 의도를 분명히 하라 - 변수, 함수, 클래스의 이름을 보고 존재 이유, 사용방법, 기능 등에 대해 알아보기 어려워 주석이 필요하다면 좋지 못한 코드다. 그릇된 정보를 피하라 - List type 이 아닌 객체인데 변수명에 List가 들어간다거나 let l ; 처럼 l 이 알파벳 l 인지 i 인지 1인지 구분이 안되게 작성하면 안된다. 의미있게 구분하라 - getAccount() , getAccounts() , getAccountsInfo() 처럼 3개의 함수명이 있다고 하자. 의미가 구분이 되는가? 함수명이나 클래스 명 변수명은 각자 해당 기능이 무엇인지 의미가 분명하게..

22.01.23 😃 책에서 기억하고 싶은 내용을 써보세요. 깨끗한 코드의 정의 - 우아하고 효율적인 코드, 논리가 간단하고 코드 간의 의존성이 최대한 적은 코드 (유지보수가 쉬운 코드) - 단순하고 직접적인 코드, 잘 쓴 문장처럼 읽으면 작성한 사람의 의도가 읽히는 코드 (명쾌한 추상화와 단순한 제어문) - 명확하며 최소한의 API - 모든 테스트를 통과하며, 중복이 없고, 클래스, 메서드, 함수를 최소한으로 하는 코드 - 중복을 피하고 한 기능만 수행하고 제대로 표현하고 작게 추상화하라 보이스카우트 규칙 - 캠프장에 왔을 때보다 떠날 때 더 깨끗이 하고 떠나라. 시간이 지날수록 엉망이 되는 것을 막아야 한다. 즉 코드를 작성 후가 하기 전보다 더 깔끔해지게 하라. 많은 걸 할 필요는 없고 - 변수 하나..

22.01.22 😃 책에서 기억하고 싶은 내용을 써보세요. 코드는 요구사항을 상세히 표현하는 수단이다. 어떤 언어든 코드는 기계가 이해하고 실행할 정도로 정확하고 상세하게 정형화 되어야 한다. 르블랑의 법칙 : 나중은 돌아오지 않는다. 나쁜 코드를 쓰는 이유가 시간을 단축하기 위해, 빨리 구현하기 위해서? 틀렸다 나쁜 코드는 심각한 장애물이다. '코드 감각' 을 훈련시켜야 한다.'코드 감각'이 없는 개발자도 나쁜 모듈을 알아는 본다. 끝이다. 코드 감각이 있는 개발자는 나쁜 모듈을 좋은 모듈로 수정 할 수 있다. 🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요 비즈니스가 장기화될수록 제품의 코드는 거대해진다. 코드를 처음 작성할 때 (몰라서? 시간이 없어서? 그 이유가 뭐가 되었든 간에) 깨끗하..

추천사 부분을 간략히 읽고 정리해보자 😃 책에서 기억하고 싶은 내용을 써보세요. '사소한 곳에서 발휘하는 정직은 사소하지 않다.' 소프트 웨어의 80% 이상이 유지보수다 5S 정리(sort) - 적절한 명명법으로 등과 같은 방법을 사용해 무엇이 어디에 있는지 알아야 한다. 정돈(체계화) - 코드는 누구나 예상하는 위치에 있어야 한다. 청소(광내기) - 작업을 하며 떨어뜨린 부스러기나 쓰레기는 치워야한다. 코드도 마찬가지다 코드를 작성하며 만들어낸 부산물, 주석이 있는가? 지워라. 청결(표준화) - 작업공간을 청소하는 방식을 그룹원들이 동일하게 따르게 한다. 코드 작성할때도 컨벤션과 규칙이 있다 표준을 따라라 생활화(규율) - 관례를 따르고 자기 작품을 자주 돌아보고 기꺼이 변경하라(리팩터링하라는 말인가?..

사람의 이름이건 제품의 이름이건 '이름' 이라는건 중요하다. 개발에서도 이름은 중요하다. 개발은 보통 혼자하는 것이 아니기 때문에 남들이 봤을 때 클래스, 함수명만 보고도 어떤 기능을 하는 클래스구나 함수구나를 알 수 있는 이름을 짓는것이 중요하다. 클린코드 2장에서는 변수 즉 좋은 이름을 선택하는 방법들에 대해 설명해준다. 의도를 분명히 하라 - 변수, 함수, 클래스의 이름을 보고 존재 이유, 사용방법, 기능 등에 대해 알아보기 어려워 주석이 필요하다면 좋지 못한 코드다. 그릇된 정보를 피하라 - List type 이 아닌 객체인데 변수명에 List가 들어간다거나 let l ; 처럼 l 이 알파벳 l 인지 i 인지 1인지 구분이 안되게 작성하면 안된다. 의미있게 구분하라 - getAccount() , ..

제품 개발을 하면서도 내가 지금 개선/ 개발 하고자 하는 이 기능이 유저의 구매, 서비스 이용 여정에 있어 어느 단계에 있고 유저가 이용하는데 있어 도움이 되는 기능인지 등 지표를 확인하며 체크하곤 합니다. 사실 유저가 유입되고 구매로 전환되고 등의 모든 단계를 각각 추적하고 데이터를 분석해서 마케팅에 적용하고 비즈니스를 개선 시키는 단계들이 모두 착착 이루어 진다면 참 좋겠지만 항상 시간과 인력이 딸리는 스타트업에서는 그 과정이 전부 어렵게만 느껴집니다. 그래서 많은 스타트업 들은 AARRR 퍼널 이론을 택하여 각 단계(퍼널)별로 전환이 얼마나 이루어지는지 데이터를 추적하고 있습니다. 현재 우리 회사에서도 AARRR 이라는 마케팅 프레임워크를 적용하여 제품 기획과 개발에 들어갈때 고려하고 있습니다. A..

내가 실무에서 사용하는 프레임워크인 Ruby on Rails 의 소개글을 읽어보자 https://dhh.dk/2012/rails-is-omakase.html https://rubyonrails.org/doctrine David Heinemeier Hansson 레일즈를 창조하신 개발자님께서 직접 작성한 글이다. 레일즈는 오마카세다! 레일즈 개발자가 표현한 레일즈란 이렇게 표현할 수 있다. 오마카세라는것이 쉐프가 각각의 코스요리 메인디쉬, 디저트, 음료 등 밸런스를 고려해서 구성을 해놓는 것인데 내 해산물 오마카세에서 난 해산물이 싫어 핫도그 먹고싶어!! 이런다고 핫도그가 나오지는 않는다. 물론 샴페인에서 화이트 와인으로 바꾼다던지 하는 정도의 선택권은 있을 수 있다. 레일즈라는 프레임 워크가 딱 이렇다...

내가 재직중인 회사의 서비스에는 BEM 스타일의 코드들이 드문드문 살고있다. 해당 코드들을 레거시로 정의하고 기능 개선을 할때마다 보이면 tailwind 로 교체하는 작업들을 해주고 있지만 아직도 같이 살아 숨쉬고 있는 녀석들이다. 같이 살고 있는 녀석들인데 내가 이녀석들을 잘 모르면 안되겠지? 먼저 BEM 이라는 것은 CSS 방법론 중 하나로 클래스 네이밍 컨벤션의 일종이라고 볼 수 있다. BEM? BEM 은 위의 Block, Element, Modifier 3가지 요소를 말하며 해당 요소의 연결은 Block-name__Element--Modifier 로 연결한다. Block - 컴포넌트로써 사용할 수 있는 가장 바깥영역의 블록을 정의한다. 예를 들어 위의 사이트 이미지에서 빨간 테두리는 head bl..