C# 개발 비화

C# 개발 비화: "

2008년에 일본에서 열렸던
Developer Summit 2008에서 MS의 C# 개발팀에서
일했던 분의 강연을 정리한 글을 번역했습니다. C#의 개발 비화를 조금 알게 되어서 저는 꽤 재미있게
봤습니다.^^

강연자 소개

C#과의 만남

o 인턴으로 Microsoft 에
간 것이 계기

+ 「Windows와 같이 거대한 프로덕트를 어떻게 개발하고 있지?」라고 하는 흥미로부터

+ 인턴의
배속처가 당시는 아직 비밀이었던 C# 팀이었다.

# 배속처가 정해져서 접수하러 갔을 때 접수하는 분으로부터 「이런 빌딩(부서?) 들은 적 없다」라고 들었다

* COOL(C like Object Oriented Language) 등의 코드네임으로 불리고 있었던 시대

강연자와 함수형 언어

o 대학의 과제로 scheme를
사용하여 인공지능을 만들어 본 경험이 있었다

+ 전혀 함수형 언어가 아닌 것처럼 프로그램을 짜 버렸다

+ 100 행을 넘는 코드가 되어 버려서 결국 움직이지 않았다

+ 정답이 매우 짧은(20행
정도?) 코드로 놀랐다

C# 언어의 사양

* 쿼리 식의 from x in
xs 라고 하는 구문에 대해

o 당초는 foreach(var
item in source) where ... 라고 하는 구문도 검토되고 있었다

o Anders는 쿼리 식에 1년
정도 반대하고 있었다

+ 그러나 usability 테스트(테스터에 새로운 구문을 시험해 보는)를 해 보았더니 메소드 방식으로는
아무도 join을 쓸 수 없었다

o SQL로 어순으로 select 보다 from이 먼저 오는 것은 IntelliSense에서 형태 정보를
사용하기 위해

+ 2005년의 발표 단계에서는 Visual Basic는 select x in xs 이었다

# VB에서는 당초 select x를
쓴 시점에서 in xs까지 자동 생성되었지만 커서가 전후로 격렬하게 움직이는 것이 사용하기 어렵다고
하여 결국 C# 방식으로 변경되었다

# (Anders) 「그러서 말했었잖아」

o from from in xs는 당초 쓸 수 있도록 할 생각이었지만
문법상의 애매함이 발생하는 것을 알게 되어 지원에서 제했다

+
항상 복수의 파서를 쓰고 검증하고 있다

+ yacc 라면 compile
error가 취급하기 어렵기 때문에 결국 자기가 쓰게 된다

+ Visual C++는 가장
yacc를 혹사 하고 있는 컴파일러의 하나일지도?

# yacc의 결과를 yacc에서 처리 하는 것 같은 일을 하고 있다

o var에 의한 형 추론 이야기는
C# 1.0 무렵부터 있었다

o 당시는 JavaScript로
오인 당하면 「좋지 않다」라고 생각하고 있었다

o 지금은 상황이 바뀌었다

o 지금은 Ruby가 디자인
미팅에서 화제에 오르는 일도

o (Anders) 「Ruby로
할 수 있는데 어째서 C#에서는 할 수 없어!」

o 옛날 아직 해외에서 Ruby가
지금처럼 소란을 피우지 않은 무렵 강연자가 Anders에게 Ruby의
이야기를 했지만 무시되었다

o 지금 Anders가
흥미를 가지고 있는 것

o 메타
프로그래밍

o 언어 설계에서 후회하고 있는 것

o
anonymous method에서 yield를 사용할 수 없는 것

o void의 취급

o Equals의 취급

o
null의 취급

+ Ruby의
nil은 훌륭하다

o Tuple를 넣는다고 해도 패턴 매치의 문법을 어떻게 할지 좋은 해결법이
발견되지 않는다

C# 팀의 규모

o C# 2.0 의 시점에서 언어 개발은 10명

o designer 3명

o
developer 5명

o tester 2명

o IDE 등을 포함하면 더 증가한다

o 지금은 더 증가하고 있다

C#의 개발 형태

o 디자인 미팅은 주 3회, 각 2시간

* 언어
사양이 정해지면 구현 해 보고 테스트

o C# 1.0이 릴리스 될 무렵에는 이미 Microsoft Research로부터 거의 움직이는 형태의 Generics 구현이
올라 오고 있었다

o 결국 거의 고쳐 써는 바람에 2년
정도 걸렸다

o
내용은 거의 같다

o
「심볼명 붙이는 방법이 Research 냄새 」 가 마음에 들지 않는 등등

o
다음에 머지 할 경우에 곤란했다

o 우물쭈물
하고 있으면 Research의 무리는 마음대로 fork하여
스스로 언어 확장을 하기 시작한다

o 소프트웨어라고 하는 것은 역시 개인적인 면이 강하다

o 2 주 정도 묵묵히 작업하여 단번에 체크인 하는 사람도

o 「기계와 같은 놈」이라고 불리고 있다

o 체크인 하자마자 휴가 가는 놈이 있어 곤란하다

o 마음에 드는 곳은 Anders이 코드를 쓰는 일도

o 그렇지만 실제로 제품 코드로 하려면 여러 가지 테스트라든가 대조표가
있어서 거기까지 해 주는 것은 아니다

o 할 수 있으면 C#로 C# 컴파일러를 고쳐 쓰고 싶지만 그 비용을 정당화 할 수 없기 때문에 아직도 할 수 없다

C#에 대한 요구 사항을 올리는 방법

o 다양한 채널이 있다

o 요망은 일단 PM이
정리하여 적당하게 집계하여 Anders에게 제출한다

o 확실하게 reject 되는
것은 여기서 떨어진다

+ 그렇지만 이전 reject 된
것이 통과하기도 하니까 어렵다

o Anders의 기분이 좋을 것 같은 때에 리스트 올리면 모두 통과한다

o 강연자 자신이 밀어서 채용된 부분도

o
C# 2.0의 yield return는 처음 yield만이었다. return이 있는 것이 좋다고 강연자가 추천해서 통과했다.

C#의 호환성

o 어떤 언어 사양이 다음에 어떻게 영향을 주는지 처음부터 간파하는
것은 매우 곤란

o 이번에 강연자가 일본을 방문할 때 「Ruby의 변수 범위에 대해서는 접하지 말아라」라고 조언 되었다

o 한 번 결정한 언어 사양의 변경은 매우 곤란

o 이미
사내에 다수의 C# 프로젝트가 있다

+ 현재 Microsoft 사내에서의 신규 프로젝트의 반은 C#

+ 다른 부문에서의 트러블 대응이 부사장 경유로 내려오는 일도

+ C++ 컴파일러 팀에는 빌드 시간이 10% 증가한
것만으로 Windows 팀으로부터 「버그」가 올라 온다

# 48
시간 걸리는 빌드가
52 시간이 되면 여러 가지 문제가 일어난다

o foreach 에 대해서 출력하는 IL 코드를 변경한 것만으로 문제가 보고되어 온다

o
IL 해석 툴의 동작이 영향을 받았다

출처 : http://d.hatena.ne.jp/NyaRuRu/20080215/p3

"