개발 방법론을 알아야 하는 이유

IT 업계에서 일을 하다 보면, 개발자도 ‘두 부류’로 나뉘는 걸 자주 느낍니다. 하나는 “개발방법론이 왜 중요한지 이해하고, 그에 따라 일하려는 사람.” 다른 하나는 “그냥 시키는 대로만 하다 퇴근하는 사람.”

처음엔 저도 개발방법론이 뭔지도 모르고 그냥 주어진 일을 처리하는 데 급급했어요. 그런데 프로젝트를 여러 번 반복하고, 팀원들과 충돌도 겪고, 일정이 꼬여 밤샘까지 해보다 보니 문득 이런 생각이 들더군요. “어떻게 해야할까?”, "그만둬야 하나"

하지만, 뛰어난 PM들 개발자들이 모두 그렇게 떠나갔다면 지금의 IT세상은 오지 않았을 거에요.

결국 좀 더 효율적으로 일을 할 수 있게 배워야 한다는 것을 느겼습니다.

개발방법론, 결국은 ‘소통의 언어’다

‘개발 방법론’이라는 단어 자체는 굉장히 무겁고, 학술적인 느낌을 줍니다.

하지만 본질은 굉장히 실용적입니다. 혼자 코딩할 때는 몰라도 팀 프로젝트에서는 반드시 필요한 도구라는 이야기죠.

예를 들어 캡슐화는 외부에서 객체의 내부를 무작정 건드리지 못하게 막아주는 개념입니다.

실무에서는 주로 private, public 키워드로 표현되죠. 추상화 역시 마찬가지입니다. 공통 기능을 묶어 추상화하고, 하위 클래스가 그걸 구현하게 만드는 구조입니다.

캡슐화

디자인 원칙을 알면, 코드에 대한 생각이 달라진다

개발자라면 꼭 한 번쯤 들어봤을 ‘SOLID 원칙’도 그 중심에 있죠. 한 프로젝트에서 제가 맡은 클래스가 무려 1,000줄이 넘은 적이 있습니다. 그 안에 데이터 처리부터 UI 로직, 예외처리, 네트워크 호출까지 모두 들어 있었습니다.

그 당시에는 잘 돌아가니 그냥 넘어갔는데, 몇 달 뒤 기능 추가하면서 지옥을 맛봤습니다.

지금 내가 짜는 코드가, 몇 개월 뒤, 혹은 몇 년 뒤의 나에게 어떤 짐으로 돌아올지 생각해 보는 것.

그게 개발 방법론을 배우는 이유고, 또 우리가 이 원칙들을 공부해야 하는 이유라고 저는 생각합니다.

오늘 내가 걸어간 길은 훗날 누군가의 이정표가 될 지어다... 

꼭 기억해 주시고,

이론적인 내용도 전달 드리겠습니다.

 

개발방법론이란?
소프트웨어를 생산하는 데에 필요한 프로그래밍 개발 과정들을 정리하고
 표준화하여 프로그래머들이 프로그래밍 개발과정에서 각개인이 개발과정에서의
 일관성을 유지하고 프로그래머들간의 효과적인 협업이 이루어질수 있도록 돕기 위한
 방법론이다.

우선 주변 지식부터 알아보자.
캡술화(encapsulation)와 추상화(Abstraction)의 차이점
[캡슐화의 정의]
객체의 속성(Data Fields)과 행위(메소드, Methods)를 하나로 묶고, 실제 구현 내용 일부를 일부에 감추어 은닉하는 

객체지향의 특성
[캡슐화의특징] 
-클래스와 메소드 기준으로: public, private
-정보은닉의 확장

[추상화의정의]
공통 성질을 추출하여 슈퍼클래스를 설정하는 특성
[추상화의 유형] 
- 기능 추상화: 클래스 내 메소드
- 데이터 추상화: 객체 테이터 타입
- 제어 추상화: 제어명령

알아본 김에 다형성(Polymorphism)까지도 알아보자.
[다형성의 정의]
같은 함수(Method) 이름으로, 여러 개의 메서드를 만들 수 있는 기법
[다형성의 특징]
동적 바인딩, 확장성, 재사용성
[다향성의 기법]
오버로딩(Overloading): 파라미터
오버라이딩(Overriding, 수직): 재정의

다형성

[책체지향 설계의 원리]
1. 단일책임의 원칙(SRP: Single Response Principle )
- 모듈화: 결합도 응집도
- 객체는 하나의 책임만, 기능한개만
- 클래스 메소드 분리 구성도
2. 개방 폐쇄(OCP: Open Closed Principle) 
- Side Effect 제거
- 확장에는 열림 수정에는 닫힘
- 클래스 상속 구성도 정도만
3. 리스코프 치환(LSP:Liskov Substitution P)
- 부모 클래스 > 자식클래스 대체 되도 이상 없음
- 정사각형 extends 사각형 
  > 정사각형 에서 높이 너비를 동일하게 셋팅 오류
- 메소드 접근제어, 상속관계 재확인
4. 인터페이스 분리(ISP: Interface Segregation P)
- 하나의 일반인터페이스 > 구체 인터페이스
- 영향최소화, 결합도 낮추기
- 반대: Facade 패턴
5. 의존성 역전의 원칙(DIP: Dependency Inversion P)
- 구체클래스 말고 추상클래스에 의존
- 알람클래스(추상), 시계 타이머 등에 의존하면 안됌
- 느슨한 결합도

그럼 오늘도 나의 경험이 조금이라도 누군가에게 도움이 되었길 바래본다.