Posted on .
이제까지 시도되지 않았던 이렇게 극단적으로 적용된 개발방법론 류에 대하여 확신이 없어서 문서화를 하기로 했다. 간단히 말해서, 테스트 주도와 같은 세쌍둥이 개발이다.
우리의 alpha codebase의 속도전 개발을 하는데 있어서 4명이 베를린의 사무실의 테이블에 둘러 앉았다. (vitalik, jeff, gavin) 3명은 이더리움 프로토콜의 개발을 위한 클린룸을 소유하고 있다. 4번째 맴버는 Christoph, 테스트 팀장이다.
우리의 목표는 실제 개발을 위한 마지막 3일 안에 3개의 완전히 호환되는 개발, 확실한 스펙 정의 였다.
생각보다 멀어졌다. 이 프로세스는 정상적으로 몇주가 걸렸다.
신속한 처리가 우리에게 필요했다. 우리의 프로세스는 매우 단순했다. 우선 우리는 다양한 협의가 깨어지는 변화에 대하여 토론했다. 그리고 적절하게 우리가 할수 있는 최선을 다해 설명했다. 그리고는, 개인적으로 우리 각자가 잘못된 부분을 동시에 변경하자, 머리를 쳐들고 반드시 있어야 하는 스펙에 대하여 명확히 설명할 수 있도록 하자.
동시에, Christoph는 벙법을 고안하고 코드를 테스트하고 결과를 체워넣고 수동으로라도, 개발에 있어 먼것을 먼저.
마일스톤의 변경사항의 가치가 코딩되고 테스트된 후, 각각의 클린룸 개발이 다시 Christoph가 컴파일한 일반적인 데이터로 테스트하기로 했다. 특이사항이 발견되면, 우리는 그룹으로 디버깅을 한다. 이것이 잘 테스트된 코드를 빨리 생산해 내는 효과적인 방법임으로 판단되는 상황에서는, 아마도 더욱 중요하겠지만, 정상적인 스펙의 혼란없는 제시가.
그러한 극단적인 것을 해낼수 있는 다른 기술이 있는가?
=============================================
이렇게 3명의 개발자는 Geth / Eth / Pyethapp 을 각각 개발하고 통합테스트해서 내놓았던 것이다. ^^
'Ethereum' 카테고리의 다른 글
ethereum wiki (0) | 2018.04.23 |
---|---|
이더리움의 합의알고리즘의 코드변경이 리뷰를 눈앞에 두고 있다 (0) | 2018.04.23 |
Welcom, Blockchain developers! (1) | 2018.03.20 |
go-ethereum JavaScript Console (0) | 2018.03.19 |
Account Types, Gas and Transactions (0) | 2018.03.16 |