Today Clip Article 2020-03-30

오늘 (2020-03-30) 원노트에 클리핑한 글들에 대한 기록을 남겨 놓는다

#clip #development #gossip

프로비저닝(Provisioning) 이란?

Jins’ Dev Inside

곧 같이 적겠지만 도커에 관련된 초보 기술 블러그를 읽으면서 나온 용어다. 서버 / 운영체제 / 소프트웨어 / 계정 프로비저닝에 대해서 상세하게 설명한다.

도커(Docker) 입문편 / 컨테이너 기초부터 서버 배포까지

44BITS

도커에 ‘도’도 잘 모르는 내가 아무런 막힘 없이 편하게 읽을 수 있는 기초 내용이다. 디지털오션을 이용해서 직접 배포하는 내용까지 있어서 기본 개념 및 실습 해 보기에는 정말 좋은 글이다.

LINE에서 전 직원이 재택 근무하면서 생산성을 유지하는 방법

LINE Engineering

재택근무를 하면서 느낀 내용이 모두 비슷하리라. 여기서 적어 놓은 내용도 공감하는 것이 매우 많다. 하지만 내가 했던 부분은 하드웨어적인 부분이 많아서 재택에는 한계가 발생하는 경우가 많았다면, 소프트웨어적이 요소가 많다면 더 좋은 성과를 내는 방법이 존재할 것으로 생각이 든다.

“객체지향 프로그래밍 – 역대급 재난인가?”외 재미있는 개발 이야기

Kenu Heo

소소하게 만담을 하면서 여러가지 주제에 대해서 이야기를 해 주는 영상이다. 매일은 아니지만 나름 핫한 내용으로 구성을 하고 있다. 이 영상은 한달 전 쯤에 올라왔는데 이제야 봤다. 전반 정도의 시간을 할애한 항목이 있는데 그게 제목과 같은 내용이다. 아주 지대로 어그로를 끌고 싶었던 글인거 같은데, 능력이 부족한 나로써는 다 이해가 되지는 않더라.

주장

  • OOP가 절차적인 프로그래밍 보다 좋다는 객관적인 증거는 없음

  • 동물, 개, 사람등의 계층이 깨끗하지만, 애플리케이션 복잡도가 높아 지면 평평해짐. 디자인패턴을 도입하면 추가적인 복잡성이 발생

  • OOP는 시한폭탄으로 코드 기반이 커지면 언젠가폭발 -> 레거시코드 기반이 되므로 재작업

  • OOP는 인간두뇌에 자연스럽지 않음 -> 사람은 행동을 중심으로 사고함

Linus Torvalds가 C++를 싫어하는 이유

  • 프로그래머가 선택할 수 있는 옵션이 적을수록 코드의 탄력성이 높아짐

  • C로 제한함으로써 이를 달성할 수 있다고 주장 -> 도로의 제한속도가 있는 이유

코드 복잡성

  • 소프트웨어 개발의 가장 중요한 측면은 복잡도를 낮추는것

  • 코드기반이 복잡하고 유지보수가 불가능하다면 100% 테스트 커버리지도 쓸모가 없어짐

  • 코드기반이 복잡한 이유 - 공유가능한 변경상태(전역변수까지 들어가면…), 잘못된 추상화, 낮은신호 대 잡음비(boiler plate code, 특히자바…)

상태의 문제

  • 가변상태 - 메소드를 호출할 때 발생하는 상황과 부작용이 무엇인지 이해를 해야 하는 어려움

  • 인간 두뇌의 한계 - 5+-2 이론 -> 가변 상태의 정신 저글링이 OOP의 핵심이므로 이를 제대로 다루기가 어려움

  • •OOP는프로그램전체의상태를분산시켜코드구성문제를더욱악화시키고, 흩어진상태는다양한객체들사이에서무차별적으로공유됨

  • 레고 트럭 조립(50개상자에 무작위로 넣은 부품을 꺼내 조립하려면?)

  • 동시성 문제까지 어려움을 유발 -> 병행/병렬작업을 위해 스레드 잠금, 뮤텍스등등 도입 -> 교착상태유발, 디버깅 어려움 유발

캡슐화의 문제

  • 캡슐화는 OOP의 가장 큰 장점 중 하나(외부접근으로 부터 객체 내부상태를 보호)

  • 하지만 트로이목마 -> 안전한듯이 보이게 만들지만, 안전하지 않은 코드가 코드기반에 침투해서 썩게 만드는 문제

모델링문제

  • 현실세계는 계층적이지 않음

  • 부모의 DNA를 물러 받더라도, 이를 변경 시킬 수 없음 -> 부모의 행동을 물려 받지도 부모의행동을 재정의할 수도 없음

명사왕국

  • OOP의 근본적인 한계는 모든 것을 명사로 강제

어려운 단위 테스트

  • 의존성을 별도 클래스로 추출, 새로 작성된 클래스의 인터페이스 작성, 필드선언, mock프레임워크로 종속성 흉내내기, 종속성 주입을 위한 IoC프레임워크 사용 등등…

신호대잡음

  • 상용구 코드는 프로그램을 컴파일하는데 필요한 ‘소음’ -> boiler plate 코드는 작성에 시간이 걸리고, 잡음이 추가 되어 코드기반을 읽기 어렵게 만드는 주범

리펙토링

  • OOP 코드는 리펙토링이 어려움 -> 복잡한 의존성 그래프와 코드 기반에 흩어져 있는 상태가 주범

반창고

  • 디자인패턴 - OOP의 단점을 해결하기 위해서만 존재

문제공장

  • 유지보수가 용이한 객체지향 코드작성은 무척어렵다 -> 일관성이 없고, 표준을 준수하지 않은 OOP 코드기반 vs 오버엔지니어링으로 잘못된 추상화가 존재하는 코드 탑

결국

1

OOP가업계를지배하는이유

  • 자바 - 처음에는 단순했으나 OOP를 강요

  • C# - 우수한 개발자 도구가 포함된 .Net 생태계 구축 + 비주얼 스튜디오 조합

대안 - 함수형프로그래밍