출처: https://hackernoon.com/how-to-find-the-best-solution-for-a-bug-33818838502
최최최종
정말로 끝이 난 것 같을 때가 사실은 끝이 아닌 겁니다. 프로그래밍에서는 정말로 그런 것 같아요. 최대한 수정했다고 생각했는데 또 버그가 보이고, 수정했는데 또 다른 버그가 보이는 일정이었습니다.
제가 버그라고 한 것들은 그냥 수정해야 하는 모든 것들입니다. 버그가 대체 어느 범위까지를 말하는 지를 모르겠어서 말이죠. 기능이 잘 동작하지 않는 경우도, CSS 를 수정하는 것도 다 버그라고 생각하고 수정에 수정을 더해갔습니다.
어느 정도 괜찮은 것 같아 마스터로 병합했음에도 작은 버그들이 이어져 핫픽스를 2~3차례 정도 더 진행했던 것 같습니다. 그러고 나니 이제는 어느 정도 안정적으로 서비스를 할 수 있을 것 같네요. 모든 팀원들도 다 어느 정도 만족한 것 같습니다.
사소한 꿀팁
오늘은 거의 모든 시간을 4명의 팀원이 함께 모여서 진행했습니다. 할 것이 없어서 조금 느슨한 시간들도 있었지만, 같이 모여서 진행하다 보니 얻게되는 소소한 꿀팁들이 정말 도움이 많이 되었네요. 특히나 진작에 알았으면 좋았을 것 같은 꿀팁들을 얻을 수 있어서 오늘은 여기에 대해 짧게 정리하는 것으로 블로깅을 진행하려 합니다.
개발자도구로 CSS 미리 확인해보기
CSS 를 변경해서 내가 의도한 대로 렌더링이 바뀌는지를 확인할 때, 직접 코드를 수정하기보다는 개발자도구에서 먼저 확인해보는 편이 생산성을 크게 향상시켜줍니다. 사소하게 넣어볼 수 있는 정도를 몰랐던 것은 아니지만 보다 적극적으로 활용할수록 더 빠르게 작업을 이어나갈 수 있는 것 같네요.
특히 사파리에서는 일부 CSS 가 동작하지 않거나 다르게 동작하는 경우가 있어 주의가 필요합니다. 가급적이면 사파리와 크롬 두 브라우저에서 다 확인해보는 편이 좋은 것 같네요. 특히 모바일의 경우 안드로이드와 애플이 거의 양분하고 있다 보니 사파리를 꼭 체크하는 편이 반응형을 구현하는데 아주 중요한 것 같습니다.
Visual Studio Code 내가 변경한 작업 확인하기
git status 를 찍어보면 내가 변경한 작업물이 어떤 것들인지를 확인할 수 있죠. 사이드바에서 Explorer 메뉴를 눌러 파일들을 보면 변경한 것들은 M 이라는 글자로 나타나니까 이걸로 확인하기도 했었구요.
이제껏 여기까지만 알고서 진행하다가, 변경한 코드를 직접 눈으로 확인할 수 있는 메뉴를 팀원의 조언으로 알게 되었습니다. 왼쪽 사이드바에 있는 Source Control 이라는 메뉴를 누르게 되면 내가 작업한 파일들의 목록이 나오고, 개별적으로 클릭해 내가 변경한 것들을 기존의 파일과 나란히 두고 확인할 수 있습니다.
무엇을 변경했는지가 한 눈에 들어오다보니 확실히 작업을 확인하는데 도움이 되더라구요. 늘 그렇지만 너무 짧은 시간에 많은 것을 배우다보니 때로는 이런 사소하지만 중요한 정보를 모르고 지나치는 경우가 많은 것 같습니다. 조금만 더 일찍 알았더라면 생산성이 크게 향상되었을 것 같네요. 이제라도 알았으니 정말 다행입니다.
AWS Billing 예산 짜기
AWS 는 프리티어라는 이름으로 무료로 사용할 수 있는 영역을 제공합니다. 단, 어느 정도 제한 사항이 존재하죠. 프로젝트에 돌입하다 보면 어느 정도 요금을 지불해야 하는 경우들이 발생하는데요. 이 때 Billing 에 들어가 예산을 설정해두면 설정한 예산 한도를 초과하게 될 때, 등록한 이메일로 알림을 받을 수 있습니다.
누구나 처음에는 AWS 가 익숙하지 않은 만큼 어디에서 어떤 식으로 예산이 초과될지 예측하기가 어려운데요. 예산을 설정해두고 알림을 받도록 해두면 혹시라도 내가 모르는 사이에 예산이 초과하는 상황을 방지할 수 있어 (심리적으로도) 보다 더 안정적인 사용이 가능합니다.
