[Developer] 초보 개발자

프로그래밍 실력을 한층 높여 줄 개발 3대 원칙! KISS 란? DRY란? YAGNI 란?

OnceBH 2021. 2. 21. 05:25
반응형

프로그래밍 실력을 한층 높여 줄 개발 3대 원칙! KISS 란? DRY 란? YAGNI 란?

 

프로그래밍이라는 것은 어떠한 생각이나 아이디어를 실체화

시키는 작업이라고 나름 개인적으로 생각합니다.

아이디어를 실체화시키려면 일단 처음 이러한 아이디어를

시각화시킬 필요가 있습니다.

이를 위해 UML을 예전에 언급한 적이 있죠.

UML은 정말 필요하고 유용하니 꼭 알아두시고 몇몇 자주 사용되는

다이어그램들을 알아 두시는 것이 좋습니다.

 

목차

 

  1. KISS
  2. DRY
  3. YAGNI
  4. 마치며

 

자 이제 아이디어를 시각화시켰고,

그에 필요한 기능, 특징들을 결정했습니다.

이제 우리는 실질적인 프로그래밍 단계에 서있습니다.

사실 코드를 작성하는데 무슨 방법이 필요하겠습니까?

오류 없이 잘 작동한다면 일단 그걸로 별 탈이 없겠죠.

하지만 그럼에도 불구하고 이러한 원칙들이 왜 필요한 것일까요?

 

예전에도 언급했지만 일단 개발자는 게을러야 합니다.

너무 게으른 나머지 똑같은 일을 반복하지 않으려 노력해야 합니다.

그리고 너무 게으른 나머지 코드를 간단히 짜도록 숙련되어야 합니다.

이게 무슨 말일까요? 왜 게으른데 이렇게 노력하고 숙련해야 할까요??

우리 코드를 최대한 간단히 그리고 직관적으로 짜야합니다.

이로 인해 혹여나 있을 이후의 업데이트, 업그레이드를 더 짜임새 있게

준비하고 대비할 수 있습니다.

프로그래밍이라는 것은 코드를 작성하는 행위이지만, 프로그래머라면,

프로그램을 작성하는 것뿐 아니라 그에 맞는 후작업들도 생각하고, 대비해야 합니다.

그리고 이러한 프로젝트가 나 혼자만의 프로젝트가 아닌 팀 프로젝트라면,

더더욱 이러한 스킬이 요구될 것입니다.

 

이를 위해 3가지의 기본적인 원칙을 알아보고자 합니다.

 

1. KISS

 

Keep It Simple Stupid, Keep It Small and Simple, Keep It Short and Simple의 약자입니다.

말 그대로 코드를 짧고 간단하게 짜라는 말입니다.

코드를 작성하는데 가능한 한 간단하고 쉽게 짜는 것이 훨씬 효율적이라는 것을 나타내는 

원칙이지 않을까 싶습니다.

즉 코드를 짜는 과정에서 필요한 것과 불필요한 것을 나누어 코드를 최적화하라는 것입니다.

이미 언급했듯이 코드를 가능한 한 짧고 직관적으로 짜는 노력이 필요합니다.

단순하고 쉬울수록 이해하기 쉽고 또한 버그를 찾아내기도 쉽습니다.

코드가 너무 복잡하고 스파게티 저럼 꼬여있다면,

작성하는 순간도 곤욕이고 후에 업데이트나 버그를 찾는 데는 몇 배로 곤욕입니다.

처음부터 코드를 짧고 최적화하게 짜는 것은 상당히 힘듭니다.

그렇기에 가능한 한 가능하게 짧게 짜도록 노력하시고 후에 언제든지

코드를 수정하실 수 있으니 처음부터 완벽한 코드를 짜려고 하지는 마세요.

스트레스만 받습니다.

 

 

2. DRY

 

Do not Repeat Yourself의 약자입니다.

즉 같은 행동을 반복하지 말라는 뜻입니다.

코드를 작성하는데 불필요하게 같은 작업을 반복하는 코드를

여러 번 사용 할 이유가 없습니다.

여러번 같은 일을 반복하게 된다면, 언제든지 하나의 함수에

각각 상황에 따른 파라미터를 제공함으로써 얼마든지 다양하게 사용

가능합니다.

또한 한 가지 함수에 여러 처리를 기대하지 마시기 바랍니다.

하나에 함수는 한가지 일만 해도 충분합니다.

하나의 함수에 여러 처리를 기대한다면 함수 자체도 불명확해지고,

상황이 조금만 바뀌면 또 비슷한 함수를 만들어야 될 가능성이 커집니다.

기억합시다. 하나의 함수에는 하나의 처리만 하는 걸로.

 

3. YAGNI

 

You Ain't Gonna Need It의 약자입니다.

즉 정말 필요한 코드만 작성하라는 것입니다.

아까 후의 업데이트 혹은 업그레이드를 위해 코드를 간결하고 명확하게

짤 필요가 있다고 했습니다.

하지만 이는 절대 미래에 언젠가 쓰일지 모르는 기능을 미리 준비하고

대비하라는 뜻이 아닙니다.

우리는 현재 지금 당장 필요한 기능들을 간결하고 명확하게만 짜는데

집중해야 합니다. 미래를 준비한다고 이런저런 불필요한 코드를 미리

작성한다면 단순히 장황하고 코드만 복잡해집니다.

미래에 어떠한 업데이트, 버그 픽스, 업그레이드를 대비하라는 것은

지금 필요한 코드를 짧고 명확하게 짜 놓아 언젠가 필요할 후 작업을

편하고 짜임새 있게 가능하도록 만드는 것이지 후에 필요할 어떠한 작업을

미리 준비하라는 뜻이 아닙니다.

정말 당장 필요하고 사용되는 기능들만 작성하세요!

 

 

 

4. 마치며

 

오늘은 3가지 원칙을 알아보았는데, 그다지 어렵지 않은 원칙입니다.

사실 이러한 원칙은 직접 일하고 프로젝트에 참여하다 보면

자연스럽게 배우게 되고 터득하는 부분입니다.

개인적인 생각이지만 혼자서 공부하는 것도 좋지만,

어리숙하더라도 협업을 도전해보시는 게 참 많은 도움이 될 거라

믿습니다. 협업을 통해서 다른 사람은 어떻게 코드를 작성하는지,

내 코드를 다른 팀원과 공유해 피드백을 받을 수 있을 것입니다.

 

또한 꾸준히!! 언어와 친해지고 익숙해지는 것일 것입니다.

사용하는 언어나 프레임워크, 라이브러리의 도큐먼트와 친해지는 것도

상당히 도움이 많이 됩니다. 인터넷에서 코드를 단순히 찾아

복사 붙여 넣기 하여 동작하는 프로그램을 만드는 것도 좋지만,

사용하기 전에 왜 이렇게 동작하는지 고민해보시는 것도 정말 좋을 것 같네요.

언어, 프레임워크, 라이브러리에 따라 어느 정도 정형화된 방법은 있을 것입니다.

하지만 이 또한 회사, 심지어 팀에 따라 조금씩 다른 방법을 사용하기도 합니다.

그러니 처음부터 너무 이러한 원칙을 지키려 스트레스받으시지 마시고,

처음에는 작성하고 자신만의 스타일을 만드신 뒤 협업에 필요한 방법에 따라

자신의 스타일을 접목시키면 좋지 않을까 싶습니다.

 

항상 처음이 어렵습니다.

매 순간이 고비 같고, 못할 것 같아도 뒤 돌아보면 나름 별게 아니었을 일들이 

대부분 일 것입니다. 항상 도전하시고 모르는 일, 새로운 일에 거부감, 두려움을

갖지 마세요. 항상 도전하세요!

 

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

반응형