|
http://www.hackerschool.org/HS_Boards/zboard.php?id=HS_Translate&no=16 [복사]
어느새 번역 날자가 10일로 바꿔져있는지;;
번역은 하고 있는중이고요, 아래 내용은 스크립트입니다.
가로 쳐진 부분은 적긴 했으나 확실치 않은 부분이며 ***은 모르는 부분입니다.
그리고 해석을 하지 않아서 일단 말이 이어지면 한 문장으로 하였습니다.
...
For the pass couple of years have been doing a code review for methodologya lot of large reallycode base.
몇 년 동안 아주 많은 라인을 가지고 있는 코드들을 검토 해왔습니다.
And initially when I started doing code review it was pretty difficult trying (figure) all their everything by has 600,000 lines of code.
그리고 제가 처음으로 코드 검토를 하기 시작했을 때 600000 만 줄의 코드를 (분석) 하는 게 꽤나 힘들었습니다.
I have to review that code, trying find 디픽스(패치하는건데..) and it's really difficult for anyone person are single team *** and review code without communicating and following tool every single step.
제가 그 60만줄짜리 코드에서 디픽스를 찾으려 했는데 커뮤니티의 도움 없이 싱글 스탭(코드를 한 줄씩 실행) 하면서 검토하는 것은 혼자서 하기에는 정말로 힘든 것이었습니다.
So, pass two years (are so it) ah... with help of few friends of mine with a they stop it used to work for became up with some part of methodology .
2년이 지나고 도움을 주는 친구와 함께 몇 가지 방법들을 찾곤 했습니다.
Little on... last year, I think a microsoft started pushing threat analysis (go a bit) I look into that (in a like) there ideas as well, so I try come up with someone different technical previewing large sour code bases.
작년, 전 마이크로소프트사(;이하 마소)가 위험분석에 대해 지원을 시작했다고 생각했습니다. 저는 마소와 그 위험분석 개념에 대해 조사하였습니다. 그래서 전 많은 량의 코드를 (검토) 하는 색다른 기술을 찾아보았습니다.
And today I'm going to try focus this *** on that particular topic.
그리고 저는 오늘 이것(위험분석)에 초점을 맞추려 합니다.
Basically how do go about reviewing large code basis doing source code review and doing focus source code review to get most effective result.
Defense in depth today
We have firewalls, this is a big picture i guess, we have Firewalls, we have DMZ, Host Assessment We have difficult Hardened Builds, Vulnerability Scanning but now this Code Review is becoming more and more popular a lot of company want to do not just common do ****** test it there product company but black box testing but also look at code review.
How do we go going do that code review.
So this is the six point methodology started with Threat Model will talk about Threat Modeling basically trying to get (data flood *******) of entire application and trying to figure out all the major entry point are all the major *** someone else going to access something and trying to see if there *** could be trace I particularly point like for web application if like google the biggest *** search the search fill it self *** properly they would be no problems are something among those line so we will talk about every single major entry point what are they different technique (we can) *** doing that.
Second step *** Cursory Code Review.
The reason for that is that every single person in world in doing a code review should understand how *** (indial) application is written have common (please) where you have *** (store) have common please where you have *** common note (store) so that when initially your reviewing it you are understanding the (mind set of) programmer.
The goldest to think like wonder programer was trying to do all there.
You not going to go to depth you just see what exactly happening from *** ***.
Then you going to separation of code will talk about couple of (meter) (there's) stander (meter) that microsoft come up with and then there's (meter) 엠플로포우징 application architecture trying to be a value 투들 *** (difference) seperations how do you give value to it how do you figure out what exactly would give you more benefit focus your (dying) to was.
Then we will talk about maintaining code notes with reviewer name.
This is very important simplely because reviewer *** bunch of code and he will understand it he puts notes down review is could also accessing same function he doesn't spend time trying to understand function code again.
so It is good idea to have reviewer note and reviewer names also little (they) what we (end up) doing giving customers just graph that particular name and *** you don't have to maintain multiple note
|
Hit : 1743 Date : 2011/05/10 10:09
|
97, 
1/4 
멍멍
