<div id="readability-page-1" class="page"><section><h2 id="요약"><a href="#%EC%9A%94%EC%95%BD" aria-label="요약 permalink"></a>요약</h2>
<p>코딩을 어떻게 하면 좋은 코드가 나올까? SOLID, DRY, YAGNI 등 많은 코딩, 디자인
가이드가 있다.</p>
<hr>
<h2 id="solid"><a href="#solid" aria-label="solid permalink"></a>SOLID</h2>
<p><strong>Abstraction, One Behavior class, Encapsulation</strong></p>
<ul>
<li>S 하나의 클래스는 한 가지 일만, 변경하기 위한 이유는 하나만 갖고 있어야 한다.</li>
<li>O 확장에는 열려있고, 변화에는 닫혀 있어야 한다</li>
<li>L 하위 클래스는 기존 클래스와 치환되어도 동작 해야 한다</li>
<li>I 인터페이스를 작게 하고, 클라이언트가 사용 안하는 함수는 공급도 안하게 한다.</li>
<li>D 추상화에 의존해라. 구체적인 것 말고.</li>
</ul>
<h4 id="single-reason"><a href="#single-reason" aria-label="single reason permalink"></a>Single reason</h4>
<p>변경하기 위한 이유는 버그 수정이나 리팩토링일 때가 아니라 디자인 설계 시의 얘기</p>
<h4 id="dip를-통해-외부-라이브러리-대신-임의의-객체를-만들어-테스트하기-용이해진다"><a href="#dip%EB%A5%BC-%ED%86%B5%ED%95%B4-%EC%99%B8%EB%B6%80-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC-%EB%8C%80%EC%8B%A0-%EC%9E%84%EC%9D%98%EC%9D%98-%EA%B0%9D%EC%B2%B4%EB%A5%BC-%EB%A7%8C%EB%93%A4%EC%96%B4-%ED%85%8C%EC%8A%A4%ED%8A%B8%ED%95%98%EA%B8%B0-%EC%9A%A9%EC%9D%B4%ED%95%B4%EC%A7%84%EB%8B%A4" aria-label="dip를 통해 외부 라이브러리 대신 임의의 객체를 만들어 테스트하기 용이해진다 permalink"></a>DIP를 통해 외부 라이브러리 대신 임의의 객체를 만들어 테스트하기 용이해진다.</h4>
<p>테스트 시에 외부 API의 기능을 테스트하는게 아니라 내 구현을 테스트한다.</p>
<h2 id="oop"><a href="#oop" aria-label="oop permalink"></a>OOP</h2>
<ul>
<li><strong>Encapsulation, Composition, Inheritance, Delegation, Polymorphism, Open recursion</strong></li>
<li>same Input, should same output</li>
<li>
<p>Encapsulation = Module?</p>
<ul>
<li>Encapsulation is hide the value</li>
</ul>
</li>
</ul>
<h4 id="폴리모피즘"><a href="#%ED%8F%B4%EB%A6%AC%EB%AA%A8%ED%94%BC%EC%A6%98" aria-label="폴리모피즘 permalink"></a>폴리모피즘</h4>
<p>객체 생성 시 고정된 객체를 만드는 것이 아니라 기준만 만들고 실제 구현은 각
상황에 맞게 수정할 수 있게 하는 것</p>
<p>인터페이스나 추상클래스를 이용하여 상속해 여러 객체를 하나의 기준으로 만드는 것
그리고 이를 이용하여 오버라이딩 하여 각 객체에 맞게 재구현할 수 있는 것</p>
<p>하나의 객체를 다양한 방법으로 사용할 수 있게 하는 것</p>
<h4 id="coupling-vs-cohesion"><a href="#coupling-vs-cohesion" aria-label="coupling vs cohesion permalink"></a>coupling vs cohesion</h4>
<p>내부에서의 변수들의 활용이 잘되면 응집도가 높다고 한다
클래스의 변수를 메소드가 여러개 잘 사용하면 응집도가 높다고 볼 수 있다
각 객체 간 연결이 느슨하게 되있으면 결합도가 낮다고 한다</p>
<h2 id="functional-programming"><a href="#functional-programming" aria-label="functional programming permalink"></a>Functional Programming</h2>
<p>불변성</p>
<h2 id="coding-convention"><a href="#coding-convention" aria-label="coding convention permalink"></a>Coding Convention</h2>
<p>회사의 컨벤션 룰을 따르자. lint도 설정하고</p>
<ul>
<li>python -- underscore</li>
<li>golang -- camel</li>
<li><code>-</code> vs <code>_</code></li>
<li><code>tab</code> vs <code>space</code></li>
</ul>
<h2 id="clean-code"><a href="#clean-code" aria-label="clean code permalink"></a>Clean Code</h2>
<ul>
<li>Robert C. Martin</li>
<li><a href="https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29">https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29</a></li>
<li>Meaningful naming</li>
</ul>
<h2 id="tdd"><a href="#tdd" aria-label="tdd permalink"></a>TDD</h2>
<ul>
<li>at least make test code.</li>
<li>Test, Log(error handling), API</li>
</ul>
<h4 id="why-test"><a href="#why-test" aria-label="why test permalink"></a>Why Test?</h4>
<ul>
<li>code make concrete</li>
<li><a href="https://drive.google.com/file/d/13r0fkQbcbd_2DG34l9Mm5VMRk8ewIImS/view?usp=sharing">The Art of Software Testing</a></li>
</ul>
<h4 id="test"><a href="#test" aria-label="test permalink"></a>test</h4>
<ul>
<li>boundary check</li>
</ul>
<h4 id="bdd-ddd"><a href="#bdd-ddd" aria-label="bdd ddd permalink"></a>BDD, DDD</h4>
<h4 id="unit-testing-system-testing"><a href="#unit-testing-system-testing" aria-label="unit testing system testing permalink"></a>unit testing, system testing</h4>
<ul>
<li><a href="https://www.geeksforgeeks.org/difference-between-unit-testing-and-system-testing/">https://www.geeksforgeeks.org/difference-between-unit-testing-and-system-testing/</a></li>
<li>unit testing</li>
<li>single module base,</li>
<li>system testing</li>
<li>depends specific requirement, totally test</li>
</ul>
<h4 id="refactoring"><a href="#refactoring" aria-label="refactoring permalink"></a>Refactoring</h4>
<ul>
<li>변화는 향상을 가져온다. 마치 책의 퇴고처럼</li>
<li>작가가 퇴고를 거듭하며 더 좋은 글이 되는 것처럼 리팩토링을 통해 더 나은 코드를 만들 수 있다</li>
<li>리팩토링을 두려워하지 말자</li>
</ul>
<h4 id="유닛-테스트"><a href="#%EC%9C%A0%EB%8B%9B-%ED%85%8C%EC%8A%A4%ED%8A%B8" aria-label="유닛 테스트 permalink"></a>유닛 테스트</h4>
<p>유닛 테스트를 어노테이션을 만들어서 입력값만 지정해서 원하는 출력값이 나오는지
확인하면 테스트와 실제 코드가 같이 있게 되어 좋지 않을까?
결과의 멱등성을 유도하는 방향으로 함수를 작성하고.</p>
<pre><code>@Test(input1:'1',input2:'2')
def add(a int, b int):
    return a + b
</code></pre>
<p>복잡한 로직이 필요하거나, 함수 실행 전에 선언해야하는 것들이 있으면 처리가
힘들겠다.</p>
<pre><code>Square s = Square{}
s.SetLength(5)

class Square():
    len = ''
    @Test(what input can in here?)
    def SetLength(i int):
        len = i
</code></pre>
<p>테스트코드를 먼저 적고 테스트 코드만 통과할 정도의 함수만 작성하고 문제가 생기면
추가하는 방식으로 한다</p>
<ul>
<li>주먹구구와 점진적 개선의 차이는 뭘까</li>
</ul>
<h4 id="기능이-전반적으로-바뀌는-경우-ab-테스트를-해야한다"><a href="#%EA%B8%B0%EB%8A%A5%EC%9D%B4-%EC%A0%84%EB%B0%98%EC%A0%81%EC%9C%BC%EB%A1%9C-%EB%B0%94%EB%80%8C%EB%8A%94-%EA%B2%BD%EC%9A%B0-ab-%ED%85%8C%EC%8A%A4%ED%8A%B8%EB%A5%BC-%ED%95%B4%EC%95%BC%ED%95%9C%EB%8B%A4" aria-label="기능이 전반적으로 바뀌는 경우 ab 테스트를 해야한다 permalink"></a>기능이 전반적으로 바뀌는 경우 a/b 테스트를 해야한다</h4>
<p>블루 그린 배포를 하던지 해서 배포 방식을 상황에 맞게 설정해야겠다</p>
<h4 id="load-vs-performance-vs-stress-test"><a href="#load-vs-performance-vs-stress-test" aria-label="load vs performance vs stress test permalink"></a>Load vs Performance vs Stress test</h4>
<p>Reliability, Stability, Response time, Scalability</p>
<p>Performance Test</p>
<ul>
<li>it includes Load test and Stress test</li>
<li>사용자가 원하는 조건이 있을 때 만족할 수 있는지 확인하기 위해 사용</li>
</ul>
<p>Load Test</p>
<ul>
<li>how much can handle resource of cpu, memory</li>
<li>verifies whether the application can handle the expected load.</li>
</ul>
<p>Stress Test</p>
<ul>
<li>find the breaking point(maximum point)</li>
</ul>
<blockquote>
<p><a href="https://stackify.com/load-testing-vs-performance-testing-vs-stress-testing/">https://stackify.com/load-testing-vs-performance-testing-vs-stress-testing/</a></p>
</blockquote>
<h4 id="stage-test"><a href="#stage-test" aria-label="stage test permalink"></a>stage test</h4>
<h4 id="e2e-test"><a href="#e2e-test" aria-label="e2e test permalink"></a>E2E test</h4>
<ul>
<li>End to end test</li>
</ul>
<h4 id="acceptance-test"><a href="#acceptance-test" aria-label="acceptance test permalink"></a>Acceptance test</h4>
<p>인수 테스트? (인수/인계할 때 그 인수?) 고객이 인수하는? 수락으로 해석해도 되겠다
측정할 수 있는 기준을 마련한다는 것</p>
<p>인수테스트를 기반으로 유닛테스트를 조정할 수 있겠다</p>
<p>기획 -&gt; 기능 -&gt; 스토리 -&gt; 시나리오 -&gt; 테스트</p>
<h2 id="error-handling"><a href="#error-handling" aria-label="error handling permalink"></a>Error Handling</h2>
<ul>
<li>Exception File, Network</li>
</ul>
<pre><code>#whitelist?
def do_something:
 if do_something:
  return false

 return true

err = do_something
if err: generateError
</code></pre>
<ul>
<li>엣지 케이스를 확인한다</li>
<li>정상적일 때가 아니라 최악의 상황을 생각한다</li>
</ul>
<h4 id="에러-처리"><a href="#%EC%97%90%EB%9F%AC-%EC%B2%98%EB%A6%AC" aria-label="에러 처리 permalink"></a>에러 처리</h4>
<p>예외로 볼것인가 에러로 볼것인가(회복 가능한가 아닌가)
호출자가 에러처리를 할 것인가, 유닛에서 에러처리를 할 것인가
유닛 함수는 리턴값을 항상 가지게 한다</p>
<p>하마님의 블로그 참고
<a href="https://hamait.tistory.com/1027?category=250996">https://hamait.tistory.com/1027?category=250996</a></p>
<p>포프님의 영상 다시 참조해본다</p>
<ul>
<li>caller 에서는 에러가 뜬 것만 확인하고 내부를 알려고 할 필요 없다</li>
</ul>
<p>에러를 밑단에서 처리하면 프로그램이 뻗을지 말지를 호스트가 선택할 수 없다
에러를 호스트가 처리하면 밑단에서 스택이 잔뜩 쌓여서 호스트에 전달되어야 한다</p>
<p>에러 처리를 어떻게 할지 호스트가 결정해야한다?
밑에서 처리하고 로그만 남긴다?
문제가 생겼는데 에러만 남고 아무 이상이 없으면 문제
문제가 별게 아닌데 정지되도 문제</p>
<p>최대한 정지 없이 문제를 회복해서 진행시켜야 한다</p>
<h4 id="빠른-리턴-vs-리턴은-한-곳에서만"><a href="#%EB%B9%A0%EB%A5%B8-%EB%A6%AC%ED%84%B4-vs-%EB%A6%AC%ED%84%B4%EC%9D%80-%ED%95%9C-%EA%B3%B3%EC%97%90%EC%84%9C%EB%A7%8C" aria-label="빠른 리턴 vs 리턴은 한 곳에서만 permalink"></a>빠른 리턴 vs 리턴은 한 곳에서만</h4>
<p>golang의 에러 처리 방식 vs 책 클린 코드에서 나온 리턴을 마지막에만 두자는 얘기</p>
<hr>
<h4 id="language-design-principle"><a href="#language-design-principle" aria-label="language design principle permalink"></a>Language Design Principle</h4>
<p><a href="Software#History">C</a>
</p></section></div>

shdkej

요약
코딩을 어떻게 하면 좋은 코드가 나올까? SOLID, DRY, YAGNI 등 많은 코딩, 디자인
가이드가 있다.
SOLID
Abstraction, One Behavior class, Encapsulation
S 하나의 클래스는 한 가지 일만, 변경하기 위한 이유는 하나만 갖고 있어야 한다.
O 확장에는 열려있고, 변화에는 닫혀 있어야 한다
L 하위 클래스는 기존 클래스와 치환되어도 동작 해야 한다
I 인터페이스를 작게 하고, 클라이언트가 사용 안하는 함수는 공급도 안하게 한다.
D 추상화에 의존해라. 구체적인 것 말고.
Single reason
변경하기 위한 이유는 버그 수정이나 리팩토링일 때가 아니라 디자인 설계 시의 얘기
DIP를 통해 외부 라이브러리 대신 임의의 객체를 만들어 테스트하기 용이해진다.
테스트 시에 외부 API의 기능을 테스트하는게 아니라 내 구현을 테스트한다.
OOP
Encapsulation, Composition, Inheritance, Delegation, Polymorphism, Open recursion
same Input, should same output
Encapsulation = Module?
Encapsulation is hide the value
폴리모피즘
객체 생성 시 고정된 객체를 만드는 것이 아니라 기준만 만들고 실제 구현은 각
상황에 맞게 수정할 수 있게 하는 것
인터페이스나 추상클래스를 이용하여 상속해 여러 객체를 하나의 기준으로 만드는 것
그리고 이를 이용하여 오버라이딩 하여 각 객체에 맞게 재구현할 수 있는 것
하나의 객체를 다양한 방법으로 사용할 수 있게 하는 것
coupling vs cohesion
내부에서의 변수들의 활용이 잘되면 응집도가 높다고 한다
클래스의 변수를 메소드가 여러개 잘 사용하면 응집도가 높다고 볼 수 있다
각 객체 간 연결이 느슨하게 되있으면 결합도가 낮다고 한다
Functional Programming
불변성
Coding Convention
회사의 컨벤션 룰을 따르자. lint도 설정하고
python -- underscore
golang -- camel
- vs _
tab vs space
Clean Code
Robert C. Martin
https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29
Meaningful naming
TDD
at least make test code.
Test, Log(error handling), API
Why Test?
code make concrete
The Art of Software Testing
test
boundary check
BDD, DDD
unit testing, system testing
https://www.geeksforgeeks.org/difference-between-unit-testing-and-system-testing/
unit testing
single module base,
system testing
depends specific requirement, totally test
Refactoring
변화는 향상을 가져온다. 마치 책의 퇴고처럼
작가가 퇴고를 거듭하며 더 좋은 글이 되는 것처럼 리팩토링을 통해 더 나은 코드를 만들 수 있다
리팩토링을 두려워하지 말자
유닛 테스트
유닛 테스트를 어노테이션을 만들어서 입력값만 지정해서 원하는 출력값이 나오는지
확인하면 테스트와 실제 코드가 같이 있게 되어 좋지 않을까?
결과의 멱등성을 유도하는 방향으로 함수를 작성하고.
@Test(input1:'1',input2:'2')
def add(a int, b int):
    return a + b
복잡한 로직이 필요하거나, 함수 실행 전에 선언해야하는 것들이 있으면 처리가
힘들겠다.
Square s = Square{}
s.SetLength(5)
class Square():
    len = ''
    @Test(what input can in here?)
    def SetLength(i int):
        len = i
테스트코드를 먼저 적고 테스트 코드만 통과할 정도의 함수만 작성하고 문제가 생기면
추가하는 방식으로 한다
주먹구구와 점진적 개선의 차이는 뭘까
기능이 전반적으로 바뀌는 경우 a/b 테스트를 해야한다
블루 그린 배포를 하던지 해서 배포 방식을 상황에 맞게 설정해야겠다
Load vs Performance vs Stress test
Reliability, Stability, Response time, Scalability
Performance Test
it includes Load test and Stress test
사용자가 원하는 조건이 있을 때 만족할 수 있는지 확인하기 위해 사용
Load Test
how much can handle resource of cpu, memory
verifies whether the application can handle the expected load.
Stress Test
find the breaking point(maximum point)
https://stackify.com/load-testing-vs-performance-testing-vs-stress-testing/
stage test
E2E test
End to end test
Acceptance test
인수 테스트? (인수/인계할 때 그 인수?) 고객이 인수하는? 수락으로 해석해도 되겠다
측정할 수 있는 기준을 마련한다는 것
인수테스트를 기반으로 유닛테스트를 조정할 수 있겠다
기획 -> 기능 -> 스토리 -> 시나리오 -> 테스트
Error Handling
Exception File, Network
#whitelist?
def do_something:
 if do_something:
  return false
 return true
err = do_something
if err: generateError
엣지 케이스를 확인한다
정상적일 때가 아니라 최악의 상황을 생각한다
에러 처리
예외로 볼것인가 에러로 볼것인가(회복 가능한가 아닌가)
호출자가 에러처리를 할 것인가, 유닛에서 에러처리를 할 것인가
유닛 함수는 리턴값을 항상 가지게 한다
하마님의 블로그 참고
https://hamait.tistory.com/1027?category=250996
포프님의 영상 다시 참조해본다
caller 에서는 에러가 뜬 것만 확인하고 내부를 알려고 할 필요 없다
에러를 밑단에서 처리하면 프로그램이 뻗을지 말지를 호스트가 선택할 수 없다
에러를 호스트가 처리하면 밑단에서 스택이 잔뜩 쌓여서 호스트에 전달되어야 한다
에러 처리를 어떻게 할지 호스트가 결정해야한다?
밑에서 처리하고 로그만 남긴다?
문제가 생겼는데 에러만 남고 아무 이상이 없으면 문제
문제가 별게 아닌데 정지되도 문제
최대한 정지 없이 문제를 회복해서 진행시켜야 한다
빠른 리턴 vs 리턴은 한 곳에서만
golang의 에러 처리 방식 vs 책 클린 코드에서 나온 리턴을 마지막에만 두자는 얘기
Language Design Principle
C
[[Python#The Zen of Python]]
[[Golang#Philosophy]]
Internal Link
[[Architecture#Goal]]
[[Project#Project start]]
[[Think#개발의 목표]]
[[Information#비판 대신 진취적 개선에 에너지를 쏟는다.]]
[[Think#Safety programming]]
[[Think#가려움을 해결한 방법 1]]
[[Architecture#Check Point]]
[[Technology#Functional_Programming]]
Reference
https://en.wikipedia.org/wiki/SOLID
https://en.wikipedia.org/wiki/Object-oriented_programming
https://www.freecodecamp.org/news/object-oriented-programming-concepts-21bb035f7260/
https://chodragon9.github.io/blog/easy-code/
https://github.com/rwaldron/idiomatic.js/blob/master/translations/ko_KR/readme.md

Coding Rule?

댓글