7월 넷째주 회고 거리

7월 넷째주 회고거리

UI/UX 프로젝트

회사에서 UI/UX 프로젝트가 진행 중이다. 사실 이 프로젝트의 이름은 UI/UX 프로젝트이지만, 뜯어보면 웹사이트 내의 모든 코드 베이스를 바꾸는 작업이며 나는 여기서 Frontend 와 Backend 코드를 분리해보려 한다.

그 이유는 여러가지가 있다.

• 장애가 발생했을 때 장애가 퍼지는 영역을 최소화하고 싶다.
  • 서버쪽의 코드가 제대로 작동하지 않거나 느리더라도 프론트쪽에서 서버 통신이 없는 간단한 부분을 먼저 보여주고 싶다.
• 언젠가는 프레임워크의 분리를 통해 전문화를 이뤄내고 싶다.
  • 요즘은 프론트 생태계에 프론트에 특화된 많은 개발도구가 존재하는데, 현재의 상황에선 이러한 도구를 활용하기 어려운 실정이다.
• 레거시 코드베이스를 걷어내고 싶다.
  • JSTL 과 같은 코드가 지속적으로 프로젝트에 사용된다면, 성장을 원하는 많은 개발자들은 이 회사에 지원하지 않으려 할 것이다.
• 유지보수 시의 복잡성을 최소화하고 싶다.
  • 프론트에서는 프론트의 역할만 하는 것이 명시되어 있을 때 복잡성은 더 줄어들 것이다.

내 능력의 한계

• 남들이 잘 이해하지 못하는 어려운 것들을 이해할 능력이 있진 않다.
  • 어떻게 나만의 강점을 만들어야 할까? 한번 고민해보자.

설계하자. 만들기 전에

• 최소 30초 이상은 설계하는 시간을 가지고 만들어본다고 생각하자. 만드는 프로덕트의 규모에 따라 결과물이 배는 나을 수도 있다.

좋은 코드의 조건 중 하나는 메세지를 ‘잘’ 전달하는 코드가 아닐까?

• 사람은 복잡한 세상 속에서 협업과 분업으로 일의 효율을 극대화하면서 살아간다. 그래서 각자 ‘직업’ 이란 것이 있다.
• 개발자는 코드를 작성한다. 혼자 작성할 때는 어차피 나 혼자이기에 나만 아는 내용들을 마구 끼워넣는다. 그러나, 함께 작성할 때, 특히 인원이 많을 때는 다르다. 남들이 보았을 때, 이해하기 쉬운 코드에 가치가 생긴다. 그리고 이 가치를 따르다보면 미래의 나에게도 도움이 된다는 것을 깨닫는다.
• 사회에서도 우리는 누군가와 소통하고 메세지를 주고받는다. 이 과정에서 오해를 사지 않게 하는 것은 중요하다. 메세지의 의도가 변질되지 않게 하는 기술..

회고하는 방법

• 잘한 점은?
• 아쉬운 점은?
• 무엇을 배웠는가?
• 아직도 안 풀린 궁금증은?
• 앞으로 어떻게 다르게 할 것인가?

설계할 때

• 책임을 여러군데로 분산시키지 말자.
  • Single source of truth 를 가급적 지키려 하자.
  • 렌더링은 한군데서만 하는 게 좋을 것 같다.

나쁜 습관

• 해야할 일을 미뤄둔 체 계속 다른 것에 홀리는 습관이 있다.
  • 이것만 버려지면 얼마나 대단한 사람이 될 수 있을까?
  • 이것을 버릴 수 있는 심리적인 트리거나 환경적으로 조절할 수 있는 것이 있다면, 적극적으로 메모하고 생각해보고 시도해야겠다.
  • 과제나 경쟁이 있을 때는 잘 하는 것 보면, 인정욕구가 어느정도 이것을 상쇄시켜주는 것 같다.

응집도 있는 삶을 살자

• 여러가지에 집중하기보다 하나를 제대로 하자.
• 공부에 집중할 때 다른 유튜브같은거에 한 눈 팔리지 말자. 효율이 떨어진다.
  • 그리고 나는 컨텍스트 스위칭 비용이 꽤 높은 편에 속하는 사람인 것 같다.
• 뽀모도로를 활용해보자.

짝프로그래밍할 때

• 가르치는 입장이 되지말고, 동등하게 접근하자.
• 나도 해결 못할 수 있다. 아는 체 하지말자.

머리를 쓴 뒤에는 몸을 쓰자

• 공부한 뒤에 쉬는시간에는 설거지같은 간단한 잡무를 하는게 뇌를 식히는데 도움을 준다.

In preparing for battle I have always found that plans are useless, but planning is indispensable.

공부에서 이루고 싶은 것

• 남들이 쉽게 성취하지 못한 것을 성취해보자.
• 압도적인 인풋과 아웃풋이 필요하다.
• 업계의 최상위에 위치한 사람들도 여전히 말도 안되게 열심히 한다.
• 지금 하는 것들은 미래에 어떻게든 가치로 이어질 것들이다.