Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[이유희] 3장: 기본 도구 #32

Merged
merged 3 commits into from
Aug 6, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
113 changes: 113 additions & 0 deletions 3장/이유희.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,113 @@
## 3장 기본 두구

📌 정리


3장은 도구를 단순히 사용하는 것을 넘어서 나만의 작업대를 구축할 것을 강조하는 챕터다. <br>
일반 텍스트, 셸, 파워 에디팅, 버전 관리, 디버깅, 텍스트 처리, 엔지니어링 일지 각각의 장점을 설명해 주고 <br>
구체적으로 ***어떻게*** 사용해서 나만의 연장(extension)으로 만들지 설명한다.<br><br>
이 챕터를 읽고 생각난 세션이 있는데 시청 강추 드립니다.<br>
[출처: re:COMMIT, 연사: 김영재, 세션: 시야가 넓은 개발자는 무엇이 다를까](https://youtu.be/NLSzp1Y-qLU?si=FER7iAAVALua_f12)
Comment on lines +9 to +10
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

저한테 필요한 세션이네요..🥹 감사합니당

---

#### 🏷️ 일반 텍스트의 힘
- 지식을 일반 텍스트로 저장하라.
> 이 부분을 읽으면서 설정 파일이 생각났습니다.<br>
> yml, json syntax로 환경 설정 값을 관리하니 읽기도 편하고 변경하기도 편하고..

#### 🏷️ 셸 가지고 놀기

- GUI 환경의 기능은 일반적으로 설계자가 의도한 범위를 넘어설 수 없다
> 동의하는 게 툴 익스텐션도 제공하는 기능만까지만 사용 가능하니까요! 셀을 가지고 노는 수준이 되면 많은 것들을 자동화할 수 있을 것 같아요.<br>
> 그러나 저는 아직까진 기존 익스텐션으로도 충분해요

#### 🏷️ 파워 에디팅

##### vim command 정리

| command | 설명 |
|:-------------------------------------------------------------------------------------:|:---------------------------------------------------------|
| | 💡 텍스트를 편집할 때 문자, 단어, 줄, 문단 단위로 커서를 이동하거나 내용을 선택하라 |
| w | 커서를 다음 단어로 이동 |
| b | 커서를 앞 단어로 이동 |
| } | 커서를 다음 블록으로 이동 |
| { | 커서를 앞 블록으로 이동 |
| V | 라인 전체 선택 |
| Vj 또는 Vk | 멀티 라인 선택 j(상) k(하) |
| ve | 단어 선택 (현재 커서 위치서부터 단어 끝까지 선택) |
| v} | 블록 선택 (현재 커서 위치서부터 블록 끝까지 선택) |
| | 💡 코드를 편집할 때 반대쪽 괄호로 이동하거나, 함수, 모듈 등 다양한 문법 단위로 커서를 이동하라 |
| 커서를 괄호에 두고 % | 현재 괄호의 짝이되는 괄호로 이동 |
| [[ | 파일의 시작 지점으로 이동 |
| ]] | 파일의 끝 지점으로 이동 |
| | 💡 특정 줄 번호로 이동하라 |
| n(n은 라인번호)gg | n번 라인으로 이동 |
| 1. Vj (멀티라인 선택)<br/> 2. : (명령어 입력 모드) <br/> 3. sort (i는 Case insensitive sort, !는 역순) | 여러 줄을 선택한 후 가나다순으로 정렬하라 |
| | 문자열로, 또 정규 표현식으로 검색하라. 이전에 검색했던 것을 다시 검색하라 |
| /pattern | 정규식 패턴 검색 |
| n | 패턴에 일치하는 다음 단어로 이동 |
| :%s/old/new/g | 패턴에 일치하는 모든 old를 new로 변경 |
| `모르겠음` | 이전에 검색했던 것을 다시 검색하라 |
| `모르겠음` | 에디터 창을 여러 구역으로 쪼개라. 그리고 각 구역 사이를 이동하라 |
| control w | 인서트 모드에서 마지막에 입력한 단어 지우기 |

> 상우좌하 이동만 사용하다 다른 명령어도 정리해봤습니다. 자꾸 사용해서 손에 익혀야 겠네요
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

저희 동료분 중 한 분은 배경 화면이 vi 커맨드 더라고요 ㅋㅋㅋㅋㅋ


##### Intellij 단축키 정리

| shortcut | 설명 |
|:-------------------:|:--------------|
| control + shift + R | 테스트 실행하라 |
| F2 | 컴파일 에러 위치로 이동 |


##### code 포맷팅

- 변경한 코드의 들여쓰기 indent를 자동으로 맞춰라
> [spotless](https://github.com/diffplug/spotless) (코드 포맷팅 라이브러리) 사용하고 있습니다.


#### 생산성 향상에 도움이 된 툴
> 제가 사용하고 있는 툴중에 생산성 향상에 도움되는 툴 공유드립니다

1. Raycast
- 노트북 시스템 뿐만 아니라 노션, 슬랙, 깃, 지라 등 어플리케이션의 기능을 일원화 해주는 툴입니다. 최고입니다.
2. Perplexity
- AI기반 검색 엔진 서비스인데 답변 뿐만 아니라 참고 링크와 연관 질문까지 제공해주고 답변 텍스트중에서 드래그로 후속 질문까지 가능합니다.
- 퍼플렉시티는 어떤 개념을 공부할 때 구글링으로 여러 블로그에서 정보 취합해주는 시간을 줄여줘서 자주 사용하고 있습니다.
Comment on lines +73 to +77
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

오오오 공유 감사합니다 👍 👍 👍



#### 🏷️ 버전 관리

> 주로 사용하는 명령어
>> reset, rebase, cherry-pick, stash
>
> 다른 명령어도 구경해보자. [docs](https://git-scm.com/docs)
>
> 전 회사에서 배포 주기가 일 2회였습니다. 배포 주기가 짧다 보니 코드 롤백도 꽤 빈번하게 발생했어요. 그래서 revert를 자주 사용했습니다. <br> 운영 코드 롤백해본 경험이 없어서 revert 처음 사용하던 날 굉장히 긴장했던 기억이 나네요. <br> 롤백 해보면서 커밋 단위가 롤백 상황에서도 중요하단 걸 느꼈어요. 커밋 단위가 명확하지 않으면 어떤 코드가 롤백된 건지 헷갈리더라구요..

#### 🏷️ 디버깅

- 실마리 찾기
- 컴파일 에러 확인
- 관련 자료를 모두 모아야 한다.
> 버그 리포트를 보고 원인을 단언하고 접근하면 삽질 시간이 증가하더라구요.
- 경계 조건과 실제 최종 사용자의 사용 패턴 모두를 철저히 테스트해야 한다
> `계약에 의한 설계`가 생각났다.
> > Supplier(특정 메서드 구현하여 제공하는 사람)은 Client(메서드 사용하는 사람)이 메서드 호출(사용) 시 모든 입력 조건에 맞게 결과를 보장해야 하는 것이다. 그렇다. 버트란드 마이어가 제시한 DbC는 메서드마다 계약을 부과한다. 계약은 크게 사전 조건(precondition), 사후 조건(postcondition), 사후 조건 안의 페널티(penalty), 불변 조건(Invariant condition)이 있다. <br>
출처: [쿠킴의 레시피 <<Design by Contract(계약에 의한 설계)와 테스트 코드 그리고 예제>>](https://kukim.tistory.com/76)
>
> 사전 조건, 사후 조건에 대한 테스트 케이스를 꼼꼼히 작성해두면 디버깅 단축에 도움이 될 것 같다.
- 디버깅 전략
- 버그 재현하기. 버그를 재현할 수 없다면 어떻게 그 버그를 고쳤다는 것을 확인할 수 있겠는가?
- 미지의 세계에 온 프로그래머
> 이직 후 새로운 코드 파악할 때 아주 도움될 것 같다. 코드의 히스토리를 모르니 모든게 미지의 영역이다. <br>그래서 무조건 질문하기 바빴는데 아래 팁들을 적극 활용했다면 테스트 케이스도 보완하고 버그 픽스도 더 빨리 했을 듯..
- 코드를 고치기 전 실패하는 테스트부터.
> 많은 고수 개발자들이 강조하는 버그 재현하기... 실천하자
- 릴리즈 사이에서 발생한 문제
> 시도해본 적 없는 방식인데 다음 회사에서 시도해봐야겠다.
- 소거법
- 우리 둘 중 하나가 자신의 실수일 수 있는 일을 시스템의 문제라고 탓하기 시작하면 우리는 그 사건을 떠올리도록 'select가 망가졌어'라는 표현을 사용한다.
> 삽질할 때 이 일화를 떠올려야 겠다.
- 디버깅 체크 리스트 (137p)
> 문제 해결 문서 템플릿을 만들어 기록했었는데 디버깅 체크리스트를 추가해야겠다.
Loading