오늘도 현석님이 중간에 제출한 코드를 기반으로 피드백해주시는 시간이 있었다. 워낙 좋은 얘기를 많이해주셔서 전부 블로그에 정리하고싶은데, 전부 올리면 문제가 되지 않을까..? 싶어 몇개만 추려서 올려본다.
예전에 클린코드에 대해 간략하게 찾아봤을때 인자가 두개 이상인 함수는 비권장한다는 글을 읽었었다. 그때 당시에는 단순히 인자가 여러개 되면 함수에 너무 많은 역할을 하고 유지보수 성에서 복잡하겠구나~ 라고 생각하고 넘어갔는데, 오늘 현석님이 피드백해주신 예시를 보고 함수의 인자를 다루는게 왜 중요한지 알게 되었다.
아래 코드의 경우에는 인자를 세개를 받고있다. 그러나 만약에 인자를 넘기는 순서가 변경된다면? 중간에 있는 인자를 넘기지 않아 인자의 순서가 밀린다면?
function getUniqueRandomNumbers(low, high, count) {
// some code
}
예외처리 구문을 사용하거나 JSDoc을 사용하거나 TypeScript등을 사용해 이런 상황을 방지할 수 있겠지만, 위험이 있는 코드라는건 분명해졌다. 또한 위의 함수의 경우 low/high, width/height, min/max같이 통상적으로 생각하는 순서의 흐름이 적용되어 있지만 이런 흐름이 적용되지 않는 함수의 경우 순서를 혼동하기 쉬울것이다. 그래서 인자를 여러개 넘길 경우 object로 넘기는 이유에 단순히 확장성이나 간편함때문에는 아니겠구나! 싶어졌다. 인자가 여러개일 경우 객체로 넘기는 방법은 전에도 사용하고 있었지만, 조금 더 구체적인 사용 이유와 주의점을 알게 되어 중요성을 다시 한번 깨닫게 되었다. 👍
이 부분에 대해 설명을 들었을때 정말 머리를 한대 얻어맞은 기분이였다. 블로그엔 정리하진 않았지만 저번 세션에도 비슷한 얘기를 해주셨는데, 최근 유행하는 코드에 대한 얘기였다.
export default class Component {
constructor($target, props) {
this.$target = $target;
this.props = props;
this.state = {};
this.setUp();
this.render();
this.setEvent();
}
setUp() {}
setState(newState) {
this.state = { ...newState };
this.render();
}
setEvent() {}
render() {
this.$target.innerHTML = this.template();
this.mounted();
}
mounted() {}
template() {
return '';
}
}
이런식으로 base 클래스를 정의한다음 extends해 컴포넌트를 작성하는 기법! 나는 미션에 실제로 활용하진 않았지만, 전에 비슷한 형식으로 코드를 작성한 적이 있었다. 이런 방식으로 코드를 작성하는건 준일님의 블로그 글에서 큰 영향을 받았는데, (다른분들은 아닐수도 있지만) 현석님이 자바스크립트를 공부하는 목적과 걸맞지 않은 유행에 치중한 코드를 작성하는게 과연 우리가 바닐라 자바스크립트를 쓰는 이유에 걸맞은가? 라고 말하셨다. (축약해서 적느라 그렇지 실제로 말투가 이러시진 않았다!!ㅋㅋㅋ) 자신의 생각이 적용되지 않는채로 코드를 작성하는건 그냥 npm에서 모듈을 install하는것과 다름 없다고 ㅋㅋㅋ말씀하셨는데, 나도 class로 컴포넌트처럼 코드를 작성하는걸 먼저 접한 입장에서 큰 생각없이 습관적으로 코드를 작성한것 같아 뒤를 돌아보게 됐다.
그리고 우리가 주로 사용하는 인스턴스를 사용해 컴포넌트를 만드는 경우에는, 클래스의 재활용적인 의미와 잘 부합하지 않는다라는 말씀도 하셨다. 근데 확실히 나같은 경우에도 클래스(혹은 함수형으로 작성한다 해도)로 컴포넌트를 만들고 new로 인스턴스를 생성하면, 해당 인스턴스를 한번만 생성하고 사용하는 식의 코드가 많았다. 또한 이건 나도 작성하면서도 의문을 갖고 있었는데, 지금 작성하는 코드를 굳이 인스턴스로 생성하지 않고 static으로 작성해도 별다른 차이가 없겠다는 관점이였다.
현석님은 만약 인스턴스를 한번만 사용하고, 전부 static 메서드로 사용해도 큰 차이점이 없다면 싱글턴 패턴에 대해 알아보라고 조언을 해주셨다. 싱글턴 패턴의 경우 자바스크립트의 기본기 관련 책을 보면 많이 듣는 키워드인데 사실 찾아봐도 잘 이해가 되지 않아 넘어갔었다. (..)ㅎㅎ 그런데 이번 예시를 듣고 나니 싱글턴 패턴이 추구하는 목적과 내가 작성하던 코드의 흐름이 비슷한것 같았어서, 뭔가 그동안 작성했던 내 코드에 대해 고민을 많이 하게되었다.
그동안 import/export 문법을 사용해 프로그래밍을 여럿해봤음에도 불구하고 import 문 작성 순서를 크게 고민한적은 없었는데, 이번 기회에 대해 import순서에도 규칙이 있으면 좋겠구나! 싶었다. eslint sort import 라는 키워드로 검색해보는걸 추천해주셨는데, 읽어봐야지~ 하고서 미루고 있다. 조만간 꼭 읽기로..!!
사실 이번 세션 회고를 올리게 된 가장 큰 이유! 인생 처음으로 페어 프로그래밍을 해봤다. 종종 메이커준님이 페어 프로그래밍 워크숍을 여셨는데, 그동안 사정으로 인해 한번도 참여를 못해봤다.ㅜㅜ그래서 라이브세션 도중 갑자기 페어프로그래밍 참여자를 모집할때 민폐가 될까 고민하다가 큰맘 먹고 신청을 해봤는데, 마음 먹고 신청하길 아주 잘했다 싶었다.
사실 나는 페어프로그래밍만 처음이 아니라 cypress도 처음이였다. 그래서 너무 어리버리한 모습을 보여 같이 세션에 참여하던 분들께 민폐가 될까 많이 걱정이였는데, 준님 뿐만 아니라 같이 페어로 진행하셨던 분이 친절하게 이끌어주셔서 부담을 좀 덜을 수 있었다. !!
페어프로그래밍 인증샷 👍
처음 해본 페어프로그래밍 후기는 일단 확실히 나 혼자 뿐만 아니라 다른 사람이랑 진행해보니 사소한 실수 (오타라던가..)를 쉽게 찾을수 있다는 점이였다. 즉석에서 간단하게 진행한 프로그래밍이라 깊은 부분까지는 작성하지 않아 자세한 후기를 남기긴 힘들지만, 확실히 상대방이 무언가 잘 모르는 상황에서 적응하려 할땐 페어프로그래밍이 좋겠다는 생각이였다. 실무에서도 적용하면 참 좋을것 같다는 생각이였다!
그리고 cypress에 대해 어려울것 같다는 생각을 많이 갖고 있었는데, 처음 해본 후기는 생각보다 쉽다라는 점이였다. 전에 자스민으로 유닛테스트를 작게 해본 경험이 있었는데, 유닛 테스트보다 메서드도 훨씬 직관적이고 여러모로 쉬운 느낌? 역시 지레 겁먹는것보다 뭐라도 직접 해보는게 좋은것 같다.
넥스트스텝에서 하는 스터디는 진행해주시는 분들 뿐만 아니라 참여하는 분들까지 활발히 의견을 제시해주셔서 재밌는것 같다. 특히 주제를 제시해주시고 각자 생각하는 의견에 대해 질문을 받으실때, 여러 의견이 나오기도 하고 내가 몰랐던 부분들도 많이 보여서 너무 재밌다. 또 페어프로그래밍..당시 줌에 30분 정도 참여했던걸로 기억하는데, 준비되지 않은 상황에서 충동적으로 신청한 페어프로그래밍이라 처음에는 괜히 신청했나 불안에 떨었다. 근데 페어프로그래밍을 마치고 나니까 너무너무 재밌었고 유익한 경험이였다! 정말 고민하다가 에라 모르겠다 하고 내린 결정이였는데, 끝나고 나서는 신청하길 잘했다고 내 자신을 칭찬해 줬다. 그리고 염소같이 떨리는 내 목소리로 진행하는데도 같이 들어주신 나머지분들께도 감사를 하고싶다..ㅎㅎ 이제 자동차 경주 미션을 하러 간다! 끝!