개발한당

자유 [펌] 업계에서 6년 있은 뒤, 마음이 바뀐 소프트웨어 개발 토픽들 12

2
2021-01-25 12:10:22 수정일 : 2021-01-25 12:15:32 223.♡.145.89
REGENTAG.

마음을 바꾼 것들: 과거엔 싸웠지만, 이제는 믿게된 것들


- 다양한 경험 수준을 가진 사람들로 구성된 팀에서는 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들은 별로 보고싶지 않네요.

출처 : https://news.hada.io/topic?id=3635
REGENTAG. 님의 게시글 댓글
SIGNATURE
ㅇ “연대를 구하여 고립을 두려워하지 않는다.”
ㅇ GitHub: https://github.com/Regentag
ㅇ 작업표시줄에 노란 리본을 달아주세요: https://github.com/Regentag/Remember0416
서명 더 보기 서명 가리기
sk8snow
IP 118.♡.46.42
01-25 2021-01-25 12:13:53
·
어떤 언어고 나쁜 언어는 없다고 생각해요 나쁘게 쓰니까 문제지 =3=3=3
REGENTAG.
IP 219.♡.148.113
01-25 2021-01-25 22:58:32
·
@피로곰님 Java가 상당히 verbose 하긴 하죠.. python이나 ruby같은 언어에 비하면요.
그렇지만 저는 python이나 ruby에는 정이 안 가더라고요. 그렇다고 Java를 사랑하는것도 아니지만요 ㅎㅎ
dante2k
IP 121.♡.253.241
01-25 2021-01-25 12:34:33
·
spring boot 로 오시면....
삭제 되었습니다.
리안
IP 121.♡.127.163
01-25 2021-01-25 18:17:20
·
코드 스타일, 린팅 규칙 및 기타 사소한 것들을 강조하는 사람들은 미친 괴짜들임 <- 이거 빼고는 다 동의합니다 ㅎㅎ;
항상 그렇지만 프로젝트에 따라 어떤 규칙은 무시해도 되는게 있어서 항상 유연한게 좋긴 합니다.
실버 불렛은 없다는것만 항상 유의하면...
상식
IP 218.♡.220.238
01-27 2021-01-27 22:55:22
·
@리안님 공감합니다. 진짜 이상한 사람들과 코딩한 경험이 없다는건 참 행복한거죠.
goxgo
IP 121.♡.99.101
01-28 2021-01-28 20:23:32
·
@리안님 저도 코드 스타일, 린팅 규칙 및 기타 사소한 것들은 기본이라고 생각해요. 특히 협업할때 난리 나죠 ㅎㅎ
퓨리넬
IP 124.♡.222.83
01-25 2021-01-25 19:23:50
·
자바는 지금도 충분히 좋지만...코틀린을 써 보니 자바로 돌아가고 싶지 않아요. ㅎㅎㅎ
제 최애는 스위프트고 그 다음이 코틀린, 타입스크립트 정도로 볼 수 있겠네요.
그런데 스위프트는 써먹을 곳이 iOS 앱 개발 말고는 별로 없네요...ㅠ_ㅠ
리척
IP 222.♡.20.99
01-25 2021-01-25 20:17:47 / 수정일: 2021-01-25 22:05:31
·
자바는 나쁜 언어는 아니지만, 이게 언제나 상대적인지라 jvm 에서는 더 좋은 대안들이 많기 때문에 개인적으로는 굳이 자바를 선택할 이유를 못 찾겠더군요. 최근에도 자바가 많이 좋아졌다고 해서 자바15로 서비스 하나를 개발시작했지만, 결국 2달만에 팀원들과의 협의하에 코틀린으로 바꿔버렸습니다. 여러 언어를 쓰면서 눈이 높아져서 그런지 개인적으로는 여전히 너무 불편합니다..

뭔가 저런 스타일의 글은 광역 어그로를 끄는지라 원글에도 가보면 아니나 다를까 엄청난 쓰레드가 달리는군요.
저도 몇가지 동의하지 않는것도 있고, 본인이 제대로 사용을 못하면서 필요없다라고 하는것도 있긴 하지만 대체적으로는 비슷한 의견이긴 하네요.

저런식의 본인 경험에 의해 믿게 된 것들은 참고용으로만 보는게 좋을것 같습니다.
가끔 보면 유명한 누가 이렇게 얘기했다더라, 내가 지금까지 살아보니 이게 맞다라고 하면서
다름을 인정하지 않고 이건 틀렸어라고 하게 되면 결국 나이가 들면서 소위 말하는 꼰대가 되어 가는것 같습니다.
1incompany
IP 125.♡.94.184
01-31 2021-01-31 12:18:37
·
@리척님 기존 프젝을 코틀린으로 바꿀정도로 단점이 뭐였는지 궁금합니다. 기 개발된 걸 수정할정도라면 뭔가가 있을 것 같아서오.
리척
IP 123.♡.195.161
01-31 2021-01-31 15:10:07 / 수정일: 2021-02-01 08:33:27
·
@1incompany님
개발은 Java15 + Groovy 를 사용해서 시작을 했었고, Groovy는 Bean 의 getter/setter를 매번 생성해주는걸 피하기 위해서였고, Lombok 같은 라이브러리는 모두 싫어했기때문에 고려대상이 아니었습니다.
개발하면서 느낀 단점들은:
* Java15에서 추가된 record 를 사용하려고 했으나 사용가능 용도가 한정적이었고,
* Stream API 는 사용할때마다 쓸데없이 코드가 길어졌습니다. groovy, scala, kotlin 등을 사용해본 사람들은 모두 왜 이런 쓸데없이 verbose한 코드들을 타이핑하고 있어야하는가 하는 마음이 드는걸 이해할 수 있을듯 합니다.
* 함수를 파라미터로 넘기거나 리턴값으로 사용하려고 해도 마찬가지로 너무 불편했습니다.
* 테스트 코드 작성시에도 코드가 너무 장황해져서 코드 가독성이 좋지 않았습니다.
* kotlin 과 같은 nullable 타입이 없어서 NullPointerException을 컴파일타임에 걸러주지 못합니다.
* IntelliJ 에서는 문제없는데 vscode 사용자들은 Java+Groovy 조인트 컴파일을 지원하지 않아서 Groovy 코드를 참조하는데서는 모두 에러가 떠서 vscode는 단순 텍스트 에디터로 전락하게 됨.
* 장기적으로 개발해가면서 사용할 서비스인데, 점점 쇠락해가는 언어와 발전가능성이 높은 언어 중 어떤 것을 선택할지에 대한 고민.

대충 생각나는건 이정도였던것 같습니다.
1incompany
IP 125.♡.94.184
01-31 2021-01-31 15:59:01
·
@리척님 우와. 답변 잘 읽었습니다. 장기적으로 개발해가면서 사용할 서비스라는 데에서 이해가 됐습니다. 그리고 부럽네요. 개발한 것을 다시 변경할 시간이 있었다는 것이요.
리척
IP 123.♡.195.161
02-01 2021-02-01 08:39:42
·
@1incompany님
개발 초기라 Java클래스 400여개, 테스트 클래스 40개 정도라서 많지 않아서, 팀원들에게 코드 프리즈하고 하루만 시간달라고 하고 하루만에 뜯어고쳤습니다.
IntelliJ 에서 Java->Kotlin 변환을 지원하기 때문에, 복잡한 클래스정도만 이상하게 변환된거 수동으로 변환하고 하면 금방합니다. 그리고 TDD 로 개발을 해서 테스트 코드가 있어서 변경하고 나서도 제대로 변환되었다는 마음의 안정을 얻을 수 있었네요.
코틀린 변환에 걸리는 시간은 변환하는 사람의 코틀린 사용 수준에 따라 많이 달라질 수 있을듯합니다.
목록으로
글쓰기
글쓰기
목록으로 댓글보기