업계에서 10년 있은 뒤, 마음이 바뀐 소프트웨어 개발 토픽들
(chriskiehl.com)- 4년 전에도 같은 주제로 글을 작성했고, 10년째에 돌아보기로 해서 다시 작성함
바뀐 생각들
- 단순함은 저절로 주어지지 않고, 지속적 노력이 필요한 요소임
- 복잡성을 관리하거나 이해하는 것에 자부심을 가질 이유가 없음을 깨달았음
- 다양한 경험 수준이 섞인 팀에서는 Typed 언어가 필수적임
- Java는 재미없어서 오히려 훌륭한 언어임
- REPL은 설계 도구로서는 유용하지 않지만 탐색적 용도로는 유용함
- 실제 프로그래밍은 코드를 작성하기 전 단계에서 거의 다 이루어져야 함
- Frontend 개발은 Kafkaesque 악몽과 같은 영역이 되었고, 더 이상 즐겁지 않음
- 우아함이라는 개념은 실제 측정 지표가 되지 못함
- 제대로 된 매니지먼트는 매우 귀중한 존재임 (오랜 경력 동안 제대로 된 매니지먼트를 거의 보지 못했음)
- DynamoDB는 특정 워크로드에 정확히 부합한다면 좋은 데이터베이스임
- 객체지향은 잘 맞는 영역에서 탁월한 방식임. Functional만 맹신하는 태도는 어리석음
얻게 된 의견들
- 엔지니어링의 핵심은 소통
- Java에서 Monad 개념을 너무 심하게 적용하면 안 됨
- Query Planner는 혹독한 존재임
- 어떤 것이 '쉽다'고 느끼는 순간은 사실 제대로 이해하지 못했다는 신호임
- 신입 개발자에게 탐구와 실수를 할 수 있는 여유를 주어야 함
- Soft skill을 적극적으로 발전시켜야 함. 투자 효과가 즉각적으로 나타남
- 일반 애플리케이션 개발에서는 '진짜 범용 추상화'라는 것이 거의 없음. 필요한 코드만 작성하는 편이 좋음
- 반면, 라이브러리 개발은 추상을 설계하는 일임. 올바른 구조(알제브라적 형태)를 찾는 데 시간을 들여야 함
- ORM은 모든 언어, 모든 구현에서 문제가 많음. 그냥 SQL을 직접 작성하는 편이 나음
- Functional 프로그래밍의 문제는 종종 그 신봉자들 때문임
- 충분히 오랜 기간이 지나면 Serverless Functions 위에 시스템을 쌓은 것을 크게 후회하게 됨
- Type은 우리가 세상을 바라보며 내리는 단언임
- 분산 락은 여전히 대단히 어려운 문제임
- 형식적 모델링과 분석 능력은 반드시 갖춰야 할 역량임
- 통합 테스트 스위트에서 가장 중요한 특성은 격리성임
- DynamoDB는 일반 애플리케이션 개발을 위한 최악의 선택이 될 수도 있음
- 대부분의 사람들은 코드 '장인 정신'에 크게 관심이 없음. 관심을 가지는 사람을 소중히 대하되, 나머지 사람들과는 그들이 있는 자리에서 협업해야 함
- Gradual, dependently typed 언어가 미래라는 생각임
- 테스트 코드에는 아무리 많은 주석을 달아도 부족함이 없다는 확신임
바뀌지 않은 의견들
- 코드 스타일, 린팅 규칙 등 사소한 문제에 집착하는 사람들은 여전히 이상한 부류라고 생각함. 더 중요한 것에 집중해야 함
- 코드 커버리지는 코드 품질과 무관하다는 입장을 유지함 (많은 경우 반비례하는 경향도 있음)
- Monolith는 여전히 괜찮은 선택이라고 여김
- 수십 년간 축적된 RDBMS 연구와 개선을 이기는 것은 어렵다는 점을 인정함
- Micro-service를 적용하려면 합당한 이유가 필수적임 (요즘 점점 당연시되는 경향이 아쉬움)
- 대부분의 프로젝트(심지어 AWS 내부 프로젝트도 마찬가지)는 실제로 '스케일링'이 필요 없고, 오히려 스케일링을 전제로 설계하면 해가 되는 경우가 많음
- 프로젝트 매니저의 93%, 어쩌면 95.2% 정도는 사라져도 별 영향이 없거나 오히려 효율성이 높아질 것이라는 생각임 (4년 전보다 비율이 상승했음)
- 15년 차에는 또 어떻게 달라질지 지켜볼 예정임
서버리스위에 시스템을 쌓아서 후회중인 1인.
콜드스타트는 여전히 느리고,
어느순간 트래픽이 폭증하면서 온디멘드와 별반 차이가 없어졌고,
오만 수단을 다 동원해도 배포가 너무 느림.
팟캐스트에서 줏어 듣기로, 값이 타입에 영향을 주는 그런 타입시스템이라고 들었습니다. 이 글의 저자가 뻥셔널 언어 언급하는거 보니 그 얘기가 맞을겁니다. 뻥셔널 언어쪽에서 연구하고 만들고 있는거다보니....
예를 들면, List 타입이... 값들이 다 정렬이 되 있으면 SortedList 가 되는....
이런 성질이 있으면, 컴파일 시간에 타입검사가 더 많은걸 증명할 수 있겠죠.
어떤 함수가 SortedList 를 받아서 Sorted List 가 리턴되는 함수라면... 그런데 만약에 코드가 버그가있어서 Sort 상태를 깨버리면 컴파일 할때 type 에러가 나는거죠.
당연히.... 타입검사의 비용은 상당히 비싸겠죠...
실용성이 어디까지 와 있는지는 전혀 감이 안오네요.
대부분의 사람들은 코드 '장인 정신'에 크게 관심이 없음. 관심을 가지는 사람을 소중히 대하되, 나머지 사람들과는 그들이 있는 자리에서 협업해야 함
공감..
코드 커버리지는 코드 품질과 무관경우라면
- 커버리지가 형편없이 낮아 (제 기준으로는 80프로) 의미가 없거나
- 테스트 시나리오가 오로지 정상코드에서만 동작하는 노멀 시나리오만 작성되었을 경우
두가지가 아닐까 생각합니다.
테스트 코드는 높은 커버리지와 에러를 유발하는 다양한 시나리오로 같은 부분을 다른 인풋으로 여러번 테스트할때 비로소 의미를 가지게 된다고 생각합니다.
후자의 의미로 해석하는 편이 와닿네요. 코드 커버리지라는 숫자가 높은 게 코드 품질과 직결되는 게 아니라, 의미 있는 테스트 케이스로 채우는 게 중요하니까요
코드 스타일, 린팅 규칙 등 사소한 문제에 집착하는 사람들은 여전히 이상한 부류라고 생각함. 더 중요한 것에 집중해야 함
https://www.youtube.com/watch?v=JcY35HD77lg&t=828s
하지만 그냥 넘어가서는 안되는데, 사람인 이상 집중하기 어렵게 만드는 요소이므로 해결하고 진행하는 편이 좋다는 말도 있습니다.
Hacker News 의견
- 코드 스타일이나 린팅 규칙에 집착하는 사람들을 이상하게 보는 의견이 있음. 그러나 세부 사항에 신경 쓰는 것은 장인 정신을 소중히 여기는 것임
- 코드 작성 전에 대부분의 프로그래밍이 완료되어야 한다는 의견에 반대하는 개발자가 있음. 코딩과 설계를 반복적으로 진행하는 것이 중요하다고 생각함
- 복잡성을 관리하고 이해하는 것이 중요하다는 의견이 있음. 단순한 시스템은 복잡성을 다른 곳으로 옮길 뿐임
- Java가 지루한 언어라는 의견에 반대하는 사람도 있음. Spring 같은 Java 코드는 지루하지 않고 재미도 없다고 생각함
- 코드 작성 없이 프로그래밍이 완료되어야 한다는 의견에 반대하는 사람도 있음. 코드를 작성하지 않으면 현실에서 벗어나기 쉽다고 생각함
- 형식적 모델링과 분석이 필수적이라는 의견에 반대하는 사람도 있음. 실험이 더 중요하다고 생각함
- 테스트 코드에 주석을 많이 다는 것이 좋다는 의견이 있음
- 프론트엔드 개발이 악몽 같다는 의견이 있음. 그러나 React + Typescript + MobX 앱을 업데이트하는 데 큰 문제가 없었음
- 소프트웨어 개발은 조직의 단계에 따라 다르게 보아야 한다는 의견이 있음. 스타트업과 시장 적합성이 확립된 조직은 다르게 접근해야 함
- Java의 Checked Exceptions가 좋은 아이디어였다는 의견이 있음. 더 나은 오류 처리를 위해 약간의 문법적 개선이 필요했음
- 모놀리식 아키텍처가 여전히 좋다는 의견이 있음. RDBMS의 연구와 개선을 이기기 어렵다고 생각함
- 혼합된 경험 수준의 팀에서는 타입이 있는 언어가 필수적이라는 의견이 있음. 프로그래머의 관점을 고려해야 함
- 프로젝트 매니저의 대부분이 없어져도 큰 영향이 없을 것이라는 의견이 있음
- 코드 스타일에 대한 스트레스는 프로젝트 스타일을 맞추는 것이 중요하다는 의견이 있음
- 프론트엔드 개발이 악몽 같지만 가끔 즐긴다는 사람도 있음
- 우아함은 진정한 지표가 아니라는 의견이 있음. 우아한 솔루션이 항상 실용적이지는 않음
- DynamoDB가 일반 애플리케이션 개발에 최악의 선택이라는 의견이 있음. SQL이 더 적합한 경우가 많음