일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
Tags
- 체인의정석
- 스마트컨트렉트프록시
- ethers websocket
- 러스트 기초 학습
- git rebase
- rust 기초
- multicall
- 머신러닝기초
- 티스토리챌린지
- 스마트 컨트렉트 함수이름 중복
- vue기초
- chainlink 설명
- 러스트 기초
- ethers typescript
- 프록시배포구조
- SBT표준
- 러스트기초
- ethers v6
- 컨트렉트 배포 자동화
- 스마트컨트렉트테스트
- 컨트렉트 동일한 함수이름 호출
- Vue.js
- 스마트컨트렉트 함수이름 중복 호출
- ethers type
- 스마트컨트렉트 예약어 함수이름 중복
- Vue
- ethers
- ambiguous function description
- 오블완
- nest.js설명
Archives
- Today
- Total
목록sw미팅 (1)
체인의정석
소프트웨어 구현 방법론 - Software Inspection & peer review
SW peer review란 소프트웨어 개발자가 아닌 3자가 소프트웨어 작업관련 산출물을 검사하고 결함을 발견하고 개선 기회를 제공하는 활동이다. 보통 이런게 쓸모 없다고 생각하는 경우가 많지만 나중에 나온 소프트웨어가 잘못나왔을때 있는 손해를 생각해보면 이것이 잘못된 것임을 알 수 있다. 소프트웨어가 잘못 나오게 되면 그에 따른 손해는 훨씬 크기 때문이다. 먼저 Inspection에 대한 대상은 코드 뿐만이 아니라 모든 문서가 대상이된다. 문서를 모두 다같이 검토하는 것이다. 명세서, 설계서, 소스코드가 모두 inspection의 대상이 된다. Inspection을 위해서는 우선 진입 기준이 있는데 Inspection을 시작할 수 있는 산출물의 최소 조건이 이것이다. 근거문서가 검토되고 베이스라인이 설..
개발
2020. 6. 14. 23:09