Conversation
|
우측에 있는 |
There was a problem hiding this comment.
Code Review
This pull request adds study notes for chapters 4 through 9 of 'Street Coder', covering security modeling, performance optimization, and bug triage. A spelling correction was suggested for the week 2 notes to improve linguistic accuracy.
| - 은둔 보안: 임시 방편이지만 **시간을 버는 용도**로는 좋음 | ||
| - 검증된 보안 라이브러리를 사용할 것 | ||
| - **타이밍 공격 방지** | ||
| - : 별것 아니라고 생각되지만 해커들에게 좋은 먹이감이 될 수 있겠네.. |
|
|
||
| ## 논의 | ||
|
|
||
| 저희 회사는 버그 분류를 우선순위 정도로만 하고 있는데, 다른 분들은 어떻게 분류하는지 경험을 이야기하면 좋을 것 같습니다. |
There was a problem hiding this comment.
보통 (심각도) 우선순위로 하죠.
그리고 배포하는 주기가 정해져 있으니까 그 배포 기간만큼 버그 수정 할 수 있는 목록도 우선순위로 짤리고요.
| - 플래그 저장시 문자열 지양 | ||
| - 불리언 평가 최적화 (변수 > 필드 > 속성 > 메서드 호출) | ||
| - CPU 최적화 | ||
| - 데이터 정렬: CPU는 4, 8, 16바이트 단위로 정렬된 데이터를 읽음 |
There was a problem hiding this comment.
이 부분도 모임 때 언급한 내용이긴 한데,
1990년대 CPU의 주소 접근 방식 아키텍처가 빠르게 발전하고 있던 시기와 맞물려서 일어났던 일입니다.
지금은 기존 32비트(4바이트) 아니면 64비트(8바이트)가 기본 단위이고
이것도 프로그래머가 신경쓰지 않아도 되는 게 CPU 레벨, 컴파일러 레벨에서 주소 지정 단위를 가상으로 잡아서 실행해주기 때문에 그렇습니다.
하지만 1990년대는 JAVA와 같은 JVM도 없었고, IBM PC 호환 CPU에 디스크(360K ~ 1.2M)에 담을 수 있는 용량의 프로그램만 썼던 시절이기도 했습니다.
네이티브 언어(C언어), 네이티브 컴파일러(Turbo-C), 네이티브 환경에서 동작하는 실행 파일(exe)이었습니다.
CPU도 80년대부터 쓰던 구형은 8비트, 80년대 후반 보급된 16비트 CPU, 90년대 초반 부터는 최신 CPU는 32비트를 썼습니다.
그나마 32비트 CPU는 엄청나게 비쌌기 때문에 일반 가정집에서 살 수 있는 컴퓨터는 아니었습니다.
따라서 16비트, 32비트에 따른 주소 지정 방식이 2바이트, 4바이트로 달랐기 때문에 책에서도 CPU 별로 바이트 단위로 읽는 기준이 다른 걸 설명한 거죠.
늦었네요.. 죄송합니다
closes #652