Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

2020년 2월 22일 개발 이야기 정리

1,174 views

Published on

유튜브에서 방송한 자료입니다. https://www.youtube.com/watch?v=Htz33OAhYvo

개발 이야기 유튜브 리스트는 다음과 같습니다: https://www.youtube.com/playlist?list=PLdntWJk2tJPKvRB0mSqC5tyKUv7HFtcqg

Published in: Software
  • Be the first to comment

  • Be the first to like this

2020년 2월 22일 개발 이야기 정리

  1. 1. 2020년 2월 22일 개발 이야기 정리 박재호(jrogue@gmail.com)
  2. 2. 참고 자료 • <컴퓨터 vs 책> 블로그 • http://jhrogue.blogspot.com/ • OKJSPTV 유튜브 방송 • https://www.youtube.com/watch?v=Htz33OAhYvo
  3. 3. 오늘의 짤방 프로그래머: 돌아가면 된거지— (via @hanalen_)
  4. 4. (오늘의 논쟁) 객체지향 프로그래밍 – 역대 급 재난(1) • https://medium.com/better-programming/object-oriented- programming-the-trillion-dollar-disaster-92a4b666c7c7 • 주장 • OOP가 절차적인 프로그래밍보다 좋다는 객관적인 증거는 없음 • 동물, 개, 사람 등의 계층이 깨끗하지만, 애플리케이션 복잡도가 높아지면 평평해짐, 디 자인 패턴을 도입하면 추가적인 복잡성이 발생 • OOP는 시한폭탄으로 코드 기반이 커지면 언젠가 폭발 → 레거시 코드 기반이 되므로 재작업 • OOP는 인간 두뇌에 자연스럽지 않음 → 사람은 행동을 중심으로 사고함 • 리누스 토발즈이 C++를 싫어하는 이유 • 프로그래머가 선택할 수 있는 옵션이 적을수록 코드의 탄력성이 높아짐 • 리누스 토발즈는 C로 제한함으로써 이를 달성할 수 있다고 주장 → 도로의 제한속도가 있는 이유
  5. 5. (오늘의 논쟁) 객체지향 프로그래밍 – 역대 급 재난(2) • (계속됨) • 코드 복잡성 • 소프트웨어 개발의 가장 중요한 측면은 복잡도를 낮추는 것 • 코드 기반이 복잡하고 유지보수가 불가능하다면 100% 테스트 커버리지도 쓸모가 없 어짐 • 코드 기반이 복잡한 이유: 공유 가능한 변경 상태(전역변수까지 들어가면…), 잘못된 추 상화, 낮은 신호 대 잡음비(boiler plate code, 특히 자바…) • 상태의 문제 • 가변 상태: 메소드를 호출할 때 발생하는 상황과 부작용이 무엇인지 이해를 해야 하는 어려움 • 인간 두뇌의 한계: 5+-2 이론 → 가변 상태의 정신 저글링이 OOP의 핵심이므로 이를 제대로 다루기가 어려움
  6. 6. (오늘의 논쟁) 객체지향 프로그래밍 – 역대 급 재난(3) • (계속됨) • 상태의 문제(계속됨) • OOP는 프로그램 전체의 상태를 분산시켜 코드 구성 문제를 더욱 악화시키고, 흩어진 상태는 다양한 객체들 사이에서 무차별적으로 공유됨 • 레고 트럭 조립(50개 상자에 무작위로 넣은 부품을 꺼내 조립하려면?) • 동시성 문제까지 어려움을 유발 → 병행/병렬 작업을 위해 스레드 잠금, 뮤텍스 등등 도 입 → 교착 상태 유발, 디버깅 어려움 유발 • 캡슐화의 문제 • 캡슐화는 OOP의 가장 큰 장점 중 하나(외부 접근으로부터 객체 내부 상태를 보호) • 하지만 트로이 목마: 안전한 듯이 보이게 만들지만 안전하지 않은 코드가 코드 기반에 침투해서 썩게 만드는 문제
  7. 7. (오늘의 논쟁) 객체지향 프로그래밍 – 역대 급 재난(4) • (계속됨) • 모델링 문제 • 현실 세계는 계층적이지 않음 • 부모의 DNA를 물러받더라도 이를 변경시킬 수 없음 → 부모의 행동을 물려받지도 부 모의 행동을 재정의할 수도 없음 • 명사 왕국 • OOP의 근본적인 한계는 모든 것을 명사로 강제 • 어려운 단위 테스트 • 의존성을 별도 클래스로 추출, 새로 작성된 클래스의 인터페이스 작성, 필드 선언, mock 프레임워크로 종속성 흉내내기, 종속성 주입을 위한 IoC 프레임워크 사용 등등 …
  8. 8. (오늘의 논쟁) 객체지향 프로그래밍 – 역대 급 재난(5) • (계속됨) • 신호 대 잡음 • 상용구 코드는 프로그램을 컴파일하는 데 필요한 ‘소음’ → boiler plate 코드는 작성에 시간이 걸리고 잡음이 추가되어 코드 기반을 읽기 어렵게 만드는 주범 • 리펙토링 • OOP 코드는 리펙토링이 어려움 → 복잡한 의존성 그래프와 코드 기반에 흩어져 있는 상태가 주범 • 반창고 • 디자인 패턴: OOP의 단점을 해결하기 위해서만 존재 • 문제 공장 • 유지보수가 용이한 객체 지향 코드 작성은 무척 어렵다 → 일관성이 없고 표준을 준수 하지 않은 OOP 코드 기반 vs 오버엔지니어링으로 잘못된 추상화가 존재하는 코드 탑
  9. 9. (오늘의 논쟁) 객체지향 프로그래밍 – 역대 급 재난(6) • 결국은…
  10. 10. (오늘의 논쟁) 객체지향 프로그래밍 – 역대 급 재난(7) • OOP가 업계를 지배하는 이유 • 자바 • 처음에는 단순했으나 OOP를 강요 • C# • 우수한 개발자 도구가 포함된 .Net 생태계 구축 + 비주얼스튜디오 조합 • 대안 • 함수형 프로그래밍
  11. 11. (생산성) Kasaya - 브라우저 자동화를 위한 위지윅 스크립팅 언어(1) • https://github.com/syscolabs/kasaya • 준비물 • JDK • 크롬 66 이상 • Node.js(v12 이상)
  12. 12. (생산성) Kasaya - 브라우저 자동화를 위한 위지윅 스크립팅 언어(2) • 구글에서 cat 입력 결과
  13. 13. (생산성) 8년 동안 사이드 프로젝트에서 배 운 교훈(1) • https://www.junglecoder.com/blog/idea-chain-themes • 핵심 정리 • 빈 상태에서 프로그래밍은 쓸모가 없다: 공학용 계산기를 만들든, 게임을 만 들든 구체적인 목표를 달성하기 위해 프로그래밍을 하라 • 프로그래밍 언어 구현은 어렵지만 보람이 있다: 간단한 구문 분석 루틴을 작 성하면 많은 것을 배운다 • 생각을 조직화해야 하지만 쉽지는 않다: 주어진 시간 동안 뭔가를 추적하기 위해 도움이 되는 시스템을 구축하자(예: Trello, 메모앱 등) • 검색은 디버깅을 위한 유용한 도구: 로컬 컴퓨터를 검색하는 과정에서 유용 한 도구를 활용하자(예: everything)
  14. 14. (생산성) 8년 동안 사이드 프로젝트에서 배 운 교훈(2) • Everything • https://voidtools.com/ko-kr/ • 실시간 파일/폴더 검색 • 색인 속도가 엄청나게 빠름(몇 초 이내 완료) • 모든 디스크에 담긴 파일 이름/디렉터리 이름을 검색해줌 • 윈도우 NTFS 색인을 활용해 speed up!
  15. 15. (개발) Deno 설치 • https://dev.to/kushal/getting-started-with-deno-3a4e • Deno는 자바스크립트와 타입스크립트를 위한 안전한 런타임
  16. 16. (개발) Theia: Cloud & Desktop IDE • https://theia-ide.org/ • Java/JavaScript/Python emd 60가지 언어 지원 • 내장 터미널 • 데스크탑과 클라우드에서 동작 • 오픈소스

×