본문 바로가기

분류 전체보기260

3,000...3,000...3,000... (22.08.18 TIL) 벌써 1주차가 내일 하루 밖에 안남았다. 9개의 퀘스트 과제와 리팩토링을 오늘 마지막으로 겨우 끝내고, 마지막 추가 과제인 '3,000줄 코드 짜기' 에 드디어 진입했다. 사실 시작하기 전에는 다른 과제를 하느라 바빠서 이게 이렇게 많은 양인 지, 이렇게 힘든 건지 몰랐고요? 3천줄 이라는 양이 가늠이 아예 안잡혀서 겁도 안났었다. 이런 긴 코드를 작성해 본 적이 없었으니까. 근데 코드 10줄을 쓰고, 50줄을 쓰고, 100줄을 쓰고 200줄까지 열심히 쓰고 난 후 남은 분량이 2800줄 이라는 것을 자각했을 때 순간 토할 뻔 했다. ㅎㅎ '??? : 이거 뭐야? 지금 이렇게 몰두해서 많이 써냈는데 고작 200줄 이라고!??! 아직 2800줄이 남았다고????' 이런 느낌이었다. 차라리 스토리라도 주어졌.. 2022. 8. 18.
코드 리팩토링 #3 (변경 가능성 있는 값은 변수에 넣어주기) * 코드 리팩토링 #3 (22.08.18) - 주어진 문제에 대한 답을 일문일답 식으로 작성하는 프로그램 ※ 의미없는 정답 값이 문자열 그대로 출력문에 사용되었다. - 문제에 대한 답을 그대로 출력문에 문자열로 작성하여 답을 체크하였다. 이런 방식은 추후 정답이 변경될 경우, 일일히 문자열을 변경해주어야 하는 불편함이 생긴다. 유지보수의 용이성을 위해 아무 의미 없는 값을 그대로 써주는 것 보다는 변수에 할당해주면 추후 값이 바뀌어도 변수의 값만 바꾸면 되기 때문에 훨씬 코드도 간결해진다. 의미 없는 값은 변수에 할당하는 습관을 들이자! //이전 코드 System.out.println("------------ 문제 1 ------------"); System.out.println("RAM 은 무엇의 줄임.. 2022. 8. 18.
git pull 지양하기 멋모르고 git 을 쓸 때는 로컬 저장소로 원격 저장소 내용을 불러오려고 할 때 git pull 만 사용했었다. 그런데 git pull 은 웬만하면 지양해야 한다는 사실을 알게되었다! 이유는 무엇일까? 터미널 명령어를 입력한다는 것은 기본적으로 내가 어떤 실행을 명령하는 건지 구체화하여 입력해야 한다. 정확한 명령만이 내가 원하는 결과로 만들 수 있다. 정확하지 않으면 언제나 내가 원하지 않는 어떤 미지의 변화가 생길 수 밖에 없고, 그렇게 된다면 통제하기가 어려워진다. 그래서 git fetch 보다는 git fetch upstream main 을, git rebase 보다는 git rebase upstream/main 을 해주는 것이 좋다. 또한 git pull은 기본적으로 fetch와 merge 이다.. 2022. 8. 18.
코드 리팩토링 #2 (No newline at end of file, EOF) github 에러 * 코드 리팩토링 #2 (22.08.17) - No newline at end of file, EOF / github 에러 github 에 PR 을 올리고 나서 로지님께 받은 리뷰 코멘트를 보는데 남겨주신 내용중에 이런 에러를 지적해 주신 것을 발견했다. 그리고 내 코드를 보니 파일 끝에 경고 이모티콘과 함께 'No newline at end of file' 이라는 경고문이 떠 있었다. '파일의 끝에 개행문자가 없음' 이라는 뜻으로, 파일의 제일 마지막 한줄을 꼭 비워두라는(개행) 의미였다. PR 올리기 전에 코드를 마지막에 한 번 보면서 쓸 데 없는 괄호, 쓸 데 없는 개행을 지우는 편인데 파일 끝 개행도 일부러 지운 것이였다. 근데 이것이 경고를 발생시켰다니! 파일 끝에 개행을 추가 하는 이유는 예전.. 2022. 8. 17.
나의 기억력을 믿지 않기 (22.08.17 TIL) 회사생활을 하면서 제일 싫어했던 것 중 하나가 '어제 했던 같은 실수 오늘 또 반복하기' 였다. 그런데 내가 여기 와서 동기분들에게 했던 질문 또 하고, 명령어 잘못 써서 같은 오류를 또 만나고 있으니 너무 제 자신이 싫어지고요? 그냥 놀고 싶습니다. (넝담) 아니 분명 당시에는 머릿속으로 완벽하게 이해했다고 생각했는데? 어떻게 뒤돌아 서니 까먹을 수 있음? 어? 어쨌든 나의 기억력을 믿지 않기 위해 세세한 것 하나 하나 기록을 남기기로 했다. 진작 했어야 했는데! 어제는 혼자 보는 오류 정리 기록용 카테고리를 만들었었고, 오늘은 거기에 리팩토링 기록을 추가하고 폴더명도 다시 바꿨는데 조금 신나는 기분이였다. 비록 아직은 극초반이기도 하고, 간단한 코드들이지만 리뷰를 받은게 여기 메가테라에 와서 처음이였.. 2022. 8. 17.
코드 리팩토링 #1 * 코드 리팩토링 #1 (22.08.17) - 주어진 문제에 대한 답을 일문일답 식으로 작성하는 프로그램 1) 문제를 출력하고 답을 입력받는 부분이 한 눈에 확인하기 어렵게 나뉘어져 있었다. - 1~5번까지의 문제들이 있는 코드가 한 번에 나열된 후 그에 따른 5개의 답이 또 나열되는 방식이었다. 이 방식은 문제에 대한 답을 확인하려면 스크롤을 내려 아래로 가야 하는 번거로움이 있었다. 문제가 있는 부분과 답을 확인하는 부분이 한 쌍으로 있다면 코드의 가독성이 높아질 것이라는 피드백을 주신대로 수정하였다. 2) 변수를 선언할 때 의도 없는 줄임말을 사용하였다. - 관례적으로 자주 쓰이는 줄임말들은 변수명으로 사용해도 무방하지만, 아무 의미 없이 줄임말을 변수명으로 쓰면 이게 어떤 변수인지 바로 파악하기 .. 2022. 8. 17.

티스토리툴바