전체 글

전체 글

    [Refactoring - 1일차] 리팩토링 2판 by Martin Fowler

    리팩터링 2판을 읽으며 정리한 내용을 담고자 일종의 일기를 쓴다. 책을 갖고 있지 않은 사람이나 정보를 얻고자 하는 사람에게는 해당 내용들이 무슨말인가 할 수 있다. 일종의 필기라고 생각하고 책과 함께 읽으면 좋을 것 같다. 나 또한 다시 읽을때 함께 꺼내 보고자 정리하였다. 프로그램이 새로운 기능을 추가하기 편한 구조가 아니라면, 기능 추가가 쉬운 형태로 리팩터링을 하자 1. 중복 코드의 여지가 있는 것들을 분리하자 로직 변경이 없지 않는 이상, 오래 사용할 코드에서 중복코드는 골치거리가 된다. 2. 확장성이 있는 (변동이 있는) 코드들은 분리하자 저자의 경험상 어떤 방식으로 정하든 반드시 6개월안에 변경하게 된다 -> 깊은 공감 즉 변경이라는 것이 리팩토링의 중요성을 깨닫게 해준다. 리팩토링의 과정에..

    [npm] 리액트 패키지를 만들어 npm에 배포해보자 - 1

    [npm] 리액트 패키지를 만들어 npm에 배포해보자 - 1

    개인적인 웹 프로젝트를 개발하고 있던 도중, 평소 관심이 많았던 스크롤 이벤트에 대해 상당히 열이 받아 있었다... 다양한 스크롤 이벤트들이 많고, 특히 꽤나 Fancy 한 (앱x 이라든지...) 웹들은 다양한 스크롤 이벤트를 바탕으로 새로운 패러다임을 보여주기도 하는데, 이러한 이벤트들을 직접 구현하려니 꽤나 복잡하였다... 하지만 레퍼런스를 안보며 직접 창조한다 생각하고 개발하면 재미가 있기에? 이어가던 도중, 꽤나 괜찮은 아이디어라 판단 된 컴포넌트를 구상하게 되었다. 하나의 프로젝트만을 위해 이 컴포넌트를 만들어? 하기엔 너무 아까워 생각하던 와중, 오픈소스에 기여도 할 수 있고, 공부도 될겸 npm 패키지를 배포해보자라는 생각을 하게 되었다! 서론이 길었지만, 천리길도 한걸음 부터, 우선 Rea..

    [OAuth 2.0] Microsoft ID 플랫폼과 함께 OAuth 2.0 복기하기

    [OAuth 2.0] Microsoft ID 플랫폼과 함께 OAuth 2.0 복기하기

    대형 플랫폼이라면 갖고 있는 소셜 로그인,,, 어느 순간부터 모든 플랫폼들이 소셜 로그인 프로바이더를 제공하며, 사용자에게 간편한 Sign-In / Sign-Up 방식을 제공하고 있다. 사용자는 자신의 정보를 최소한으로 입력하면서 (OAuth / OpenID 를 제공하는 플랫폼으로 부터의 정보를 받으며) 다양한 웹/앱 서비스에 접근할 수 있고, 또한 사용하는 서비스들의 계정 정보를 어느정도 획일화하며 정리 할 수 있어 외우기도 간편하다. 이렇기에 다양한 서비스들은 유명한 프로바이더(구글, 페이스북, 네이버, 카카오 등...)를 도입하기도 한다. 지금까지 구글, 페이스북, 네이버, 카카오, 라쿠텐의 OAuth2.0, Steam의 OpenID 를 통해 인증 및 인가를 받아와 본 경험이 있는데, 새롭게 회사에..

    [Web App] Frontend Developer로 Web App 개발하기

    [Web App] Frontend Developer로 Web App 개발하기

    Frontend 개발자의 길을 걷고있다면, Web App 이라는 단어를 흔히 들어본 경험이 있을 것 이다. Web App은 무엇이고, 그 배경은 무엇일까? Web App 이란? 웹 브라우저를 통해 접근할 수 있는 어플리케이션의 일종이다. 모바일에서 접근하였을 때 모바일 어플리케이션과 유사한 동작을 구현 할 수 있다. Web App 와 비교할만한 배경들은? - Mobile Web: 모바일에 알맞게 만들어진 web, 흔히 반응형 웹을 구성해 모바일웹 환경을 구축한다. - Native App: 모바일 OS에 맞게 만들어진 어플리케이션. 각각의 언어를 통해 OS에 최적화 된 서비스를 제공 할 수 있다. - Hybrid App: 모바일 웹과 네이티브 앱의 장점을 섞어 만들고자 한 어플리케이션. 상위 두개의 반반치..

    [현업 프로젝트 - 1] Semi-Regression

    [현업 프로젝트 - 1] Semi-Regression

    신입으로 취업한지 어느덧 5개월차... 거의 반년이 되어가는데, 다른 의미로 현타가 오고있다... 우선, 현 회사에서 처음으로 큰? 프로젝트를 들어갔고, 개발한 지 3개월 차가 되었다. 나는 현재 Web (React, Node), Chrome Extention, Electron으로 이루어진 3개의 프로덕트 개발을 맡았다. 기존 당차게 당부한, "이미 개발되었던 적이 있던 것들!" 이라는 매니저분들의 말들과는 200% 다르게... 살이 붙고 뼈가 붙고, 또 바뀌고 또 바뀌었다... 그 과정 속에서 팀이 이루고 있는 프로세스의 결함, 개발 과정 속에서 지속적으로 바뀌는 변곡점, 문서의 부재와 커뮤니케이션 오류, 빡빡한 일정과 고려되지 않은 세부 기능들... 이 외에도 정말 많은 것들이 힘들게 하고 있는 것은..

    [Design Pattern] 의존성 (Dependency)

    [Design Pattern] 의존성 (Dependency)

    다양한 레거시 코드들을 다루며, 유지보수와 새로운 기능들을 붙히고 있는 가운데, 가장 많이 부딫히고 있는 큰 문제점 중 하나는 의존성(dependency) 문제이다. 우선 해당 코드들은 5년전 활발하게 개발되고, 3년전까지만 유지보수가 꽤나 일어 난 것을 커밋을 통해 확인한 바 있다... 의존성 문제로 일어나는 곳이 한두곳이 아니었다. 객체를 활발하게 다루는 일종의 컨트롤러 서버(현 서비스는 Back과 Front의 객체를 다루는 Controller 역할을 중간 미들웨어 역할의 서버가 컨트롤러처럼 동작하고 있다) 내에서의 메소드간의 의존성이 깊고, 이 의존성들이 일종의 콜백 지옥을 이루고 있어 그 구조를 제작자 없이 파악하기 너무 힘들었다. 또한, 현재 담당하고있는 Electron으로 제작된 데스크탑 어플..