Blob Blame History Raw
<?xml version="1.0" encoding="utf-8"?>
<page xmlns="http://projectmallard.org/1.0/" xmlns:its="http://www.w3.org/2005/11/its" type="topic" id="writing-good-code" xml:lang="ko">

  <info>
    <link type="guide" xref="index#general-guidelines"/>
    
    <credit type="author copyright">
      <name>Federico Mena-Quintero</name>
      <email its:translate="no">federico@gnome.org</email>
      <years>2013</years>
    </credit>
    <credit type="author copyright">
      <name>Miguel de Icaza</name>
      <email its:translate="no">miguel@gnome.org</email>
    </credit>
    <credit type="author copyright">
      <name>Morten Welinder</name>
      <email its:translate="no">mortenw@gnome.org</email>
    </credit>

    <include xmlns="http://www.w3.org/2001/XInclude" href="cc-by-sa-3-0.xml"/>

    <desc>프로젝트의 보존성을 유지하는 바람직하고, 가독성 높은 코드</desc>
  
    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
      <mal:name>조성호</mal:name>
      <mal:email>shcho@gnome.org</mal:email>
      <mal:years>2016, 2017.</mal:years>
    </mal:credit>
  </info>

  <title>바람직한 코드 작성의 중요성</title>

  <p>그놈은 매우 야심적인 자유 소프트웨어 프로젝트이며, 상호간 더 혹은 덜 독립적인 수많은 소프트웨어 패키지로 이루어져있습니다. 그놈에서 작업하는 수많은 결과물은 자발적인 봉사자가 만들어냅니다. 그놈 프로젝트에서 전일 내지는 시간제로 일하는 여러 사람이 있지만, 기여자의 상당수가 봉사자로 이루어져있습니다. 프로그래머는 때때로 오고가며, 그놈 프로젝트를 진행하는 각기 다른 상당한 시간동안 기여할 수 있습니다. “실 세계”에서 여러 사람의 책임감은 변화를 이끌어낼 것이며, 그놈에 상당한 시간을 들일 수 있는 만큼 노력이 반영됩니다.</p>

  <p>소프트웨어 개발은 상당한 시간동안 공을 들이 노력으로 이루어집니다. 이게 대부분 여러 시간제 봉사자가 자체적으로 거대한 프로젝트를 시작할 수 없는 이유입니다. 기존의 프로젝트에 기여하면, 결과가 즉시 나타나고 바로 활용할 수 있기 때문에 더 쉬우며, 기여 보상을 더 많이 받을 수 있습니다.</p>

  <p>따라서, 사람이 기존 프로젝트에 쉽게 기여할 수 있으려면 이 점이 중요하겠다는 결론을 내렸습니다. 프로그램 코드를 쉽게 읽고, 이해하고, 수정하고, 관리할 수 있는지 여부를 확인하는 길이 한 방법입니다.</p>

  <p>지저분한 코드는 알아보기 힘들며, 코드가 어떤 동작을 하는지 알아볼 수 없다면 흥미를 잃어버립니다. 또한 프로그래머가 코드를 빨리 이해하여 버그 수정 및 개선에 적은 시간을 들이는 행동으로 기여를 시작할 수 있게 하는게 중요합니다. 소스 코드는 <em>의사 소통</em>의 한 유형이며, 컴퓨터보단 사람을 위합니다. 누군가가 오탈자, 잘못된 문법, 엉성한 문장 부호가 있는 소설을 읽기 싫어하는 것처럼, 프로그래머도 다른 프로그래머가 쉽게 이해하고 수정할 수 있는 바람직한 코드를 작성하도록 노력해야합니다.</p>

  <p>바람직한 코드의 품질을 확보하려 지켜야 할 몇가지 중요한 사항이 있습니다:</p>

  <terms>
    <item>
      <title>명확성</title>
      <p>깔끔한 코드는 최소한의 노력으로도 읽기 쉽습니다. 사람이 쉽게 이해하기 시작하도록 해줍니다. 코드 작성 방식 그 자체(중괄호 위치, 들여쓰기, 변수 이름) 및, 코드의 실제 제어문 흐름이 깔끔한 코드 구성 개념에 해당합니다.</p>
    </item>

    <item>
      <title>일관성</title>
      <p>일관된 코드는 프로그램이 어떻게 동작하는지 쉽게 이해할 수 있게 해줍니다. 일관성 있는 코드를 볼 때, 잠재적인 몇 가지 가정을 두고 코드 동작을 기대하기 때문에 코드를 쉽고 안전하게 수정할 수 있습니다. 다른 곳에 있는 동일<em>해보이는</em> 코드는, 마찬가지로 동일하게 <em>동작</em>해야합니다.</p>
    </item>

    <item>
      <title>확장성</title>
      <p>범용 코드는 많은 코드를 하드코딩했을 경우의 특수 목적 코드보다 재활용 및 수정이 쉽습니다. 누군가 프로그램에 새 기능을 추가하려고 하면 코드 규모를 쉽게 확장할 수 있게 설계 했을 경우 분명히 쉽게 처리할 수 있습니다. 이 방식으로 코드를 작성하지 않으면 여러 사람이 기능을 추가할 때 난잡파게 뜯어 고칠수밖에 없게 만듭니다.</p>
    </item>

    <item>
      <title>정확성</title>
      <p>마지막으로 올바르게 설계한 코드는 버그를 걱정하지 않고 적은 시간을 들일 수 있게 하며, 프로그램 기능 개선에 더 많은 시간을 들일 수 있게 합니다. 사용자는 그 어느 누구도 오류로 갑작스럽게 끝나는 프로그램을 좋아하지 않기에 올바른 코드를 선호합니다. 올바르고 안전하게 작성한 코드(예: 일관된 상태를 유지하는 프로그램인지 분명하게 확인해 본 코드)는 대부분의 어이없는 버그를 막아줍니다.</p>
    </item>
  </terms>

  <section id="book-references">
    <title>참고 서적</title>

    <list>
      <item><p>Steve McConnell 저, <link href="http://www.cc2e.com">Code Complete</link>.</p></item>
      <item><p>Martin Fowler 저, <link href="http://martinfowler.com/books/refactoring.html"> Refactoring: Improving the Design of Existing Code </link>.</p></item>
      <item><p>Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides 저, <link href="http://en.wikipedia.org/wiki/Design_Patterns"> Design Patterns: Elements of Reusable Object-Oriented Software </link>.</p></item>
      <item><p>Arthur Riel 저, <link href="http://astore.amazon.com/gnomestore-20/detail/020163385X"> Object-Oriented Design Heuristics </link>.</p></item>
    </list>
  </section>
</page>