코딩과외#1 2020/03/06/금

오늘의 Action Item 🎯

• PyCharm 커뮤니티 버전으로 다운 받기

1. 코퀄의 코드 작성은 개발자의 목적지

• 고퀄의 코드를 작성하는 것은 개발자의 목적지임!
• 개발자란 코드를 생산해 내는 사람
• '코드 품질'이 중요한 이유:
  * 프로그램은 계속해서 업데이트 됨
  • 프로그램은 완성이라는 개념이 없음
  • 서비스가 종료될 때까지는 계속해서 수정됨
  • 프로젝트/서비스/프로그램은 생명체와 같아서 계속해서 개선/확장함
  • 그래서 '아키텍처'가 중요함

2. What is PROGRAM

• OOP 개념이 제일 중요!
• 핵심적 요소를 가지고 코드짜기
  

3. 컴파일 vs. 인터프리터의 장단점

소스코드 --> 변환 --> 프로그램

• 컴파일: 한꺼번에 변환, 변환에 대한 결과는 프로그램
  * 컴파일 시간 소요
  • 프로그램이 만들어진 이후에는 실행속도가 빠름! (추가변환이 필요없음)
  • 메모리에 적재되는 메모리의 양이 많음
  • 프로그램 파일 형태로 실행되기 때문에 소스코드가 은닉됨
• 인터프리터: 한줄씩 동적으로 실행, 변환에대한 별도의 결과물이 없음!
  * 스크립트 언어
  • 'line by line'으로 실행
  • 소스코드 자체가 노출 (장점: 개발 단위에서 서로 작업하기는 용이)
  • 소요시간: 줄단위 번역 시간 + 런타임시간
  • 요즘은 PC가 좋아서 위의 소요시간이 큰 문제는 되지 않음
  • 전체 프로그램이 적재되서 실행되는 것이 아니라서 메모리 부담적음
    

4. 프로그램이란?

• '자료구조'와 '알고리즘'으로 구성되어 있음
• 자료구조 왜 중요? => 어떻게 구현?모델링? 하는 가가 중요

5. 프로그램 언어에 대하여

• 메모리에 대한 개념을 기준으로 Native/Managed 언어로 나눔
• Native (=Un-managed)
  * 메모리를 개발자가 직접 제어
  • 예) C, C++ 만 존재
  • 운영체제, 펌웨어, 일부 코어 라이브러리
• Managed
  * 메모리를 개발자가 직접 제어 X
  • 예) C,C++제외한 나머지 언어라고 보면 됨
  • Garbage Collector가 reference counter가 0인 것을 해제
  • 메모리를 개발자가 직접 제어하는 것은 아니나, 개발자는 Garbage Collector가 어떻게 동작하는지 이해하고 더 나아가 이를 이용할 수 있어야함

6. 요즘 개발 트랜드

• 빠른 제품 생산성에 중점을을 두고 있음!
• 디테일로 중요하긴 하지만 그보다 생산성이 더 중요! (디테일<생산성)

7. 변수

• "0.1 x 0.1"은 과연 0.01일까?
  * 대답은 No!
  • 소수는 컴퓨터로 표현이 부정확함
  • 소수는 근사값으로 표현됨
  • 소수는 부정확하다는 것을 인지하고 코딩할 것

    >>> 0.1 * 0.1 == 0.01
    False
    >>>
    >>> 0.1*0.1
    0.010000000000000002
    >>>

• L value와 R value
  * L = R
  • R value의 값/type을 기준으로 L value가 정의 됨!
  • L value에는 mutable만 올 수 있음!
  • immutable => 변경불가 (예: True, False, 상순, 문자열)

8. 연산자

• 연산자에도 비용이 존재!
  * 될 수 있으면 비용이 적은 연산자로 대체해서 사용할 것!
  • 이것으로 고려하고 안고려하고는 큰 차이를 만들어 낸다!
  • 쓸데없는 계산을 안하도록 코딩하자!

9. Code Convention

• 함수 naming
  * ex) is_connect()
• PEP8 : 파이썬 코드스타일 표준

10. 콘솔창의 입출력 용도

• 개발/개발자/관리자 레벨에서 빠르게 입출력을 볼 수 있는 것이 장점

11. IDE (통합 개발 시스템)

12. Python

• 파이썬 버전은 프로젝트마다 다르다 (독립적)
• 가상환경과 파이썬 버전
• 파이썬마다 인터프리터 버전 존재?
• 프로세스는 하나의 프로그램?

13. 조건문

• 조건문의 논리흐름의 분기로 인식할 것
• "else"는 꼭 쓸 것! (모든 경우를 커버하기 위해)
• 들여쓰기가 더해질 수록 depth가 깊어져서 프로그램 복잡도가 올라감에 주의!
• 가독성은 곧 구조 아키텍처, 코드품질이다!
• 코드를 파악하는 시간이 짧아야 한다!
• 가독성! 로직개선!

14. 좋은 개발자가 되는 길

• 지금 여기서 개선할 사항이 있는가? 고민
• 지금 여기서 위험사항이 있는가? 고민
• 계속해서 더 나은 코드를 위해 refactoring해야 함!
• 잘하는 사람이 짠 코드를 많이보고, 잘하는 사람으로부터 코드리뷰를 많이 받을 것!
• 코드리뷰와 아키텍처 중요!

The END :-)