(Fintech W-IOI #13-14) Git과 GitHub | Software의 개발과 보수

 

 

• git
  
  • Computer File군의 변경 사항을 추적하는 분산 Version 관리 System.
  • 주로 Softward Source Code를 (공동) 개발하는 Programmer(들)의 작업을 조정하는 데 사용됩니다.
  • 하지만 (Website 개발, 책이나 논문 작성 등) 다양한 용도로 사용할 수 있습니다.
• GitHub
  
  • git을 이용한 Software 개발 및 Version 관리를 위한 Hosting Service
• 현재 시점에서 Data와 Code (← 꽤나 광범위한 개념) Management의 요체.
  
  • 반드시 git/GitHub일 필요는 없지만, 비슷한 개념을 적용합니다.

git이란 무엇이고 GitHub란? 아니, 왜 그런 걸 알아야 하나요?

 

 

• Linux Kernel의 Source Code 관리에 사용하기 위해 Linus Torvalds가 개발 (현재 maintenance는 하마노 순)
• Free Software (License : GPL)
  ↑ Source Code는 Open 되어 있고, 개선된 Code의 배포는 동일한 License로 해야 한다.
• 중요 개념
  
  • Repository : (저장소의 의미) 관리 대상을 두는 Database
  • Clone : Repository를 Local 환경에 복제하는 것
  • Commit : 변경 사항을 Local Repository에 기록한다.
  • Push : Local Repository → Remote Repository에 변경 사항 반영
  • Pull : Remote Repository → Local Repository에 변경 사항 반영 (fetch 하여 merge)
  • Branch : 동시에 변경을 진행하고 있는, 분기된 또 다른 버전

git

 

• GNU란 무엇인가요?
  
  • GNU's Not Unix의 약자입니다! . . . 그럼 GNU는 무엇일까요?
• GPL은 리처드 스톨만이 GNU 프로젝트를 위해 만든 Free Software License이며, 다음과 같은 내용을 허용합니다.
  
  • 자유 0: Program을 실행하는 것(어떤 목적이든 상관 없음)
  • 자유 1: Program의 동작을 조사하고 수정할 수 있습니다.
    
    • ↑ 따라서 Program의 Source Code에 접근할 수 있어야 합니다.
  • 자유 2: Program을 재배포할 수 있습니다.
  • 자유 3: Program을 개선하고, 그 개선을 대중에게 Release할 수 있습니다.
• 또한 2차적 저작물에 대해서도 위의 4가지 자유를 보호하려고 합니다.
  →[Copyleft]의 개념
• Open Source Software의 License는 이 밖에도 있으며,
  제약(? (←「자유」인데)가 엄격하다고 여기는 개발자들로부터 외면당하기도 합니다.

GNU General Public License (GPL)

 

• GitHub, Inc.가 운영 (Microsoft산하)
• 너무 많은 사람들이 이용하고 있기 때문에, 다운되면 큰일입니다.
  
  • Service Deploy(실행 File 등을 Server에 배치하는 것)에도 사용됩니다.
• 중요 개념
  
  • Fork : 원래의 Repository와 동일한 것을 스스로 관리하기 위해 복제하는 것
  • Pull Request : 원래의 관리자에게 자신이 변경한 Pull을 가져와 달라고 요청하는 것
    
    • 담당자를 지정할 수 있다.
  • Issue : Idea, Feedback, Task, Bug를 추적합니다.
    
    • 담당자를 지정할 수 있습니다.
  • Wiki : Wiki Page를 생성할 수 있습니다.
    
    • Wikipedia(Wiki를 응용한 백과사전)가 아닙니다!

GitHub

 

• Data와 Code를 관리하기 위해 만들어졌다
• Programmer는 Code가 문서라고 생각한다.
  ⇒ 문서 관리에 사용할 수 있다!
• 예를 들어 법조문도 관리할 수 있지만 . . .
  • https://arstechnica.com/tech-policy/2018/11/how-i-changed-the-law-with-a-github-pull-request/
• 여러분도 꼭 효과적인 사용법을 생각해서 사용해보시기 바랍니다!

GitHub에서 우리들이 할 수 있는 것

---

 

• 필요한 요소
  
  • 1. 요구사항 분석
  • 2. 사양서 작성
  • 3. Architecture 설계
  • 4. 구현 (Code 작성)
  • 5. Test 및 평가 (Code가 설계를 충족하는지, 설계가 사양을 충족하는지, 사양이 요구 사항을 충족하는지)
  • 6. Deploy (사용 가능하도록 배포)
  • 문서화 (Documentation)
• Deploy 후에도 개발은 계속된다(그때마다 위의 요소군이 필요하다).
  
  • Bug 수정
  • 새로운 기능 추가
  • 성능 개선
  • 가독성과 유지보수성을 높이기 위한 구조 개선 (Refactoring)
    ← Software를 장기적으로 건강하게 유지하는 데 중요
• 두 가지 방향성
  
  • Waterfall : 1∼6을 순서대로, 가능한 한 크게 적게 돌리되, 문서(사양서, 설계서)를 하나씩 작성한다.
  • 반복형 개발 : 1∼6을 반드시 그 순서가 아니라 가능한 한 작고 많이 돌리고, 
    독립적인 문서 작성을 피하고, Code를 문서화한다.

Software의 개발 Process

 

 

 

• 반복형 개발을 크게 보면
  
  • Software System을 점진적으로 개발한다(Incremental)
  • 반복마다 설계가 수정되고, 사양과 요구사항도 재검토한다.
  • Test는 자동화한다(여러 번 반복하고 퇴행도 감지해야 하므로).
    
    • Code를 작성할 때 Test Code도 함께 작성한다(애초에 Test하지 않으면 작성할 수 있는지 알 수 없다)
  • Architecture는 Refactoring을 통해 탄생한다
  • Code를 작성하는 것이 곧 설계이고 문서화이다.
• Agile Software 개발 선언 (The Manifesto for Agile Software Development)
  
  • Process나 Tool보다 '개개인의 상호작용'을
  • 철저한 문서화보다는 '움직이는 Software'를
  • 계약 협상보다 '고객과의 협업'을
  • 계획을 따르기보다 '변화에 대한 대응'을

반복형 개발과 Agile(민첩한) 개발

 

• Agile 개발을 전제로 한 조직 개편이 필요하다.
• 개발(Dev)과 운영(Ops)을 보다 긴밀하게 연계한다.
  
  • 조직의 개발 부서, IT(정보 System 운영) 부서, QA(품질보증) 부서의 연계를 강화하거나 경계가 모호해진다.

DevOps

 

• Bug Report는 문제 파악과 해결을 위한 첫 번째 단계입니다.
• 사실에 근거하여 상세히 설명하세요.
  
  • 발생한 사건은? (어떤 현상이 발생했나요?)
    
    • Error Message도 함께 알려주세요!
    • Error가 표시되어도 혐오스럽게 지우지 마세요! 원인을 파악할 수 있는 중요한 정보가 담겨 있습니다!
  • 재현하는 절차는? (실행 환경도)
    
    • 재현만 할 수 있다면 이쪽입니다(대부분의 경우).
• 교재나 수업에 대한 Feedback도 기본적인 생각은 동일합니다!
  
  • 당신이 발견한 중요한 문제를 강사의 머릿속에서 재현할 수 있도록 도와주세요!
  • '모르겠다'가 아닌 '이렇게 이해했다'를

Bug 보고 방법