-
Notifications
You must be signed in to change notification settings - Fork 10
/
0299.txt
146 lines (146 loc) · 7.12 KB
/
0299.txt
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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
안녕하세요, 포프입니다, 예전에.
'디버깅이 프로그래밍의 반이다'라는 비디오를 만든 적이 있어요.
디버깅의 중요성을 말했죠.
그거하고 대개 비슷한 이야기의 비디오에요.
제가 최근에 이제 어떤 주니어급의 프로그래머를,
멘토링을 하다가 발견한 문제인데
옆에 앉혀놓고 프로그래밍을 하다가,
버그가 나왔을 때 고치는 걸 보고,
'디버깅이 반이다'라는 비디오에서는
정말 디버깅을 중요시하라고 그랬어요.
근데 이거는 어떻게 보면 기술의 문제도 아니고,
아, 뭐 기술의 문제일 수는 있어, 그런데.
기법의 문제일수도 있는데 그것보다 더 중요한 거는,
개인의 자세인 거 같아요.
제가 얼마 전에 만든 비디오에서 그런 이야기를 했죠.
숫자놀음, 정치, 뭐 이야기, 이런거 이야기하다가
실수를 할 줄 알아야 된다 사람은, 실수를 하는 게 솔직히
어느 정도는 중요하다는 이야기를 했어요.
거기서 고쳐 가지고 배워 나가면 되니까,
똑같은 이야기에요.
디버깅을 잘못하는 아이들의 문제점을 제가 보니까,
버그를 만드는 거를 무서워해요.
그리고 이제 버그가 만들어지면
버그있다고, 그럼 거기다 자기가 실수했다는 게 너무 부끄럽고, 그래서 그거를 피하려고 하는 경우가 많아요.
그거를 피하려고 하는 아이들의 특징 중의 하나가
빨리 덮으려는거지, 이 버그를 만듦으로 해서
이 버그를 고치고 이 버그가 왜 만들어졌는지 이해를
해서 다음에 이런 버그를 안만들겠다라는,
원인을 찾아서 실제로 그 원인을 없애는 것보다는
이 현상이 보이잖아요, 버그라는 현상이,
어떻게든 이걸 안보이게 덮어버리고,
아무 일도 없었던 것처럼 넘어가고 싶어하는 아이들
그게 삶에서도 나와요.
그 사람들이 어떻게 살고 어떻게 그런
자기 실수에 대해 대처하느냐라는 그런 자세가
버그를 고치는 거에서도 나와요.
그래서 이런 아이들의 특징은,
이것 저것 해요, 이것 저것 하다가
버그가 일단 사라졌어,
그러면 끝났습니다하고 덮으려고 그래요.
제가 그 때 볼 때, 딱 잡거든요. "야,"
너 이거 바로 그 전에 있을 때가 훨씬 더 나은 코드라고,
그 전에 있을때는 버그가 100% 터졌잖아.
지금 네가 이거를 덮으면 지금은 안터지는데,
나중에 터지면 어떻게 할거냐고, 다시.
그 때 또 고칠거냐고, 그 때 이만큼 시간 투자해서
다시 현장 찾아내 고칠거냐고,
차라리 버그가 100%날 때,
이 현상을 덮는게 중요한 게 아니라 정확히 이 버그가
어떻게 났는지를 이해를 하고
논리적으로 왜 났느냐를 알면은
이거를 고치면
언더라인 이슈라고 그러거든요, 실제 가장
근원이 되는 문제, 이유를 고치면
버그는 사라지니까, 그런게 확인이 됐을 때가
버그가 고친거라고 하는거라고,
그거를 굉장히 강조를 했어요.
이제 괴롭죠, 본인은, 왜냐하면 버그가 났을 때,
누구도 이유를 한 번에 알지 못해요.
그러면 내가 진짜 엄청 멍청한거야,
어떻게든 이걸 찾는데 답이 안 나와.
디버깅하는데 왠만한거
막 몇 시간 걸리는 경우 많거든요.
몇 시간 동안 답이 안 나와, 난 되게 멍청해 보이잖아요.
그러면 거기서 스트레스 되게 많이 받는거야.
덮고 넘어 가자.
이렇게 넘어가요.
근데 문제는 뭐냐면
걔네들은 죽어도 디버깅을 못해요. 나중에 가도.
처음에, 처음에 어렸을 때 배우면,
주니어 때 배우면
그나마 누군 옆에서 용서라도 하잖아요.
그래, 주니어니까 좀 더 해 이런 식으로.
그래 가지고 연차 쌓여왔고 어쩌다가.
올라가요, Intermediate, Senior
근데 그 때도 버그 못 잡고 있어,
그러면 어떻게 할거에요?
욕만 먹는거죠, 제가 예전에,
'디버깅은 해봤니'라는 비디오에서 어떤 시니어가
디버깅을 못하는 걸 엄청 깐 적이 있어요.
바로 그런 사람이 되는 거에요. 정말 가면
갈수록 쓸 데 없고 뒤에서 수군수군 거리는 사람.
차라리
기회가 있을 때
그거를
문제를 보는 습관을 들이고
거기서
똑같은 문제를 안 만들 수 있는 실력을 키우라는거죠.
그게 되게 중요하다고 생각하는데, 왜 그렇게,
모든 사람은 아니에요, 왜 그렇게,
그런데 일부 사람들이 왜 그렇게,
버그를 만드는 걸 무서워하는지 모르겠어요.
버그를 만드는 거는,
쪽팔린 게 아니에요
그 버그에,
뭐라고 그럴까, 원인을 찾아, 고치는 대신에
현상을 덮어버리는게 쪽팔린 거에요.
그게 정말 쪽팔린 거에요.
그래서
그런 말을 정말 하고 싶었어요. 내가
디버깅 실력이 모자란다고 하는 사람들은
조금 그 부분을 고민해보시기를 바래요.
내가 정말 어떤 문제를 봤을 때,
내가 이거를 100% 이해를 못 해도
그냥 덮고 넘어가는 경우가 많은가.
그거를 정말 제대로 봐야할 거 같아요, 그래서.
버그를 확실히 고치는 방법은 언제나 확실해요.
버그를 발견해요,
버그가 난 이유를 확실히 이해를 해요,
그리고 그 근본이 되는 문제를 고쳤는데,
버그가 안 나, 그러면 고친 거에요.
근데 그게 아니라
그냥 뭔지 몰라서 아무거나 막
이렇게 고치다 보니까, 고쳐졌어.
근데 이게 이거를 왜 고쳤는지,
분명하게, 뭐라고 그럴까?
인과? 인과라고 하죠, 원인과 결과.
그런 필수적인 인과관계가 안 보여,
그럼 제대로 안 고친 거에요.
그거를 이해할 때까지 버그는 파야되요.
문제는 이제 나중에 당연히 당장 뭐가 서비스가
나가야되는데 이게 깨진다, 이런 경우에는
대충 땜빵을 쳐놓고 나가는 경우도 있어요.
근데 그거는 언제나 주석을 달아놓고
자기가 시간이 날 때, 나잖아요.
프로젝트 나가고 나면, 그 때 보면서
다시 한 번 제대로 파야 되는 거에요.
그리고 주석에 이게 왜 고쳐지는지 모르겠지만 일단은,
핵으로라도 이렇게 한다라고 남겨놓고
내 이름 박아두면은,
내가 나중에 쪽팔려라도 찾게 돼.
그런데 이런 아이들 특징이 안 남기죠.
대충 고치고 넘어가,
나중에 또 비슷한 거에서 뻑이 나요.
그러면 그 코드를 보는 사람은 아무것도 몰라요.
보면서 이게 왜 이렇게 코드가 있을까,
이 코드가 과연 제대로 고친걸까, 아닐까.
이거를 과연 빼도 될까, 아닐까.
유지 보수가 힘들어져요.
그래서 제가 하고 싶었던 말은
디버깅을
버그를 만드는 거를 두려워하지 말자.
근데 버그를 제대로 못 고치는 거에 정말
쪽팔려하자는 이야기를 하고 싶었어요.
예, 그럼 그 정도로 하죠.
예, 포프였습니다.