마음을 바꾼 것들: 과거엔 싸웠지만, 이제는 믿게된 것들
- 다양한 경험 수준을 가진 사람들로 구성된 팀에서는 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년차가 되었을때 뭐가 또 바뀌거나 뒤집혔는지 살펴보겠음
https://news.hada.io/topic?id=3635
=======
자바는 그렇게 나쁜 언어가 아닙니다!
하지만 Spring과 끔찍한 xml들은 별로 보고싶지 않네요.
그렇지만 저는 python이나 ruby에는 정이 안 가더라고요. 그렇다고 Java를 사랑하는것도 아니지만요 ㅎㅎ
항상 그렇지만 프로젝트에 따라 어떤 규칙은 무시해도 되는게 있어서 항상 유연한게 좋긴 합니다.
실버 불렛은 없다는것만 항상 유의하면...
제 최애는 스위프트고 그 다음이 코틀린, 타입스크립트 정도로 볼 수 있겠네요.
그런데 스위프트는 써먹을 곳이 iOS 앱 개발 말고는 별로 없네요...ㅠ_ㅠ
뭔가 저런 스타일의 글은 광역 어그로를 끄는지라 원글에도 가보면 아니나 다를까 엄청난 쓰레드가 달리는군요.
저도 몇가지 동의하지 않는것도 있고, 본인이 제대로 사용을 못하면서 필요없다라고 하는것도 있긴 하지만 대체적으로는 비슷한 의견이긴 하네요.
저런식의 본인 경험에 의해 믿게 된 것들은 참고용으로만 보는게 좋을것 같습니다.
가끔 보면 유명한 누가 이렇게 얘기했다더라, 내가 지금까지 살아보니 이게 맞다라고 하면서
다름을 인정하지 않고 이건 틀렸어라고 하게 되면 결국 나이가 들면서 소위 말하는 꼰대가 되어 가는것 같습니다.
개발은 Java15 + Groovy 를 사용해서 시작을 했었고, Groovy는 Bean 의 getter/setter를 매번 생성해주는걸 피하기 위해서였고, Lombok 같은 라이브러리는 모두 싫어했기때문에 고려대상이 아니었습니다.
개발하면서 느낀 단점들은:
* Java15에서 추가된 record 를 사용하려고 했으나 사용가능 용도가 한정적이었고,
* Stream API 는 사용할때마다 쓸데없이 코드가 길어졌습니다. groovy, scala, kotlin 등을 사용해본 사람들은 모두 왜 이런 쓸데없이 verbose한 코드들을 타이핑하고 있어야하는가 하는 마음이 드는걸 이해할 수 있을듯 합니다.
* 함수를 파라미터로 넘기거나 리턴값으로 사용하려고 해도 마찬가지로 너무 불편했습니다.
* 테스트 코드 작성시에도 코드가 너무 장황해져서 코드 가독성이 좋지 않았습니다.
* kotlin 과 같은 nullable 타입이 없어서 NullPointerException을 컴파일타임에 걸러주지 못합니다.
* IntelliJ 에서는 문제없는데 vscode 사용자들은 Java+Groovy 조인트 컴파일을 지원하지 않아서 Groovy 코드를 참조하는데서는 모두 에러가 떠서 vscode는 단순 텍스트 에디터로 전락하게 됨.
* 장기적으로 개발해가면서 사용할 서비스인데, 점점 쇠락해가는 언어와 발전가능성이 높은 언어 중 어떤 것을 선택할지에 대한 고민.
대충 생각나는건 이정도였던것 같습니다.
개발 초기라 Java클래스 400여개, 테스트 클래스 40개 정도라서 많지 않아서, 팀원들에게 코드 프리즈하고 하루만 시간달라고 하고 하루만에 뜯어고쳤습니다.
IntelliJ 에서 Java->Kotlin 변환을 지원하기 때문에, 복잡한 클래스정도만 이상하게 변환된거 수동으로 변환하고 하면 금방합니다. 그리고 TDD 로 개발을 해서 테스트 코드가 있어서 변경하고 나서도 제대로 변환되었다는 마음의 안정을 얻을 수 있었네요.
코틀린 변환에 걸리는 시간은 변환하는 사람의 코틀린 사용 수준에 따라 많이 달라질 수 있을듯합니다.