2016년 11월 5일 있었던 GDG DevFest 2016 Seoul 행사에서 진행된 `Boot Camp: 초보 개발자를 위한 웹 프론트엔드 개발 101` 워크숍의 소개 부분 슬라이드입니다.
- 행사 URL: https://festi.kr/festi/gdg-korea-2016-devfest-seoul/program/92/
Embedded C에서 TDD를 실천하기 위해 시도했던 경험과 방법을 기록해 보았습니다.
HW로부터 생기는 버그인지 SW로부터 생기는 버그인지 짐작조차 되지 않는 상황이 자주 발생한다면, TDD를 시작해보세요.
이 자료에서는 호스트 시스템(PC)에서 TDD를 실천하는 방법과 타깃 시스템(nRF51-DK)에서 TDD를 실천하는 방법을 기록하였습니다.
또한, nRF51-DK가 아닌 다른 보드를 가지고 있더라도 실천 가능합니다.
ktim610@gmail.com
저는 핀테크 서비스 개발 프로젝트에 참여하여 CI 구축과 QA 자동화 부분 개발을 담당하였습니다.
프로젝트가 시작하면 수 많은 개발자들과 기획자 그리고 QA 들이 다투는 것은 빈번한 일상입니다..
바쁜 개발 과정에서 기본적인 로그인 함수의 구현을 계속해서 체크해야 하는 것은 매우 불편하고 번거롭죠.
Selenium과 Jenkins를 통해 다음과 같은 상황을 자동화하여 개발자들과 QA/기획자들간의 갈등을 줄이고자 합니다.
스크린샷 중 가린부분들은 현재 회사 프로젝트 유출 방지를 위한 것이니 너그러이 용서해주시길..
2016년 11월 5일 있었던 GDG DevFest 2016 Seoul 행사에서 진행된 `Boot Camp: 초보 개발자를 위한 웹 프론트엔드 개발 101` 워크숍의 소개 부분 슬라이드입니다.
- 행사 URL: https://festi.kr/festi/gdg-korea-2016-devfest-seoul/program/92/
Embedded C에서 TDD를 실천하기 위해 시도했던 경험과 방법을 기록해 보았습니다.
HW로부터 생기는 버그인지 SW로부터 생기는 버그인지 짐작조차 되지 않는 상황이 자주 발생한다면, TDD를 시작해보세요.
이 자료에서는 호스트 시스템(PC)에서 TDD를 실천하는 방법과 타깃 시스템(nRF51-DK)에서 TDD를 실천하는 방법을 기록하였습니다.
또한, nRF51-DK가 아닌 다른 보드를 가지고 있더라도 실천 가능합니다.
ktim610@gmail.com
저는 핀테크 서비스 개발 프로젝트에 참여하여 CI 구축과 QA 자동화 부분 개발을 담당하였습니다.
프로젝트가 시작하면 수 많은 개발자들과 기획자 그리고 QA 들이 다투는 것은 빈번한 일상입니다..
바쁜 개발 과정에서 기본적인 로그인 함수의 구현을 계속해서 체크해야 하는 것은 매우 불편하고 번거롭죠.
Selenium과 Jenkins를 통해 다음과 같은 상황을 자동화하여 개발자들과 QA/기획자들간의 갈등을 줄이고자 합니다.
스크린샷 중 가린부분들은 현재 회사 프로젝트 유출 방지를 위한 것이니 너그러이 용서해주시길..
상업적 이용 및 출처없는 무단전재를 금합니다.
애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)
애자일의 스크럼, XP에 대한 기본적인 소개와 스크럼 팀 안에서 테스트 역할자로써 사용자 스토리 리뷰, 테스트 설계, 짝 테스트, 테스트 자동화 등에 대한 내용을 사례 기반으로 소개하고 있습니다.
GitHub로 프로젝트 운영하기
-시스템소프트웨어 연구실 이건희
목차
-깃허브란?
-Repository 활용하기
-branches, releases
-깃허브 프로젝트 문서화
깃허브란?
• 깃(Git)을 사용하는 프로젝트를 지원하는 웹호스팅 서비스
• 다른 사람들과의 협업을 매우 용이하게 해줌
Repository 활용하기
Issue , Pull requests
• Issue 카테고리는 왜 사용하는가요?
• 버그를 기록하거나 요구사항을 전달할려고 사용
• Pull requests 카테고리는 왜 사용하는가요?
• 현재 진행중인 작업이 무엇인지 알게해줌. • 수정사항을 Merge 시킬 때 사용.
Pull requests로 넣은 수정사항이 Merge됨에 따라 Contributor가 될 수 있습니다!
branches, releases
branches
• 테스트 해보거나 새로운 기능을 개발하기 위해 사용하는 독립적인 commit
• Master branch : 기본 branch이자, 최종적으로 마무리 되는 branch
깃허브 문서화
README
• 해당 프로젝트의 개요나 설명, 설치법에 대해서 설명
• ‘README.md’ 파일을 인식
README’s Labels
• Badge images • Custom badge
https://shields.io/
README’s Labels
• Travis CI
• Continuous Integration : 푸시할 때 자동화된 빌드 및 테스트가 실 행되고 소프트웨어 품질을 향상시키는 개발 방식
• https://travis-ci.org/
Issue & Pull requests Template
• Maintainer에게 좀 더 정확하 게 의견을 전달하기 위해 만듬
• Insights > Comminuty 에서 추가 가능
LICENSE
네이버 오픈소스 가이드 https://naver.github.io/OpenSourceGuide/book/
그 외의 Community profile
• Code of conduct
• Contributing guidelines
그 외에 프로젝트 관리에 도움되는 것
OpenHub 어플리케이션
Git Bash (Git bash 사용법 : http://gbsb.tistory.com/10)
GitHub Desktop
참고
• 네이버 오픈소스 가이드 https://naver.github.io/OpenSourceGuide/book/
• 실제로 사용한 프로젝트 https://github.com/kuj0210/IoT-Pet-Home-System
4. 설계란?
• 계획을 세움, 또는 그 계획
• 건축, 토목, 기계 제작 따위에서, 그 목적에 따라 실제적인 계획
을 세워 도면 따위로 명시하는 일
- 네이버 사전 참고 – ‘설계’
5. 개발 환경 관련 설계
• 운영체제나 환경
• 개발 언어 및 툴
• 사용할 소프트웨어 버전
• 사용할 프레임워크
-> Win10, CentOS, MacOS, AWS Cloud 등
-> C – VS / C++ - VS Code / Java – InteliJ 등
-> APM Setup7, MySQL 8.0 등
-> Java의 Spring, Python의 Django 등
6. 개발 환경은 왜 맞춰야 할까?
• 운영체제마다 작동방법이 다르기 때문
• 소프트웨어 버전마다 지원안되는 기능이 있을 수도 있음
• 프레임워크는 소스코드의 흐름을 바꾸기 때문
7. 구현 관련 설계
• 디자인 패턴
• 클래스 정의
• 함수 정의
• 변수 정의
-> 3학년 1학기 소프트웨어 공학에서 자세히 배움
개별적으로 공부하자면 MVC, MVP, MVVC 정도..?
-> 당장 2학기부터 중요함!
8. 구현 설계를 왜 해야할까?
• Code Coverage 를 높이기 위해
• 우아한 코드(Graceful Code)를 위해
• 팀원들간의 Code Conflict를 막기 위해
9. 디자인 패턴
• 소스 코드를 구성하는 형태 혹은 패턴
• MVC 패턴의 예를 들어보자
• M – Model : 프로그램이 실질적으로 돌아가는 것을 말함
• V – View : 프로그램이 보이는 곳을 말함 (Button, TextView 등등)
• C - Controller : 프로그램을 어떻게 돌릴 것인가 분기하는 곳
10. 디자인 패턴 – MVC
switch(버튼)
case: 버튼1
case: 버튼2
case: 버튼3
버튼1 관련 실행버튼 1
버튼 2
버튼 3
버튼2 관련 실행
버튼3 관련 실행
View
Controller
Model
11. 클래스 정의
• 클래스 간의 관계 정의
• 클래스의 역할을 정의
• 클래스 내부 함수 정의
• 클래스 내부 변수 정의
12. 클래스 정의 - 예시
사람
한국인 미국인 일본인
대학생 직장인
금오공대 서울대 포항공대 카이스트
13. 클래스 정의 - 예시
private boolean 불보쌈;
private int 나이;
private int 키;
private double 학점;
public 건희();
public boolean 불보쌈사줌();
private boolean 살아있냐;
private int 나이;
private int 키;
private double 학점;
public 우진();
public boolean 불보쌈먹을수있냐();
class 건희 class 우진
금오공대
14. 함수 정의
• 어떤 역할을 하는 함수인가?
• 어떤 Parameter를 쓰는가?
• 어떤 값을 Return 하는가?
15. 함수 정의 – 예시
• 건희 class의 불보쌈사줌 메서드 정의
public boolean 불보쌈사줌( int 오늘의만족도 ) {
// 오늘의 만족도에 따라서
// 불보쌈을 사줄지 결정해주는 메서드.
// args : 오늘의만족도 : 얼마나 기분이 좋냐
// return : 사줌? 안사줌?
if (만족도 >= 80) return true;
else /*(만족도 < 80)*/ return true;
}
함수의 return 정의 함수의 parameter 정의
함수의 역할 정의
함수 설명
17. 각 컴포넌트별 네임 규칙
• 프로젝트를 진행함에 따라서 무작위의 이름을 쓰는 것을 방지
• 한 눈에 무슨 역할을 하는지 알기 쉽게 정할 것
• 가급적이면 상수를 쓰는 행위는 하지 말 것
(하더라도 #define이나 final형으로 정의하고 쓰자)
18. 네이밍 정의 방법
• 클래스명 : 첫 문자는 대문자로 써주자
• 함수명 : (동사)+(목적어) or (명사)+(동사)
: 띄어쓰기가 필요한 경우 ‘_’ 혹은 대문자를 쓰자
• 변수명 : (명사)_(명사) or (명사)
: 띄어쓰기는 ‘_’를 쓰고, 소문자로 표기
• 상수명 : 대문자의 명사로 표기
19. 네이밍 정의 방법 – 예시 (Java 스타일)
public class Keonhee {
private int money;
private boolean bool_bossam;
private int key;
public boolean getBool_bossam(int status);
public int printMoney();
};
20. 네이밍 정의 방법 – 예시 (C++ 스타일)
class Keonhee {
private:
int money;
boolean bool_bossam;
int key;
public:
boolean get_bool_bossam(int status);
int print_money();
};
22. 구현은 어떻게 하면 효율적일까?
• 작은 컴포넌트 -> 큰 컴포넌트로 구현
• 함수나 클래스를 구현하면서 테스트 케이스를 놓자
• 역할군 혹은 클래스 별로 파일을 나누자 - 모듈화
23. 왜 구현을 작은 단위부터 할까?
• 큰 단위의 계획은 설계에서 했다.
• 작은 곳부터 에러나 버그없이해야 한다.
• 역할군을 명확하게 하기 위해서
24. 컴포넌트가 구현되면?
• 반드시 테스트를 진행해야 한다.
• 안하게 되면 추후에 버그가 겉잡을 수 없을 정도로 터진다.
• 테스트 케이스를 반드시 만들자. ( printf 등을 적극적으로 활용 )
• 주석이나 문서로 반드시 설명을 적어주자.
- Contributing이나 프로젝트 진행에 따라서 매우 중요함
25. 왜 파일을 나누는 것일까?
• 효율적인 소스코드 관리를 위해서
• 팀원이 만약 main함수에 소스코드를 모두 작성했다면 너의 기분은?
• 팀원이 1000줄이 넘는 소스코드를 인계 해줬다면?
26. 왜 파일을 나누는 것일까?
• 효율적인 소스코드 관리를 위해서
• 팀원이 만약 main함수에 소스코드를 모두 작성했다면 너의 기분은?
• 팀원이 1000줄이 넘는 소스코드를 인계 해줬다면?
27. 각 컴포넌트 테스트 및 구현이 끝나면?
• 팀원들끼리 컴포넌트를 합친다.
• 합친 후의 코드를 작성한다.
• 테스트 및 테스트 케이스를 작성한다.
• 만약 팀원들 간의 네이밍 규칙이나 정의를 안해놨다면?
28. 각 컴포넌트 테스트 및 구현이 끝나면?
• 팀원들끼리 컴포넌트를 합친다.
• 합친 후의 코드를 작성한다.
• 테스트 및 테스트 케이스를 작성한다.
• 만약 팀원들 간의 네이밍 규칙이나 정의를 안해놨다면?
29. 테스트 케이스는 왜 작성해야죠?
• 버그가 터지는지 안터지는지 어떻게 알죠?
• 어떻게 이 함수나 변수를 사용해야죠?
• 즉, 예제를 작성하는 것이 테스트 케이스
33. Github 의 기능들
• 소스 코드 저장
• 소스 코드 버전별 정리 - tag / version
• 소스 코드 분기별 관리 - branch
• 프로젝트 전반적인 관리
• 해당 프로젝트에 이슈 남기기 기능 – Issue 카테고리
• 소스코드 수정 건의 기능 – Pull requests 카테고리
• 소스코드 문서화
37. 실전에서 매우 중요하다
• 설계 과정이 제대로 안되면 구현에서 문제가 나온다.
• 이전 버전 관리를 안해놓으면 처음부터 다시 짤지도 모른다.
• 안하면 소스코드가 미친듯이 꼬인다.
38. Github는 왜 알려주었는가?
• 프로젝트 관리를 메인으로 하는 가장 유명한 툴이다.
• 잘 사용하면 이만큼 편한 툴이 없다.
(특히 리눅스, Mac환경에선 매우 편리함)
• 취업 준비할 때 이만큼 좋은 포트폴리오가 없다.
39. 그 외에 알아둬야할 점
• 창설 혹은 팀 단위의 경진대회 같은데에서
싸우기 싫으면 알아두는게 가장 좋음.
• 디자인 패턴은 전부 다 알필욘 없다.
하지만 실전에서 자주 쓰이는 패턴 정도는 알아두자.(특히 MVC)
• 실제로 개발자들이 중요하게 생각하는 과목
- 운영체제, 네트워크, 소프트웨어공학, 데이터베이스, 자료구조
40. 그 외에 팀 프로젝트할때 쓸만한 것
• Goorm IDE - 소스코드 공유 및 실시간 작성 툴
• AWS Cloud - 원격 서버. 실제로 배그도 여기에 서버 둠
• PuTTy, 팀 뷰어 – 원격 제어 프로그램
• Eclipse Coverage 기능 – 소스코드 활용도 체크 기능