나빼고다천재

회사가 맥북 지급해줘서 쓰고 있는데

사실 윈도우 환경에 비해 압도적으로 편하다는 모르겠음

아래는 내가 생각한 장점

1. 빌드시간이 빠르다(동 사양에서는 빠른진 모르겠음 이전에 썼던 그램보단 빨랐다)

2. 별도의 터미널 프로그램 설치없이 iterm으로 접속가능한거

3. xcode 사용이 가능하다

4. 컨트롤 + 스페이스 이거 ㅈㄴ 편함

단점

1. 시스템 오류 혹은 오래된 레거시 툴 이런것들은 맥용 셋팅 맥용 버전 다 따로 찾아야봐야함 심지어 최신버전도

2. 램 확장성이 구림(개발자 피시는 램 많은게 장땡인데...)

3. xcode 사용성 개구림

4. 폴더 열었을때 윈도우마냥 경로 안보여줌

5. 최소화 하면 알트탭해도 리스트가 안나옴 독 열어서 직접 다시 원상복구 시켜줘야함

6. 무슨 이유인진 모르겠는데 램을 자꾸 퍼먹음 run cat 이라는걸 받아서 쓰는데 여유 램 공간이 idle 상태에서도 2기가가 채 안나옴

뭐 이게 맞다 그르다 이건 아닌데

사실 나는 맥이 좋은지 모르겠음

사양이 그렇게 높은것도 아니고...그램처럼 휴대성이 좋은것도 아니고...걍 로고 감성인듯

이외에 쓰시는분들 혹여나 EAGLE 보시면 장점 단점좀 써주십쇼 

고견을 듣고 장점은 수용하고 단점은 참고해보겠습니다

참고한다고

간혹 코드들을 보면 

1. export const handler = async (param) => {
  // 함수 내용
};

2. export async function handler (param) {
  // 함수 내용
};

3. const handler = async (param) => {
  // 함수 내용
};
export default handler;

이러한(더있을 수 도 있음) 차이는 초보자가 보기엔

뭔 차이임? 싶지만 사실 기능적으로는 큰 차이 없다.

관용적인 차이 일뿐이다.

다만 export defalut는 리팩토링과 트리쉐이킹으로 인한 번들 크기 감소 등.. 여러 이슈가 있어서 큰 규모라면 추전하지않는

물론 이는 아직도 소소한 논쟁이 있을 정도로 민감한 주제이니 이게 맞다 저게 맞다 하지말고 다니는 회사의 코딩 컨벤션을 

따라가자

뭐 애로우 펑션 이라고 부르는데 한국어로는 화살표 함수라고 부른다.

화살표 함수는 ES6부터 도입되었는데 이전에는 function을 시작으로하는 일반 함수가 사용되었다.

사용법은 보기보다 간단한데

function helloWolrd(){
	return "helloworld!"
}

이것은 화살표 함수 이전의 일반 함수의 형태이다.

const helloWorld = () => {
	return "helloworld!"
}

언뜻봐도 다르다는 사실을 알수있다 이 화살표 함수는 늘 뭔가 새로 도입되면 으레 하는 이야기처럼

가독성,간결성 이런 단어들이 장점이지만 무엇보다 핵심 몇개를 소개하겠다.

1. this 바인딩

화살표 함수 전 this는 분명 유용한 기능임에 부정할수없다. 하지만 종종 this는 예측불가능한 

분명 나는 이 함수를 가르켰는데 전혀 엉뚱한게 나온다거나 하는 엉뚱한 작동을 했다.

문젠 예측할 수 없기에 디버깅이 너무 어려웠다.

그래서 그 문제를 보완하고자 이 익명함수(화살표함수는 위 방법대로 만든다면 익명함수다)에 보완된 기능을 넣었다.

원랜 이거보다 this 바인딩의 개념은 훨씬 더 복잡하지만...이렇다는것만 알아두자

2. arg 속성의 사용불가

function regularFunction() {
  console.log(arguments);
}

const arrowFunction = () => {
  console.log(arguments); 
}

arg 속성이 위는 작동되지만 아래는 안될것이다.

3. constructor가 없다

원랜 일반 함수는 안에 prototype이라는 여러가지 기본 속성을 달고있는데 그 중에 constructor(흔히 말하는 생성자 함수)

가없어서 new 연산자도 불가능하다. 물론 생성자 함수와 여러가지 기본 속성들이 없어서 가벼운것도 특징

그외에도 return 문 생략 괄호 생략 등이 있지만 이건 컨벤션과 각 팀별 관례 혹은 관습에 따라 다르기 때문에

넣지않았다. 애초에 좀 핵심적인 부분만 짚고 싶어서 쓴글이기도 하고

어느날 아는사람이 where x = null 로 조회하니 결과가 안나오더라

where is null 은 조회가 된다는것이다

"null은 값이 없으니 비교가 안되죠" 라고하니깐 이해를 잘못하던데 좀 더 자세히 설명하려고 글을 썼다

NULL은 특수한 값입니다. 일반적인 비교 연산자(=)에는 작동하지 않습니다.

이 알수없는 값은 비교연산자에 들어가게 되는 순간 false를 반환하여 작동하지 않습니다.

즉 여기서 알수있는것은 true가 반환되어야 거기에 맞는 값이 반환되는것인데

null은 알수없는 값이 있는 유니크한 값이라 자동적으로 비교연산자가 false로 반환하기 때문에 값이 없는거다.

아래는 null 값을 검색하는 일반적인 권장방법이다.

select * from sample
where test is null

이렇게 IS NULL(혹은 is not null) 같은 형태의 명시적 방법이 권장됩니다.

오늘은 조금 이슈와 되는 이야기에 대해 해보자한다.

지금 프론트엔드의 개발환경은 바야흐로 대 타입스크립트의 시대이다. 고품질의 프레임워크 중 일부는 타입스크립트를

강제하며 기업들의 요구사항에도 타입스크립트의 사용 경험을 요구하는곳이 늘고있다.

실제로 몇번의 타입스크립트 사용도 해보았다. 이것이 제공하는 이점은 이미 인터넷에 널리고 널렸지만

오늘은 반대의 사례를 한번 보고 왜 그런일이 일어났는지를 고찰해보자

Turbo8의 타입스크립트 드랍

Turbo8에 대해 생소하다는 사람이 있겠지만 뒤의 말이 핵심이다 Turbo8의 개발자 DAVID HEINEMEIER HANSSON

이라는 사람이 타입 스크립트를 드랍하고 모두 javascript로 통일하겠단다.

문제는 이 사람이 나름의 커리어를 가진 사람이라는것이다.

루비온 레일즈의 프레임워크 개발자 창시자 중 한명이다(이하 데이비드). 이런 인지도 있는자가 왜 그런짓을 한것일까?

추가적으로 레딧과 포럼에서는 그의 행동이 오픈소스에 기여한 개발자들을 무시하는 처사라 비난하고 있으며

그가 타입스크립트의 어떤 부분이 싫은지 명확하게 설명하지 않고 있다며 그를 비꼬고 있다

(덤으로 turbo8의 PR창은 난리났다. 이런식으로 기여자들을 무시하는 처사는 처음이다 바보같은 짓이다.

이렇게 할꺼였으면 TSDoc을 활용해 타입에 대한 가이드라도 있어야했다. 등등..

재미있는건 옹호하는댓글도 상당수있으며 잘된 결정이라 해주는 사람도 있다.

시간이 있으면 보러가보자)

화자는 그러한 부분을 제하고 그가 블로그에 남긴 글들과 그리고 실제 개발자들이 느끼는 부분

그리고 화자의 사견을 덧붙여 글을 작성하도록 하겠다.

(아래 내용은 데이비드의 블로그 내용 중 일부를 한글로 번역하여 가져왔다)

타입 스크립트는 쉬운 일을 어렵게 만듭니다. 어려움이 닥치면 아무거나(any)라고 하게 되죠
그런건 사양하겠습니다.

데이비드의 타입스크립트에 관한 글들 중 가장 인상적인 부분이자 타입스크립트를 사용하며 느낀 첫부분인것 같다.

타입스크립트의 분명한 단점이다. 그의 관점은 짧고 간결해야할 작성을 타입을 명시하고 정하는 행위가 어려운

일이라 표현하고 있다. 이것은 틀린말이 아니다. 물론 누군가는 그렇게 어려운 일이 아니라는 논리를 펼치겠지만

우린 그가 루비 온 레일즈라는 프로그래밍 역사에 기록될 뛰어난 프레임워크의 개발자 중 한명이라는 사실을

기억해야한다. 권위에 기대는것이 아니라 그렇게 생각하는 이유는 다음 문단을 보며 알수있다.

우리가 브라우저에 실행되는것이 Typescript가 아니라 Javascript를 실행한다는 사실을 받아드려야합니다.
그렇기 때문에 어떠한 도구나 타이핑 없이 코드를 쓸수있다는 그 상황이 축복인것입니다.

그의 논지는 웹에서 작동되는 언어는 타입스크립트가 아니라 자바스크립트이며 그러한 사실을 인정하고 그것이 

흔히들 이야기하는 스펙임을 깔고 가야한다는것이다. 그는 실제로 타입스크립트를 제거하는 코드가 담긴 

형상을 turbo8로 병합하면서 코드의 간결성,직관성이 훨씬 좋아졌다는 코멘트로 남겼다.

포럼에서 타입스크립트를 싫어하는 이유를 정리해보았다.

1. 코드를 짜는 시간보다 TS 완벽한 타입체크를 하는데 더 많은 시간들 들여야한다.

2. 지원하지않는 외부 라이브러리들이 존재한다.

3. 자바스크립트는 애초에 C++,java 같은 강타입 언어들의 패러다임을 벗어나고자 나온 약타입언어다. 그렇기에

일정 부분 유연성을 주어야한다.

4. TS는 coffescript,backbone 같은것처럼 언젠간 없어지겠지만 JS는 그렇지않다. 

5. 브라우저의 디버깅이 훨씬 더 어렵다.

6. 빌드 프로세스가 복잡해진다.

7. 새로운 개발자나 후임자가 배우기 어렵다.

아래는 레딧에서 타입스크립트에 관한 글중 최고 표를 받은 댓글 내용 중 일부이다.

Q1. 타입스크립트를 좋아하시나요 싫어하시나요?

A1. 나는 그 언어를 싫어한다. 나쁘진 않지만 필요하지 않을뿐이다. 대규모의 프로젝트를 진행할때도

오류추적이 그렇게 복잡했던적이 없다. 정작 그 언어가 가진 단점은 코드를 읽기 어렵게해 

평생 직장을 얻게 해주는것뿐이다. 

Q2. 순수한 자바스크립트를 선호하는 그 이유는 무엇입니까?

A2. 일반 JS는 읽기가 매우 쉽습니다. 대부분의 문서와 도구는 일반 JS에 다 포함되어있습니다

코드를 작성하고 웹에서 즉각적으로 결과를 확인하는 디버깅으로 충분합니다. 

Q3. 타입스크립트를 사용하면 생산성이 떨어지나요?

A3. 명백합니다 느려집니다. 타입스크립트와 싸우는 시간이 더욱 더 늘어날것입니다. 모두가 타입스크립트의

생산성을 찬양하지만 실상은 그렇지 않습니다. 이상하게 타입스크립트의 생산성을 이야기할땐

초기설정와 중간설정(작은 단위의 임포트,인터페이스 추상화)의 시간을 빼고 코드를 치고

디버깅 하는 시간만 거론합니다

그러면서 자바스크립트의 생산성을 이야기할땐 마치 디버깅을 하게 되면 세상의 종말이 올것이라

디버깅에 큰일이 날것처럼 이야기합니다. 실상은 그렇지 않습니다.

모든 프로그램은 잠재적인 위험을 가지고 있습니다. 

화자는 타입스크립트를 신봉하지도 그렇다고 부정하지도 않는다.

다만 일부 부정적인 의견과 긍정적인 의견을 모두 받아드린 편이다.

해줄수있는 말은 취업을 원한다면 배워야한다는것이다.

타입스크립트의 강점은 데이터의 타입을 저장하고 보존하는것이다. (그게 인자건 무엇이든)

그렇기에 필요로하는 타입을 정하는데 과거에는 any 타입을 남발했지만 요즘에는 이보다 더 세련된 방법이 있다.

바로 제너릭이라고 말하는것이다.

아래를 보자

function anyTypeFunction(arg: any): any { 
	return arg; 
}

타입스크립트에 처음 입문하거나 타입을 확신할 수 없을때 이렇게 쓰는 경향이 있다.

나도 그런다.

하지만 이렇게 함으로써 인자의 최초타입은 유실되었고 이후 전달받을 데이터의 타입도 신뢰성이 떨어진다.

이럴땐

function genericFunction(arg: T): T { 
	return arg; 
}

이렇게 해보자 위 함수는 인자의 타입을 제너릭이라 명명하여 해당 인자의 타입을 강제로 변환시키지 않으며

내부 로직을 거쳐도 보존된 타입을 그대로 다시 돌려준다.

이로써 타입의 신뢰도와 예측불가능한 상황을 줄일 수 있다.

이것으로 인해 얻은 강점은

1. 인자의  타입의 변동성에도 대응할 수 있다.

2. 타입의 안정성을 확보할 수 있다.

3. 가독성이 상승한다.

얼마전 본업이 아닌 일을 자주하고 있다고 했는데 그게 자바다.

사실 본업이 아니여서 굳이 이걸 정리한다거나 뒤져본다거나 할 필요가 있을까? 

싶은데 해두면 뭔가 자랑거리 하나 느는거 같아서 탭을 신설했다 

주로 올릴건 spring(boot 아님),트러블슈팅 정도지않을까? 싶음

언제 올릴지는 몰?루

객체지향 프로그래밍이 대세인지 모르겠지만 객체지향이라는 말을 요근래 자주 접하게 됬다.

자바스크립트는 그 태생부터 객체지향 언어였다. 

하지만 태생이 그렇다뿐이지 처음엔 객체지향에 적합한 언어는 아니였다.

그렇기에 초기에 많은(나도 그러하다)언어의 태생은 잊은채 명령형으로 자바스크립트를 다루기 시작했다.

const one = "hello";
const two = "world!";
cosnt plus = one + two;
console.log(plus); // helloworld!

우리가 지금도(나쁘다는뜻이 아니다)보는 일반적인 명령형 구조이다. 

위에서 아래로 구성되며 자연스레 읽힌다

하지만 많은 개발자들이 객체지향의 장점에 주목하기 시작했다. 

객체지향은 명령형과는 다른 견고함을 지녔으며 뛰어난 재사용성,유지보수성,확장성 등을 선보였다.

이러한 장점들에 반한 사람들은 자바스크립트의 태생을 주목하기 시작했고 

ES6부터 드디어 자바스크립트에도 객체지향이라는 봄이 찾아오기 시작했다.

- 자바스크립트에도 객체지향이라는 봄이 오는가

객체지향의 지원을 위해 많은 것들이 도입됬다. 

클래스,상속,모듈,화살표함수 등 이런 많은것들이 등장했다 아래를 살펴보자

// 명령형 코드로 배열에서 최댓값을 구하는 함수
function getMax(arr) {
  let max = arr[0];

  for(let i = 1; i < arr.length; i++) {
    if(arr[i] > max) {
      max = arr[i];
    }
  }

  return max;
}

console.log(getMax([1, 5, 2, 7, 3, 9])); // 9

위는 명령형으로 만들어진 함수이다. 일반적인 방법을 사용했고 으레 그렇듯 반복문을 활용해 배열안에 있는

숫자 중 가장 큰 수를 가져온다.

이런 단순 한번만 쓰자면 별 문제가 없어보인다. 문젠 이것을 확장하거나 재사용을 할때 문제가 생겨버린다.

최대값이 아닌 최솟값을 찾는 기능을 추가하자면?

다른 기능과 조합가는 경우에는?

순회하는 배열안의 원소들이 천개,만개를 넘어서면?

명령형이 생기는 문제들에 직면할수있다. 객제지향이 매력적으로 보고 싶다면 아래 코드를 보자

// 객체지향적으로 배열에서 최댓값을 구하는 클래스
class MaxFinder {
  constructor(arr) {
    this.arr = arr;
  }

  find() {
    return Math.max(...this.arr);
  }
}

const finder = new MaxFinder([1, 5, 2, 7, 3, 9]);
console.log(finder.find()); // 9

클래스로 MaxFinder를 만들고 안에 find라는 메서드를 만들고 메서드는 안에는 숫자를 파라미터로 받아

스프레드오퍼레이터를 활용해 받은 다음 큰 수를 받아낸다. 

정말 멋진 코드가 아닐 수가 없다.

하지만 이러한 객제지향은 가장 큰 난관은 프론트엔드의 관점에서 객체지향은 그저 이런게 있다라고 알고 

넘기는거 말고는 방법이 없다

객체지향을 처음 접하면 명령형에 비해 생산성이 떨어지는건 모두가 아는 사실

이것이 프론트엔드의 객체지향의 문제점이다 

프론트엔드의 귀결은 모두가 리액트(아마도)로 되기 때문에 선언형을 배우게 될텐데 선언형은 

객체지향과 다른 패러다임을 향하고 있기 때문에 굉장히 다르다.

아래의 코드를 보자

// 선언형 코드로 배열에서 최댓값을 구하는 함수
function getMax(arr) {
  return arr.reduce((acc, cur) => cur > acc ? cur : acc, arr[0]);
}

consleo.log(getMax([1, 5, 2, 7, 3, 9])); // 9

객체지향과의 차이점이 한눈에 보일것이라 생각한다. 

이러한 이유 때문에 프론트엔드의 객체지향은 잡힐듯 잡히지 않는 신기루 같은 존재가 되어버린거다.

물론 도입하자고 하면 도입할 수 있겠지만 프레임워크의 권장,표준 이라는것을 쉽게 무시할 수 없다

절대강자로 자리잡은 리액트의 선언형을 그 누가 객체지향으로 하겠는가?

혹시 모른다 구글이라면 가능할지도