협업을 위해서 주니어가 제일 신경써야하는 부분은 가독성이다.
웹/모바일 변천사
웹
그시절1.0
그시절 코드를 간단하게 보여주심.
- marquee: 마키 태그는 지금은 deprecated되었는데, css쓰지않았는데도 글씨가 움직이는게 혁신이었다고ㅋㅋㅋㅋ
- iframe:
그시절 개발이란 view와 logic이 혼재되어있었다.
그시절2.0
제이쿼리로 클래스만 주면 되던 시절
그시절3.0
파일을 분리해 head에 script, link를 통해 import함.
html파일에 js를 쓰지 않는다.
기존에 의미없이 영역만 나누었던 div, span을 넘어 의미를 가진 tag가 나타났다.
main, section, h1, aside, nav...
컴퓨터가 태그를 이해할 수 있게 되었다.
그리고 canvas 태그가 나오면서 activeX 설치하지 않아도 플래시게임을 할 수 있게 되었다.
즉, 웹은 이해할 수 있는 방향으로 발전되어왔다.
모바일
java, c++ -> Cordova -> Kotlin, Swift -> RN, Flutter, PWA
모바일 역시 가독성이 개선되는 방향으로 발전되었다.
하이브리드앱
요즘은 웹에서도 모바일과 같은 화면이 나오는 일이 많아졌다.
모던 프레임워크
렌더를 하는 함수가 들어간다.
로직과 뷰가 나누어지면서 구조화되었다.
태그에 개발자가 원하는 방식으로 이름을 지어 넣을 수 있게 되었다.
기능들을 세세하게 나눌 수 있다.
- 사고를 정리하는 것이 중요하다.
- 기능별로 나누어서 코드를 짜면 파일 하나만 고쳐도 기능이 작동한다.
next router
spa에 초점이 맞춰져 있었음.
페이지 이동할 때 새로고침하지 않는다. 이동하지 않고 내용만 바꿔준다.(서버에 요청하지 않음)
1.0 page Router
페이지 하나하나가 view
2.0 app Router
서버사이드, 클라이언트사이드를 나누어서 작업.
axios를 쓰지 않아도 된다.(서버가 바깥에 있다는 가정 하에 사용하는 것.)
page.jsx만 view
layout.jsx: 루트에 레이아웃을 만들어서 변하지 않는 부분(header)은 한번만 렌더링하면 되도록 함.
useClient의 경우 클라이언트 컴포넌트만 쓴다. 서버 컴포넌트는 쓸 수 없다. useState 등의 훅을 쓸 수 없다.
내 문제를 정의할 줄 알아야한다.
기능이 안돼요 엉엉(사용자 질문)
내가 이 url 요청했는데 500 떨어진다(개발자 질문)
네트워크 7계층
개발자도구에서 네트워크를 보자.
코드 퀄리티
타입스크립트
자바스크립트는 몽키패치로 인해, 타입이 제대로 설정되어있지 않기 때문이다.
이와같은 문제에 대한 유튜브 영상을 하나(feat 노마드코더) 봤는데,
[] + {} 는 [object object] 를 반환하지만,
{} + [] 는 0을 리턴하는 충격적인 모습을 볼 수 있었다....
js는 16bit 이상을 처리할 수 없다.
디자인패턴
'특정 문맥에서 공통적으로 발생하는 문제에 대해 재사용 가능한 해결책'
팩토리패턴
피자 만드는 예시.
makepizza(){}
servepizza(){}싱글톤
싱글톤은 한곳에 저장됨. 어디서 불러도 같은 함수가 리턴된다.
let a = getCart()
let b = getCart()
// 보통 이 함수들은 다르다.(다른 공간에 각각 저장됨)퍼사드 패턴
헬퍼함수를 만들어서 어디서든 import해와 사용 가능하다.
이제 날짜 포맷이 바뀌면 이거 하나만 수정하면 된다.
getNowDate() {
return new Date();
}
TDD
테스트 코드는 작성할 수 있어야 한다고 생각.
testing flutter apps
tests/Feature -> 전체적인 테스트
/Unit -> 유닛 테스트테스트 커버리지를 보여준다.(어디까지 얼마나 테스트했는지)
테스트코드를 잘 짰는지 알 수 있다.
테스트파일을 통해 커버리지가 80%이상이라는 것을 증명하는 커버리지 레포트를 제출하기도 함(하청, 정부사업)
트렌드
State of JS
stackoverflow survey
PWA
웹에서 앱설치(앱처럼 보이도록 함)를 할 수 있다.
AI와 접목
클라우드와 서버리스
웹 보안
개발자의 기본 소양
- 코드컨벤션을 반드시 익힌다.(가독성)
- 중복코드는 가능한 배제하되, 역할이 보이도록 한다. 이 경우 오히려 반복이 나은 경우가 있다.
- oop의 5대 원칙: SOLID
- 단일책임의 원칙: 하나의 기능 하나의 목표(SRP)
- 라이브러리의 원리를 생각해본다.
- 항상 레퍼런스를 참고한다.
개발을 어떻게 배워야지(스킬 스펙업) 보다는 가지고있는 것을 활용, 확장하자.
어떤 역할을 하는 개발자가 될지를 생각해서 어필하자.
스타트업 생태계
(내) 능력보다 사람이 중요하다.
후일담
스타트업 대표님이라서 그런지 생각지 못한 다른 관점에서의 이야기를 많이 해주신 것 같다.
제일 핵심이었던, 8시간의 강의 시간을 관통한 주제는 '가독성' 이었다.
좀 분리가 필요해보인다 반복되는거같다 싶으면 바로 분리하고 리팩토링했는데, 여러모로 다시 생각해보면서 진행해야할 것 같다. 역시 리팩터링 책을 사야... 근데 책이 너무 크고 두껍다보니 전자책으로 사고싶은데 그럼 필기를 또 못하고... 휴 고민이다.
대기업에 가서 분업화가 잘 되어서 한 파트만 맡기보다 여러 부분을 개발해보고싶다.
직접 이것저것 건들여보고 만들어보고 하는 게 좋거든.
본 후기는 유데미-스나이퍼팩토리 앱/웹 개발자 인턴형 프로그램 학습 일지 후기로 작성 되었습니다.
