일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 화장품
- 백준알고리즘
- 채권
- 독서
- 책알남
- JavaScript
- 알고리즘 공부
- 자바스크립트
- 지혜를가진흑곰
- 다독
- 알고리즘공부
- 경제
- C
- 서평
- 재테크
- 알고리즘트레이닝
- Java
- algorithmStudy
- 주식
- 프로그래머스 알고리즘 공부
- algorithmtraining
- 책을알려주는남자
- 독후감
- 성분
- C++
- 돈
- 투자
- algorithmTest
- 자바
- 프로그래밍언어
- Today
- Total
탁월함은 어떻게 나오는가?
예측가능하기 좋은 코딩은 해야하는 것일까? 그렇다면 왜 해야하는 것일까? 본문
예측가능하기 좋은 코딩은 해야하는 것일까? 그렇다면 왜 해야하는 것일까?
Snow-ball 2023. 1. 30. 13:00최근에 개발자들이랑 이야기를 하다보면 예측가능한 코드가 좋다고 이야기를 하고 있는 편이다. 왜 나는 코드가 예측가능해야지 좋다라고 이야기를 하는것일까? 그 부분에 대한 정리가 필요하다고 생각이 들었고, 내 생각을 정리한 내용이다.
* 언어는 typescript *
예측가능해지면 좋은건 무엇일까?
첫번째. 코드를 읽으면서 어떻게 동작할지 예측 가능해진다면 우리가 코드를 개선하거나 추가할 때 모든 코드를 보지 않아도 원하는 기능을 제거하거나 추가하거나 개선하기가 쉬워질것이다. 간단하게 코드를 만들어 보았다.
1
|
const userProfile: UsersModel = user.importProfile();
|
cs |
위의 코드를 보면 네이밍과 타입을 지정함으로써 누가봐도 어떤 데이터가 담길지에 대한 예측이 가능해진다. user.importProfile() 가 실행된다면 결과값은 userProfile이 담길것이라는 것을 알 수 있고, 이것은 UsersModel과 같은 형태의 데이터가 담길것이다. 그렇다면 우리가 userProfile에 관한 데이터를 만질일이 없다면, 건들이지 않고 바로 넘어가도 된다. 그렇다면 필요없는 시간낭비가 줄을 것이다.
또한 함수를 누군가 만들어놨다면, 함수 내부를 굳이 분석해보지 않아도 넣는값과 리턴되는 값으로 예측을 할 수 있게 된다.
1
2
3
4
|
function add(param1: number, param2: number): number {
// 엄청 긴 코드가 있다고 가정한다.
}
|
cs |
이렇게 된다면 함수가 파라미터 2개를 어떤것을 받고 어떻게 동작하고 결과값이 어떻게 나올지에 대한 고민은 하지 않아도 된다. 그렇기 때문에 시간낭비가 줄어든다.
그렇다면 네이밍과 타입에 대한 지정만으로 충분할까? 아니다. 자바스크립트 자체에서도 지원해주는 것들도 사용하면 좋다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
1 === '1' // false
1 == '1'. // true
// 자바스크립트에서는 ==, ===을 사용할 수 있지만, ==을 사용하면 예측하기 어려워진다.
let text = 1; // 상수를 let을 사용해도 되지만 const를 사용한다면
const text = 1; // 명시적으로 상수임을 알려줄 수 있고, 개발자의 실수를 예방할 수 있다.
// let으로만 작성한다면 어떤 변수가 상수인지 알기 어려워 예측하기 어려워진다.
if (true) {}
if (false) {} // 조건문에서는 true, false 를 사용해야한다.
if (truthy) {} // 자바스크립트는 true 같이 동작하는 truthy, false 같이 동작하는 falsy 값이 존재한다.
if (falsy) {} // 하지만, 조건문에서는 truthy, falsy값을 사용하는 순간 예측하기 어려워진다.
readonly prisma: PrismaService; // readonly를 붙혀줌으로써 읽기에만 명시적으로 알려줄수 있고 읽기로만 사용할 수 있다.
|
cs |
이런 방식으로도 개발자가 예측하는데로 동작하게 가공을 해야한다. 아무리 뛰어난 개발자 또한 사람이다. 사람은 실수를 하는 동물이다. 물론, 실수 자체를 줄일 수 있도록 개발자는 노력해야겠지만, 실수 자체를 막아버리도록 하는 방식 또한 지향해야지 안정적인 프로그래밍이 가능할 것이라고 생각을 한다.
두번째. 버그가 발생할 확률이 줄어들고 또한 버그가 발생하더라도 수정하기 좋아질 것이다. 프로그램을 만들고 운영하면서 제일 어려운것은 버그이다. 버그는 매번 안되는것이 아닌 어쩔때는 되고 어쩔때는 안되는것이다.그리고 그 버그가 왜 발생하는지 알수가 없다면, 개발자는 항상 엄청난 괴로움에 빠질 것이다.
결국 버그는 논리적으로는 타당하나 어떤 예측하지 못한 데이터가 예측하지 못한 코드를 작동시키거나 작동시키지 않는바람에 생겨나는 것이다. 결국 그말은 코드를 읽는 개발자들을 위해서도 예측가능해야되지만, 코드를 직접 실행하는 컴퓨터도 예측가능한 코드가 더 안정적인 프로그램으로 만드는 지름길일 것이다.
대표적으로 유명한 버그 중 하나의 스토리는 윈도우를 초창기부터 겪어온 사람들이라면 왠만하면 알고 있을 윈도우의 '블루 스크린'이다. 윈도우 1.x버전부터 존재해왔지만, 고치지 못했다고 한다. 결국에는 윈도 98를 발표할 때에 '빌게이츠의 굴욕'이라는 타이틀을 만든 버그이다.