Hi yoahn 개발블로그

소프트웨어 설계자는 사용하지 않은 것에 의존하지 않아야 한다. 가정: user1 은 op1 을, user2 는 op2 를, user3 는 op3 만을 사용한다 OPS 가 정적 타입 언어 클래스라면, User 는 사용하지 않는 메서드에 의존하게 된다. 이러한 의존성으로 인해 사용하지 않는 메서드가 변경되면 User 도 다시 컴파일한 후 새로 배포해야 한다. 위와 같이 구성하면, 자신과는 관계없는 변경이라면, 다시 컴파일하고 배포하는 상황은 생기지 않는다. 위의 사례는 정적 타입 언어에 해당하는 사례. 동적 타입 언어(루비, 파이썬)에서는 소스 코드에 이러한 선언문이 존재하지 않는다. 대신 런타임에 추론이 발생한다. 따라서 소스 코드 의존성이 아예 없다. 재컴파일과 재배포가 필요없다. 정적 타입 언어보다 유..

하위 타입에 관한 원칙 상호 대체 가능한 구성요소를 이용해 소프트웨어 시스템을 만들 수 있으려면, 이들 구성 요소는 반드시 서로 치환 가능해야 한다. S 타입 객체 o1 각각에 대응하는 T 타입 객체 o2 가 있고, o2 자리에 o1 을 치환하더라도 프로그램의 행위가 변하지 않는다면 S 는 T 의 하위 타입이다. 예제 Billing 애플리케이션에서 License의 calcFee() 호출 LSP 준수 설계 → Billing 애플리케이션의 행위가 License 의 하위 타입 중 뭘 사용하는지에 대해 의존하지 않음 정사각형/직사각형 문제 → LSP 위반 Rectangle 의 높이와 너비는 서로 독립적으로 변경될 수 있는 반면, Square의 높이와 너비는 반드시 함께 변경됨 LSP 위반을 막기 위해 실제 타입..

소프트웨어 개체는 확장에는 열려있어야 하고, 변경에는 닫혀 있어야 한다. 개체의 행위는 확장할 수 있어야 하지만, 개체를 변경해서는 안된다. 기존 코드를 수정하기 보다는 새로운 코드를 추가하는 방식으로 시스템의 행위를 변경할 수 있도록 설계해야 소프트웨어 시스템을 쉽게 변경할 수 있다. 기능이 추가되는 경우 소프트웨어 아키텍처가 훌륭하다면 변경되는 코드의 양이 최소화될 것이다. (이상적인 변경량을 0이다.) How? SRP: 서로 다른 목적으로 변경되는 요소를 적절하게 분리하고, DIP: 요소 사이의 의존성을 체계화함으로써 변경량을 최소화할 수 있다. A 컴포넌트에서 발생한 변경으로부터 B 컴포넌트를 보호하려면 A 컴포넌트가 B 컴포넌트에 의존해야한다. Presenter 에서 발생한 변경으로부터 Cont..

콘웨이 법칙에 따른 따름정리: 소프트웨어 시스템이 가질 수 있는 최적의 구조는 시스템을 만드는 조직의 사회적 구조에 영향을 받는다. 각 소프트웨어 모듈은 변경의 이유가 단 하나여야 한다. 단일 책임 원칙은 객체 지향 설계 원칙 중 하나로, 하나의 클래스는 하나의 책임만 가져야 한다는 것을 의미합니다. 즉, 클래스가 변경되어야 하는 이유는 오직 하나뿐이어야 한다는 것입니다. 이를 통해 클래스의 응집도(cohesion)가 높아지고 결합도(coupling)가 낮아져 유지보수와 확장성이 증가하게 됩니다. SRP를 준수하는 코드는 각 클래스가 자신의 책임에 충실하고 다른 클래스와 관련 없는 기능이 없는 것이 특징입니다. 이를 위해서는 클래스의 책임을 명확히 분리하고, 각각의 책임이 변경될 때 다른 책임에 영향을 ..

깔끔하지 않은 코드를 쓰면 아키텍처가 좋아도 의미가 없고, 깔끔한 코드를 사용하더라도 아키텍처가 나쁘면 의미가 없다. SOLID 좋은 코드로 좋은 아키텍처를 정의하기 위한 원칙 목적 중간 소프트웨어의 구조가 변경에 유연하다. 이해하기 쉽다 많은 SW 시스템에 사용될 수 있는 컴포넌트의 기반이 된다. 중간수준 모듈 수준에서 작업할 때 적용할 수 있다는 것 코드 수준보다는 상위 수준에서 적용되며 모듈과 컴포넌트 내부에서 사용되는 소프트웨어 구조를 정의하는데 도움 2023.08.20 - [Computer Engineering] - 7장 SRP: Single Responsibility Principle 단일 책임 원칙 7장 SRP: Single Responsibility Principle 단일 책임 원칙 콘웨이..

리팩토링을 목표로 시작했던 3기, 리빌딩으로 마무리했다. 탁구 매칭 & 랭킹 시스템으로 42Seoul 카뎃들을 대상으로 하는 서비스이고 작년쯤부터 개발했던걸로 알고있다. 1기때 메인 기능 개발하고 2기때는 관리자 기능이 추가됐다. 나는 3기때 들어오게 되서 기존 서버 구성을 늦게 알게 되었는데, OAuth 를 잘못 사용하고 있는 부분(안쓰고 있는 것과 마찬가지였다.)과 데이터베이스 정규화 제대로 안되어있는 부분들(외래키가 불필요하게 많이 걸려있는 부분, 컬럼은 있는데 값이 아예 안들어가는 부분,,)로 인해 3기 온보딩 중에 설계문제로 디비에 똑같은 데이터가 두번 들어가는 문제가 있었다. 또한 코드 리팩토링을 해야하는데 안쓰는 클래스 파일도 몇개 있는데 양이 많고 기존 코드에 대해 완벽히 이해하고 있는 사..

Jenkins 를 이용하여 CI/CD를 할 때, Docker를 사용하는 상황이라면 Jenkins 가 설치된 인스턴스에 이미 Docker 가 깔려있지만 Jenkins 이미지 안에는 Docker 가 없기 때문에 docker 실행시 오류가 발생한다. 이를 해결하기 위해 Jenkins 이미지 안에 도커를 또 깔아야 할까? 아니다. 호스트 컴퓨터에 깔려있는 도커 데몬과, 젠킨스 컨테이너 내에 존재하는 도커 클라이언트가 통신할 수 있도록 해주면 된다. 1. docker 설치 sudo wget -qO- https://get.docker.com/ | sh sudo usermod -aG docker ${USER} # docker 실행을 sudo 권한 없이 할 수 있게 해줌 sudo systemctl start docke..

42GG 플젝을 진행하던 중 무려 테이블 5개를 동시에 조인해야하는 상황이 발생했다. 현재 서비스중인 프로젝트이다보니 DB 에 저장된 데이터 양도 좀 있고, 꾸준히 사용하는 분들이 계시기 때문에 앞으로 더 많은 데이터가 생길 수 있어 해당 쿼리 뿐만 아니라 다른 sql 쿼리들도 최적화가 가능한 쿼리가 있는지 확인하기 위해 사용해보려고 한다. 실행계획이란 DB 옵티마이저가 쿼리를 어떻게 실행할지에 대한 계획이다. 실행계획을 통해 데이터를 조회할 때 검색시에 테이블을 풀스캔하는지, range scan 을 하는지 봐야하고 설정해둔 인덱스를 타는지 확인할 수 있다. EXPLAIN SELECT * FROM A, B WHERE A.bid=B.id; Explain 키워드를 통해 실행계획을 확인할 수 있다. (이외에도..

이번주에 두번째 스프린트가 종료된다. 사실 그동안 개발을 할때 일단 빨리 하고 코드는 나중에 개선하면 된다는 생각을 가지고 있었는데, 잘못된 생각이었던것 같다. 시스템 자체 복잡도가 낮지 않은 프로젝트인데, 좀만 복잡한 api 를 구현할 때가 되면 머리로만 생각해서 짜는게 쉽지 않다. DB join 쿼리부터 복잡할때도 있고 이것저것 고려해야 할 요소가 많은데 어디 페이지에서 어떤 용도로 쓰는거라는 설명 한줄 가지고는 부족하다. api 하나를 예시로 들면, 게임 종료되면 랭크게임의 경우 같은 게임을 한 두명에게 동시에 입력받아서 그 점수가 같을 때에야 ELO 시스템을 통해 탁구력을 계산한다. 그런데 42gg 서비스는 랭킹 조회 성능 개선을 위해 Redis 를 사용하고 있다. 그래서 탁구력을 계산하면, 그 ..

기존 시스템 분석하면서 왜 이렇게 되어있나 싶은 로직과 DB를 마주하였다. https://www.figma.com/file/uiJL8G0rKLp8ZIJc5Rj7Fy/42GG?node-id=0%3A1&t=MIs1LoNUqxts1I5o-1 DB가 제일 심각했는데, 실제 DB와 ERD가 차이가 있기도 했고, user 테이블의 외래키를 id(INT) 를 거는 테이블과 intra id (VARCHAR)를 외래키로 거는 테이블의 공존하는 상황이었다. 원래 42gg 3기 프로젝트 진행 목적은 리팩토링이었다. 성능 개선이나 코드 가독성 향상을 목표로 하고 있었는데, 레거시 파악을 하다 보니 시스템 개선이 시급하다고 생각했다. 깔끔하지 않은 뼈대를 고치다보면 누더기가 될 뿐,, 하나의 외래키를 여러 테이블에서 가지고 있..