Hi yoahn 개발블로그

42gg 프로젝트에 처음 들어간지 1년이 다 되어간다. 들어가게 되었던 계기는 취준만 하니까 지루하고 쳐져서 하게된것도 있었고, 실제 서비스 운영 경험을 갖고 싶었다. 3기로 들어갈때 쯤에는 운영 경험이라고 하면 뭔가 대단해보이고, 깊은 지식을 얻을 수 있는 것들을 기대했었다. 근데 막상 3기로 들어가서 개발을 해보니까 그냥 개발이랑 뭐가 다른건지 의문이 들었던것 같다. 그런데 개발하다 보니 운영중에 발생하는 버그도 마주치며 해결해보고, 기능 개선을 위해 팀을 설득시키는 경험도 해보면서 그냥 하고싶다고 할 수 있는것도 아니고, 그걸 지금 해결해야할 만큼 중요한 일인가도 생각해보게 되고, 다른 사람들을 설득시키려다보니 이제 왜?라는 물음에 그냥!이 아니라 명확한 이유와 근거를 들어야 한다는 것도 깨달을 수..

42gg 3기 개발을 마치고 4기 분들한테 인수인계를 했지만, gg 서비스가 운영되는 서비스다 보니 aws 에 올라가 있는데 거기 접근을 잘 하는 사람이 많지 않기도 하고 해서 계속 GG를 다른 팀원 한명과 유지보수를 해왔고, 그러다 프로젝트 리더를 맡게 되었다. (다들 부담스러워 하기도 하고 해서 내가 하게 됐다.) 근데 막상 PL 까지 맡으니까 좀 더 개선할 점이나 해결해야 하는 일들이 보이기 시작했고, 그래서 몇가지 이슈를 진행했다. 일단 가장 먼저 해결했던 부분은 슬랙봇. 42 서울 슬랙에 슬랙봇을 추가하여 예약 관련한 알림을 보내려고 했는데, 이걸 하려면 파리에 있는 관리자와 연락을 해야 했다. 근데 파리가 일처리를 빨리 해주는 편은 아니라서 오래 걸렸던 것도 있었고, 해당 관리자 계정이 이름이..

42GG 3기때 리팩토링을 하면서 몇가지 규칙을 정했었는데, 그중 하나인 Builder 패턴에 대한 글이다. 먼저 현재 팀에서 정한 규칙은, Builder 호출을 컨트롤러단, 서비스 단에서는 금지하는 규칙이다. @Builder 패턴의 장점 먼저 builder 패턴의 장점을 알아보자 내가 생각하는 장점 매개변수 명시적 지정 매개변수가 많은 생성자의 경우, 타입이 같은 매개변수가 여러개가 있다면 각 위치에 어떤 값을 넣느냐가 매우 중요해진다. 이때 리팩토링을 하다가 원래 있던 위치의 매개변수가 생성자 내에서 같은 타입이지만 다른 역할로 변경되었다면, 프로그램 실행에는 문제가 없기 때문에 버그를 잡기 어렵다. 하지만 builder 패턴을 사용하면 어떤 멤버변수를 초기화 할건지를 명시적으로 지정하게 되어 생성자..

좋은 코드란 무엇일까? 리팩터링2판, 클린아키텍처 책을 읽으면서 좋은 코드가 무엇인가에 대해 생각해보게 되었다! 1. 가독성이 좋은 코드 가독성이 좋으면 코드를 작성하는 사람도 디버깅이 쉬워지고, 다른 사람도 코드를 읽기 쉬워지면서 유지보수성이 올라가게 된다. 읽기 편한 코드 변수, 함수, 클래스 등의 역할과 동작, 어떤 관계인지 직관적으로 파악 가능한 코드 2. 중복이 없는 코드 가짜 중복이 아닌 진짜 중복이 없는 코드

고수준 정책을 구현하는 코드는 저수준 세부사항을 구현하는 코드에 절대로 의존해서는 안된다. 세부사항이 정책에 의존해야 한다. 유연성이 극대화된 시스템이란? 소스 코드 의존성이 추상에 의존하며 구체에는 의존하지 않는 시스템 자바와 같은 정적 타입 언어에서, use, import, include 구문은 오직 인터페이스나 추상 클래스 같은 추상적인 선언만을 참조해야 한다는 뜻이다. 구체적인 대상에는 절대로 의존해서는 안된다. 루비나 파이썬과 같은 동적 타입 언어에도 동일한 규칙이 적용된다. 소스코드 의존 관계에서 구체 모듈은 참조해서는 안된다. 하지만 구체 모듈이 무엇인지를 정의하기가 다소 어렵다. 소프트웨어 시스템이라면 구체적인 많은 장치에 의존한다. java 의 String 클래스는 구체 클래스이다. 이를..

소프트웨어 설계자는 사용하지 않은 것에 의존하지 않아야 한다. 가정: 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 단일 책임 원칙 콘웨이..