#참가하게 된 계기& 마음 가짐
기다리던 우테코 프리코스가 드디어 시작되었다.
나의 주니어로써의 목표를 크게 말하자면 단 하나다 온전한 개발자로 우뚝 서는것.
우테코는 그 목표를 실현하기 위한 가장 좋은 수단이라는 생각에서 참여하게 되었다
조금 더 세부적인 이야기는 매달 (하려고)하는 나의 무지성 개발 일기 10월 회고' #우테코 지원' 부분 에 적혀있다.
https://hello-coding-world.tistory.com/44
요약 하자면 깃이나 각종 컨벤션을 잘 지켜나가면서 작업을 해야겠다는 필요성 , 좀 더 가독성이 좋은 코드 , 설계 지향적인 코드 같은것들이 독학 하면서도 점차 점차 맞닿아가며 정말 좋은 개발자가 되고싶다고 느끼던 시점이라서
셀프 프로젝트에서도 나름대로 노력은 하고있었지만
나 혼자 하는것이 아니라 협업 혹은 주어진 사양에 좀 더 맞춰서 위에서 말한 모든 것들의 좋은 훈련과정을 겪을 수 있다면 좋겠다고 생각했었고 갈증이 있었다.
본 과정에 들어가지 못하더라도 프리코스에서라도 많이 적용하고 개발자 적인 습관 들을 들이고 성장해서 나가야겠다는 마음가짐으로 입성하였다
# 개인적 으로 전체과정에 임하면서 가장 신경쓰는 부분
기본적으로는 물론 스스로 갈증을 느꼈던 부분들의 원칙 들을 생각하면서 잘 코드를 작성하는것이지만
일주차가 아닌 전체 코스에 임하면서 내가 가장 많이 신경쓰려고 하는 부분은 크게 세 가지이다.
첫 번째는 다른 동기들의 코드를 최대한 많이 보고 빨아들이는것
두 번째는 가능한 우테코 프리코스 에서 제공하는 자원들을 최대한 활용해보려고 하는 것.
이를테면 이번 프리코스 과정에서 시도 해볼 만한 것 은 내 생각에 피어 리뷰 같은것이겠지만
여건이 되지 않는다면 그냥 혼자 돌아다니면서 라도 궁금한 점이 있다면
적극적으로 슬랙 아이디 랑 매칭시켜가며 직접 물어볼 생각이다
"소중한 시간 쪼개서 내꺼 봐주세요" 라곤 부탁못하겠고... 해서 그런쪽 으로라도 먼저 다가가서 노력해보려고한다.
세 번째는 학습과정 블로그 글 작성 이건 10월 회고때도 스스로 느낀것이지만
블로그 글을 작성하는 것은 내가 생각하는 좀 더 간절히 공부하는 것의 일환이다.
원래도 깃헙저장소나 노션에 작성은 하지만 그건 정말로 비유하자면 강의필기 수준이였고 능동적인 공부라고 보기 어려웠다.
프로젝트를 임하면서 적는 글이나 , 직접 찾아가며 우여곡절을 겪은 글이야말로 능동적인 공부이자 훗날의 가장 훌룡한 참조 글이 될것이라고 생각하여 적극적으로 작성하고자한다.
또한,
과제를 제출할 때 'git’과 '과정별 언어’를 학습하면서 느낀 점을 소감문으로 작성해 주세요. 이때 학습한 '과정’을 잘 드러내 주세요.
라는 요구사항에 내가 할수있는 최선을 적어보기 위함과
우테코에 지원 했을때 지원 동기 들에 글자수 제한이 있어
원래 적어놨던 내용의 반이상 날리며 추리는 과정이 있었기 때문에 이번에도 혹시 그런 제약이 있을지도 모르겠다 싶어 제약없는 블로그에 정리해두려는 의도였다.
# 1주차 미션
미션의 진행방식은 이렇다
- 미션은 기능 요구 사항, 프로그래밍 요구 사항, 과제 진행 요구 사항 세 가지로 구성되어 있다.
프로그래밍 요구사항은 노드 버젼 이였고 과제 진행요구 사항은 pr 날리고 우테코 홈페이지에 올리는것 이였다.
메일이랑 요구사항들을 한 2~3번 정도 빠진건없는지 확인하면서 읽어보았는데
그 중 기능 요구사항 에 적혀있는
- 세 개의 요구 사항을 만족하기 위해 노력한다. 특히 기능을 구현하기 전에 기능 목록을 만들고, 기능 단위로 커밋 하는 방식으로 진행한다.
이부분을 보면서 부터 갑자기 설레이기 시작했다.
'기능을 구현하기전에 기능목록을 만든다'. 그리고 '기능 단위로 커밋한다.'
다르게 말하면 내 생각에 저 말은 곧 설계하는것이였고 사고해가면서 코드를 치며 분리 하는 것 이였고 굉장히 하고싶었던 훈련이였기 때문이였다.
# 시작 전
본격적으로 시작하기에 앞서 첫날에 한일은 이렇다.
최상단쪽의 스크린샷에서 보았듯이 나름의 컨벤션은 생각하면서 커밋을 남기고있었지만 어디까지나 '나름' 에 불과한 제멋대로의 커밋에 불과했다
그래서 미션에 들어가기전에 가장먼저 확인한것이 깃 컨벤션이였다.
일단 내가 평소에 생각 해서 쓰던 깃 컨벤션은 add/modify/fix/style/html/hooks/lib 같이 온갖게 섞여 있는데 순수 바닐라 자바스크립트 로 작성하는 것과는 맞지 않다고 생각하기도 해서 요번에 새로 봐야겠다 싶어
1주차에는
- feat :기능 추가
- fix : 버그 픽스
- docs : 문서
- refactor : 리펙토링
- test : 테스트 코드
이런 형태를 따라가고자 했다.
첫날에는 7문제를 전부 읽어보면서 구현목록 문서 작성을 시작 했는데 참으로 부족함을 많이 느꼈다.
완벽해야되지 않을까? 생각에 겁이나서 작성을 망설이거나 버벅거리기도 했다
생각해보니 내 수준에 완벽하게 적는게 가능하지도 않을뿐더러 그런게 어디있나 싶어서
하면서 고쳐나가야지 하는 생각으로 생각을 바로 고쳐 먹고 생각나는대로 미흡하면 미흡한 대로 적기로했다.
알고리즘 문제를 풀어보려고 할때에도 그냥 ' while써서 이렇게 하면 풀리겠지' 하고 생각만 했던것을 글로 적어 내려가며 설계 하니까 재미있었다
다른 것 보다도 아예 요구사항이 없으면 좀 막막했을텐데 어떤 사양을 주고 기능목록을 설계한다는 게 참 재밌었다.
# 미션 돌입
여기서 부턴 몇째날 같은 형식이 아니라 미션 진행하면서 겪은 시도, 우여곡절의 기록이다.
첫 주차에는 일단 가장 먼저 그 간의 내가 크게 신경쓰지 않았고 등한시했지만
진짜로 필요하다고 생각하는 '협업하기좋은' ,' 가독성이 좋은' , '유지보수하기 좋은' 이라는 3가지 방향을 목표로 고쳐나가야겠다고 생각했다
깃 커밋 컨벤션을 본격적인 미션전에 본 것 도 그런이유였다.
그리하여 첫째로 찾아보게 된 것은 변수명 , 함수명 명명법 이였다.
1) 의도를 분명히 하여 명시적인 변수,함수 명 작성하기
변수명 규칙 혹은 variables naming rule 을 검색하면 카멜 케이스 스네이크케이스 같은 규칙이 나온다.
처음 코드 칠때만해도 카멜케이스 그지같이 생겼네 했는데 이젠 나름 반자동적으로 쳐서
string.substring() 메서드를 쓸때마다 subString()으로 적어서 작동이 안되는 일이 지금도 종종 일어난다.
하여튼 내가 고치려고 했던 습관은 카멜 스네이크 같은 규칙이 아니고
찾아보니 클린코드에 해당하는 규칙 원칙 들이였다.
많이 부족한 내가 가장 먼저 적용해보려고 한 규칙은 많은 규칙 중 단 한가지였다.
의도가 분명할 것 (명시적 일 것)
그리하여 모든 변수, 함수 명을 짓는데 나름대로 굉장히 공을 들였는데 솔직히 맞는지 모르겠다 이건 영어실력이랑 좀 비례하다고 생각하는데 난 영어는 개초밥이여서
그리하여 Boolean 타입은 isOddNum isEvenNum 같은 형식으로
함수는 동사 형태로 변수들도 명시적으로 적으려 노력했다.
1-1) 명시적으로 쓰려 했던 예시들
한가지만 예를 들자면 각 페이지의 단위별 총합 총곱을 구해야되서 왼쪽 페이지 오른쪽 페이지를 분리해서 배열로 만들어야 됬는데
const leftPageArray
같은 방식으로 최대한 명시적으로 명명하려 노력했다.
예전이였으면 그냥 leftArray 아니면 더 줄여서 그냥 lArr 아니면 array 부분 빼고 leftPage 같이 내좋을대로 적거나 아주아주 초창기에는 카멜케이스도 안지켜서 larr 로 적기도 했는데 이런부분에서 신경을 많이쓰려고했다.
하면서 절절히 느낀 건 그동안 너무나도 제멋대로쓴 코드가 많다는걸 심각하게 느꼈다
함수의 매개변수, 함수명 , 온갖메서드들의 currentValue 들 ( array.map((item)=>item) 이면 나는 모든 배열의 map currentValue를 item이나 v로 주곤 했다)
여기에다가 모든 케이스를 적자면 너무 길어질거 같아 생략하겠다...
생전 거의 안 했던 리팩토링을 하면서도 절절히 느꼈다.
이렇게 하는 게 맞는 길이라는 걸...(그동안 정말 비읍시옷이였다는걸) 내가 지은 네이밍들에 따라서 리팩토링의 수월도가 달라졌다 내가친 코드였음 에도 불구하고 말이다
1-2) i 의 명시적 풀네임은 무엇일까 ?
while 문의 조건식에 i 라는 변수가 배열의 길이 만큼이 되면 멈추는 식을 작성하는데
이 i 는 별생각없이 for문의 i 를 생각하고 적었는데 for문에서 i 의 명시적 풀네임이 뭘까??(뭐의 줄임말일까??) 하고 찾아보게되었다.
별생각없이 index 인가하고 생각했는데 정확한 소스는 찾을수없었고
급하게 잠깐 검색해본 결과로는 index 나 iterator(반복자) 라는 의견이 강했다.
내가 풀이하는 while문의 조건식 i 는 반복자라는 의미가 더 맞을거같아
iteratorValue라고 변수명을 지었다.
let iteratorValue = 0;
while (iteratorValue !== arrayCryptogram.length)참고로 i를 선언할일이있어서 변수명을 고민하다가 이렇게 한거지 모든 for문 의 i 를 iteratorValue 라고 적으며 오바떨진않았다
1-3) 코드 컨벤션 공부
클린 코드의 원칙만 조금 찾아보고 적용해보려고 한 것만으로는 뭔가 부족하지 않나 싶어 컨벤션을 더 찾아보다가 작년 우테코 과제 공통 요구사항에
자바스크립트 코드 컨벤션을 지키면서 프로그래밍 한다.
정답이 없으므로, 다양한 컨벤션을 비교해보며 스스로 더 적절해보이는 컨벤션을 자율적으로 선택한다.
Google JavaScript Style Guide
Airbnb JavaScript Style Guide()
JavaScript Standard Style
NHN FE개발랩
이 부분 을 보고 내가 찾던 게 여기있네 하면서 하나 씩 들어가서 간독 하다가.
javascript Standard Style 사이트의 Try it out 에 (https://standardjs.com/demo.html) 들어가면 코드를 붙여 넣어 데모를 실행할 수 있었다.
거기에 코드를 넣고 돌려본 결과
if (1 <= left && right <= 400 && right === left + 1)
가
if (left >= 1 && right <= 400 && right === left + 1)
이렇게 바뀌는 것을 볼 수 있었다
에러 메세지가 Expected literal to be on the right side of <=. (yoda) 이렇게 떴는데 앞에 에러는 그렇다 치고
(요다) 는 뭐지 싶어 찾아보니 스타워즈 요다인가 했는데
https://eslint.org/docs/latest/rules/yoda
This is called a Yoda condition because it reads as, “if red equals the color”, similar to the way the Star Wars character Yoda speaks.
??
맞았다. 다만 이 비유가 개인적으로 안와닿는건 난 스타워즈를 제대로 본적이없다 그냥 요다가 유느님 닮았다는거 말고는 요다에 대해서 특별히 아는게 없어서 별로 와닿지 않았다.
어찌됬건 Run Detail을 읽어보니 중요한건
https://ui.toast.com/fe-guide/ko_CODING-CONVENTION#%EC%BD%94%EB%94%A9-%EC%BB%A8%EB%B2%A4%EC%85%98
2) 평소 잘 안 쓰던 방법 적용해보기& 다양하게 해보기 & 궁금한거 적용해보기
이건 그냥 개인적인 목표이기도 하고 평소에도 하려고하는 것인데
될 수있는 한 이런 기회에 많이 연습하고 싶어서 알고있는 방법중 잘 안쓰는 방법을 총망라해보고싶었다.
2-1) 재귀함수 활용해보기
물론 맞게 써먹을 생각이 나야...되지만 다행히 3번 문제에서 떠올라서 써먹었다
당연히 재귀를 써먹으면 지역변수를 알아서 기억하는 줄알고 선언해놓고 썼는데 기억을 못하고 계속 초기화 되길래 애를 많이 먹었다.
2-2) 다양하게 구현하기
이건 평소에도 그냥 종종 하는 것이라 특별히 했다고 하긴 뭣하지만
배열이나 문자열 만드는 방법 들의 경우에도
배열의 경우에는 Array.from() 이나 split("")을 써서 서로 다르게 만들어본다던지 걍 스프레드 연산자로 [...array] 바로 만든다던지
문자열의 경우는 toString() 이나 + " " 같은 방법으로 만드는 등의 개인적인 시도를 했다.
2-3) 궁금한건 바로바로 해보기
4번의 청개구리 사전 문제 같은경우 상수 오브젝트를 생성해놓고 썼는데 정말정말 갑자기 모던자바스크립트에서 오브젝트 freeze 하는게 생각이 났다.
오브젝트는 const 로 선언해도 메모리 참조 라 모양이 똑같이 생겨도 엄격비교를 하여도 false로 나온다.
그래서 const 로 선언해봐야 값을 막 넣을수있어서 아주 맨 처음 프로그래밍을 배울땐 그럼 뭔소용이지? 싶었는데
이번기회에 상수오브젝트로 대문자로 선언해본김에 막아보기로했다.
https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Statements/const
오브젝트를 덮어쓰면 오류가 발생합니다 MY_OBJECT = {'OTHER_KEY': 'value'};
하지만 오브젝트의 키는 보호되지 않습니다.
그러므로 아래 문장은 문제없이 실행됩니다 MY_OBJECT.key = 'otherValue';
오브젝트를 변경할 수 없게 하려면 Object.freeze() 를 사용해야 합니다
LOWERCASE_FROG_DICTIONARY_OBJ["a"] = "d";
console.log(LOWERCASE_FROG_DICTIONARY_OBJ["a"]);
Object.freeze(LOWERCASE_FROG_DICTIONARY_OBJ);
LOWERCASE_FROG_DICTIONARY_OBJ["a"] = "s";
console.log(LOWERCASE_FROG_DICTIONARY_OBJ["a"]);
? 처음에 에러가 없길래 뭐야 개뿔도안되잖아 했는데 콘솔을 찍어보니 에러만 안날 뿐이지 추가가안되는걸 확인할수있었다.
3) 될 수 있는 한 짧게 써보기
이건 그 다음주부터 요구 될것으로 예상되는 이전 기수들의 매주차 과제에 있던
indent(인덴트, 들여쓰기) depth를 3이 넘지 않도록 구현한다. 2까지만 허용한다 , 함수(또는 메소드)의 길이가 15라인을 넘어가지 않도록 구현한다
위의 조건 대로 구현해보고자 한것인데,
이런 요구 조건은 결국 내가 원초에 참가 하여 얻어가고 싶던 훈련이랑 아주 잘 맞는 방향이였음으로 첫주에는 포함되어있지 않았지만
지금부터 해보지 않을 이유가없었다.
이를 위해 자연히 함수 분리 , 쓸데없는 변수가 너무 많이 선언된건 아닌가? , 반복되는 코드를 하나로 줄일 수 없는가? 를 고민하여 짜보게되었는데 솔직히 재미있었다 (아직까지는)
진짜 구현만 되는 코드만 치다가 이렇게 쳐보니까 웃긴 소릴지 모르겠지만 잘 작성했냐 아니냐랑 별개로 제대로 고민하는 프로그래머 같아지는거 같았다
그 밖에도 코드의 가독성이나 좀 더 짧게 쓰기 위해서
if(true){
return result}
같은형태라면
if(true) return result
같은 형태로 한 줄로 줄이고 / 가능 하면 else 문 안써보기
지역변수 최대한 줄이기 같은 자체적인 제약을 줘 보기도했다.
4) 실수와 우여곡절
4-1) 구현목록 작성 우여곡절과 커밋 실수
당연하다면 당연한 일이였다.
첫날에 버벅거리며 작성했던 기능 설계 목록은 만들고나니 적을 필요없는 쓸데없는걸 기능에 적어놓았던것도 있고 계속 수정 사항이있어 docs 로 커밋을 하는 일이 계속 생겼다.
또 기능 구현 목록은 4~5 가지로 작성해놓고 커밋은 다 구현하고 나서 하나로 날리는 바보짓을 하기도 했다.
그리고 다 구현하고 난 다음에 구현목록을 수정할 일이 많았는데 거기서 의외로 리팩토링이 가능했다.
예를들어 구현목록에 구현기능을 적을때 '~하고' 같이 and 의 말이 들어가면 두가지의 기능이 들어간게 아닌가 자연히 생각해보고 그의미는 곧 분리가 가능한지 생각해볼수있음을 의미했다.
4-2) 스테이징 활용
위의 바보짓도 있고하여 의도했던 대로의 깃 커밋을 위하여 스테이징을 최대한 활용하려고했다
커밋하기전에 분기를 'git add' 로 스테이징해서 비교했다.
4-3) 그밖에 내가 인지 못하는 많은 문제들
이 당연히 있을것으로 생각된다
솔직히 많이 변수명 짓는것도 많이 미숙할것이고 (농담 안하고 이전에 요번 만큼 제대로 지어본적이 없다)
공통 피드백을 주실 것 이라고 하니 그것또한 잘 기록해서 나한테 해당하는 부분들을 체크하고
다음 주 차 에 바로 적용하고
프리코스가 끝나면 또 다시 한번 보고 적용해나가면서 착실히 습관화 해야겠다.
# 1주차 소감
의외로 생각보다 재미있었다.
원래의 예상은 고통스러움이 가득할 거라 생각했다. (당연히 없진 않았다)
왜냐하면 프리코스에 참가하는 다른 사람들이 그렇듯 나 역시 우테코라는 교육의 기회에 나만의 이유로 간절함이 묻어있다
어떤 타인과의 비교 이런것보다도 나 스스로가 나를 많이 옥죌거라고 생각해서 간절한 만큼 스스로를 옥죄여서 고통스러울 것이라고 생각했다.
하지만 생각보다 재미있었다.
이유는 하면서 느낀건데 내 생각대로 내가 평소에 느끼던 갈증들 과 잘 맞았기 때문이라고 생각한다.
우테코의 교육 과정이 복잡한 기능 구현 , 최신 기술 사용 , 알고리즘의 알고리즘 같은것들을 중시했다면
아마 나는 처음 코테를 봤을때 처럼 다시 한번 스스로의 무능력함에 진절머리를 느꼈을 지도 모른다.
(물론 2중 for문으로 해결한게 많아서 여전히 무능함을 느끼긴 했지만 예전엔 2중 for문 돌릴 생각도 못해서 결과적으로 성장이라 느꼈다.)
그리고 내가 만약 클린코드 , 협업과 소통에서의 성장, 설계 , 테스트코드 같은것들의 중요성을 등한시 했거나 깨닫지 못했다면 어거지로 스스로 목죄가면서 '이게 뭐냐' 며 재미없게 했을것같다.
작년 우테코 기능 요구 사항 같은걸 찾아보면서 굳이 1주차에 요구하지도 않을 걸 해보겠다고 혼자 나대는 일도 없었을것이고.
프리코스는 우테코랑 지원자간에 맞는지 고민해보는 시간이며, 우아한테크코스 교육 과정을 미리 경험하고 교육 참여 여부를 결정할 수 있는 시간이라고 한다.
한달이면 어떤 습관을 만들기에 꽤 괜찮은시간이다.
그래서 1주차가 끝나고 나서 나는 주도적으로 프리코스 에 참가해서 개발자로써의 성장을 도모 해 보려는 나의 마음가짐을 재확인하고 재 다짐할 수 있었다.
이미 좀 글이 길지만 너무 길어질 거 같아서 여담
요번 우테코 1주차 문제를 솔직히 테스트케이스는 다 통과해도 완벽히 풀진 못했고 느꼈다.
적어도 내가 인지하는 완벽히란
모든 예외사항 테스트 케이스 만들어 넣어가며 , 제한 사항까지 다 구현해가며 치는 분들도 있었는데 나는 그렇게까진 하지못했다.
(제한 사항같은 경우는 당연히 그런 인풋만 들어온다는 약속이겠거니 했는데 거기까지 다 구현하는 것을 보고 좀 놀라기도했다)
알고리즘 문제를 조금 이라도 풀어봤다면 문제 예시의 인풋 테스트 케이스만 통과했다는게 얼마나 반쪽짜리 구현인지 잘 수 있을것이다.
가까운 미래에는 저 지점까지 생각 하면서 해야 겠구나 하는 생각은 있어도 당장 그것때문에 넘 비교되고 위축되거나 하는건 전혀없다
오히려 근례의 나 , 하다못해 당장 7월의 나였더라면 아마 지금 이 주어진 문제에서 한 두개 정도 밖에못풀었거나 재귀 같은 것을 써보자고 하는 건 엄두도 못냈을것이다
그래서 우테코 프리코스가 끝나고 난뒤의 내가 조금 더 기대가되며
앞으로도 조급해하지말고 충실한 현재를 살아나가는게 내 인생목표다
'우아한 테크 프리코스' 카테고리의 다른 글
| 우테코 프리코스 4주차 후기 (0) | 2022.11.23 |
|---|---|
| 우테코 프리코스 3 주차 후기 (+ 코드 리뷰 받은 느낀 점) (0) | 2022.11.16 |
| 우테코 프리 코스 2주차 후기 (0) | 2022.11.09 |
