소프트웨어 개발 전략

“솔리드 원칙(Solid Principles)”

SOLID 원칙이란, 소프트웨어 개발 전략으로, 객체 지향 프로그래밍 및 설계 시 반영되어야 할 다섯 가지 기본 원칙을 말합니다. SOLID 원칙을 지킴으로써 개발자가 소스코드를 읽기 쉽고, 확장하기 쉬운 수준으로 소스코드를 Refactoring할 때 적용시킬 수 있습니다. 이는 곧 쉬운 확장과 유연한 유지보수와도 관련이 있습니다. 웹진의 지면을 빌어 SOLID 원칙을 여러분께 소개해 드리겠습니다.

단일 책임 원칙

(SRP : Single Reponsibility Priciple)

<단일 책임 원칙>

“하나의 클래스는 하나의 책임만을 맡아야 한다.” 는 의미입니다. 위 그림을 보게 되면, 첫 번째 그림은 하나의 클래스가 2개의 책임을 가지고 있는 것을 볼 수 있습니다. 그 아래 그림은 첫 번째 그림을 단일 책임 원칙에 맞게 Refactoring한 결과입니다. 단적인 예로 이렇게 SRP를 지킨 프로젝트의 코드일 경우 재배포시 프로젝트 전체 배포가 아닌 컴포넌트 단위의 배포가 가능하게 됩니다.

개방, 폐쇄 원칙

(OCP : Open/Closed Principle)

“확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다.” 는 의미입니다. 즉, 변경을 위한 비용은 줄이고, 확장에 투입된 비용은 극대화해야 한다는 의미로, 요구사항의 변경이나 추가사항이 발생 시 기존 구성요소는 수정이 일어나지 말아야 하며, 기존 구성요소를 확장하여 추가사항에 대응할 수 있어야 한다는 뜻입니다. 아래 그림을 보면 OCP적용 전일 때, Service는 구체클래스 (ConcreteServiceA, ConcreteServiceB)에 의존적이고, 구체클래스의 변경에 영향을 받으며, 추가되는 구체 클래스는 코드의 수정 없이는 처리할 수 없습니다. 반면 OCP가 적용된 상태를 보면,

<개방, 폐쇄 원칙>

Service는 ServiceImpl에 의존하므로 구체 클래스를 코드의 수정 없이 처리할 수 있게 됩니다.

리스코프 치환 원칙

(LSP : Liskov Substitution Principle)

쉽게 말해 “자식 클래스는 부모클래스를 대체할 수 있다” 는 뜻입니다. 즉, 기반클래스와 파생클래스의 호환을 말합니다. 다른 원칙들에 비해 오해가 많은 원칙이라고 하는데, 앞서 소개했던 원칙들처럼 간단하게 소개하겠습니다.

<리스코프 치환 원칙>

LSP 적용 전 그림을 보면, 파생 클래스에서 기반 클래스의 모든 메소드(예외 포함)를 지원하지 않는데, 이는 IS-A 관계가 성립하지 않는다는 뜻이고, 다형성은 IS-A 관계를 기반으로 하므로 안정적인 다형성 유지를 힘들게 합니다. 반면 LSP 적용 후의 그림을 보게 되면, 파생 클래스는 기반 클래스의 모든 메소드를 지원하고, IS-A 관계가 성립하므로 안정적인 다형성 유지는 가능하게 합니다. 이 원칙은 SOLID원칙 중  가장 어려운 원칙이며, 지속적인 이해와 케이스 연구가 필요합니다.

인터페이스 분할 원칙

(ISP :Interface Segregration Principle)

“하나의 범용 인터페이스보다 특화된 여러 개의 인터페이스가 낫다” 는 뜻입니다. 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙입니다.

<인터페이스 분할 원칙>

즉, “하나의 인터페이스로 모든 것을 처리하는 것 보다는 작은 여러 개의 인터페이스로 처리하는 것이 낫다“라는 원칙입니다. 첫 번째 그림을 보면, 클라이언트는 자신이 사용하지 않는 메소드에 의존하고 있는 것을 볼 수 있습니다.

그 말은, 사용하지 않는 메소드에 변경이 일어날 경우 그 영향을 받는 다는 것을 말합니다. ISP가 적용된 그림을 보게 되면, 클라이언트는 자신이 필요한 메소드에만 의존하므로, 사용하지 않는 메소드를 구현할 필요도, 변경에 대해서 영향을 받는 이유도 없어지게 됩니다.

의존관계 역전 원칙

(DIP : Dependency Inverse Principle)

<의존관계 역전 원칙>

의존 관계의 역전이란 구조적 디자인에서 발생하던 하위 레벨 모듈의 변경이 상위 레벨 모듈의 변경을 요구하는 위계관계를 끊는다는 의미의 역적입니다. 즉, 실제 사용관계는 바뀌지 않으나 관계를 최대한 느슨하게 만드는 것이 목적입니다. DIP 적용 전의 모습은 하위 수준에 있는 모듈이 변경 시 Client도 영향을 받고 상위 수준의 모듈이 포함된 라이브러리는 하위 수준의 모듈이 포함된 라이브러리의 변경에 영향을 받습니다. 반면 DIP가 적용되면, 상위 수준의 모듈은 인터페이스에 의존하게 되고, 그 말은 하위 수준 모듈의 변경에도 영향을 받지 않는 다는 것을 뜻하고, 마찬가지로 상위 수준의 모듈이 포함된 라이브러리는 하위 수준 모듈이 포함된 라이브러리의 변경에도 영향을 받지 않는다는 뜻이 됩니다. 이상으로 소프트웨어 개발 SOLID 원칙에 대해서 알아봤습니다. 즉, 이 원칙의 궁극적인 목적은 코드를 유연하게, 재사용 가능하게 만드는 것이 주목적입니다. 이에 따른 이점은 개발자 여러분이 더 잘 알고 계실 것으로 생각됩니다. 짧은 내용으로 모든 것을 알 수는 없겠지만, 관심 있는 분들은 같이 연구하고 토론했으면 좋겠습니다. 감사합니다. (김승엽 대리)

‘JBMS Geo Field Monitoring 솔루션’ 사내 시연

지난 5월 14일 서비스플랫폼 사업부 주관으로 신규 솔루션의 발표가 진행되었습니다. 이번 발표는 JBMap Suite : Geo Field Monitoring 솔루션의 중간 발표 형식으로 사장님을 비롯해 7명이 참석하여 사내 행사로 진행되었습니다.

<사내시연>

JBMap Suite : Geo Field Monitoring 은 기존 관제 솔루션의 적용 대상과 기능을 획기적으로 확장시킬 수 있는 새로운 제품입니다.

현재의 솔루션은 웹 기반으로 개발되었기 때문에, 적용될 수 있는 단말이 제한적이었습니다. 단순한 업무 목적에서는 일반 스마트폰을 사용해 구현이 가능하지만, 관제업무를 위한 전용 단말의 적용은 쉽지 않았습니다.

Geo Field Monitoring 에서는 CS환경이 추가되어 관제 전용 단말의 카메라, 마이크 등 자원의 제어가 용이하며 전용 단말 개발업체에서 제공하는 실시간 동영상, PPT, CCTV 용 네이티브 라이브러리 혹은 연계모듈을 손쉽게 적용할 수 있습니다. 플랫폼의 확장으로 추가되는 관제 특화 서비스는 기존의 GIS 기능과 결합하여 전문 관제 서비스가 가능할 것으로 기대됩니다. 솔루션의 개발이 완료되면 향후 진행될 관제 프로젝트 및 개발중인 JBMS Vector TMS와 연동할 계획입니다. (주서연 주임)

Tip! NAS 대용량 파일 첨부

구글메일에서 허용되는 첨부파일의 최대 크기는 25MB로 그 이상의 파일은 전송이 불가능합니다. 이 경우 구글 드라이브를 이용하는 방법도 있지만, 이번 기사에서는 회사의 NAS 서버를 이용하여 파일을 전송하는 방법을 알아보겠습니다.

일단 첫 번째로, 외부에서 NAS로 접속(Https://data.enjoybt.co.kr:5001)한 후, [File Station]으로 들어갑니다. [File Station]에서는 첨부할 파일을 선택한 후 오른쪽 마우스를 클릭하고, ‘파일링크공유’를 클릭합니다.

<파일링크공유 클릭>

그 다음, 공유링크에 있는 링크를 복사한 후, 파일을 보낼 메일로 들어갑니다.

<링크 복사>

메일에서는 링크를 걸어줄 문장을 적고 드래그합니다. 드래그한 후, 링크삽입 버튼을 누르게 되면, 링크를 삽입할 수 있는 창이 나타나게 됩니다. [File Station]에서 가져온 공유 링크를 그대로 링크 삽입창에 넣어주게 되면, 앞서 드래그 한 문장에 링크가 삽입됩니다. 아래에 두 그림을 보고 확인하시기 바랍니다.

<문장에 링크삽입1>

<문장에 링크삽입2>

삽입된 문장을 클릭하면 첨부한 파일이 다운되는 것을 확인할 수 있습니다. 추가적으로 공유링크 설정 시, 유효기간과 액세스 횟수를 정하는 기능도 있습니다. 파일 링크 공유에서 ‘유효기간 탭‘을 선택하게 되면 다음과 같은 창이 뜨게 됩니다.

<추가기능>

‘유효기간 사용자 지정’에서는 파일을 다운받을 수 있는 유효기간을 설정할 수 있고, ‘유효한 엑세스 횟수 사용자 지정’에서는 파일을 다운받을 수 있는 최대 횟수를 설정할 수 있습니다. (성인호 주임)

‘제이비티 위키’ - 기술블로그 오픈!

기술블로그 오픈 취지

 사내 기술블로그 ‘제이비티 위키‘는 사내 구성원들이 개발 업무를 진행하면서 얻은 노하우나 관련 기술 정보 등을 공유할 수 있는 블로그 입니다. 일상적인 내용은 이미 밴드를 통해 공유하고 있지만, 기술적인 부분을 공유하고 각자 하고 있는 일에 대해 공유하는 공간이 없어 개설하게 되었습니다. 모두가 함께 공유하고 시너지가 될 수 있는 매개체가 되었으면 합니다.

<기술블로그 ‘제이비티 위키’>

(remote.enjoybt.co.kr:9000/wordpress)

구성과 소개

 현재 개설된 기술블로그는 워드프레스로 만들어진 블로그로 어떤 글이든지 작성 가능하며, 이에 해당하는 카테고리만 지정해주면 됩니다. 상단에는 각종 사내서비스로 이동하기 위한 링크메뉴가 있고, 아래는 최신 게시글이 배치되어있습니다. 아직 내용이 많지 않지만 제이비티 개발자라면 필수로 가입하여 아주 작은 것이라도 글로 남겨보는 것이 어떨까요? 반드시 소프트웨어 개발 관련이 아니라도 상관이 없습니다.

이용 팁

 - 기술블로그는 로그인을 해야만 접속할 수 있습니다. 가입신청은 가입신청 후 이메일 인증으로 바로 처리됩니다.

 - 글을 작성할 때 이미지를 업로드한 후 특성이미지로 설정하면 글 미리보기에 대표이미지로 설정됩니다. 이상으로 시네 기술블로그 ‘제이비티 위키’에 대해서 알아봤습니다. 사우여러분의 많은 관심 부탁드립니다. (최임청 과장)

[강추기사모음] 이 기사 보셨나요?

이 코너에서는 함께 공유하면 좋을만한 기사들을 선정해 보았습니다. 기사 제목을 선택하시면 해당 페이지로 이동합니다. 잘 알려지지 않은 기사 중에서 다른 직원들과 나누고 싶은 정보가 있다면 뉴스레터 편집실로 알려 주세요.

≫ 리더가 조직을 침묵시킨다. (출처:고영성의 뒤죽박죽 경영상식, 2015.04.28)

≫ 매혹적이고 특이한 개발자 복지혜택 10가지 (출처:IT World, 2015.05.12)

≫ 백두산 화산 폭발하면 남한에 최대 11억1천900억 피해 (출처:연합뉴스, 2015.05.21.)

≫ [설명자료] 백두산 화산폭발하면 남한 최대 11조1천900억피해

(출처:국민안전처, 2015.05.21.)

≫ 애자일 프로젝트의 위험신호 40가지 (출처:CIO Korea, 2015.05.13)

≫ 죽어가는 개발 프로젝트 살리기 (출처:IDG, 2015.04.22)

≫ SW개발자 성장에 꼭 필요한 리뷰 (출처:ZDNet Korea, 2015.05.26)