분류 전체보기317 프론트엔드 설계 고민 -6- 요즘 운동에 빠져서 개발을 소홀히하고 있다. 그래서 글쓰는 것도 프로젝트 진행도 느긋하게 지연 되는데.. 원래 쓰려던 내용은 UI 컴포넌트를 구성하는 법에 대한 디테일이였지만 최근에 상태관리에 대해서 어려워 하는 사람들이 많은걸 봐서 인지 상태관리에 대해서 조금 정리하는게 좋을거 같다는 생각이 들었다. 웹 프론트엔드에서의 상태관리 도구의 경우 여러가지가 있지만 큰 맥락은 변하지 않으므로 익숙한 react와 recoil 기준으로 생각을 간단하게 정리해보겠다. 웹프론트 개발자는 웹 어플리케이션을 만든다. 그런데 왜 굳이 웹 사이트를 웹앱이라고 하는 것일까? 오늘날에 와서는 엄밀한 구분이 불가능한 편이지만 기존의 웹 사이트의 경우 정적인 웹에 가까웠다. 단순히 마크업 된 페이지를 제공해주고 사용자 액션에 따라.. 2022. 10. 3. 프론트엔드 개발에 대한 생각 개인적으로 공통단에 대해서 관심이 많다. 개발을 처음 독학으로 시작할때 부터 어지간한 프로그램을 이해하는데 큰 어려움이 없었고 어지간한 것들은 그 내부를 보지 않고도 어떻게 구현해야할지 직관이 가능했는데(분야에 상관없이 허와 실을 직관하는데 재능이 있는 편이다.) 그래서 그런지 처음부터 개발을 하면서 클린코드나 설계등에 대해서 꾸준히 관심을 가지고 관련해서 공부도 해보고 나름대로 이해도 하고 직접 적용해보고 응용도 하는 등 꾸준히 행해왔다. 더욱이 웹이라는 고수준으로 추상화된 환경에서 보편적인 기능을 개발하는데 특이한 경우가 아니라면 사실 특출난 알고리즘이나 최적화를 통한 성능적인 고려를 할 필요가 거의 없고 문제 없는 설계에 집중하는 것 만으로도 성능을 어느 정도 잡아 낼 수 있었기에 더욱 그러했다.(.. 2022. 9. 14. 취향차이 소프트웨어 개발 자체가 획기적인 패러다임이 나오지 않는 한 빠른 속도로 서로간의 좋은점을 모방해서 그런가. 기술 스택이나 패러다임에서 엄청나게 독특한게 아닌 이상 별차이가 없고 그러다보니 특수한 상황이 아니라면 그저 개개인의 취향에 따라 달라진다고 밖에 표현을 못하는 거 같다. 상대적인 강점조차 빠른 속도로 따라잡아가니 하루가 다르게 기술 선택등 요소에서 명확한 기준이 흐릿해지고 그냥 사용자가 많고 개인이 쓰고 싶은거 쓰는게 유일한 기준이 되는 상황이 너무 자주 보인다. 그냥 사용자 많고 업데이트 빠른게 최선의 선택인듯... 어제 통용되던 이유가 몇달에서 빠르면 몇주사이에 중요하지 않아지는(경쟁자도 비슷한 것을 지원함) 것을 보고 있으면 정말이지... 2022. 9. 5. 알고리즘 아직 경험이 부족한지 쉽다고 생각하고 넘어간데서 뒤통수 맞는 경우가 많은거 같다. 이제 까지 푼 문제 다합쳐도 200문제 정도 밖에 안되니 당연한건가? 귀찮아도 공부좀해야지... 2022. 8. 23. 이전 1 ··· 14 15 16 17 18 19 20 ··· 80 다음
