-
Notifications
You must be signed in to change notification settings - Fork 10
/
0199.txt
254 lines (254 loc) · 9.9 KB
/
0199.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
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
안녕하세요 포프 입니다.
음.. 오랜만에 코딩 얘기좀해볼께요
C# 쪽인데 정확히 닷넷 쪽인것 같아요
그
C 쪽을 많이 하셨던 분들 또 C# 하셨던 분들 마찬가지겠지만
Assert 라는거 아시잖아요
디버깅 동안의
어떤 조건이 잘못됬을때
프로그램 실행을 멈춰버리고
누군가 디버깅할 수 있게 해주는
그런 것들
릴리즈 코드를
출시용 코드를 빌드 해버리면
알아서 빠져주는 것보다는
Assert 라는 코드가 있잖아요.
그게 굉장히 유용했어요
요즘은 Exception Handling하고 점 이런 걸 많이
하긴 한데
뭐.. 제가 볼때는
제가 Exception Handling를 그다지
크게 좋아지않는거나 다들 아시기때문에
아이디어는 괜찮았는데
무언가 좀..
실수 없이 쓰기에는 굉장히 좀 (한숨)
문제가 많은
그런거같아요 뭐든 간에 전에 얘기 했으니 넘어가고
제가 이제 C# 쪽을 많이 하면서
이제 웹쪽을 하면서 Assert 를 안쓰는 사람들일 굉장히 많이 봤거든요 그래서
그이유는 알아요 Assert 를 안쓰는 이유는
이제 뭐 Exception Handling 으로 다쳐리를 하겠다 이건데
근데
Assert 라는게 솔직히 디버깅에서 굉장이 유용한 툴이긴 하거든요?
그래서
Assert 를 무지하게 박아도
실제 실행 되는 코드에서는 Assert 가 사라져 버리니깐
그럼 Exception 도 발생되지 않으니깐
문제라고 말할수 있는데
제가 볼 때는 Assert
발라 버리는 사람들이
코드에서 Assert 를 엄청 발라버리는
코드가
Exception 에만 의존하는 것보다 훨씬
안정되고 좋았어요 왜냐하면
Exception (웃음)
그게 Assert 라는 것 자체는
굉장히
단순한 개념인데 이 Exception 은
이건 어떻게 핸들링 해야
되는지에 대한 그런 논란도
많고 올바른 방법인지 그러고
Exception 이 났을때
아무런 문제가 없이 돌아야 된다는
허황된 얘기도 있었고
그래서 일반 사람들의
이해하기가 더 어렵고
프로그래머도 이해하기
어려운 상황에서
Exception를 잘 써야 한다는
강박관념 때문에 잘 안쓰게되는
그런 방법 그런 경우도 있는거죠
근데 Assert 는 디버그에서만 돌고 사라지니깐
천개 이천개를 박아도
상관이 없거든요 속도 좀
느려진 것 빼고는
실행되는 코드에서는 문제가 없으니깐
그러다가 이제 게임쪽에서
있으신 분들은 많이
그런거 했을꺼에요 자체 Assert
만들어가지고 디버그 중인
Assert 해서 딱 멈추고
디버그 해서
릴리스 동안에는 화면에 Assert 가 떴다
머 이거 프린트 할래 이런걸로 보여줘 가지고
그런 것들
뭐 그걸을 잘 만들면
개인 Assert 만들어 디버깅 할땐 Assert
실행중일 땐 Exception
이렇게 할 수 있는 거구요
그런 걸을 이제
저는 그쪽 백그라운드으로 왔으니깐
제가 지금 회사에서 그런걸 잘 안하는걸 보고 좀
많이 놀랐거든요
Exception Handling 으로 처리만 하기에는
디버깅이 좀 힘들어지는 일이 있을거 같고
그런걸 보다가
최근에 이제 닷넷에서 새로나온게
있더라구요 Code Contract 라고
Code Contract 가면 보통
아시잖아요 에전에 정말
IDE 나 컴파일러 지원이 전혀 없을때
Code Contract 라고 하면 보통의 경우
Free Condition (자유 조건) 머고 Post Condition (사후 조건) 머고
그런거 주석으로 달아 두고 문서로 이거다 라고 하는거였는데
이 C#에서는 그리고 닷넷 에서는 Code Contract 그런
코어 라이브러리를 같이
제공을 해요 컴파일러 쪽에서
아직 완벽하게 Integration(통합) 잘 되지 않았는데
개념은 비슷해요 Assert 랑 되게 비슷해요
Contract.Ensures 하면 이 조건이 맞아야
되고
그런게 있어요 리턴값은 이거여야 되고 그런걸 코드에 넣어두면
컴파일중에 잡기도하고
그게 또 재밌는 거죠 컴파일 중에 잡을수 있다는게
실행중에도 잡기도 해요
실행중에 잡으면 Exception을 던지다 거나
이런 여려가지 세팅이 가능해요
제가 아까말했던 Assert하고 Exception 을 둘다 왔다갔다
할 수 있는 그런 비슷한것을
만들어 주긴 했는데
이게 벌써 나온지가 한..
버전 몇에 나온지는 기억은안나는데
몇년 돼요
근데 아직도
저희도 이제 product environment (제품 환경)에 쓸려고 했는데
아직 쓸만큼 편하게 어떻게 할수없어요
되게 막 그 Edge Case (알고리즘이 처리하는 데이터의 값이 알고리즘의 특성에 따른 일정한 범위를 넘을 경우에 발생하는 문제를 가리킨다.)라고 하죠
좀 이렇게
실수 많이 할 수 있는 부분도 많고
특히 막 Interface 넣고 Inheritance넣고 이런 상황에서는
Interface 에서 상속해서 Attribute를 받고
이런 이상한짓을 해야하기 때문에
솔직히 개인적인 함수로 그냥 myAssertOrException 해가지고
막 호출 하는것 보다
사용 예가 굉장히 좀 까다로워요.
그게되게 문제예요 그러고
어떤 언어든 어떤 새로운거든
사용하기가 간단해야 사람들이 신속하게 쓸수가 있거든요
근데 그런 문제가 좀있어요 이게
그래서 과연 이게 나아질 거냐
물론 나아져야겠죠
제가볼때는 이 Code Contract 라는 자체가
어찌 보면 Extension (확장)
개념을 시작했어요 자체의
지원이 아니라
외부 라이브러리가 지원을해서 컴파일 하는 도중에 무슨 바이너리 인젝션 하고
막 막 별 이상한짓 하거든요
코드를 보면 좀 학을 떼어요
실제 이 작동하는 코드를 보면
그래서 컴파일 하면서
2배 3배 느려지고
그려고 막 Exception 을 Throw 할때
라이브러리 에서 이게 되거 저게 안되면
이상한 Exception 을 주고
재대로 작동도 안하고 막 이런 이상한
여러개가 있어요
세팅이 좀 까다로워 지는데
개념은 좋아요 뭐든간에 그래서 이제
컴파일에서 좀더 제대로 지원해서
훨씬 빠르게 하고 이러면 좋아지는데
지금은 컴파일 하고 난 다음에
다시 또 바이러리 긁어서
또 한번 뭘 하는거 같더라구요
뭐든간에 그런 처리가 들어오면 안좋것은 뻔하고
제가 볼 때는 앞으로
2~3년 안에는 쓸 수 있지
않을까 란 생각이 들어요
뭐 지금 자체로는
무슨 익스텐션 깔지 않는
이상은 뭐따로 깔지 않는 이상은
컴파일할때 Enabled 못하는 걸로 알고있어요
좀 이상한데
비슷한 예가 옛날에 있었어요
Static Analysis (정적 분석) 라고 해서
제가 한번 다룰려다가 안 다룬것 같은데
C 쪽에서 코드 하시는분들은 알잖아요.
포인터 같은거나 아니면 Buffer Overrun 같은거
실행을 하지않으면 잡지 못하잖아요.
근데 그걸 컴파일 도중에
분석을 해서 이런 위험이
있다라고 판단해 주는 게
이제 정적 분석?
Static Analysis
Analyse
그거라고 있어요
그게
한동안 따른 인텔쪽이나 다른 회사들이 만들어서
유명하다가
이제 C 에는 완벽하게 들어왔죠
C# 에 먼저 들어왔었고
그게 처음 들어올때 똑같이 들어와서
사용하기 힘들었어요
지금은 그냥
솔루션인가 가서
Static Analysis 누르면 그냥 다되요
그런데 예전에는 그걸 하려면
Project properties (프로젝트 속성) 에서
지정해 주고 컴파일을 새로 한번 한다음에
컴파일을 다시 해줘야 했거든요
따로 따로 막 세팅 해준 다음
그게 되게 불편했는데
지금은 그냥
매뉴 버튼 한번 누르면
해줘요
얼마 전에 나왔던 C 에서 나왔던
그런
Profile..
아...
어찌고 Optimization 이였는데..
(Profile-Guided Optimizations)
프로그램을 돌리면서 Profile로
돌린 다음에
자료가 나온거에 따라
컴파일에 쓸 수 있게 하는
이런 것도 예전에 처음할때는
굉장히 복잡하게 무슨
define 해주고 뭐해주고 컴파일 한다음에
이런 막 이상한 짓 해줘야 했었는데
지금은 그냥 툴에서 한 번에 하게 해주죠
내부적으로 똑같이 도는데
툴이 편해진것 뿐이죠
자체를 지원을 좀더 잘 해주는거고
그래서 지금은 Static Analysis 라던가 뭐
Profile... 정확하게 이름이 잘 기억이 안나요
Profile 어쩌고 Optimization 인데
그거라던가
Profile Base Op...
Optimization Profile..
둘중 하나 인거 같아요
그런 것들을 보면서
으~음~ 역시 좀 더
몇 년이 지나고
함께 사용하기 편해지면 정말
회사에서 다쓸수 있을 정도로
편해지는 구나 생각이 들어요
지금 있는 정도 있는 Code Contracts 는
말그대로 혼자 쓰기에 좋은 정도가 아닐까 싶어요
그래서 한..
지금 2015 나왔죠
크게 바뀐 건 없어요 2015 에서
제가 볼땐 2017 정도되면
좀 무언가 제대로 되지 않을까
생각이 들고
그냥 그런게 있다고
말씀드리고 싶었어요
Code Contract 한번 찾아보세요.
C# 닷넷 코드에서
컴파일 도중에 Assert 처럼
Static Assert 네 완벽하게 C 에선
그것처럼 체크를 해주고
그러고 디버그 일때는 Assert를 박아주고
뭐 이런 것들
실행중에는
뭐 Exception을 날려주고
Code Contract 를 한번 보길 바라는데
설명서가 하나 딱 있어요.
PDF 파일로 봤던거 같은데
읽으면 되게 까다로운 조건 도있고 그래서
보면은 아 이게 널리 쓸 수 없구나
라고 생각하시는데 그냥
이런 게
지원이 된다 그러구
제가 볼땐 1~2 년 안에 굉장히 많이 쓸 수 있을 것 같아요.
그래서 그런거 소개 시켜드리고 싶었고
네 포프 였습니다.