알쏭달쏭 컴퓨터 세상

우선 나는 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 자원의 사용량이 실시간..

이전글 : 2021.10.10 - [✍🏻] - [캐치미] 개발자도 기획해요 - #1 기획을 시작한 이유 [캐치미] 개발자도 기획해요 - #1 기획을 시작한 이유 쉽지 않은 글의 시작이다. 너무 생각이 많으면 전달이 어려워서다. 이를 정리하기 위해 첫 서비스 기획 프로젝트 회고를 남겨보려 한다. 나는 개발자다. 정확히는 약 6개월 전 개발자 지망생일 khl6235.tistory.com 대학생 연합 IT 벤처창업동아리 SOPT(이하 SOPT, 솝트)에는 약 3주간의 장기 해커톤, 앱잼이 있다. 기획, 디자인, 개발 파트원들이 모여 하나의 새로운 서비스를 만들어내는 앱잼은 솝트의 꽃이라고 할 수 있을 정도로 큰 행사이다. 앱잼에서 내가 떠올린 아이디어로 서비스를 만들기 위해서는 우선 기획 경선에 나가야 한다...

쉽지 않은 글의 시작이다. 너무 생각이 많으면 전달이 어려워서다. 이를 정리하기 위해 첫 서비스 기획 프로젝트 회고를 남겨보려 한다. 나는 개발자다. 정확히는 약 6개월 전 개발자 지망생일 때 서비스 기획에 도전했다. 오랜 기간 계속 해온 동아리, SOPT에서 안드로이드와 서버 개발을 배웠고 모바일 앱 개발 프로젝트에 다수 참여했었다. 이 동아리를 통해 개발자가 되어야겠다는 생각을 굳혔고, IT 업계의 매력에 빠져 현재는 개발 직군으로 일하고 있다. 그런데 왜 갑자기 기획을 하게 되었을까? SOPT는 기획, 디자인, 개발(안드로이드, iOS, 웹, 서버) 파트로 이루어져 있고 모든 회원들은 본인이 선택한 하나의 파트 안에 속해있다. 처음 들어간 2019년에는 안드로이드 파트였고 이어서 서버 파트를 수료하..

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

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