[TechNews] 유용한 개발 관련 아티클 및 영상 #21

1. 유용한 개발 관련 아티클 및 영상 #21

---

JAVA 10에 도입된 지역변수 타입 추론에 대한 스타일 가이드

• 타입 추론에 대하여
  • 타입 추론은 간결함을 가능하게 해주지만, 중요한 타입 정보를 생략하여 가독성을 떨어뜨림
  • 모든 기능과 마찬가지로 판단력을 가지고 사용해야 하며, 언제 사용해야 하고 언제 사용하지 말아야 하는지에 대한 포괄적인 규칙은 없음
  • 이 문서의 목표는 주변 코드가 변수 선언에 미치는 영향을 살펴보고, 몇 가지 장단점을 설명하고, 변수의 효과적인 사용을 위한 지침을 제공하는 것임
• 코드 작성의 원칙들
  1. 코드를 읽는 것이 작성하는 것보다 중요하다
     1. 코드는 작성하는 것보다 읽는 경우가 훨씬 더 많음
     2. 따라서 코드의 작성은 원저자가 아닌, 미래의 독자에게 미치는 영향에 따라 결정되어야 함
  2. 코드는 로컬 추론 시에 명확해야 한다
     1. 독자는 var 선언을 보고 어떻게 사용되는지, 무슨 일이 일어나고 있는지 즉시 이해할 수 있어야 함
     2. 코드가 코드 일부의 문맥만 보고도 쉽게 이해할 수 있어야 이상적임
     3. var 선언을 이해하기 위해 여러 위치를 살펴야 한다면, var 사용이 적합하지 않거나 코드 자체에 문제가 있을 수 있음
  3. 코드 가독성은 IDE에 의존해서는 안된다
     1. 타입 선언의 경우, var를 모든 곳에서 사용하지 않는 이유는 다음과 같음
     2. 첫 번째로 코드가 IDE 외부에서 읽히는 경우가 많음
     3. 두 번째로 IDE 내에서 코드를 읽을 때도 추가 정보를 위해 명시적인 작업이 필요할 수 있음
     4. 코드는 스스로를 드러내야 하며, 도구의 도움 없이도 코드 자체로 이해할 수 있어야 함
  4. 명시적인 타입 선언에는 장단점이 있다
     1. 명시적인 타입 선언으로 인해 유용한 정보를 방해하는 불필요한 요소가 추가될 수 있음
     2. 명시적인 타입 선언을 생략하면 혼란을 줄일 수 있지만, 생략해도 이해도가 떨어지지 않는 경우에만 가능해야 함
• 가이드라인
  • 유용한 정보를 제공하는 변수명을 선택하라
    • 변수 선언 시에는 변수명을 통해 의미와 용도를 전달할 수 있음
    • 명시적인 타입을 생략할 때는 종종 변수명을 개선하는 작업이 수반되어야 함
  • 지역 변수의 스코프를 최소화하라
    • 특히 var을 사용하여 명시적인 타입 선언을 생략하는 경우에 더욱 중요함
    • 이를 위해 var 선언을 풀고, 코드를 변경한 후에 다시 var로 변경하는 전략을 사용할 수 있음
  • 객체 초기화 시에 충분한 정보를 제공한다면 var을 고려하라
    • 생성자로 객체를 생성하는 경우, 클래스의 이름은 종종 왼쪽의 명시적 타입으로 반복되므로 타입 이름이 긴 경우 var를 사용하면 정보 손실 없이 간결하게 표현할 수 있음
    • 정적 팩토리 메서드를 사용하는 경우, 그 이름에 충분한 타입 정보가 포함되어 있다면 var를 사용할 수 있음
  • 체이닝되거나 중첩되는 표현식을 제거하기 위해 var을 사용하라
    • 긴 메서드 체인을 분리하고자 하는 경우에 var을 사용할 수 있음
  • 로컬 변수를 사용한 '인터페이스 프로그래밍'에 대해 너무 염려하지 마라
    • var를 사용하면 인터페이스 타입으로 선언되지 않고 구체 타입이 추론됨
    • 하지만 위의 가이드라인을 잘 따르면 구체적인 타입의 누수로 인한 문제를 쉽게 완화할 수 있음
  • 다이아몬드 또는 일반 메서드와 함께 var를 사용하는 경우에 주의하라
    • var itemQueue = new PriorityQueue<Item>() 로의 선언은 괜찮음
    • var itemQueue = new PriorityQueue<>()로의 선언은 Object로 추론되어 문제가 생길 수 있음
  • 리터럴과 함께 var를 사용할 때는 주의하라
    • 원시 리터럴은 var 선언의 이니셜라이저로 사용할 수 있는데, 일반적으로 타입 이름이 짧기 때문에 이러한 경우 var를 사용하는 것이 큰 이점을 제공하지는 않을 것임
    • 일반적으로 boolean, character, long, string의 경우에는 var를 사용해도 문제가 없음
    • 하지만 숫자 값(Number Value) 특히 정수형을 사용하는 경우에는 주의해야 함, 대표적으로 Long 타입이 Integer로 추론될 수 있음

 

출처: https://openjdk.org/projects/amber/guides/lvti-style-guide

 

 

 

소프트웨어는 공학(Engineering)일까? 공예(Craft)일까?

• 공학적인 측면
  • 소프트웨어 개발은 문제에 대해 과학적 접근법에 기반해서 해결착을 찾아야 함, 과학적 접근법은 다음의 4단계로 구성됨
    • Characterize(특징화): 현재 상태를 관찰
    • Hypothesize(가설): 당신의 관찰을 설명할 수 있는 서술, 이론을 만듦.
    • Predict(예측): 가설을 기반으로 예측
    • Experiment(실험): 예측을 테스트
  • 이러한 접근법은 학교에서 많이 배우고 연습할 수 있으며, 특히 대학에서 전산 관련 학과를 공부한 분들이라면 전공과목 과제를 풀 때 이런 접근을 많이 함
  • 합리적, 논리적 사고에 기반해서 가정을 세우고, 실험을 해서 다음에도 동일한 문제는 이 방법으로 해결할 수 있다는 것을 보이는 경험임
  • 하지만 업무의 대부분은 운영을 하면서 기능을 추가하고, 기존 기능을 변경 등이 80% 이상을 차지함
  • 이런 부분은 대학교에서 교수님들에게 배우기 어렵다고 생각하는데, 교수들의 대부분은 서비스를 운영해 본 경험이 없으실 것이기 때문임
• 공예적인 측면
  • 운영을 하다 보면 공예적인 측면이 많이 필요하다고 느낄 수 있음
  • 특히 책에서 답을 찾을 수 없는 경우가 많은데, 함께 일하는 동료 개발자들에게서 배우는 경우가 많음
  • 요즘은 짝프로그래밍이나 몹프로그래밍을 통해 알려주는 것이 훨씬 빠르고, 효과적으로 온보딩하는데 도움이 됨. 즉 공예적인 측면, 경험적인 측면이 더 필요해진 것 같음
  • 알아서 하라고 던져주기보다는 같이하면서 빠르게 온보딩시키는 게 맞다고 생각하며, 신규 입사자들이 어려워하는 것은 개발 자체가 아니라 배포, 배포 후 검증, CS 대응 등인데 이런 업무는 함께 일하지 않고는 배우기 어려운 영역이기 때문임
• 결국 이론과 경험이 조화를 이뤄야 함, 경험적인 부분이 반드시 필요하지만 이론적 성장과 동반되었을 때 둘의 시너지가 폭발적으로 증가함

 

출처: https://brunch.co.kr/@cleancode/75

 

 

 

OpenAI와 Tesla AI 조직의 핵심 연구원이 학부생에게 전하는 조언

• 대학생들은 좋은 성적을 받고 싶어하지만, 사실 성적이 매우 나쁘지 않은 한 아무도 당신의 성적에 신경 쓰지 않을 것임
• 시간은 소중하고 한정된 자원이므로, 시험에서 실수하지 않을 정도로만 공부한 후에는 훨씬 더 중요한 일들에 집중해야 함
• 성적보다 중요한 요소들로는 다음과 같은 것들이 있을 수 있음
  • 실제 경험을 쌓고, 실제 코드 기반 프로젝트나 단순한 코스워크 이외의 문제를 해결하는 것이 매우 중요함
  • 당신을 알고 추천서를 써줄 수 있는 교수님이나 사람들은 당신이 주도적이고, 열정적이며, 추진력이 있다는 것을 적어줄 것임
  • 취업을 생각한다면 인턴십을, 대학원 진학을 고려한다면 연구 경험을 쌓을 수 있음
  • 추천서에 당신이 주도적이고, 동기 부여가 되어 있으며, 독립적으로 사고하는 사람이라고 적어주는 저명한 교수님이 있다면, 성적 같은 사소한 것들은 완전히 무색하게 만들 수 있음

 

출처: https://www.linkedin.com/posts/danielylee_stanford를-졸업하고-openai와-tesla의-ai-조직의-핵심-연구원으로-activity-7196553468776443904-hkGO

 

 

 

리액트 컴파일러의 오픈소스화

• 더 이상 useMemo, useCallback 등으로 메모이징을 직접 하지 않아도, 리액트 컴파일러가 빌드 타임에 해줌
• Rules of React를 지키는 한, 기본적으로 퍼포먼스 최적화를 위해 특별히 뭔가 할 필요가 없음
• React Compiler는 Server Components와 더불어 React가 제시한 리렌더링 문제를 스스 로 해결해가는 과정인 것 같음
• Server Components는 서버에서 단 한 번 실행되므로 리렌더링을 신경 쓸 필요가 없고, React Compiler는 클라이언트 사이드에서 필요한 메모이제이션을 자동으로 처리해줌

 

출처: https://www.linkedin.com/posts/wooing_react-compiler가-오픈소스화-되었습니다-간단히-살펴보자면-activity-7196726451520344064-S4AY

 

 

 

테스트 주도 개발(TDD)의 장단점: Bob Martin과 Jim Coplien의 토론

• TDD의 3가지 원칙들
  • 테스트 주도 개발자들은 실패하는 단위 테스트를 작성하기 전까지는 한 줄의 상용 코드를 작성하지 않음
  • 실패하기에 충분한 양의 단위 테스트만을 작성해야 함(컴파일 실패도 실패에 포함됨)
  • 현재 실패하는 테스트 코드들을 성공시킬 만큼만 상용 코드를 작성해야 함
• TDD로 개발하면 갖는 우려들(많은 고객과의 폭넓은 작업과 스크럼 마스터 등과의 상호작용에서 기인함)
  • 아키텍처나 프레임워크 없이 TDD를 사용한다는 것, TDD를 사용해 아키텍처를 이끌어내야 함, 그러다보니 단위테스트를 하는 입장에서 자연스럽게 절차적 하향식 아키텍처를 초래함
  • GIU를 망가 뜨리는데, 더 이상 시스템 구조를 도메인 지식이나 사용자의 개념 모델에 따라 이끌어갈 수 없음
• 공통의 의견
  • 아키텍처는 한 번에 완성되는 것이 아니며, 좋은 설계 기술과 아키텍처 기술을 활용해 다양한 실험을 통해 점진적으로 진화하며 구축되는 것임
  • 최소한으로 만들어야 하며, 추측에 기반한 아키텍처를 설계해서는 안됨

 

출처: https://www.youtube.com/watch?v=eRxc4PD6RN0