사실 더 일찍 쓰고 싶었는데 이 제목으로 글을 작성하고 싶은데, 계속해서 사람들이 이런 제목으로 회고를 작성해서 좀만 늦게 써서 히히 내가 제일 늦게 써야지
하다가 결국 지금 쓰게 되었다...
아예 할꺼면 2Q에 연말 회고를 하고 3Q에 연초 회고를 하면 세상에서 제일 빠른 연말 회고, 제일 느린 연초 회고를 할 수 있지 않을까?
이직
회사를 옮기게 되었다.
이런 저런 이유로 회사의 내부 사정이 어려워지고,
사실 그건 별로 상관 없는데,
보고 배울만한 분들이 떠나고 회사 분위기가 전체적으로 축 쳐지는것이 너무 싫었다.
이직한 회사는 기존 회사랑 많이 다른 느낌이다.
기존 회사는 돈은 못벌고 기술적인 부분에서는 뛰어났고,
현 회사는 돈은 잘 벌지만 기술적인 부분에서 더 나아질수 있는 부분들이 많이 보인다.
그만큼 성장을 빠르게 많이 했다는 반증이며 할 수 있는 것들이 많다는 것이 좋다.
책
책을 많이 읽었다
아주 많이는 아니지만
지난 1년간 처음 회사를 다니며 이것저것 배웠지만
좋은 코드가 무엇인가?
에 대해서 그렇게 치열하게 고민해보진 않았고, 그 점이 아쉬웠다
올해 읽었던 개발 관련된 책
- 클린 아키텍쳐
- 좋은 코드 나쁜 코드
- 오브젝트
솔직히 말해서 그렇게 완전 모든 문장 하나하나를 집중해서 읽진 않았다. 원래 그런 스타일이 아니기도 하고
보통 그떄 읽었던 느낌만을 기억하는 편이다. 가끔은 읽는 방식을 바꿔서 읽어보면 다르게 보이지 않을까 하는 생각도 있다.
읽다보니 드는 생각으로는
위 책들에서는 좋은 코드, 설계에 대한 방법론으로 설명을 하지만, 이 개념이 꼭 코드, 시스템 설계에 대해서 국한되는 얘기만은 아니겠다는 생각이 들었다
결국 좋은 OO를 만들기 위한 방법의 일환으로
OO에 대한 개념에 제약을 건다는 것이다.
그것이 팀의 영역으로 가면 코딩 컨벤션이라던지, 개발적 방법론에 영역에 가면, 함수형, OOP, 등의 방법론을 통해 추구하는 것이 아닐까.
만약 좋은 코드가 무엇이라고 생각하냐는 질문에 OOP를 따르며 SOLID 원칙을 잘 지키는 코드라고 하면 그것은 맞는 말일까?
모르겠다.
OKR처럼 좋은 코드가 가지는 특성이 Object가 되고 OOP->SOLID 원칙을 준수하는 것은 Key Result여야하지 않을까
그럼 좋은 코드란 무엇일까
개발자의 의도와 동일하게 살아있는 코드가 아닐까?
살아남았다는건 강하다는 것 Yeah
단순히 오래 살아남아있다는 것이 좋은 코드인거 같지는 않다.
죽지 못해 살아있는 코드를 좋은 코드라고 할순 없으니까
딱 깔끔하게 죽을 코드는 죽고, 오래 살아있을 코드는 의도대로 살아있는 것이 좋지 않을까
갑자기 너무 글이 길어져서 여기까지...
글
좀 사람들에게 가치를 만드는 글을 쓰고 싶다는 목표가 있었다.
그 목표를 잡고 귀신같이 티스토리에서 글 쓰는 것을 멈췄다.(..?)
너무 목표가 거창했나...
그래도 연말이 되어서 후다닥 글을 하나 쓰게 되었다.
https://kanary159357.github.io/blog/why_use_ref/
Why useRef has different types?
Let's figure out why useRef has several types in types/react
kanary159357.github.io
useRef의 type은 왜 이따구로 많은가? 에 대해서 찾아봤다. useRef의 3가지 타입이 어디다 쓰는진 알겠는데, 진짜 의도가 이건지?가 궁금했다.
글 쓰고 싶은건 좀 있다.
Barrel files가 large file webpack 환경에서 얼마나 악영향을 끼치는데 프로파일링하는거 레포랑 글 딱 준비하면 좋을거 같고
RNNoise 붙이면서 RNNoise가 뭔데? 그리고 WASM 코드는 왜 이렇게 짰는데? Web Audio의 기초적인것들 등등
적어도 올해는 위의 내용들은 다 써보면 좋겠다.
아쉬운 점
그래서 내가 회사에서 올해 뭐했는데?를 문서화하지 못했다. 이것도 근시일내에 까먹기 전에 이력서에 업데이트해야겠다.
-> 이력서 업데이트하고 1Q 혹은 TF 종료시 업데이트해보자
전반적인 인생 및 생각에 대한 문서화가 부족한거 같다. 옵시디언에 풀어내보자
해보고 싶은 것
강의를 찍어보자 인프런에 크몽에?
