Overview Web Programming 여러 분야의 개발을 동시에 하면서 항상 그래 왔지만 유난히도 '참 가야 할 길이 멀구나' 싶은 생각이 들었던 한 주였다. 우선 프런트엔드 쪽에서는 그동안 개발했던 웹 랜딩페이지(+모바일 대응) 보다는 철저히 모바일을 위한, 데스크톱이 아닌 디바이스의 환경에 최적화된 웹뷰 작업이었다. 프론트엔드 개발을 하면서 가장 귀찮았던 것이 크로스 브라우징이었는데 디바이스 쪽은 훨씬 고려해야 할 것들이 많았다. 기본적으로 브라우저 대응(iOS -> Safari, Android -> Chrome)및 다양한 해상도와 Notch 등의 디바이스 특성 등을 고려하면서도 전반적으로 데스크톱이 아닌 디바이스이기 때문에 고려해야 할 사항들(보안상 이슈로 인한 동영상 플레이 제한 등)까지 ..

Overview 회사에서 새롭게 읽게 되는 여러 코드들을 통해, 그리고 코로나 19의 거리두기 강화로 인한 재택근무로 인해 접하게 되는 콘텐츠의 양과 질이 동시에 높아졌던 한 주였던 것 같다. 무엇보다 월간 750만 유저가 사용하는 글로벌 서비스(Qanda)를 프로덕션 하는 회사이니만큼, 그만큼의 트래픽을 감당하기 위한 여러 아키텍처들을 보고, 또 질문하면서 어깨너머로 다양한 코드들을 익힐 수 있어서 굉장히 좋은 경험을 했던 한 주였다. Nextjs Nextjs는 React JS에서 서버 사이드 렌더링(SSR)을 할 수 있도록 지원해주는 프레임워크이다. 사용해 본 결과, React JS에서 Next JS를 사용한다는 느낌보다는 Nextjs 프레임워크 내에서 React를 사용하는 느낌이 더 강했다. 공식 ..

Overview 새로 입사한 회사에서 사용하는 프레임워크 및 코드 관습들을 익히는데 주로 많은 시간을 사용했었던 한 주였다고 정리할 수 있을 것 같다. 기본적으로 React + Django를 사용해서 개발하는 스타일이지만, SPA 방식이 아닌 SSR (Server Side Rendering) 방식을 주로 사용하고 있었기 때문에 React에서 손쉽게 SSR을 지원해주는 Nextjs에 대해 공부하고 이것저것 정리하는 시간을 가졌다. 또한 상태관리 라이브러리로는 기존에 익숙했던 Redux가 아닌 Observable 기반의 Mobx를 사용하고 있었기 때문에 이에 대해서도 공식문서를 읽으며 간단한 튜토리얼을 진행했다. Nextjs & Mobx Nextjs는 리액트에서 Server Side Rendering에 필요..

Overview 산업기능요원 전직 대기기간 14일을 사용할 수 있게 되면서, 오래간만에 출근하지 않고, 백수의 생활을 했었던 것 같다. 밀린 프로젝트들을 정리하고, 새로운 회사에서 조금씩 공부하게 될 Django API Server, Next.js SSR framework, React Class Component(하도 Functional Component만 사용하다 보니 Class Component가 생소하게 느껴질 정도였다.)를 정리하는데 시간을 주로 할애했다. 추가적으로, 이직을 준비하면서부터 좋은 개발자란 무엇인가에 대한 고민을 계속 했었던 것 같다. 툴을 능숙하게 다루는 개발자에서 한 걸음 나아가서 툴을 이루는 근본이 되는 컴퓨터 공학. 이를 테면 Javascript 본연의 특징 및 메모리 관리,..

Overview 이번 주에는 주로 Django를 사용한 OOP 구현에 초점을 맞추어서 공부하였다. Django로 서버를 제대로 구현하려는 시도 자체를 사실상 처음 해본 것이었기 때문에, 디자인 패턴이나, 최적화같은 부분들에 신경쓰기보다는 기본적인 REST API를 제대로 구현하는 부분에 중점을 두고 공부했다. Javascript와 Python은 비슷하면서도 다른 부분이 많아서, 어느 정도 Django로 능숙하게 API를 작성하게 된 후에는, 이 두 언어의 차이점을 명확하게 이해하는 과정이 필요하겠다는 생각이 들었다. 이 부분은 따로 정리해서 중요한 부분만 골라 포스팅해볼 생각이 있다. Object Oriented Programming 객체 지향에 관한 지인들의 교재 추천(객체지향의 사실과 오해)을 받아 ..

Overview 회사 내 관리자페이지를 완전히 새로 기획하여 만들게 되면서, 이전에 급하게 만드느라 추가하지 못했던 기능들과 검토할 기회조차 없었던 기능들을 추가하려고 노력했다. 그 중에 하나가 바로 프로그램을 TDD를 사용하여 작성하는 방식이었는데, 사용자의 잔고와 사내의 잔고가 오가는 일이라 (자세한 내용은 사내 규정상 밝힐 수가 없다.) 잘못된 로직의 코드가 들어가게 되면, 큰 피해가 생길수도 있기 때문에 테스트 코드의 중요성을 깨닫게 되었고, 같이 개발하는 팀원들에게 부분적으로 TDD를 도입하는 방식을 제안했었다. TDD 도입의 현실적인 한계. TDD는 단순히 프로그램을 작성하고, 그 작성한 코드가 제대로 돌아가는지를 테스트하는 테스트코드를 작성한다는 개념이 아니라는 것을 이해하였다. TDD는 일..