업계에서 6년 있은 뒤, 마음이 바뀐 소프트웨어 개발 토픽들
(chriskiehl.com)마음을 바꾼 것들: 과거엔 싸웠지만, 이제는 믿게된 것들
- 다양한 경험 수준을 가진 사람들로 구성된 팀에서는 Typed 언어가 더 좋음
- 스탠드업 미팅은 신참들을 살펴보는데 유용
- 스프린트 회고는 유용한 것과 좋지 않은 것(애자일/스크럼 마스터가 모든 사람의 시간을 낭비하는)이 따로 있음
- 소프트웨어 아키텍쳐가 다른 무엇보다 중요. 좋은 추상화의 나쁜 구현은 코드 베이스에 해를 입히지 않음. 나쁜 추상화나 누락된 레이어들 때문에 모든 것이 안 좋아짐
- 자바는 그렇게 나쁜 언어가 아님
- 재치있는 코드는 보통 좋은 코드가 아님. 명확성이 모든 것보다 우선
- 어떤 패러다임에서도 잘못된 코드를 작성 가능
- "베스트 프랙티스"는 상황마다 다르고, 모든것에 적용가능하지 않음. 맹목적으로 따라가면 바보가 됨
- 필요가 없는데 확장 가능한 시스템을 설계하면 나쁜 엔지니어가 됨
- 정적 분석은 유용함
- DRY는 최종 목표가 아닌 특정 문제를 피하는 것
- 일반적으로 RDBMS > NoSQL
- 함수형 프로그래밍은 만병 통치약이 아닌 또 다른 도구임
도중에 내가 픽한 의견들 :
- YAGNI > SOLID > DRY : 이 순서대로
ㅤ→ You Aren't Gonna Need It : XP의 원칙중 하나
ㅤ→ SOLID : 객체지향 설계 5대원칙
ㅤㅤSigle responsiblity
ㅤㅤOpen-close
ㅤㅤLiskov substitution
ㅤㅤInterface segregation
ㅤㅤDependency inversion
ㅤ→ DRY : Don't Repeat Yourself
- 연필과 종이는 잘 사용되지 않는 최고의 프로그래밍 도구
- 실용성을 얻기위해 순수성을 거래하는 것은 일반적으로 좋은 선택
- 더 많은 기술을 추가하는 것은 좋은 선택이 아님
- 고객과 직접 대화하면 더 적은 시간으로 더 정확하게 문제에 대해서 더 많이 알 수 있음
- "Scalable" 이란 단어는 소프트웨어 엔지니어의 마음에 신비롭고 깜짝 놀라게 하는 힘이 있음. 살짝 입밖에 내는 것만으로 그들을 타락한 광란에 빠져들게 함. 이 단어를 사용함으로써 무자비한 행동들이 정당화 됨
- "엔지니어"라고 불림에도 불구하고, 대부분의 결정은 뒷받침하는 분석,데이터,숫자가 없는 화물숭배(cargo-cult) 임
ㅤ→ 화물숭배: 기술적으로 진보한 누군가(사회/선조)가 배나 비행기에 특별한 화물을 가지고 실어 올 것이라고 믿으면서 기다리는 풍습
- 90% 어쩌면 93%의 프로젝트 매니저들은 효과나 효율성면에서 이득이 없어서 내일이라도 없어질수 있음
- 100번의 인터뷰를 하고나니, 인터뷰방식은 완전히 망가져 있음. 나 역시 이걸 개선할 방법을 모르겠음
바뀌지 않은 예전 의견들:
- 코드 스타일, 린팅 규칙 및 기타 사소한 것들을 강조하는 사람들은 미친 괴짜들임
- 코드 커버리지는 코드 품질과는 전혀 상관없음
- 모노리스들은 대부분의 상황에서 꽤 좋음
- TDD 순수주의자들은 최악임. 그들의 연약한 작은 마음은 다른 워크플로우가 존재한다는 것을 처리할 수 없음
* 10년차가 되었을때 뭐가 또 바뀌거나 뒤집혔는지 살펴보겠음
이런 글도 있더라고요. 『HARD CODE』라는 책에 나오는 내용이라고 합니다.
https://johngrib.github.io/wiki/better-interview/
해커뉴스에는 다른 개발자 및 20년차 이상의 엔지니어들이 출동해서 추가 댓글을 적고 있네요.
https://news.ycombinator.com/item?id=25887373
타입 체크만 하면 해결되는 버그가 상당하다보니 계속 제기되는 이슈일 듯 합니다. 안전하게 타입을 처리하는 방법은 계속 개선되어 가고 있는 중이기도 하고요.
(하지만 TypeScript 는 좀 어렵긴 하더군요 ㅠ.ㅠ)