오픈소스 기말고사 정리

<코드 리뷰>

1. 소프트웨어를 실행하지 않고 잠재된 결함을 찾아 개선하고 소프트웨어의 품질을 높임
2. 버그 헌팅이 아니라 소통하고 일상적으로 하는 배움을 주는 활동
3. clean code와 sound design 유지
4. 미래의 결함 비용 단축 가능, 테스트보다 효과적으로 결함 발견
5. 건전한 소통으로 성장 촉진
6. 물리적 허들, 심리적 허들(프로그래머의 자아, 공감대 형성)
7. 사람이 아니라 코드를 비판해야 함
8. 코드 작성 -> 리뷰 생성 -> 리뷰 진행 -> 리뷰 완료 -> 리뷰 종료
9. 리더를 공략하고 약간은 강제적인 것이 빠른 정착
10. 가볍게 -> 강요하지 마라, 온라인 리뷰가 효율적, knowledge sharing, 미리미리 하자, 작게 자주 하자
11. 코드 작성 시 한 번에 하나의 작업만 수행, commit message에 반드시 이슈 트래커 이슈 번호를 기록, 표준 지키기
12. 이슈 완성되기 전에 개발 중간에라도 리뷰 생성
13. 리뷰어가 많다고 좋지는 않다. 보통 2 ~ 4명, 전문 리뷰어만 지정하는 건 좋지 않다.
14. author에 리뷰를 자기가 읽는다 생각하고 달자, 리뷰 대상 코드만 리뷰하고 리뷰 시간은 30분 내외가 적당
15. business logic, 스타일, 디자인 아키텍처, 테스트 코드 작성 여부, 재사용성, 확장성, 성능, 보안, 적절한 라이브러리 활용 등
16. 코멘트는 최대한 친절하고 이유를 잘 설명한다.
17. 일반적인 경우 리뷰에 ChangeSet 추가, Critical 한 경우 별도 이슈로 추출
18. Author의 판단에 따라 리뷰 종료 가능
19. 코드 리뷰의 좋은 현상: 코멘트 자연스러워짐, 코드 작성 시 신경, 리뷰 생성 수행 시간이 길어짐, 피드백받는 시간이 짧아짐, 리뷰 진행 시 불편한 점이 자주 리포팅
20. 코드 리뷰의 나쁜 현상: 설명 없이 코드만 올림, comment의 답변 없음, 피드백받는 시간이 점점 길어진다, 리뷰를 모아서 한꺼번에 요청
21. 코드 리뷰의 효과를 정량적으로 측정은 쉽지 않음, 리뷰 건수, 지행 시간 등 측정 가능한 지표들은 리뷰 도입 시 참조 용도로 활용 가능, 개발자 스스로 이점을 느낄 수 있다.
22. 결함 발견 건수, 횟수 같은 건 측정하지 말자

<Django>

1. 대부분 대규모 웹사이트는 서버의 코드를 사용해서 데이터를 동적으로 표현한다.
2. HTTP 요청에는 리소스를 식별하는 url, method(리소스 가져오기, 삭제, 게시), post메서드에 의해 전송된 데이터, 관련 쿠기에 포함
3. 웹서버는 클라이언트의 요청 메시지를 기다렸다가 응답 메시지로 웹브라우저에 응답함 -> 웹브라우저에 표시
4. 정적 사이트: 특정 리소스가 요청될 때마다 서버에서 동일한 하드 코딩된 콘텐츠를 반환
5. 동적 사이트: URL에 대해 다른 데이터 반환 가능, 요청정보를 처리하고 반환 즉 시간, 상황, 요청에 따라 다른 콘텐츠를 반환
6. 동적 웹사이트는 서버에서 코드가 실행되는데 이를 ServerSide Programming이라고 한다.
7. 서버의 역할: 정보의 효율적인 저장 및 전달, 맞춤형 사용자 경험, 콘텐츠에 대한 액세스 제어, 통신, 데이터 분석
8. 웹 프레임 워크: 개발자는 일반적으로 웹 프레임워크를 사용하여 코드 작성, 개발 속도 높이고, 다양한 유형의 작업을 단순화함. 설계된 기능, 개체, 규칙 및 기타 코드 구성의 모음, HTTP 요청 및 응답으로 작업, 요청을 라우팅, 데이터에 쉽게 액세스, DB 액세스를 추상화하고 단순화, 데이터 렌더링
9. 장고는 빠른 개발과 깔끔하고 실용적인 디자인을 장려하는 python 프레임워크(동적 기반) - 구글 앱 엔진 프리 및 오픈소스 (이베이, 워싱턴 포스트)
10. Model View Templates 패턴, 웹 관리자 제공, 코드 중복을 피해 HTML 템플릿을 정의(DRY 원리), URL(느슨하게 결합), HTML에서 비즈니스 로직 분리 가능, 파이썬을 이용한다.
11. Model: 데이터 구조 & DB 스키마, View: 사용자에게 보이는 화면 Control, Templates: 사용자에게 보여지는 화면, Controller: 장고 프레임워크, URL 파싱
12. URL은 HTTP 요청을 적절한 View로 리다이렉팅 시킨다.
13. View는 HTTP 요청을 수신하고 모델에서 필요한 데이터를 Access 해서 Template에 응답 형식을 위임
14. Model은 애플리케이션 데이터 구조를 정의하고 데이터베이스의 레코드를 관리 및 쿼리 하는 메커니즘을 제공
15. Template는 실제 콘텐츠를 나타낸다. HTML을 비롯한 프런트단의 역할을 한다.
16. model을 import 해서 DB 검색을 위한 쿼리 API를 제공
17. render 함수를 통해 템플릿을 렌더링 해서 실제로 사용자에게 보여주는 기능을 제공
18. manage.py runserver을 이용해서 서버 실행
19. 장고의 기본 DB 구성은 SQLite이다.
20. manage.py makemigrations을 실행하여 장고에 반영된 변경 사항을 저장, manage.py migrate를 실행시켜서 서버에 반영한다.
21. manage.py shell을 통해서 데이터베이스 api 탐색 가능
22. admin으로 장고 관리자 페이지 접속 가능
23. view의 각 기능들은 Python 기반의 클래스 혹은 함수로 표현이 된다.
24. 장고는 요청된 url을 검사하여 view를 선택한다.
25. URLconfs는 URL 패턴을 보기에 맵핑한다.
26. urls.py에 path로 모듈 연결
27. get_object_or_404는 get()을 사용해서 객체가 존재하면 객체를 불러오고 그렇지 않으면 http404 오류를 반환한다.
28. 코드가 적을수록 보기 좋다.

<UI>

1. 인간과 컴퓨터 사이의 효과적인 커뮤니케이션 매체
2. 위를 원칙으로 프로토타입의 기초를 형성하는 화면 레이아웃을 생성
3. 일관성, 직관적으로, 우호적으로, 친절해야 함
4. 만델의 3가지 황금률(사용자의 제어, 사용자의 메모리 부하 감소, 일관성 있는 인터페이스 )
5. 사용자에게 불필요한 동작을 강제하지 않는 ui 모드 정의(맞춤법 검사, 유연하 상호 검색, 자동 저장, 실행 취소, 다시 실행)
6. 기술 수준 향상에 따른 상호작용 간소화
7. 사용자의 메모리 부하 줄이기(단기 기억에 대한 수요 감소, 시각적 레이아웃, 단계적 정보 공개)
8. 창 제목, 그래픽 아이콘, 일관된 색상 사용 등
9. 대화 디자인의 8가지 황금률(일관성, 종료를 위한 대화 상자, 간단한 오류처리, 손쉬운 작업 반전, 내부 제어, 단기 기억 부하 감소)
10. 오류 처리(사용자가 이해할 수 있는 언어로 설명, 조언 제공, 부정적 결과, 시각적 or 청각적 신호와 메시지)
11. 도움말 기능 포함
12. 사용자 유형, 시스템 유형 및 사용자 요구 사항에 맞게 상호 작용 제공
13. Flutter 크로스 플랫폼으로 구글에서 개발, 단일 코드 베이스로 ios, 안드로이드 사용 가능
14. flutter는 dart언어를 네이티브 언어로 컴파일한다, 웹 표준 기반의 기술을 지원하여 웹 콘텐츠 생성, 리액트 네이티브는 javascript 그 자체를 실행함 flutter가 성능이 더 낫다, 외부 타사 라이브러리 사용 가능, 빠른 개발을 위해 핫 리로드 사용
15. flutter는 고품질, 고성능 모바일 애플리케이션, 반응형 프로그래밍
16. google developers codelabs 사이트에서 추가 진행 가능