알쏭달쏭 컴퓨터 세상

우선 나는 Git을 떠올리면 약간의 걱정부터 드는 개발자다. "개발자라면 당연히 Git을 눈 감고도 쓸 줄 알아야지!" 라는 말에 어느 정도 동의는 하지만, 눈 뜨고도 혹시 브랜치를 잘못 합치거나 명령어를 잘못 쳤을까 봐 긴장하곤 한다. 이런 깃린이가 Gitflow를 쓰게 되면서 브랜치에 대한 머릿속 정리가 좀더 깔끔해진 것 같아 간단히 정리해둔다. https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow Gitflow Workflow | Atlassian Git Tutorial A deep dive into the Gitflow Workflow. Learn if this Git workflow is right for you..

본 책에서 다루는 예제를 바탕으로 하고 있습니다. 계층으로 구성하기 인터페이스 & 인터페이스 구현체 → 최적은 아님… 문제점 : functional slice나 feature를 구분 짓는 패키지 경계가 없다. 애플리케이션이 어떤 유스케이스들을 제공하는지 파악 불가 기능으로 구성하기 상위 패키지 안에 다 때려넣기 장점 : 패키지 경기를 package-private 접근 수준과 결합하면 기능 사이의 불필요한 의존성 방지 가능 AccountService의 책임을 좁히기 위해 SendMoneyService. → 기능과 의도를 소리치고 있음! 단점 : 가시성 떨어짐 의존성 역전을 시켰지만, 도메인 코드가 실수로 영속성 코드에 의존하는 것을 막을 수 없다. 아키텍처적으로 표현력 있는 패키지 구조 adapter 애플..

단일 책임 원칙(SRP) ‘책임’ → ‘변경할 이유’ 로 해석이 더 맞을 듯 “컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다” 어떤 다른 이유로 sw를 변경하더라도 이 컴포넌트에 대해서는 전혀 신경 쓸 필요 없다. 변경돼도 우리가 기대한 대로 동작할 것 의존성 역전 원칙(DIP) 계층형 아키텍처에서 항상 의존성은 아래를 향하므로, 상위 계층들이 하위 계층보다 변경할 이유가 더 많다. (영속성 계층을 변경할 때마다 도메인도 변경해야 함) “코드상의 어떤 의존성이든 그 방향을 역전시킬 수 있다” 의존성의 양쪽 코드를 모두 제어할 수 있을 때만 의존성 역전 가능. 도메인 객체를 표현하는 엔티티부터 도메인 계층으로 올린다 영속성 계층에 있는 Repository가 엔티티에 의존하므로 ‘순환 의존성’ 발생 → ..

기술 서적은 기록을 해두지 않으면 금방 잊어버리는 것 같다... 필요한 내용을 찾을 때 뭔가 관련된 부분이 있었는데 하는 생각은 들지만 바로 찾아내기는 어려울 때도 많아서, 아무튼 내용 정리의 중요성을 느끼고 진짜 간단하게 작성하는 글. 계층형 아키텍처는 데이터베이스 주도 설계를 유도한다. 전통적인 계층형 아키텍처의 토대 = 데이터베이스 앱을 만드는 목적은 state가 아니라 behavior! 그런데 우리는 늘 db를 먼저 생각해왔다. → orm을 쓰기 때문 orm에 의해 관리되는 엔티티는 영속성 계층. 계층은 아래 방향으로만 접근 가능하므로 도메인과 강한 결합이 생긴다. 지름길 모드 점점 쉽게 접근할 수 있는 지름길 모드를 추구하게 되어 영속성 계층이 비대해질 것… 테스트 어려움 엔티티의 필드를 하나만..

2021.10.28 - [💻/스터디] - [AWS SAA-C02 (feat.삽가능 스터디)] EC2, ELB, RDS [AWS SAA-C02 (feat.삽가능 스터디)] EC2, ELB, RDS A-SAA-P 에이삽! 스터디 정리하기 시작 ❓ 온프레미스(On-premise) vs. 클라우드(Cloud) 온프레미스 : 실제 물리적인 서버부터 구축. 네트워크 및 인프라 모두 직접 뚝딱뚝딱. 클라우드 : 인프라 즉 IT 자 khl6235.tistory.com Aurora 고사양 상용 DB의 속도 및 가용성 + 오픈소스 DB의 단순성 및 비용 효율성 공식 문서 ⇒ RDBMS, MySQL과 호환 성능 및 확장성 처리 성능이 MySQL보다 5배 높음 클릭 몇 번으로 컴퓨팅 및 메모리 리소스 조정 가능 Auto-Sc..

A-SAA-P 에이삽! 스터디 정리하기 시작 ❓ 온프레미스(On-premise) vs. 클라우드(Cloud) 온프레미스 : 실제 물리적인 서버부터 구축. 네트워크 및 인프라 모두 직접 뚝딱뚝딱. 클라우드 : 인프라 즉 IT 자원을 다 빌려줌. 직접 보유하고 있을 필요 없이 필요할 때만 사용. ❗️ 클라우드 컴퓨팅의 조건 On Demand Self Service 사용자가 원할 때 바로 사용 Broad Network Access 네트워크 기반, 다양한 클라이언트로 접속 가능 Resource Pooling 자원은 Pool로 관리되며, 사용자의 요청에 의해 반환&할당 됨. Rapid Elasticity 사용자는 짧은 시간 내 자원을 무한대로 확장&축소 가능. Measured Service 자원의 사용량이 실시간..

1. 스프링 AOP 비즈니스 컴포넌트 개발에서 가장 중요한 두 가지 원칙은 낮은 결합도와 높은 응집도 스프링의 의존성 주입을 이용하면 비즈니스 컴포넌트를 구성하는 객체들의 결합도를 떨어뜨릴 수 있어서 의존관계를 쉽게 변경 가능 IoC - 결합도 vs. AOP - 응집도 AOP 이해하기 AOP(Aspect Oriented Programming)은 예외, 트랜잭션 등의 부가적인 코드들을 효율적으로 관리하는 데 주목 관심 분리(Separation of Concerns) 횡단 관심 : 메소드마다 공통으로 등장하는 로깅, 예외, 트랜잭션 처리 등의 코드 핵심 관심 : 사용자 요청에 따라 실제로 수행되는 핵심 비즈니스 로직 두 관심을 완벽하게 분리할 수 있다면 간결하고 응집도 높은 코드 유지 가능. 하지만 독립적인..

1. 개발 환경 구축 JDK 설치 -> 이클립스 EE 설치 -> tomcat 서버 설치 및 연동 -> 데이터베이스 구축(h2) -> STS(Spring Tool Suite) 플러그인 설치 2. 프레임워크 개요 프레임워크 개념 "뼈대 혹은 틀". 아키텍처에 해당하는 골격 코드 제공. 개발자에게 모든 것을 위임하지 않고, 애플리케이션의 기본 아키텍처는 프레임워크가 제공하고 그 뼈대에 살을 붙이는 작업만 개발자가. 장점 빠른 구현 시간 : 개발자는 비즈니스 로직만 구현하면 됨 쉬운 관리 : 같은 프레임워크 적용된 App은 아키텍처 같아서 관리 쉬움. 유지보수도 효율적. 개발자들의 역량 획일화 : 숙련자/초심자의 차이가 적음. 개발 인력 효율적 구성 가능. 검증된 아키텍처의 재사용과 일관성 유지 : 별다른 검증..

이전 글 : [스프링+리액트 웹 만들기] #1. 환경 세팅하기 DB로는 MySQL을 이용했다. formapp 이라는 이름으로 스키마를 생성했고, 대략적인 구조는 아래 그림과 같다. 1. USER user 정보를 저장해두는 테이블. userIdx가 PK로 들어가고 id와 password 칼럼을 생성했다. password가 그대로 DB에 들어가는 보안 문제를 막기 위해서는 암호화 시킨 값을 password 대신 DB에 저장하도록 하는 것이 좋지만, 로컬에서만 돌려보는 개인 공부용 프로젝트이므로 그냥 진행했다..^0^ 2. FORM 설문 정보 저장해두는 테이블. formIdx를 PK로 가지고, 작성자 id, 설문 제목, 생성 시간을 칼럼으로 두었다. 생성 시간인 createdAt 칼럼은 디폴트를 CURRENT..

4. 함수와 프로토타입 체이닝 함수 리턴 : 규칙 1) 일반 함수나 메소드는 리턴값을 지정하지 않을 경우, undefined 가 리턴된다 규칙 2) 생성자 함수에서 리턴값을 지정하지 않을 경우 생성된 객체가 리턴된다 별도의 리턴값 지정 안했을 경우, this로 바인딩된 새 객체가 리턴. 따라서 생성자 함수에서는 일반적으로 리턴값 지정 안함. 명시적으로 리턴값을 넘기면 해당 객체나 배열이 리턴되지만, 객체가 아닌 boolean, number, string의 경우는 무시되고 this로 바인딩된 객체가 리턴. 프로토타입 체이닝 : 자바스크립트의 객체 생성 규칙 모든 객체는 자신을 생성한 생성자 함수의 prototype property가 가리키는 프로토타입 객체를 자신의 부모 객체로 설정하는 [[Prototyp..