GitHub Organization을 이용하면서 발생한 문제입니다. Organization에 있는 Repository는 권한을 얻기전까지 push할 수가 없습니다. $ git push ✱ remote: Permission to Dev-Sweeter/go-jose.git denied to bang9211. fatal: unable to access 'https://bang9211@github.com/Dev-Sweeter/go-jose.git/': The requested URL returned error: 403 일전에 포스팅한 문제와 비슷한 문제입니다. [Git] remote: Support for password authentication was removed on August 13, 2021. Ple..
squash [skwɑːʃ;skwɔːʃ] 동사1. 짓누르다, 으깨다, 찌부러뜨리다 git에 commit들을 하나의 commit으로 묶을 수 있습니다 squash라고 하는데 뜻그대로 해당 commit들을 강제로 짜부시킨 느낌입니다 우선 squash라고하는 명령어는 없습니다 -i, --interactive let the user edit the list of commits to rebase rebase의 interactive 옵션을 이용해 squash를 수행할 수 있습니다 종종 PR을 하다보면 commit을 합쳐달라는 요청을 받는데 이미 push해버린 상태에서 3개의 commit을 squash 하는 예로 보겠습니다 (중요한 repository라면 사전에 백업을 먼저 수행하고 진행하세요) 3개의 commit을..
Git base로 개발을 수행하다 보면 commit -> pull -> merge -> push만 반복적으로 수행되는 경우가 많습니다 참여하는 개발자들이 많아질수록 merge가 자주 발생하게 되고 Git HIstory가 지저분해집니다(Non-linear history) Non-linear history가 있으면 안되는가? git든 현실이든 history는 다시 보기 위해 만들어두는 기록입니다 수많은 merge로인해 불필요하고 헷깔리는 commit들이 발생합니다 이러한 지저분한 기록보다는 다듬어두고 정리해두는게 훨씬 더 유용한 History를 유지할 수 있습니다 Linear History를 유지하기 위해 추천하는 방법은 rebase를 적극적으로 활용하는 것입니다 remote의 코드를 local로 pull할..
자기 전에 새 git repository를 만들고 commit & push 하려 하니 뭔가 바뀌었네요 정확히는 아래와 같은 문구가 발생합니다 remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead. remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information. 그러니까... 2일 전인 2021년 8월 13일부터 password 방식의 인증은 폐기되고 personal access token ..
Clean Code : 주석 코딩을 배우는 첫날부터 배우는 게 주석이다 사실 입문자들에겐 그저 나중에 자신이 봐도 이해할 수 있도록 설명하는 정도... 혹은 자신의 코드를 볼 누군가를 위한 힌트 정도이다 (실제로 주석을 이쁘게 잘달아야 한다고 가르친다!) 근데 그거 아는가? 흔히 우리가 어떤 책이나 논문을 읽을 때 작성자만 아는 얘기를 써놓고 거기에 주석이 달려 있으면 보기가 굉장히 불편해진다(나만 그런가) 잘된 코딩은 주석 없이 언어만 읽어도 자연스레 이해가 되어야 한다 (글과 마찬가지다) 물론 좋은 주석도 있고 실제로 많은 훌륭한 개발자들도 주석을 조금씩 사용한다 언제 어떻게 사용할지 알아보자 '우리는 코드로 의도를 표현할 방법을 찾지 못해 주석을 사용한다' 코드는 계속 변한다 프로그래머가 주석을 유..
Clean Code : 함수 함수를 만드는 방법은 취향이라고 생각했다 하지만 클린코드에선 아니다 사실 함수를 만드는 방법같은건 정해져 있어야했다 이런건 프로그래밍 언어에서 함수를 처음 배울때 같이 배워야 한다 (교수님들 화이팅) 함수를 만드는 방법 1. 작게 만들어라! 작은함수가 좋다 일반적으로 5줄 이하여야한다 블록과 들여쓰기 if/else, while 문 등에 들어가는 블록은 한 줄이어야 한다 호출되는 블록은 함수로 감싸고, 함수 이름을 적절히 지어라 이해하기 쉬워진다 함수의 들여쓰기 수준은 1단이나 2단을 넘어서면 안된다 2. 한 가지만 해라! 함수는 한 가지를 해야한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. 한 가지란? 함수 이름 아래에서 추상화 수준이 한 단계인 경우 (함수..
Agile에 대해서 정리하겠습니다 Agile = 민첩한 한글로는 '애자일'이라고 씁니다 게임에서 흔히 접하는 Agility(민첩성)의 Agile이 맞습니다(Dex 말고) 애자일은 소프트웨어 개발 방법론 중에 하나입니다 [소프트웨어 개발 방법론] 더보기 /* 개발자들이 소프트웨어 개발을 계속하다 보니 특정 과정이 반복되는 게 느껴집니다 우당탕 닥치는 대로 맨땅에서 개발하는 거보다 해당 과정을 정립해서 개발을 수행하는 게 계획/설계하기에 좋은 방법이란 걸 알게 됩니다 소프트웨어 공학 내용이죠 그렇게 소프트웨어를 개발하는 여러 가지 방법을 상세하게 정리한 방법론이 나옵니다 종류 - 애자일 방법론 - 구조적 방법론 - 정보공학 개발 방법론 - 객체 지향 개발 방법론 - 워터폴 방법론 - 등등 */ 애자일 방법론..
Clean Code : 의미 있는 이름 개발하다 보면 많이들 공감하겠지만 이름 짓는 게 참으로 어려운 일이다 이름을 짓는 일은 사실 컴파일러에겐 영향이 없다 하지만 그럼에도!!! 코딩을 하는 나와 이 코드를 사용할 동료에게 매우 중요하다 간단, 명료, 통일성을 가지고 모두가 직관적으로 알 수 있는 단어를 선택하는것이 응당하다 이름을 명확히 지을때 생각할 것 1. 의도를 분명히 밝혀라 변수, 함수, 클래스 이름으로 의도를 밝혀라 존재 이유? 수행 기능? 사용 방법? (주석이 없어도 알 수 있게) 아래 같은 변수 이름을 피해라 - list - d 2. 그릇된 정보를 피하라 프로그래머에게 어떤 특수한 정보를 제공하는 단어를 남발하지 마라 - list 같은 다른 의도로 헷갈리게 한다 유사한 개념은 유사한 표기법..
Clean Code 개발이란 건 사실 명령어를 나열하는 행위이다 많은 연구자들은 이 개발을 인간의 언어와 비슷한 형태로 만드려고 노력해왔다 프로그래밍 [언어]라는 것을 사용하고 컴퓨터와 [대화]하는 데 사용하지만 이 책의 관점에서 봤을때 프로그래밍 언어는 결국 사람과 사람 간의 대화를 위해 사용한다 어떤 책을 읽다보면 표현이 명료하며 다음이 예상되고, 머릿속에 훤히 그려지는 글들이 있다 이는 사실 프로그래밍 언어로 표현한 코드에서도 마찬가지인 것이다 훌륭하고 간단명료하게 정리된 코드는 자신뿐 아니라 다른 독자가 읽을 때도 굉장히 중요한 것이다 나쁜 코드는 당장의 생산성에는 도움이 될지 몰라도 결국 생산성을 크게 떨어트린다 다른 기업들의 블로그 포스팅을 봤을 때도 많이 본 내용이다 회사 초창기에 마구잡이식..
클린 코드를 읽기 시작하면서부터 그저 스쳐 지나가기엔 아쉬운 글들이 많다 느낀 점이나 내용을 간단히 정리하면서 읽어볼 예정 '남에게 설명할 때 더 배운다'라는 걸 최근에 많이 느낌 처음은 LINE 유튜브에서 추천하는 개발자 책으로 알게 되었다 여기저기서 종종 언급되어 읽어보고 싶어 졌음 책을 구매하고 커버부터 느낌이 좋다 특히 저 검은 얼룩이 묻은 부분 보자마자 나도 모르게 뭐 묻었지 하고 손으로 쓸어 넘기게 되더라... 본능적으로 Cleaning을 하고 싶게 함 개발자라면 설계나 코딩에 관해 자신만의 철학이 있다 나 같은 경우에는 '화려할 필요 없다. 읽기 쉬운 코드를 짜자'인데 사실 말처럼 쉽지는 않다 코드 리뷰를 하다 보면 여러 가지 충고를 받기 마련이고 리뷰에서 상사들에게 들은 내용이 책의 추천사..
