여행자의 책

회사에서의 lesson learn이 실제로 의미가 있는지 잘 모르겠음. 결국 학습이라는 건, 과거에 배웠던 걸 현재에 사용할 수 있어야하는데 그런 케이스가 내 기억에는 없었던 거 같다. 이 얘기는 사실 AB 테스트에 관련된 이야기이다. AB 테스트를 통해 조직이 학습하려면 하나의 테스트에 꽤 많이 통제된 상황에서 실험을 진행해야함. 그리고 적정한 모수를 수집하기 위해 꽤 오래 기다려야함. 무슨 말이냐면 시간 대비 얻을 수 있는 레슨이 작을 수 밖에 없는건 아닌게 아닌가? 그리고 AB 테스트를 엄밀하게 하는 이유를 생각해보면, 테스트 결과를 통해 무언가를 배울 수 있기 때문. 당연히 AB 테스트는 상당히 좋은 인과관계 추론 방법론인 것을 부정할 수 는 없다. 하지만 모수 수집을 위해 시간이 많이 들어도 진..

요즘 개발자로서의 나는 완전히 YIPS 상태이다. 코드를 한줄 작성하는게 너무 어렵다. 어떻게 짜야 맞는거지?? 옳고 그름에 완전히 잠식되었다. 어떻게 계층을 분리하고, 작성해야하는지 참 어렵다. 프레임워크를 안써서 그런거 같기도하고.. 이런 과정을 통해 나만의 기준이 세워지는 거라는 생각도 하지만 이 시간을 견뎌야하는 나는 너무 어렵다~ 돌아보면 아무것도 아니겠지.. 일단 일을 하자. 옳고 그름을 생각하지말고.. 그렇게 살꺼면.. 후후 불면은 구멍이 뚫리는 커다란 솜사탕

최근 어떤 분에게 아래와 같은 흥미로운 이야기를 들었다. 서비스의 성공과 같은 후행 지표는 운적인 요소가 많이 작용하는 지표이기 때문에 선행지표를 최대한 좋게 하거나 시도 횟수를 높이는 것이 조금 더 유효한 액션이다. 타석에 여러번 들어서야 홈런칠 확률이 높아진다는 뜻이다. 이러한 관점에서 유명한 유니콘 스타트업은 빠른 실험을 위해 속도를 내야한다면 스파게티 코드를 작성한다. 이분의 말은 오버엔지니어링 하지 않는게 중요하다 라는 뜻에서 이런 말을 하신 것 같다. 하지만 순간 엥? 뇌정지가 왔다. 어느정도 스파게티 코드일까..? 하지만 이 얘기를 듣고 여러 생각을 했다. 먼저 스파게티 코드로 작성하면 빠르게 작업할 수 있나? 라는 생각이 들었다. 작업은 빠르겠지만 프로덕트 전체 생애에서 이것이 효율적인지는..

변수명을 정하면서 is_existed라는 단어를 보면 항상 마음이 불편하다. exist는 분명 수동 표현이 없는 자동사인데 Boolean를 반환한다는 의미를 표현하기 위해서 억지로 수동형으로 만든 느낌이다. 그렇다도 does_exist나 exists 같은 단어들 역시 완전히 의미가 직관적이지 않다. is 대신 does를 붙이면 문법 나치처럼 보이고 exists라는 단어는 boolean을 반환한다는 의미가 충분히 드러나지 않는다. 이런 고민 끝에 최근에 읽은 엘레강트 오브젝트라는 책에서 답을 찾았다. is_present라고 하면 모두가 만족할 수 있는 답이된다. 그렇게 생각하지 않으시는 분들은 당신 말이 맞습니다~

어제 팀 회의를 하면서 HTTP Status Code 를 팀 컨벤션을 정하기로 했다. 회의하면서 약간 의아했던 부분을 적어둔다. * 다른 유저 A를 팔로우하는 경우, A가 탈퇴한 유저인 경우에 200번대 응답을 보내기로 정했다. * 유저가 존재하지 않는 경우, 400번대 응답을 보내기로 했다. 이 부분이 잘 이해가 되지 않았다. 물론 일종의 약속이니까 그냥 진행해도 상관없지만 200번대 응답은 성공한 응답을 의미하는데 위의 예에서는 요청이 성공하지 않았는데 200번대 응답을 보내준다는게 뭔가 마음에 걸렸다. 또 탈퇴한 것과 유저가 존재하지 않는 것 이 두가지 모두 유저에게는 똑같이 서비스에 해당 유저가 존재하지 않는 것을 의미한다. 탈퇴와 존재하지 않음을 구분할 수 있는 이유는 순전히 유저를 완전히 삭제..

페이지네이션이 들어가 있는 List API를 개발할 때 page_size를 조절해서 넘길 수 있도록 query_param 추가해주도록 하자. 고정된 페이지 사이즈 값을 정해서 주었을 때, 리스트 UI가 화면을 꽉 채워서 추가로 페이지네이션을 못할 수 있다고 한다. UI 변경해야될 때마다 바꾸는 것보다 가져올 수 있는 최대 page_size값 만 정해두고 클라단에서 필요에 따라 변경해서 사용하는게 편할 듯.

이제 어느덧 지금회사 다닌지도 9개월 정도 되었다. 일년전으로 돌아간다면 아래 것들을 준비했을 것 같다. * git 형상관리 * OOP 관련 개념 * 클린 아키텍쳐(layered architecture로 구성된 프레임워크, nestjs, spring) * 문서화(문서 자동화) * 테스트 코드 작성, 코드 리뷰 구현 방법은 일단 코드 리뷰는 혼자 할 수 있는 부분이 아니기 때문에 제외하고 적어보면 nestJS와 reactJS로 블로그 프로젝트를 만든다. 가장 간단한 형태의 리스팅기능과 글 작성 기능만 있는 형태이다. 기능별로 브랜치를 만들어 작업한다. 블로그에 글을 작성하면서 기능을 하나씩 추가한다. 사용하면서 불편했던 점을 개선할 기능들을 직접 추가한다. 이때도 역시 브랜치를 따로 파서 작업한다. 이걸 ..

NestJS는 마치 설계도 없는 레고블럭을 산 느낌이다. NestJS를 보다가 잠깐 우리 Django를 보면 이렇게 완제품으로 잘나오다니... 이런생각이 종종 든다. 음.. Nest가 직접 재료를 사다 음식을 만든다고 하면 Django는 밀키트 느낌이다. 어쨌든 Nest는 뭔가 모듈화 로직 + typescript의 type을 이용해 동적 타입언어에서 마치 스프링을 쓰는 느낌을 제공해준다. 상대적으로 러닝커브도 낮고. 난 장고가 짱인 줄 알았지만 NestJS를 계층화 시켜서 사용해보면 아 이게 의존성 주입이구나 아 이게 OOP구나 아 이게 clean architecture구나 라고 생각하게 된다. 만약 내가 개발 학원을 차린다면 무적권 장고로 개발 맛만 보여준뒤 NestJS를 배우게 하고 싶을 정도로 편하..

요즘은 프로그램을 잘하는 것은 무엇일까에 대한 고민을 많이한다. 주니어로서 좋은 지향점이 될 수 있기 때문이다. 나름대로 내린/ 결론을 짧게 적어보자면 "가독성과 유지보수성을 유지하는 복잡한 구현을 할 줄 아는 프로그래머" 정도가 될 것이다. 물론 여기에는 커뮤니케이션 스킬과 아키텍쳐나 다른 기술들이 전제가 되어야하지만 이 이야기는 좀더 더 넓은 범주에서 다루고 싶다. 여기서 이야기 할 것은 프로그래밍 오직 그 자체이다. 위에서 적은 문장을 두 부분으로 나눌 수 있다. "가독성과 유지보수성" 그리고 "'복잡한 구현" 이다. "가독성과 유지보수성" 어디서 많이 들어보지 않았는가? 바로 클린한 코드를 작성하는 능력을 말한다. 코드를 클린하게 작성하는 것을 축구 선수의 역량에 비유하자면 선수의 개인기가 좋은 ..

100만 유튜버 침착맨이 개인방송으로 유명하기 전, 웹툰 작가 이말년으로 살았을 무렵, 마이 리틀 텔레비전(마리텔)이라는 프로그램에 나온 적이 있다. 마리텔은 개인 방송 대결 프로그램으로 연예인들이 나와 개인 방송을 켜 시청자 수가 얼마나 많은지 경쟁하는 프로그램이다. 이말년의 컨텐츠는 자신이 어떤 식으로 그리는지 혹은 다른 게스트와 만화 그리기같은 컨텐츠를 주로 진행했다. 이중 기억에 남는 장면이 하나 있었다. 바로 사람들이 캐릭터를 잘 못 알아볼 때 하는 방법을 알려주는 장면이다. 캐릭터는 다양한 이유로 사람들이 잘 못알아 볼 수 있고 그럴 떄마다 그는 이마에 낙인을 찍는 다고 했다. 그 당시에는 기발한 아이디어다. 라고 생각하고 그냥 넘어갔던거 같다. 프로그램을 업으로 삼으면서 하면서 어떤식으로 객..