<div id="readability-page-1" class="page"><div id="main">
                
      
  
  
  

  
  
    <div>
      <p><a href="/298">
        코딩 컨벤션과 소프트웨어 개발 원칙
      </a></p><div>
        <p><img src="https://t1.daumcdn.net/cfile/tistory/2373F54C579717200B">
        </p>
        <div>
            <p><i></i>
              <span>By 미스터머글</span>
            </p>
            <p><a href="/category/Dev%20Note">
              <i></i>
              <span>Dev Note</span>
            </a></p><p><i></i>
              <span>2023. 10. 24. 16:30</span>
            </p>
          </div>
      </div>
    </div>
    <div><figure data-ke-mobilestyle="widthOrigin" data-filename="Dz0GB3EU0AAWbAv.jpg" data-origin-width="600" data-origin-height="600"><span data-url="https://blog.kakaocdn.net/dn/ZoXB9/btsy4liRodP/ittfgTrGVfqoGPN2xtka10/img.jpg" data-lightbox="lightbox" data-alt="이런 일이 없도록 해야한다."><img src="https://blog.kakaocdn.net/dn/ZoXB9/btsy4liRodP/ittfgTrGVfqoGPN2xtka10/img.jpg" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-filename="Dz0GB3EU0AAWbAv.jpg" data-origin-width="600" data-origin-height="600"></span><figcaption>이런 일이 없도록 해야한다.</figcaption>
</figure>


<h2 data-ke-size="size26">코딩 컨벤션</h2>
<p data-ke-size="size16">코딩 컨벤션(Coding conventions). 그대로 해석하면 코딩 규약이다. <a href="https://ui.toast.com/fe-guide/ko_CODING-CONVENTION" target="_blank" rel="noopener">NHN 클라우드의 기술 블로그</a>에서는 코딩 컨벤션을 아래와 같이 정의하고 있다.</p>
<blockquote data-ke-style="style1"><span>읽고,&nbsp;관리하기&nbsp;쉬운&nbsp;코드를&nbsp;작성하기&nbsp;위한&nbsp;일종의&nbsp;코딩&nbsp;스타일&nbsp;규약</span></blockquote>

<p data-ke-size="size16">협업으로 개발을 할 때, 각자의 개발 스타일이 다르다보니 서로의 코드를 Merge할 경우에 혼선이 있을 수 있다. 이런 혼선을 막기 위해서 사전에 코딩 컨벤션을 정한다. 코딩 컨벤션을 강제하기 위해서 IDE의 기능을 사용하거나 Lint를 사용하기도 한다. 코딩 컨벤션은 코드 스타일을 정하는 것이기에 코딩 컨벤션을 이야기할 때 스타일이라는 단어가 키워드가 되기도 한다. IntelliJ에서 코딩 컨벤션을 설정할 때 아래와 같은 모습을 볼 수 있다. 이것은 코틀린 코딩 컨벤션을 정하는 방법이다.</p>

<figure data-ke-mobilestyle="widthOrigin" data-filename="스크린샷 2023-10-24 오후 2.12.24.png" data-origin-width="1208" data-origin-height="739"><span data-url="https://blog.kakaocdn.net/dn/Hmcx7/btsy39pnK4T/jra49q69xPTdZmwprGm5KK/img.png" data-lightbox="lightbox"><img src="https://blog.kakaocdn.net/dn/Hmcx7/btsy39pnK4T/jra49q69xPTdZmwprGm5KK/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-filename="스크린샷 2023-10-24 오후 2.12.24.png" data-origin-width="1208" data-origin-height="739"></span></figure>


<p data-ke-size="size16">보통 개발 협업할 때, 사전에 정해놓고 하는 경우가 많다. 그렇기에 특정 조직에서는 이런 코딩 컨벤션을 공유하기도 한다. 혹은 공식 문서에 공개되기도 한다.</p>
<ul data-ke-list-type="disc">
<li><a href="https://google.github.io/styleguide/javaguide.html" target="_blank" rel="noopener">Google Java Style Guide</a></li>
<li><a href="https://naver.github.io/hackday-conventions-java/" target="_blank" rel="noopener">캠퍼스&nbsp;핵데이&nbsp;Java&nbsp;코딩&nbsp;컨벤션</a></li>
<li><a href="https://developer.android.com/kotlin/style-guide?hl=ko" target="_blank" rel="noopener">안드로이드 - Kotlin&nbsp;스타일&nbsp;가이드</a></li>
<li><a href="https://kotlinlang.org/docs/coding-conventions.html" target="_blank" rel="noopener">Kotlin - Coding&nbsp;conventions</a></li>
<li><a href="https://github.com/airbnb/javascript" target="_blank" rel="noopener">Airbnb JavaScript Style Guide</a> (<a href="https://github.com/tipjs/javascript-style-guide" target="_blank" rel="noopener">한글</a>)</li>
</ul>

<h2 data-ke-size="size26">소프트웨어 개발 원칙</h2>
<p data-ke-size="size16">이런 코딩 컨벤션을 보게되면 겹치는 내용들이 보인다. 우연을 아닐터. 아마도&nbsp;<b>소프트웨어 개발 원칙</b>에서 파생된게 아닐까 생각된다. 소프트웨어 개발 원칙은 효율적이고 유지보수 가능한 소프트웨어를 개발하기 위한 체계적인 가이드라인을 제공하기 위해 등장했다. 몇몇 개념은 만든 사람이나 조직을 확인할 수 있지만 그렇지 않은 경우도 있다. 이는 소프트웨어 엔지니어링이 발전하면서 자연스럽게 자리잡아서 그런게 아닐까 싶다. 흔히 3대 원칙이라고 부르는 것을 보자.</p>

<figure data-ke-mobilestyle="widthOrigin" data-origin-width="660" data-origin-height="440"><span data-url="https://blog.kakaocdn.net/dn/D49nU/btsy05HN8JE/5z34fKlh2LKklgUY8U22v1/img.jpg" data-lightbox="lightbox"><img src="https://blog.kakaocdn.net/dn/D49nU/btsy05HN8JE/5z34fKlh2LKklgUY8U22v1/img.jpg" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="660" data-origin-height="440"></span></figure>

<h3 data-ke-size="size23">KISS (Keep it simple, stupid!)</h3>
<p data-ke-size="size16">이 원칙의 핵심은 단순함에 있다. <b>Stupid라고 할 정도로 단순하게.</b> 1960년 미 해군이 처음 언급 한 <a href="https://en.wikipedia.org/wiki/KISS_principle" target="_blank" rel="noopener">설계 원칙</a>이라고 한다. Kelly Johnson이라는 전투기 엔지니어가 팀에게 몇 가지 공구를 건네주며 이 공구만으로 현장에서 수리할 수 있어야 한다는 과제를 제시하면서 이 원칙을 사용했다. <span>메세지가 단순해서인지 변형된 문구도 여러개이다.<span>&nbsp;</span></span><span>"keep it super simple", "keep it simple, silly", "keep it short and simple". 현재 개발자 사이에서는 코드만 보고도 어떤 목적을 띄는 로직인지 이해할 수 있을 정도로 단순하게 만들어야 유지보수성이 높아진다라고 하면서 이 원칙에 설득력을 높이고 있다. 객체 지향 설계 원칙인 SOLID에서 S(단일책임원칙)와 일맥상통하다.</span></p>

<figure data-ke-mobilestyle="widthOrigin" data-origin-width="600" data-origin-height="315"><span data-url="https://blog.kakaocdn.net/dn/bWYyBL/btsy6f3Iq0h/PEnGVmU4wu2tMUZeoBjR51/img.jpg" data-lightbox="lightbox"><img src="https://blog.kakaocdn.net/dn/bWYyBL/btsy6f3Iq0h/PEnGVmU4wu2tMUZeoBjR51/img.jpg" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="600" data-origin-height="315"></span></figure>

<h3 data-ke-size="size23">DRY (Don't Repeat Yourself)</h3>
<p data-ke-size="size16">개발을 처음 배울 때부터 자주 듣는 얘기다. <b>중복을 피하라.</b> 단순히 코드뿐만 아니라 목적이나 데이터 등도 여기에 포함된다. &nbsp;Andy Hunt와 Dave Thomas의 저서인 <a href="https://search.shopping.naver.com/book/search?bookTabType=ALL&amp;pageIndex=1&amp;pageSize=40&amp;query=%EC%8B%A4%EC%9A%A9%EC%A3%BC%EC%9D%98%20%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%A8%B8&amp;sort=REL" target="_blank" rel="noopener">실용주의 프로그래머</a>에 등장한 개념이다. 모든 지식은 시스템 내에서 하나의 모호하지 않고 권위 있는 단일 표현을 가져야 한다라는 목적을 가진 <a href="https://en.wikipedia.org/wiki/Don%27t_repeat_yourself" target="_blank" rel="noopener">원칙</a>이다.&nbsp;</p>

<figure data-ke-mobilestyle="widthOrigin" data-origin-width="520" data-origin-height="292"><span data-url="https://blog.kakaocdn.net/dn/HJ7Tp/btsy034if2v/lyEiDCdYQdUE3bl1zUO9qK/img.png" data-lightbox="lightbox"><img src="https://blog.kakaocdn.net/dn/HJ7Tp/btsy034if2v/lyEiDCdYQdUE3bl1zUO9qK/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="520" data-origin-height="292"></span></figure>

<h3 data-ke-size="size23">YAGNI (You Ain't Gonna Need it)</h3>
<p data-ke-size="size16"><b>지금 필요없는 기능을 만들지 말라!</b> 내 생각엔 가장 중요한 원칙이라고 보인다. 불필요한 코드 혹은 데이터가 유지보수 과정에서 불필요한 노동력과 시간을 사용하게 만든다. 익스트림 프로그래밍(XP)에서 등장하는 <a href="https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it" target="_blank" rel="noopener">개념</a>이다. 익스트림 프로그래밍(XP) 소프트웨어 개발 방법론을 만든 사람 중 한명인 Ron&nbsp;Jeffries는 "항상 실제로 필요할 때 구현하고, 필요할 것이라고 예측할 때는 절대로 구현하지 말라."라고 했다.</p>

<hr contenteditable="false" data-ke-type="horizontalRule" data-ke-style="style3">

<p data-ke-size="size16">개발에 조금이라도 익숙해 졌을 때, 예쁘게 코딩하는 방법에 관심이 생긴다. 그 시점에서 이 원칙들을 들여다보면 도움이 되지 않을까. 관련 자료들을 읽다가 인상깊은 글이 있었다. 이 글을 공유하면서 마무리하겠다.</p>

<blockquote data-ke-size="size16" data-ke-style="style1"><span>컴퓨터 프로그램의 구조와 해석 중 'Programs should be written for people to read, and only incidectally for machine to execute' 프로그램은 사람들에게 읽히기 위한 목적으로 만들어져야 하고, 우연히 컴퓨터가 실행할 수 있다면 더욱 좋다.</span></blockquote>

<blockquote data-ke-style="style2">참고자료<br>- <a href="https://velog.io/@hyundong_kk/%EC%BD%94%EB%93%9C-%EC%BB%A8%EB%B2%A4%EC%85%98" target="_blank" rel="noopener">코드 컨벤션</a><br>- [Kotlin] 공식 코틀린 <a href="https://effortguy.tistory.com/257" target="_blank" rel="noopener">코딩 컨벤션</a> 소개<br>- 코틀린, 이렇게 <a href="https://medium.com/mj-studio/%EC%BD%94%ED%8B%80%EB%A6%B0-%EC%9D%B4%EB%A0%87%EA%B2%8C-%EC%9E%91%EC%84%B1%ED%95%98%EC%8B%9C%EB%A9%B4-%EB%90%A9%EB%8B%88%EB%8B%A4-94871a1fa646" target="_blank" rel="noopener">작성하시면</a> 됩니다 <br>- 소프트웨어 개발 3대 <a href="https://velog.io/@wngud4950/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B0%9C%EB%B0%9C-3%EB%8C%80-%EC%9B%90%EC%B9%99-KISS-YAGNI-DRY" target="_blank" rel="noopener">원칙</a> (KISS, YAGNI, DRY)<br>- 소프트웨어 개발 <a href="https://code-boki.tistory.com/89" target="_blank" rel="noopener">원칙들</a> 모음<br>- 좋은 API Response Body <a href="https://jojoldu.tistory.com/720" target="_blank" rel="noopener">만들기</a> (추천👍)</blockquote>

<p data-ke-size="size16">.</p></div>

    
    
    
    
    
      <div>
        
          <p><img src="https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&amp;fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FwFTbs%2FbtrNbWWT9ii%2Frx5v5nV1y6rYqqpTfXgLa0%2Fimg.jpg" alt="thumbnail image">
          </p>
        
        
      </div>
    
    
    
    
    
  
  

      
  
            </div></div>

개발자입니까?

코딩 컨벤션
코딩 컨벤션(Coding conventions). 그대로 해석하면 코딩 규약이다. NHN 클라우드의 기술 블로그에서는 코딩 컨벤션을 아래와 같이 정의하고 있다.
읽고, 관리하기 쉬운 코드를 작성하기 위한 일종의 코딩 스타일 규약
 
협업으로 개발을 할 때, 각자의 개발 스타일이 다르다보니 서로의 코드를 Merge할 경우에 혼선이 있을 수 있다. 이런 혼선을 막기 위해서 사전에 코딩 컨벤션을 정한다. 코딩 컨벤션을 강제하기 위해서 IDE의 기능을 사용하거나 Lint를 사용하기도 한다. 코딩 컨벤션은 코드 스타일을 정하는 것이기에 코딩 컨벤션을 이야기할 때 스타일이라는 단어가 키워드가 되기도 한다. IntelliJ에서 코딩 컨벤션을 설정할 때 아래와 같은 모습을 볼 수 있다. 이것은 코틀린 코딩 컨벤션을 정하는 방법이다.
 
 
보통 개발 협업할 때, 사전에 정해놓고 하는 경우가 많다. 그렇기에 특정 조직에서는 이런 코딩 컨벤션을 공유하기도 한다. 혹은 공식 문서에 공개되기도 한다.
Google Java Style Guide
캠퍼스 핵데이 Java 코딩 컨벤션
안드로이드 - Kotlin 스타일 가이드
Kotlin - Coding conventions
Airbnb JavaScript Style Guide (한글)
 
소프트웨어 개발 원칙
이런 코딩 컨벤션을 보게되면 겹치는 내용들이 보인다. 우연을 아닐터. 아마도 소프트웨어 개발 원칙에서 파생된게 아닐까 생각된다. 소프트웨어 개발 원칙은 효율적이고 유지보수 가능한 소프트웨어를 개발하기 위한 체계적인 가이드라인을 제공하기 위해 등장했다. 몇몇 개념은 만든 사람이나 조직을 확인할 수 있지만 그렇지 않은 경우도 있다. 이는 소프트웨어 엔지니어링이 발전하면서 자연스럽게 자리잡아서 그런게 아닐까 싶다. 흔히 3대 원칙이라고 부르는 것을 보자.
 
KISS (Keep it simple, stupid!)
이 원칙의 핵심은 단순함에 있다. Stupid라고 할 정도로 단순하게. 1960년 미 해군이 처음 언급 한 설계 원칙이라고 한다. Kelly Johnson이라는 전투기 엔지니어가 팀에게 몇 가지 공구를 건네주며 이 공구만으로 현장에서 수리할 수 있어야 한다는 과제를 제시하면서 이 원칙을 사용했다. 메세지가 단순해서인지 변형된 문구도 여러개이다. "keep it super simple", "keep it simple, silly", "keep it short and simple". 현재 개발자 사이에서는 코드만 보고도 어떤 목적을 띄는 로직인지 이해할 수 있을 정도로 단순하게 만들어야 유지보수성이 높아진다라고 하면서 이 원칙에 설득력을 높이고 있다. 객체 지향 설계 원칙인 SOLID에서 S(단일책임원칙)와 일맥상통하다.
 
DRY (Don't Repeat Yourself)
개발을 처음 배울 때부터 자주 듣는 얘기다. 중복을 피하라. 단순히 코드뿐만 아니라 목적이나 데이터 등도 여기에 포함된다.  Andy Hunt와 Dave Thomas의 저서인 실용주의 프로그래머에 등장한 개념이다. 모든 지식은 시스템 내에서 하나의 모호하지 않고 권위 있는 단일 표현을 가져야 한다라는 목적을 가진 원칙이다. 
 
YAGNI (You Ain't Gonna Need it)
지금 필요없는 기능을 만들지 말라! 내 생각엔 가장 중요한 원칙이라고 보인다. 불필요한 코드 혹은 데이터가 유지보수 과정에서 불필요한 노동력과 시간을 사용하게 만든다. 익스트림 프로그래밍(XP)에서 등장하는 개념이다. 익스트림 프로그래밍(XP) 소프트웨어 개발 방법론을 만든 사람 중 한명인 Ron Jeffries는 "항상 실제로 필요할 때 구현하고, 필요할 것이라고 예측할 때는 절대로 구현하지 말라."라고 했다.
 
 
개발에 조금이라도 익숙해 졌을 때, 예쁘게 코딩하는 방법에 관심이 생긴다. 그 시점에서 이 원칙들을 들여다보면 도움이 되지 않을까. 관련 자료들을 읽다가 인상깊은 글이 있었다. 이 글을 공유하면서 마무리하겠다.
 
컴퓨터 프로그램의 구조와 해석 중 'Programs should be written for people to read, and only incidectally for machine to execute' 프로그램은 사람들에게 읽히기 위한 목적으로 만들어져야 하고, 우연히 컴퓨터가 실행할 수 있다면 더욱 좋다.
 
참고자료
- 코드 컨벤션
- [Kotlin] 공식 코틀린 코딩 컨벤션 소개
- 코틀린, 이렇게 작성하시면 됩니다 
- 소프트웨어 개발 3대 원칙 (KISS, YAGNI, DRY)
- 소프트웨어 개발 원칙들 모음
- 좋은 API Response Body 만들기 (추천 )
 
.