반응형

SSH 키 생성 

1. 터미널 실행 후 아래 명령어 실행

    - cat ~/.ssh/id_rsa.pub 

 

2. 기존에 SSH키가 있다면 위에 명령어로 SSH 키 출력된다.

 

3. No such file or directory 문구가 나온 경우 아래 명령어 실행

     - ssh-keygen

 

4. 비밀번호 설정

     - Enter키로 기본 값 그대로 생성 권장

 

 

 * github ssh 등록은 다음글에서 확인

    - https://gyucheolk.tistory.com/9?category=828085

 

[Git] SSH키 설정

GitHub을 사용하면서 매번 push 할 때마다 로그인하는 게 힘들어서.. 찾아보던 중 ssh 설정에 대해서 알게 되었습니다. 1. cmd 창에 ssh-keygen를 입력해서 ssh키를 생성한다.  - id_rsa, id_rsa.pub 파일 두개가

gyucheolk.tistory.com

 

 

 

 

 

 

728x90
반응형

'Git' 카테고리의 다른 글

Spring git .gitignore 적용 안될 때  (0) 2022.10.06
[Git] 기존 프로젝트 Git Repository 연결  (0) 2021.06.06
[Git] push 했는데 잔디가 안 심어질 때..  (0) 2021.05.09
[Git] SSH키 설정  (0) 2020.12.12
반응형

1. Edit Configurations 선택

  - 설정 위치 : 프로젝트 Run 버튼 왼쪽, 상단의 Run 카테고리 아래

 

 

2. Environment 아래에 VM option, Program arguments 설정 칸에 입력

  - ex) VM option : -Dspring.profiles.active=local (profile 로컬로 실행)

  - ex) Program arguments : arg1 arg2

 

728x90
반응형
반응형

1. Get from Version Control 선택

 

 

2. Version control Git 선택 후 URL 입력 후 Clone

 

 

* 매번 Intellij 실행 시 최근 프로젝트가 실행이 되어서 프로젝트를 선택할 수 있는 기본 화면이 안나온다면 아래와 같이 설정 변경

 

1. File > Settings ( 윈도우 기준 단축키 : Ctrl + Alt + s)

 

2. Reopen last project on startup 해제

 

728x90
반응형
반응형

목차

1. SOLID

2. 간결한 함수 작성하기

3. 안전한 함수 작성하기

4. 함수 리펙터링

 


1. SOLID

SRP - 단일 책임 원칙 

OCP - 개방 폐쇄 원칙

LSP - 리스코프 치환 원칙

ISP - 인터페이스 분리 원칙

DIP - 의존성 역전 원칙

 

SRP (단일 책임 원칙)

 * 한 클래스는 하나의 책임만 가져야 한다.

 - 클래스는 하나의 기능만 가지며, 어떤 변화에 의해 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다.

 - SRP 책임이 분명해지기 때문에, 변경에 의한 연쇄작용에서 자유로워질 수 있다.

 - 가독성 향상과 유지보수가 용이해진다.

 - 실전에서는 쉽지 않지만 늘 상기해야 한다.

 

OCP (개방 폐쇄 원칙)

 * 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야한다.

 - 변경을 위한 비용은 가능한 줄이고, 확장을 위한 비용은 가능한 극대화 해야 한다.

 - 요구사항의 변경이나 추가사항이 발생하더라도, 기존 구성요소에는 수정이 일어나지 않고, 기존 구성 요소를 쉽게 확장해서 재사용한다.

 - 객체지향의 추상화와 다형성을 활용한다.

 

LSP(리스코프 치환 원칙)

 * 서브 타입은 언제나 기반 타입으로 교체할 수 있어야 한다.

 - 서브 타입은 기반 타입이 약속한 규약(접근제한자, 예외 포함)을 지켜야 한다.

 - 클래스 상속, 인터페이스 상속을 이용해 확장성을 획득한다.

 - 다형성과 확장성을 극대화하기 위해 인터페이스를 사용하는 것이 더 좋다.

 - 합성(composition)을 이용할 수도 있다.

 

ISP(인터페이스 분리 원칙)

 * 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다.

 - 가능한 최소한의 인터페이스만 구현한다.

 - 만약 클래스를 이용하는 클라이언트가 여러 개고, 이들이 클래스의 특정 부분만 이용한다면, 여러 인터페이스로 분류하여 클라이언트가 필요한 기능만 전달한다.

 - SRP가 클래스의 단일 책임이라면, ISP는 인터페이스의 단일 책임

 

DIP(의존성 역전 원칙)

 * 상위 모델은 하위 모델에 의존하면 안된다. 둘 다 추상화에 의존해야 한다.

    추상화는 세부 사항에 의존해서는 안된다. 세부 사항은 추상화에 따라 달라진다.

 - 하위 모델의 변경이 상위 모듈의 변경을 요구하는 위계관계를 끊는다.

 - 실제 사용관계는 그대로이지만 추상화를 매개로 메시지를 주고 받으면서 관계를 느슨하게 만든다.

 

2. 간결한 함수 작성하기

 함수 인수 - 인수의 갯수는 0~2개가 적당하다.

                    3개 이상인 경우  1. 객체를 인자로 사용

                                              2. 가변 인자를 사용 ex) (Object... args) 잘 사용하지는 않는다.

 

3. 안전한 함수 사용하기

 부수 효과(Side Effect)없는 함수

 부수 효과? 값을 반환하는 함수가 외부 상태를 변경하는 경우

 

4. 함수 리펙터링

 1. 기능을 구현하는 서투른 함수를 작성한다. - 길고, 복잡하고, 중복도 있다.

 2. 테스트 코드를 작성한다. - 함수 내부의 분기와 엣지값마다 빠짐없이 테스트하는 코드를 짠다.

 3. 리팩터링 한다. - 코드를 다듬고, 함수를 쪼개고, 이름을 바꾸고, 중복을 제거한다.

 

728x90
반응형

'Book > Clean Code' 카테고리의 다른 글

[Clean Code] Chapter 07  (0) 2022.03.17
[Clean Code] Chapter 06  (0) 2022.03.13
[Clean Code] Chapter 05  (0) 2022.03.12
[Clean Code] Chapter 04  (0) 2022.03.12
[Clean Code] Chapter 01 ~ 02  (0) 2022.03.06
반응형

1장. 깨끗한 코드

나쁜 코드

 - 성능이 나쁜 코드

 - 의미가 모호한 코드

 - 중복된 코드

 

나쁜 코드가 나쁜 이유

  * 깨진 유리창 법칙(깨진 유리창을 방치해두면 그 중심으로 범죄가 확산된다.)

 - 생산성 저하

 - 새로운 시스템을 만들게 된다. (어느 한 부분만 수정할 수 없게됨, 현실적으로 매우 어려움)

 

나쁜 코드를 짜는 이유

 - 일정이 촉박해서 

 - 영향 범위가 넓어서(영향 범위 예측이 안되서 보수적으로 코드를 작성하게 된다.)

 

클린 코드

비아네 스트롭스트룹 

" 나는 우아하고 효율적인 코드를 좋아한다.

  논리가 간단해야 버그가 숨어들지 못한다.

  의존성을 최대한 줄여야 유지보수가 쉬워진다.

  오류는 명백한 전략에 의거해 철저히 처리한다.

  성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다.

  깨끗한 코드는 한 가지를 제대로 한다. "

 

클린 코드 조건

 - 성능이 좋은 코드

 - 의미가 명확한 코드 = 가독성이 좋은 코드

 - 중복이 제거된 코드

 

보이스카우트 룰

 - "캠프장을 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라" -> 전보다 더 깨끗하한 코드로 만들어라

 

2장. 의미있는 이름

 - 의미가 분명한 이름 짓기 - ex) int a, b 

 - 루프 속 ijk 사용하지 않기 - 굳이 index 값이 필요없다면.. 사용하게 된다면 최대한 의미를 부여해서 사용 ex) row, col, depth

 - 통일성 있는 단어 사용하기

 - 병수명에 타입 넣지 않기 - ex) String nameString => name, Account[] accountArray => accounts 

* 팀간의 충분한 의사소통을 통해서 맞추는게 중요

 

참고 가이드 - google java naming guide

- https://google.github.io/styleguide/javaguide.html#s3.2-package-statement

- google java naming guide 구글링하면 한국어로 번역된 블로그 많이 나온다.

728x90
반응형

'Book > Clean Code' 카테고리의 다른 글

[Clean Code] Chapter 07  (0) 2022.03.17
[Clean Code] Chapter 06  (0) 2022.03.13
[Clean Code] Chapter 05  (0) 2022.03.12
[Clean Code] Chapter 04  (0) 2022.03.12
[Clean Code] Chapter 03  (0) 2022.03.09
반응형

Intellij에 Gradle 프로젝트를 Import 하였는데 아래와 같이 오류가 발생한다.

 

Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed

 

검색 결과 Intellij에서 자바 실행을 안되는 경우 나오는 오류 메시지로 확인이 되었다.

 

프로젝트 JDK, Gradle JDK 설정 확인 필요

 

- 프로젝트 JDK

Windows : File -> Project Structure (Ctrl + Alt + Shift + S)

Mac : File -> Project Structure

 

해당 프로젝트 JDK 버전과 일치한지 확인

 

- Gradle JDK

Windows : File -> Settings (Ctrl + Alt + S)

Mac : Intellij IDEA | Preferences

 

1. Build and run using, Run tests using -> Intellij IDEA로 변경

2. Gradle JVM 해당 프로젝트 JDK 버전과 일치한지 확인

728x90
반응형
반응형

 

intellij 상단에 File -> Open -> import할 프로젝트의 build.gradle 선택 후 Open as Project 선택

 

1. Open

 

 

 

2. build.gradle 선택

 

 

3. Open as Project 선택 끝!

 

728x90
반응형
반응형

URI(Uniform Resource Identifier)

URI는 로케이터(locator), 이름(name)  또는 둘다 추가로 분류될 수 있다.

 

Uniform - 리소스 식별하는 통일된 방식

Resource - 자원, URI로 식별할 수 있는 모든 것(제한 없음)

Identifier - 다른 항목과 구분하는데 필요한 정보

 

URL - Uniform Resource Locator

 - 리소스가 있는 위치를 지정

 - URI를 URL과 같은 의미로 많이 사용

 

URN - Uniform Resource Name

 - 리소스에 이름을 부여

 - URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음.

 

URL 전체문법

 scheme://[userinfo@]host[:port][/path][?query][#fragment]

- scheme : 주로 프로토콜 사용, 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙 예) http, https, ftp 등

- [userinfo@] : URL에 사용자정보를 포함해서 인증, 거의 사용하지 않음

- host : 호스트명, 도메인명 또는 IP 주소를 직접 사용가능

- [:port] : 접속포트, 일반적으로 생략, 생략시 http는 80, https는 443

- [/path] : 리소스 경로(paht), 계층적 구조

- [?query] : ket=value 형태, ?로 시작, &로 추가 기능 (query parameter, query string등으로 불림)

- [#fragment] : html 내부 북마크 등에 사용, 서버에 전송하는 정보 아님

 

웹 브라우저 요청 흐름

HTTP 메시지 전송

  1. 클라이언트가 패킷을 생성해서 출발지 IP, PORT, 목적지 IP, PORT 전송 데이터(HTTP 메시지)를 서버에 요청한다.
  2. 데이터는 수많은 노드들을 거쳐서 서버에 전달된다.
  3. 서버는 TCP/IP 패킷을 제거 후 HTTP 메시지를 해석하여 응답 메시지를 생성한다.
  4. 서버도 똑같이 TCP/IP 패킷으로 감싼 후 클라이언트에 전달한다.

 

참고

inflean 강의 (모든 개발자를 위한 HTTP 웹 기본 지식, 김영한)

728x90
반응형

'Network' 카테고리의 다른 글

인터넷 네트워크  (0) 2021.09.04

+ Recent posts