내용에 문제가 있는 경우, 삭제, 수정조치하겠습니다.
6,7주차가 끝났다.
6주차 주말에는 너무 정신이 없어서 작성하지 못해서 이번주에 한번에 회고하고자 한다.
되돌아보기
도구를 통해 UI정확성 확인하고, 수치값으로 한번 더 확인하기
우선 PixelParallel보다 좋은 Pixel Perfect Pro라는 확장 익스텐션으로 변경했고, 작업중에 지속적으로 확인했다.
완전히 UI에 대한 정확성을 100% 챙길수는 없었지만 그런 부분이 줄어들었다.
100%가 될 수 없었던 이유는, Figma와 브라우저 렌더링 방식이 100% 동일하지 않았기때문이다.
좀더 정확하게 써보자면 원인은 다음과 같다.
1. 폰트크기가 같아도 브라우저와 피그마간에 미묘한 크기차이가 발생하고, 이로 인해 줄바꿈이 발생하는 경우 확인하기가 어려워진다.
2. border의 경우 1px이 들어가고 빠지고에 따라 뒷부분에 렌더링되는 요소들이 1px밀리기도 한다.
동시에 이 도구를 사용함으로써 시간이 낭비되는 문제도 있었다.
UI 퍼블리싱 -> 익스텐션으로 확인 하는 사이클이 반복됨에 따라 계속해서 확인-수정하는 과정이 중첩적으로 수행됐고, 시간을 많이 소요시켰다.
의식적으로 설계에 대한 시간 늘리기
이 부분에 대해서 좀더 개선이 필요하다고 느꼈다.
자꾸만 건물을 짓는 것처럼 한번에 설계하고, 한번만에 개발을 하려고 하는 경향이 있는 것 같다.
한번만에 설계를 하고 바로 작업에 들어가고, 변경된 설계에 대한 문서화를 놓치고 있다고 느꼈다.
또한 너무 큰 부분에 대해 설계해서 디테일한 부분에 대한 설계가 부족했고, 이러한 부분들때문에 디테일하게 놓치는 부분들이 발생했다. DBC가 잘 안이뤄졌다는 증거이기도 하다.
잘한 점
6,7주차에 잘한 점이라면.... 어떻게든 포기하지 않고 맡은 테스크에 대해 책임감을 갖고 개발을 했다는 점이랄까...
잘한점 보단 개선할 점을 왕창 느낄 수 있었던 두 주였다.
Cursor rule 및 MCP도입
멀게만 느껴졌던 cursor rule과 MCP를 도입해봤다.
figma mcp와 browser tools mcp, sequential thinking을 도입했고 아래와 같이 사용해봤다.
- figma UI가 코드로 잘 구현되었는지 검증
- 코드 일관성/엣지케이스 검증
아직 경험이 부족하긴 하지만, 지금까지의 결론은 아래와 같다.
figma UI 검증 : 뭔가 리뷰를 해주긴 하지만, 유효하지는 않다.
코드 일관성 검사 : 생각보다 유효했다.
엣지케이스 검증 : 그렇게 효과가 있진 않지만, 그래도 안하는 것 보단 낫다.
개선이 필요한 점
6,7주차에는 신규 기능 개발을 하게됐고, 개선할 점들을 너무나도 많이 느낄 수 있었던 주차였다.
우연에 맡기는 프로그래밍, 그로 인한 불안감
우연에 맡기는 프로그래밍
코드를 작성하다보면 무의식에 빠지는 경우가 있다.
몰입이라고도 말 할 수도 있겠지만, 이로 인해서 코드 스타일의 일관성, 그리고 정확성을 놓치게 된다면 그건 몰입이 아니고 무의식적인 행동에 불과하다.
적극적으로 내가 무슨 코드를 작성했는지 생각하고, 개선하자.
돌아본 결과 뭘하고 있는지 놓치는 경우는 잘 모르는 것에 대한 문제를 해결해야하는 경우였다. (복잡한 타입 다루기, CSS디버깅 등)
모르는 것에 대해 해결을 어떻게든 해내긴하지만, 과정에서 이전 작업에 대한 맥락을 잃는다.
큰 맥락에서 뭘 하고 있는지 잊게 된다.
동시에 문제를 해결했다는 그 효용감이 큰 맥락에서 디테일을 잃게 만든다.
불안감
6,7주차 동안, 계속해서 내면의 불안감과 싸워야했다.
주중에는 규모가 있는 신규 기능 개발이라는 미지의 영역이기때문이라고 생각했고, 단순히 내 코드에 대한 버그가 발생할까에 대한 불안감인줄로만 알았다.
실용주의 프로그래머를 읽으면서 이 근본적인 원인이 우연에 맡기는 프로그래밍때문임을 알게 됐다.
무엇인가 잘못 됐다면, 그것을 말로 설명할 수 없다 하더라도 불안하고 초조함을 느끼게 된다.
본능이 반응하고 있다는 것을 인지해야한다. 그리고 왜 그런 느낌이 드는지 알아야한다.
암묵적 가정과 상황적 우연에서 패턴 찾기
작업시 암묵적 가정을 갖고 작업한다는 걸 느꼈다.
또한 상황적 우연에서 패턴을 찾아 상관없는 부분에 대한 디버깅을 하기도 했다.
하지만
잘되는 듯한 답을 찾는 것과 올바른 답을 찾는 것은 다르며,
확고한 사실에 근거하지 않은 가정은 프로젝트에서 재앙의 근원이 된다.
개선방안
실용주의 프로그래머에서는 불안감이 느껴진다면, 아래의 방법을 통해 어떤 일을 하고 있는지 자세하게 정리해보라 제안한다.
- 코드에 대한 그림을 그려보라.
- 가정을 항상 기록해라. (문서화) -> 근거를 신뢰하기 어렵다면 최악의 상황을 가정하라
- 추측만 하지말고 직접 시험하라.
이 요소들을 내 개발 환경에 적용해볼 것이다.
또, 맥락을 잃지 않기 위해 어려운 문제를 줄여나가야한다.
적어도 CSS문제는 공부해서 해결할 수 있다.
아침에 30분씩이라도 CSS 책을 통해 이론을 쌓아 CSS에 대해 확인하고 디버깅하는 시간을 줄이려고한다.
셀프 검증시의 문제
이상하리만큼 셀프 검증시에는 보이지 않던 문제들이 코드리뷰나 QA시에서는 나타났다.
"개선" 에 초점을 맞추면 문제가 보려하기보다는 잘 되는 코드를 더 나아지게 만들려는 경향성을 갖게 되기 때문에 문제를 찾기가 어렵다고 느꼈다.
이에 코드 검증시 DBC기반으로 입력/출력에 대해 생각해보되 방향성 자체를 내 코드를 개선한다가 아니라,
남이 쓴 코드라고 생각하고, 이걸 박살내려면 어떻게 해야하지? 를 고민해볼 필요가 있다고 느꼈다.
무엇보다 기능개발이 완료됐다고 작업이 완료된 것이 아니라는 것을 명심할 필요가 있다고 느꼈다.
그건 10%만 완료된 것이다. 나머지 90%는 그것을 검증하는 것이다.
맥락을 기록하기
신규 기능은 꽤나 많은 경우가 있는 기능이었고, 이에 따라 많은 논의가 필요했다.
이 맥락을 기록하지 않아서 혼란이 생기는 경우가 있었는데, 앞으로는 이런 부분이 없어야한다고 느꼈다.
기능에 대한 논의는 구두로 하더라도 반드시 문서를 남기자.
마무리
6,7주차에는 있는 기능을 유지/보수하는 것과 신규 기능 개발을 하는 것이 얼마나 많은 차이가 있는지를 느낄 수 있는 주였다.
동시에 부족한 부분도 많이 느낄 수 있었다.
이런 부분들을 개선할 때 더욱 성장할 수 있을 것이다.
목표를 정리해보면 아래와 같다.
- UI 검증은 반복적이지 않도록 되도록 한번에 할 것
- 코드 작성시 코드 일관성과 정확성에 대해 의식을 갖고 챙길 것
- 불안감이 느껴진다면, 그림을 그려서 이유를 찾을 것
- 가정과 사실을 기록하고, 암묵적 가정을 하지 말 것
- 추측하지 말고, 시험할 것
- 아침에 30분(+)씩 CSS 학습
- 셀프 검증시 파괴에 집중해서 검증할 것
- 기능에 대한 논의는 모두 기록 할 것
