다사다난했던 나의 코딩 입문기... 컴퓨터와의 첫 싸움이 벌어졌다. 터미네이터와 싸우던 존 코너도 이런 답답한 마음이었을까?
이번주부터는 새로 제작하는 미션을 Github를 통해 멘토님의 리뷰를 받게 되는데, 이를 위해서 유닉스 커맨드에 대해 먼저 수강을 마친 후 git 강의를 수강하게 되었다.
하지만 처음 Homebrew설치 과정부터 우여곡절이 많았으니...
Homebrew홈페이지에서 다운로드 링크를 터미널에 입력 후 인스톨 과정에서 뜨는 경고 메세지를 확인 하였다.
조금 알아보니
Warning: /opt/homebrew/bin is not in your PATH 에 나와 있듯이, 아직 PATH 에 등록이 되지 않아서 그렇다고 한다.
구글링을 통해 찾은 방법
echo 'export PATH=/opt/homebrew/bin:$PATH' >> ~/.zshrc
source ~/.zshrc출처: https://devmango.tistory.com/55 [알쓸개잡:티스토리]
으로 간단히 해결 후
이제 제작한 과제를 github에 올려 볼 시간...
처음에는 코드잇에서 초대받은 리모트리포지토리에 올리는 줄 알고 해당 주소를 바로 복사해서 클론을 시도하였는데
나중에 알고보니 fork라는 기능이 따로 있었다.
기존 초대받은 미션 레포지토리에서 fork로 개인 레포지토리로 가져온 후 여기에 새로운 브랜치를 생성 후 그것을 clone해오는 방법 이었는데 처음이라 좀 헤메었던거 같다.
또 이상한 오기가 있어서 CLI환경으로 계속 시도하다보니 더 그랬을지도.. 그래도 git관련해서는 계속 CLI사용을 고집하긴 할듯 싶다.
그리하여 안내 가이드를 따라 어찌저찌 커밋 후 푸쉬까지 마친 다음 PR요청까지 완료하긴 했는데
좀 복잡한 개념이다 보니까 익숙해지는데 까지는 시간이 오래 걸릴듯 싶다
멘토님 말씀대로라면 코드랑 파일 몇번은 날려먹어야 겨우 익숙해진다는데 따로 백업용 폴더를 제작하거나 브랜치 경로를 하나 더 만드는 방법을 새로 알아봐야겠다.
그리고 팀원들끼리 같은 주제로 진행한 미션 내용에 대해 이야기 해본 결과, 정말 신기하게도 팀원들 모두가 전부 다른 방식으로 해당 미션을 제작하였다.
난 flex-box로 제작을 시도하여 보다가 도저히 안되서 grid로 바꾼 작업을
혹시나 싶어서 다른분들께 물어본 결과
처음 내가 시도하던 flex-box안에서 원하는 배치로 이끌어 낸 분들도 계셨고,
나처럼 grid형식으로 바꾸신 분들도 있었고,
해당 부분이 아직 잘 풀리지 않아서 연구중인 분도 계셨다.
또 멘토님도 가이드를 따라서 직접 제작한걸 보여주셨는데 멘토님은 신기하게도 같은 내용을 두번 기입하여
display: none 으로 반응형 웹에서 배치를 달리하는 방식을 보여주셨다.
여기서 멘토님이 작업한 방식에 대해 의문이 생겨 질문해본 결과
boky
이런식으로 작업하게되면 동일한 내용의 불필요한 요소들이 추가되는 부분인거같은데 상관 없을까요?
멘토
꽤나 좋은 질문입니다. 좋은 질문이어서 가감없이 매운맛 답변을 드리도록 하겠습니다 ! 제 답변은 당장 현업에서 어제도 일어나는 일입니다 ! 그래서 인강과 책에서는 없는 관점입니다. 흔히들 많이 이야기하는것이 불필요하게 중복된 내용 이라고 많이 이야기합니다. 특히나 리액트 개발을 하면 더더욱 그런 이야기들이 나오고요 또 블로그나 유튜브를 보면 중복을 피해라라는 내용이 많이 나옵니다. 저 역시도 초기 개발할때 중복을 무조건 피하려고 했었고요 그리고 2년 넘게 이에 대한 고민을 많이 했습니다. 해당 마크업과 질문에서 생각해볼 내용은 과연 저게 진짜 불필요한 요소인가?, 동일한 내용 두번 있으면 무조건 불필요한가 ? 라고 좀 다르게 생각해볼 수 있습니다. 둘다 어짜피 마크업하는데 필요한 요소 아닌가요? 왜 불 필요한거죠? 모바일일때와 데스크탑사이즈일때 하나씩 숨기는데 저거 서로 마크업도 가까이 붙어있고 수정하는데 바로위아래 한두줄만 바꾸면되는데 뭐가 힘들다고 그러죠? 오히려 하나만 작성해서 CSS트릭 잔뜩 써놓고 한두달뒤에 디자인 변경되었을때 CSS 막 써놓은거 이해하면서 수정하는게 더 힘들껄요??? 이렇게 반박할 수 있습니다. ㅎㅎ 실제 개발은 책에서 나오는 이상적인 코드대로 작성되지 않습니다. 그리고 내 작업은 개발자의 시간, 유지보수 난이도 그리고 개발자의 아웃풋등으로 어떻게보면 좀 더 현실적인 내용이 더 중요할때가 많습니다. 앞으로 마크업 ,코드가 어떻게 진화할지 모르는데 시작부터 완벽한 코드를 작성하기에는 불가능합니다. 저 부분이 변경되지 않을거라는 보장이 없습니다. 그렇기 때문에 중복코드 조금쓰고 간단하게 코딩을 해놓고 유지보수성을 높일 수 있다면 그게 좀 더 좋은 코드가 될 수 있습니다. 개발자의 시간과 유지보수성도 비용입니다. 그리고 얼만큼의 중복이 허용되는가? 이것은 개인의 역량, 팀의 상황에따라 다릅니다. 제 생각에는 한 3번까지는 중복코드를 써도 괜찮은것 같습니다. 저런 중복코드를 없애기 위해서 여러가지 지식들이 있습니다. 그런데 지금은 그런것을 사실 따질때가 아닙니다. 중복코드를 써보고 삽질을 몇번 해봐야지 중복코드를 없애는 지식들을 배웠을때 제대로 받아들일 수 있습니다. 주니어 개발자인 저만의 생각이 아닙니다. 해당 내용을 쏘카 CTO와 네이버 개발자에게 댓글로 질문 한 적이 있습니다. 다들 비슷한 생각을 하더라구요.
https://betterprogramming.pub/when-dry-doesnt-work-go-wet-6befda0444bf
중복을 2~3번 쓰더라도 그 이유에 대해서도 논리적인 답변이 가능하고 여러분들의 동료,상사등이 납득 할 수 있으면 괜찮은 코드입니다 ㅎㅎ
When DRY Doesn’t Work, Go WET
It’s okay if you repeat yourself
betterprogramming.pub
라는 답변을 받을 수 있었다. 매운맛이라 하셨지만 상당히 정성스럽게 써주신다 그저 감사할따름..ㅠ
이처럼 불필요한 요소를 제거하고 코드를 작성하는 과정 속에서 상당한 딜레마에 있는 요소에 대해 다시금 생각해 볼 수 있게 해주는 말씀이었다.
비록 지금 BEM클래스 네이밍 하는것도 머리가 꽉 막힌 기분이라 막막하긴 하지만 저번주에 제작한 작업물과 비교해 본 결과 확실히 깔끔해진 느낌이 크다.
이제 자바스크립트를 본격적으로 배우기 시작하는 만큼 이전처럼 HTML에 많은 시간을 쓰지는 못하겠지만 웹프론트의 기초가 되는만큼 처음부터 끝까지 HTML/CSS는 끝까지 함께 갈 거라고 생각한다 그러므로 시간과 기회가 될 때 최대한 내공 쌓아놔야지 ㅎㅎ
아무는 셋째주도 이대로 마무리 하고 다음주 부터는 코딩테스트를 위한 스터디로 같이 진행하게 되었으니 더 숨차고 바쁜 하루하루가 될거라 생각한다 그래도 취업까지 달리는 스프린터니까 ㅠㅠ
돌아오는 주 멘토님의 코드리뷰를 기다리며 이번주 회고는 여기서 마치도록 하겠다 다들 다음주도 화이팅!
