소프트웨어 설계 20년 해보고 깨달은 '좋은 설계'의 조건
- '모든 상황에서 모든 문제를 해결해주는 모범답안 같은 완벽한 해법은 없으며, 설계는 정교한 의사소통을 돕는 도구로 활용될 때만 의미가 있다고 믿습니다.' - 본문 중-
- '소통 없이는 완벽한 설계 문서란 없다.', '당장 개발을 위한 소통에 쓰이지 않는 문서나 그림 형태로 설계하는 일은 지양해야 헙나다.' - 본문 중-
완벽하고 철저한 설계는 있을 수 없고, 코딩 직전에 어떻게 해야 할지 정도만 설계하면 된다. 개발 전에 모든 것을 꼼꼼하게 설계하지 말고, 개발-리팩토링하면서 지속적으로 설계도 해나가야 한다!! (약간 애자일 개발방법과도 연결되는 것 같다 !)
[Korean FE Article] 내가 작성한 Jest 테스트는 왜 이렇게 느릴까?
- 읽은 계기 : 요즘 회사에서 jest 를 이용한 컴포넌트 테스트를 하기 시작했다~ 테스트가 돌아갈 때마다 몇 초씩 기다리는데, 지금 테스트는 짧지만 더 길어지면 더 오래 걸릴 수도 있을 것 같다. 어떻게 테스트하는 게 좋은지 미리 알아두면 좋을 것 같아서 읽었다.
- Jest 성능을 떨어뜨리는 실수들에 대해 나온다.
-
- import 할 때, 정확히 그 대상이 어디있는지 명시하자. (예- import {debounce} from 'lodash' -> import debounce from 'lodash/debounce'
-
- setupTests.ts 확인하기
-
- test 환경에서는 type 체크는 제거하기
-
- 불필요한 jest 명령어(플래그) 사용하지 않기 (cache 비활성화, 리포트 생성 등등)
-
- watch 모드 -> jest 초기 실행 시 필요한 부분을 건너뛸 수 있어 시간 절약됨.
(번역) 확장 가능한 CSS의 진화
CSS 진화 과정
- CSS 이전 : HTML 만 존재함. 마크업에 직접 속성 사용. -> 스타일 수 제한적. 스타일 중복해서 사용해야 함.
- CSS 등장 : 콘텐츠 구조(HTML)와 스타일(CSS)의 관심사가 분리됨. 중복도 제거됨.
- Less, Sass 등 도구와 패턴 등장 : 변수, 계산 함수 기능을 통해 개발자 경험 향상 / 확장을 위한 패턴 나타남.
CSS를 대규모로 관리하기 어려운 이유
- 대규모로 관리하고 효과적으로 확장하려면, 시스템이 커져도 이해하고 변경하기 쉽고 성능이 좋아야 함.
- 전역 네임스페이스, 캐스캐이딩 규칙, 선택자 특정성 때문에 CSS 확장이 어려움.
- 전역 네임 스페이스 : 대규모로 관리하다 보면, 상황을 예측하기 여려움. 예기치 못한 문제 생길 수 있음.
- 시맨틱 클래스 이름 짓기 어려움 : CSS 스타일을 주기 위한 클래스 이름을 짓기 어려움.
- 리팩토링 어려움 : 정확히 필요한 코드인지 아닌지 파악하기 어려워서, css 코드를 리팩토링하는 것보다 복사 붙여넣기하는 게 안전하다고 생각함. 그래서 파일 끝에 새 코드를 추가하고, 사용하는지 안하는지 정확히 알지 못하는 CSS 코드가 생겨남.. (ㅠㅠ 완전 공감...)
- 디버깅 어려움 : 여러 파일에 걸쳐 있는 CSS 를 다 보고, 캐스캐이딩을 계산하려면 어렵다. 생각대로 동작 안할 때도 많고.. (개발자 도구가 있어서 그나마 나은 것 같다.)
CSS 아키텍처
- OOCSS (Object Oriented CSS) : 자주 사용되는 일반적인 패턴을 재사용 가능한 클래스로 추출해서 사용한다. (예- Bootstrap)
- SMACSS
- BEM : 블록, 요소, 수정자 스타일 ! 고유한 클래스 이름을 지을 수 있는 규칙을 제공함.
- ITCSS
- 큐브 CSS
관심사 분리에 대한 재고
SPA, 컴포넌트로 개발하면서 CSS 관리 어떻게 하면 좋을지 고민함.
- 인라인 스타일 : 스타일이 그 요소에만 영향 미쳐서 안전하게 스타일링 가능 <-> 미디어 쿼리, 의사 선택자 등 기능 사용하기 어려움.
- CSS in JS : Styled Component, Emotion emd.. <-> 성능 문제 있을 수 있음. (개선하는 중)
- CSS module : 전역적으로 스타일이 적용되지 않고 지역적으로 적용 가능.
새로운 사례들
- tailwind CSS : 생산성 높임. 유지 관리 용이. 이름 계속 고민할 필요 없음. 글꼴, 색상, 간격 등 기본 디자인 요소를 제공함.
CSS 를 대규모로 잘 관리하려면?
완벽한 도구는 없음.
디자인 격차를 해소하는 기반을 구축해야 함.
일의 난이도 높이기
나도 회사 일에 적응하면서 비슷한 일을 반복하는 느낌이 들 때도 있다. (하지만 아직도 새로운 게 많아서 ..이런 때는 많지 않다.)
그럴 때 여러 개선 방법을 시도해보면서 성장할 수 있다는 내용이다! (테스트, 단축키 익히기 등등)
'함께 자라기' 책에도 비슷한 대목이 있던 게 떠올랐다.
ChatGPT 관련 아티클들
chatGPT가 유명해서 시험삼아 써보다가 유료 결재까지 했다 ㅎㅎ
코드를 입력하고 '코드 리뷰해줘'라고 하면 해주고(당연히 회사 관련 코드는 아니었고 PS 관련 코드였다.) , '서울 갊만한 장소', '이색 취미 추천' 등도 해준다!!
구글링하면 같은 키워드를 chatGPT에 검색한 결과도 보여주고! (ChatGPT for Google 크롬 익스텐션을 이용하면 되는데, 현재는 chatGPT 유료 버전만 가능한 걸로 알고 있다)
더 잘 사용할 수 있는 방법, 관련된 담론들이 궁금해서 찾아봤다!
- 사무 업무 관련해서 가이드
- chatGPT가 할 수 있는 일과 하기 어려운 일을 표로 설명하고, 예시를 보여줌.
- 보고서 초안 자성, 아이디어 탐색, 번역/요약, 표 해석
- ChatGPT Api 활용해서 프로덕트를 만들 수 있다.
- ML 기반 프로덕트를 만들 때 고려할 점을 6가지로 설명한다. (1. 모델 성능 측정, 2. 오류 처리(사람 검수하는 과정 고려하기). 3. 개선/오류 교정, 4. 답변의 안정성(항상 같은 질문에 비슷한 패턴으로 응답), 5. 속도(응답 시간), 6. 법적 책임(input, output이 chatGPT 개선을 위해 쓰일 수 있으니 민감한 정보는 넣지 말기/ chagGPT의 응답을 사용하는 것에 대한 책임은 사용자에게 있음)
- 컴퓨터 과학을 전공한 technical writer, SF 작가가 쓴 글이다. 그래서 그런지 재미있다 ㅎㅎ
- 복사기 예시를 든다. 원본을 그대로 복사하는 게(무손실 압축) 아니라, 디지털로 압축해서(손실 압축) 복사하는 복사기가 있었는데, 세세한 문자가 다르게 인쇄되는 문제가 있었다고 한다. 원본과 엄청나게 달랐다면 금세 알아챌 수 있었겠지만, 미세하게 달라져서 문제였다.
- ChatGPT 등 대규모 언어 모델도 이것과 비슷한 문제가 있을 수 있다고 한다. 딱 정확한 정보, 인용문, 근거를 찾을 수가 없는 것이다.
- '단어 시퀀스를 처리할 때는 손실 압축이 무손실 압축보다 더 똑똑해 보입니다.' (만약 ChatGPT가 딱 정확한 정보를 제공했다면, 뛰어난 검색 엔진이라고만 생각했을 텐데 이걸 자신의 언어로 말하는 걸로 보여서 더 똑똑해보인다)
- 대규모 언어 모델이 잘 쓰일 수 있는 상황이 있고, 아닌 상황이 있을 수 있다.
- 검색 엔진을 대체할 수 없을까? (원하는 정보가 있어도 그게 조작된 것이 아니라는 걸 확신할 수 없고, 근거를 명확히 알 수 없음)
- 독창적인 작품을 만들 수 있을까? => '초고는 독창적인 아이디어가 명확하게 표현된 것이 아니라 독창적인 아이디어가 제대로 표현되지 않은 것이며, 여기에는 무정형적인 불만, 말하고자 하는 내용과 말하고자 하는 내용 사이의 거리에 대한 인식이 동반되어 있습니다. 이것이 바로 재작성 과정에서 사용자가 느끼는 불만이며, 인공지능이 생성한 텍스트로 시작할 때 부족한 부분 중 하나입니다.'
[번역]잘 알려진 UI 패턴을 사용하여 리액트 애플리케이션 모듈화하기
회사 프론트엔드 동료분이 추천해주셔서 읽게 됐다! 그림, 예시 코드가 있어서 이해를 돕는다.
이론적으로는 관심사를 분리하는 게 좋다는 걸 들어서 알고는 있었지만, 그런 식으로 코드를 작성하지 못할 때도 있었다.
회사 코드에서는 관심사 분리가 어느 정도 되었기는 했지만, 나 혼자 프로젝트를 만들라고 하면 그런 구조를 만들 자신은 별로 없었다.
그래도 이 글을 읽고 그 필요성, 어떻게 해야 할지 알 수 있었다 :) 좋은 예제를 많이 보고, 공부하고, 코드에 적용해야겠다~~
- 문제 상황: 리액트 컴포넌트, 훅에 비즈니스 로직이 많은 경우 -> 코드 이해, 수정하기 어려움.
- 리액트를 뷰로만 사용하는 패턴, 기법에 대해 설명함.
- 관심사 분리 : 코드 이해 => 뷰, 뷰와 관련없는 로직을 분리하고, 로직을 잘 배치하는 것 중요함. 그러면 수정, 테스트, 재사용하기 쉬워짐.
- 리액트는 뷰를 구축하는 라이브러리! (UI 에 집중)
- 리팩토링 과정
- 단일 컴포넌트 안에 모든 코드가 있음. (네트워크 요청, 상태 관리, 로직, 렌더링..)
- 여러 컴포넌트로 분할하기. (각 컴포넌트는 한 가지에만 집중하기)
- 훅을 이용해서 상태, 로직 공유하기. (훅을 이용해서 네트워크 요청, 로직 관리하기)
- 로직을 추출, 분리하기. (네트워크 요청 / 도메인 로직 / 상태 관리 / 렌더링 따로)
- 계층화 (프레젠테이션 / 도메인/ 데이터 레이어를 분할)
개발자 진로에 중요한 직급별 스킬과 기대 역할
주니어, 미드 레벨, 시니어, 스태프, 수석, distinguished 엔지니어로 나눠서 각각 필요한 스킬, 기대 역할, 대략적으로 걸리는 시간을 설명한다.
주니어는 '명확하게 정의된 업무를 완료하고 다른 문제로 인해 업무가 차단되었을 때 도움을 요청한다.' -> 도움을 요청하는 것이 주니어의 '스킬'이라고 하는 점이 인상적이었다. 도움을 요청할 때, '남들이 내 실력이 부족하다고 생각하면 어쩌지?' 걱정을 했는데 주니어는 그렇게 하는 게 당연하다고 말해주는 것 같아서 용기가 생겼다 ㅎㅎ 계속 학습을 하면서, 꾸준히 목표를 내야 한다고 한다!!
한두 줄 요약
(번역) 리액트와 함께 일반적으로 사용되는 라이브러리들
제목 그대로 리액트와 함께 자주 사용되는 라이브러리를 소개한다. 간단히 소개하고 있어서 여기에 나오는 걸 보고 관심 있는 걸 검색하고 배우면 도움이 될 것 같다!
*작은 따옴표 안의 글은 해당 아티클을 직접 인용한 부분입니다.
'책꽃이 📔' 카테고리의 다른 글
| 개발자 원칙(읽는 중) (0) | 2023.03.22 |
|---|---|
| 23년 3월에 읽은 개발 아티클 📝 (0) | 2023.03.02 |
| 23년 1월에 읽은 개발 아티클 🔖 (0) | 2023.01.05 |
| 다른 개발자 분들의 2022 회고 글을 읽다. (0) | 2022.12.28 |
| [2022.12.12-18] 이번 주에 읽은 아티클 🔖 (0) | 2022.12.14 |