기본 프로그래밍 원칙 (Basic Programming Principles) : 10가지

10 기본 프로그래밍 원칙 모든 프로그래머가 따라야 함

10 Basic Programming Principles Every Programmer Must Follow

 

누구나 코드를 작성할 수 있습니다. 그러나 좋은 코드? 그것이 어려운 곳입니다.

 

우리는 모두 스파게티 코드, 방대한 if-else 체인, 하나의 변수 만 변경함으로써 깨질 수있는 전체 프로그램, 난독 화 된 것처럼 보이는 기능 등등에 대한 공포 이야기를 들었습니다. 그것은 당신이 벨트 아래 프로그래밍 경험의 한 학기만으로 배송 가능한 제품을 만들려고 할 때 일어납니다.

 

작동하는 코드를 작성하지 마십시오 . 앞으로도 어느 시점에서든 소프트웨어 작업을 끝낼 수있는 모든 사람이 자신 이 관리 할 수 있는 코드를 작성 하십시오. 이를 위해 귀하의 행동을 정리하는 데 도움이되는 몇 가지 원칙이 있습니다.

 

 

 

1. KISS

 

"간단하게, 바보"원칙은 거의 모든 생명의, 그러나 중간에 대형 프로그래밍 프로젝트에서 특히 필요한입니다 적용됩니다.

 

처음에 원하는 것을 만들 때 범위를 정의 할 때 시작됩니다. 게임 개발에 열정을 갖고 있다고해서 다음 월드 오브 워크래프트 또는 그랜드 도용 자동차를 만들 수있는 것은 아닙니다 . 당신이 충분히 단순화했다고 생각할 때, 한 단계 더 단순화하십시오 - 피쳐 크립은 피할 수 없으므로 작게 시작하십시오.

 

그러나 코딩이 시작된 후에도 간단하게 유지하십시오. 복잡한 코드는 설계 및 작성 시간이 오래 걸리며 버그 및 오류가 발생하기 쉽고 나중에 수정하기가 더 어렵습니다. 앙투안 드 생 텍쥐페리 (Antoine de Saint-Exupery)의 현명한 말로, "완벽 함을 얻을 수 있습니다. 추가 할 것이 없을 때가 아니라, 떠날 것이 없을 때가 있습니다."

 

 

 

2. DRY

 

"자신을 반복하지 않는다"원칙은 깨끗하고 쉬운 수정 코드에 대한 매우 중요합니다. 코드를 작성할 때 데이터 중복 및 논리 중복을 방지해야합니다. 동일한 코드 조각이 반복해서 쓰여지는 것을 보게되면,이 원리를 깨뜨리는 것입니다.

 

DRY 코드의 반대는 WET 코드입니다 : "모든 것을 두 번 쓰십시오"(또는 "모든 사람들의 시간 낭비"). WET 코드를 진단하는 가장 좋은 방법 중 하나는 스스로에게 질문하는 것입니다. 프로그램의 동작을 어떤 식 으로든 변경하려면 몇 개의 코드 영역을 수정해야합니까?

 

Podcast 디렉토리 앱을 작성한다고 가정합니다. 검색 페이지에는 팟 캐스트의 세부 정보를 가져 오는 코드가 있습니다. 팟 캐스트 페이지에는 해당 팟 캐스트의 세부 정보를 가져 오는 코드가 있습니다. 즐겨 찾기 페이지에서 동일한 가져 오기 코드. 모든 것을 하나의 함수로 추상화하여 나중에 편집해야하는 경우 한 곳에서 모두 수행 할 수 있도록하십시오.

 

 

 

3. Open / Closed (열기/닫기)

 

Java로 객체를 작성하든 Python으로 모듈을 작성하든 관계없이 코드 를 확장으로 열어서 코드 를 수정하여 닫을 수 있습니다. 이것은 모든 종류의 프로젝트에 적용되지만, 다른 사람들이 사용할 수있는 라이브러리 나 프레임 워크를 공개 할 때 특히 중요합니다.파이썬 , 코드 작성을 목표로해야합니다.

 

예를 들어 GUI 프레임 워크를 유지 관리한다고 가정합니다. 최종 사용자가 릴리스 된 코드를 직접 수정하고 통합 할 것을 기대하면서 그대로 공개 할 수 있습니다. 하지만 4 개월 후에 주요 업데이트를 릴리스하면 어떻게됩니까? 그들이했던 모든 작업을 버리지 않고 추가 기능을 어떻게 구현합니까?

 

대신 직접 수정 을 방지 하고 확장을 권장 하는 코드를 릴리스하십시오 . 이렇게하면 핵심 동작과 수정 된 동작이 분리됩니다. 혜택? 안정성 (사용자가 실수로 핵심 동작을 중단 할 수 없음) 및 유지 관리 용이성 (사용자는 확장 된 코드에 대해서만 염려함) 열기 / 닫기 원칙은 좋은 API를 만드는 열쇠 입니다.

 

 

4. Composition > Inheritance (작문> 상속)

 

원칙 "상속을 통해 구성" 복잡한 행동 개체 상태는 개별 행동을 객체의 인스턴스를 포함보다는 클래스를 상속하고 새로운 행동을 추가하여이를 수행해야합니다.

 

상속에 대한 신뢰가 두 가지 중요한 문제로 이어질 수 있습니다. 첫째, 상속 계층 구조가 눈 깜짝 할 사이에 엉망이 될 수 있습니다. 둘째, 특히 다른 상속 브랜치의 한 상속 브랜치에서 동작을 구현하려는 경우에는 특수 케이스 동작을 정의하기위한 유연성이 떨어집니다.

 

작문은 작성하기가 훨씬 쉽고, 유지 보수가 쉽고, 정의 할 수있는 행동의 종류에 거의 무한한 유연성을 허용합니다. 각각의 개별 비헤이비어는 자체 클래스이며 개별 비헤이비어를 결합하여 복잡한 비헤이비어를 만들 수 있습니다.

 

 

 

5. Single Responsibility (단일 책임)

 

단일 책임의 원칙은 프로그램의 모든 클래스 또는 모듈이 특정 기능을 하나 개의 비트를 제공하는 자신을 염려해야한다고 말한다. 로버트 마틴 (Robert C. Martin)은 "수업은 변화해야 할 한 가지 이유가 있어야합니다."라고 말했습니다.

클래스와 모듈은 종종 이런 방식으로 시작하지만 기능 및 새로운 비헤이비어를 추가하면 수백 또는 수천 줄의 코드를 사용하는 신 클래스 및 신 모듈로 쉽게 진화 할 수 있습니다. 이 시점에서 더 작은 클래스와 모듈로 나누어야합니다.

 

 

 

6. Separation of Concerns (우려의 분리)

 

우려 원칙 의 분리는 단일 책임 원리와 같지만보다 추상적 인 수준이다. 본질적으로, 프로그램은 많은 다른 중첩되지 않는 캡슐화를 갖도록 설계되어야하며, 이러한 캡슐화는 서로에 대해 알지 못한다.

 

잘 알려진 예로는 프로그램을 세 가지 영역 즉, 데이터 ( "모델"), 논리 ( "컨트롤러") 및 최종 사용자가 보는 영역으로 구분하는 MVC (Model-View-Controller) 패러다임이 있습니다. ("전망"). MVC의 변형은 오늘날 가장 널리 사용되는 웹 프레임 워크에서 일반적입니다.

 

 

 

예를 들어 데이터베이스에 데이터를로드하고 저장하는 코드는 웹에서 데이터를 렌더링하는 방법을 알 필요가 없습니다. 렌더링 코드는 최종 사용자로부터 입력을받을 수 있지만, 그 입력을 처리를 위해 로직 코드로 전달한다. 각 부분은 스스로 처리합니다.

 

모듈화 된 코드로 유지 관리가 훨씬 쉬워집니다. 그리고 앞으로 모든 렌더링 코드를 다시 작성해야 할 경우 데이터가 저장되거나 로직이 처리되는 것을 걱정하지 않고 렌더링 코드를 다시 작성할 수 있습니다.

 

 

 

7. YAGNI

 

"당신이 그것을 필요 않을거야"원칙은 당신이 기능을위한 코드를 안 생각입니다 수 있습니다 미래에 필요가 없습니다. 기회는 필요 없으며 시간 낭비 일뿐 아니라 그뿐만 아니라 코드의 복잡성을 불필요하게 증가시킵니다.

 

이것을 KISS 원칙의 특정 적용으로 간주하고 DRY 원칙을 너무 심각하게 생각하는 사람들에 대한 응답으로 볼 수 있습니다. 종종 경험이 부족한 프로그래머는 WET 코드를 피할 수있는 가장 추상적이고 포괄적 인 코드를 작성하려고하지만 너무 많은 추상화는 비 대한 유지가 불가능한 코드로 끝납니다.

 

트릭은 필요할 때만 DRY 원리를 적용하는 것입니다. 코드 덩어리가 반복해서 쓰여지는 것을 알아 채면, 코드를 추상화하십시오.하지만 코드 조각이 반복해서 쓰여질 것이라고 생각 하지 마십시오 . 더 많은 시간, 그렇지 않을 것입니다.

 

 

 

8. Avoid Premature Optimization (조기 최적화를 피하십시오.)

 

없는 조기 최적화 원리는 YAGNI의 원리와 유사하다. 차이점은 YAGNI 가 필요하기 전에 행동 을 구현 하는 경향을 다루는 반면이 원칙은 알고리즘 이 필요하기 전에 속도 를 높이는 경향을 다루는 것 입니다.

 

조숙 한 최적화의 문제는 프로그램의 병목 현상이 사실 이후에 어디까지 있는지 절대 알 수 없다는 것입니다. 물론 추측 할 수 있으며 가끔은 옳을 수도 있습니다. 그러나 더 자주는 아니지만, 생각보다 느리게하지 않거나 예상대로 호출하지 않는 기능의 속도를 높이려고 귀중한 시간을 낭비 할 것입니다.

가능한 한 획기적인 단계에 도달 한 다음 코드 를 분석하여 실제 병목 현상을 식별 하십시오.

 

 

 

9. Refactor, Refactor, Refactor

 

경험이없는 프로그래머로 받아 들여야하는 가장 어려운 진리 중 하나는 처음에는 코드가 거의 제대로 나오지 않는다는 것 입니다. 그 반짝이는 새 기능을 구현할 때 느낄 수도 있지만 프로그램이 복잡해지면서 초기 기능을 어떻게 작성했는지에 따라 향후 기능이 방해받을 수 있습니다.

 

코드베이스는 끊임없이 진화하고 있습니다. 코드의 전체 덩어리를 다시 보거나 재 작성하거나 심지어 재 설계하는 것이 정상적 일뿐만 아니라 정상적으로 수행 할 수 있습니다. 당신은 당신의 프로젝트의 요구 사항에 대한 자세한 알고 지금 당신이에서했을 때보다 시작 , 당신은 정기적으로 이전 코드를 리팩토링이 새로 얻은 지식을 사용해야합니다.

 

항상 큰 프로세스 일 필요는 없습니다. 이 단어로 사는 보이 스카우트 (Boy Scouts of America)의 한 페이지를 가져 가십시오. "캠프장을 찾은 것보다 더 깨끗하게 둡니다."오래된 코드를 확인하거나 수정해야하는 경우 항상 정리하고 더 나은 상태로 두십시오.

 

 

 

10. Clean Code > Clever Code

 

깨끗한 코드에 대해 말하자면, 자아를 문 앞에두고 영리한 코드 작성을 잊어 버리십시오 . 당신은 내가 말하는 것에 대해 알고 있습니다. 해결책보다 수수께끼처럼 보이고 단지 당신이 얼마나 똑똑한 지 보여주기 위해 존재하는 코드입니다. 사실, 아무도 정말 신경 쓰지 않습니다.

 

영리한 코드의 한 가지 예는 최대한 많은 논리를 한 줄에 채우는 것입니다. 또 다른 예는 언어의 복잡함을 이용하여 이상하지만 기능적인 문장을 작성하는 것입니다. 코드를 보면서 누군가가 "잠깐, 뭐라고?"라고 말할 수있는 모든 것.

 

좋은 프로그래머와 읽을 수있는 코드가 함께합니다. 필요한 경우 주석을 남겨 둡니다. Python과 같은 언어 또는 Google과 같은 회사의 지시에 따라 스타일 가이드를 준수하십시오. 언어 별 관용구를 관찰하고 파이썬에서 Java 코드 작성을 중단하거나 그 반대의 경우도 마찬가지입니다.

 

 

 

해외 원문 : http://www.makeuseof.com/tag/basic-programming-principles/