먼저 영상 공유 감사합니다! 영상 내용 중 100불 더 비싼 소프트웨어와 리팩터링과 잘 설계된 컴포넌트의 내용이 포함되어 있는데요. 이 세 개의 키워드로 궁금한 것이 있습니다. 잘 설계된 소프트웨어를 구매하면 기능 추가에 높은 비용(시간)이 들지 않을 것 리팩터링을 한다는 것은 기본적으로 컴포넌트화 되어있는 코드들의 구조들을 변경할 수 있는 능력을 의미한다고 생각하는데요(발표자의 책인 리팩터링 2판 내용을 근거) 유지보수 개발자들이 이러한 능력을 원하지 않는다면, 구조화로 나누어져 증가하는 파일 양의 불만이나 새로운 표현식의 습득 거부, 새로운 기술 습득을 거부하는 인원이 더 많다면 그 기준에 맞춘 더 나은 (스마트 패턴 같은) 것으로 맞추어 코드를 구현하는 것이 더 낫다는 말이 맞는 것일까요? 이러한 상태의 기능 추가는 후에 결국 추가하기 어려운 구조로 만들어 간다고 생각하고 있는데요. (잘 설계되고 구분지어진 것을 운영 하더라도 추후엔 어려운 구조를 만든다) 개발자들의 코드 이해도를 이해한 상태에서 설계된다라는 의미가 향상(성장)의 방향이라고 생각하는데, 또 다른 관점에선 현 기준에 맞춰서 하는 것이 훌륭한 개발자라는 표현이 적합한 것인가에 대한 고민에서 출발한 질문입니다. 혹시... 어떤 관점을 가지고 계신가요! 또는 제가 생각하는 부분들의 미스가 있다면 답변을 부탁드립니다!
영상에서 두번째 예시의 슈도그래프처럼 기존의 (좋은 아키텍쳐의)코드베이스는 플랫폼 역할을해서 기능추가(확장이란 표현이 더 어울릴것같은데)의 비용이 점점 적게들어갑니다. 좋은 기초이면 기능추가하는데 자연스러운 흐름으로 갔을때 최적의 결과를 기대할 수 있겠죠. 말씀하신 예시는 좋은 아키텍쳐에서 개발자가 배우기 싫어서 더 어렵게 기능을 추가한단 의미인가요? 그렇다면 리드가 얼렁 그런 사람을 집으로 보내야 할 것같구요. 리팩터링과 기능추가는 결이 다른것 같습니다. 영상에서 구분으로 따지자면 리팩터링은 안쪽품질이고 기능추가는 바깥쪽 품질일테니까요. 리팩터링이 잘되어간다면 결과적으로 기능추가의 비용도 줄어들겠죠. 영상에서 파울러님이 말씀하신것처럼 경제적인 관점이 답을 드릴것 같습니다. 당장 매출이 급하면 바깥쪽품질에 맞춰야하고, 좀 장기적으로 갈 여유가 생기면 안쪽품질에 맞춰야겠죠.
경제적인 관점을 배제할 수 없을 것 같습니다. 새로운 기술 습득도 학습 비용이 있고, 리팩터링 기법을 모르는 개발자에게 리팩터링 기법을 습득시키는 것도 비용이죠. 마감일이 급박한 프로젝트라면 구조를 변경하는 작업이 큰 부담으로 다가올 수 있습니다. 하지만 영상의 그래프처럼 장기적으로 봤을 땐 좋은 구조를 유지시키는 게 비용적으론 이득인 거라 이 부분을 사장님/팀리더가 잘 조율해야 된다고 생각합니다. 말씀 주신 훌륭한 개발자에 대한 주관적인 견해는 팀 상황에 맞게 개발하고 유지보수하되 새로운 기술습득과 구조개선에 대한 학습을 지속적으로 해야 되고, 본인뿐만 아니라 팀원들 모두가 동일한 수준으로 갈 수 있도록 설득하고 스터디해서 담당하고 있는 소프트웨어의 구조를 지속적으로 고도화시킬 수 있는 개발자라고 생각합니다. 그런데 보통 이런 분들은 능력치가 높아지면 이직을 하더라구요 ㅎㅎ
설계를 잘해서 개발을 해야지하면서 실제 개발을 진행하다보면 맞지 않은 것들이 있어 설계 수정, 코드수정하다보면 많은 시간이 소요 되더라구요. 마감시간에 쫒겨 때론 그냥 돌아가게만 할까 고민도 많이 하고 했는데, 그래도 꾸역꾸역 설계를 기반한 개발 습관을 들이니 점점 수정이 적게 들어가는 좋은 설계를 하게되는것 같습니다. 이런점이 결국 동료들에게 인정받게되는 부분이구요. 아 그리고 좋은 영상 감사드립니다!!
![[네하 나크헤데]아파치 카프카의 탄생 스토리 (한글 자막)](http://i.ytimg.com/vi/3F4XwgCfQc8/mqdefault.jpg)
![[네하 나크헤데]아파치 카프카의 탄생 스토리 (한글 자막)](/img/tr.png)
![[마틴 파울러] 리팩토링의 중요성 feat.테스트 코드를 짜는 이유(한글 자막)](http://i.ytimg.com/vi/mNPpfB8JSIU/mqdefault.jpg)
먼저 영상 공유 감사합니다! 영상 내용 중 100불 더 비싼 소프트웨어와 리팩터링과 잘 설계된 컴포넌트의 내용이 포함되어 있는데요.
이 세 개의 키워드로 궁금한 것이 있습니다.
잘 설계된 소프트웨어를 구매하면 기능 추가에 높은 비용(시간)이 들지 않을 것
리팩터링을 한다는 것은 기본적으로 컴포넌트화 되어있는 코드들의 구조들을 변경할 수 있는 능력을 의미한다고 생각하는데요(발표자의 책인 리팩터링 2판 내용을 근거)
유지보수 개발자들이 이러한 능력을 원하지 않는다면, 구조화로 나누어져 증가하는 파일 양의 불만이나 새로운 표현식의 습득 거부, 새로운 기술 습득을 거부하는 인원이 더 많다면 그 기준에 맞춘 더 나은 (스마트 패턴 같은) 것으로 맞추어 코드를 구현하는 것이 더 낫다는 말이 맞는 것일까요?
이러한 상태의 기능 추가는 후에 결국 추가하기 어려운 구조로 만들어 간다고 생각하고 있는데요.
(잘 설계되고 구분지어진 것을 운영 하더라도 추후엔 어려운 구조를 만든다)
개발자들의 코드 이해도를 이해한 상태에서 설계된다라는 의미가 향상(성장)의 방향이라고 생각하는데, 또 다른 관점에선 현 기준에 맞춰서 하는 것이 훌륭한 개발자라는 표현이 적합한 것인가에 대한 고민에서 출발한 질문입니다.
혹시... 어떤 관점을 가지고 계신가요! 또는 제가 생각하는 부분들의 미스가 있다면 답변을 부탁드립니다!
개발자들이 새로운 것을 배우면서, 계속해서 코드를 좋게 개선해나간다는 것을 전제로 하는 이야기라고 생각합니다. 그리고 조금 더 앞서서는 신규프로젝트 개발자/유지보수 개발자와 같은 구분을 하지않는다는 전제가 있다고 생각합니다.
영상에서 두번째 예시의 슈도그래프처럼 기존의 (좋은 아키텍쳐의)코드베이스는 플랫폼 역할을해서 기능추가(확장이란 표현이 더 어울릴것같은데)의 비용이 점점 적게들어갑니다. 좋은 기초이면 기능추가하는데 자연스러운 흐름으로 갔을때 최적의 결과를 기대할 수 있겠죠. 말씀하신 예시는 좋은 아키텍쳐에서 개발자가 배우기 싫어서 더 어렵게 기능을 추가한단 의미인가요? 그렇다면 리드가 얼렁 그런 사람을 집으로 보내야 할 것같구요. 리팩터링과 기능추가는 결이 다른것 같습니다. 영상에서 구분으로 따지자면 리팩터링은 안쪽품질이고 기능추가는 바깥쪽 품질일테니까요. 리팩터링이 잘되어간다면 결과적으로 기능추가의 비용도 줄어들겠죠. 영상에서 파울러님이 말씀하신것처럼 경제적인 관점이 답을 드릴것 같습니다. 당장 매출이 급하면 바깥쪽품질에 맞춰야하고, 좀 장기적으로 갈 여유가 생기면 안쪽품질에 맞춰야겠죠.
경제적인 관점을 배제할 수 없을 것 같습니다. 새로운 기술 습득도 학습 비용이 있고, 리팩터링 기법을 모르는 개발자에게 리팩터링 기법을 습득시키는 것도 비용이죠.
마감일이 급박한 프로젝트라면 구조를 변경하는 작업이 큰 부담으로 다가올 수 있습니다. 하지만 영상의 그래프처럼 장기적으로 봤을 땐 좋은 구조를 유지시키는 게 비용적으론 이득인 거라 이 부분을 사장님/팀리더가 잘 조율해야 된다고 생각합니다.
말씀 주신 훌륭한 개발자에 대한 주관적인 견해는
팀 상황에 맞게 개발하고 유지보수하되 새로운 기술습득과 구조개선에 대한 학습을 지속적으로 해야 되고, 본인뿐만 아니라 팀원들 모두가 동일한 수준으로 갈 수 있도록 설득하고 스터디해서 담당하고 있는 소프트웨어의 구조를 지속적으로 고도화시킬 수 있는 개발자라고 생각합니다.
그런데 보통 이런 분들은 능력치가 높아지면 이직을 하더라구요 ㅎㅎ
영상에서 말하는 것 처럼 아키텍처에서 말하는 중요한 핵심이 무엇이냐를 내가 담당하는 업무에 비춰 볼 때 개발 비용 완료 시간 업무상황 등을 모두 고려해야 한다는게 핵심인것 같네요
설계를 잘해서 개발을 해야지하면서 실제 개발을 진행하다보면 맞지 않은 것들이 있어 설계 수정, 코드수정하다보면 많은 시간이 소요 되더라구요. 마감시간에 쫒겨 때론 그냥 돌아가게만 할까 고민도 많이 하고 했는데, 그래도 꾸역꾸역 설계를 기반한 개발 습관을 들이니 점점 수정이 적게 들어가는 좋은 설계를 하게되는것 같습니다. 이런점이 결국 동료들에게 인정받게되는 부분이구요. 아 그리고 좋은 영상 감사드립니다!!
좋은 아키텍처가 시간을 줄인다 말고는 건진게없음 실질적으로 써먹을 수 있는 좋은 아키텍에대 알려면 이채널의 다른영상을 보세요
'좋은 아키텍처가 시간을 줄이고 비즈니스를 발전하는데 도움을 준다' 정말 좋은 관점이죠.
와~ 이런 영상 너무 좋네요. 잘 봤습니다.
안녕하세요 @오준석의 생존코딩 님~! 앞으로도 좋은 영상 공유하겠습니다😇
알고리즘의 선택을 받은 동영상 잘 봤습니다!ㅋㅋㅋ
번역, 영상 공유 감사드립니다!! 덕분에 쉽게 강연 들을 수 있었습니다!!
감사합니다.
영상 잘 봤습니다 이런영상 마니마니 올려주세요!ㅎㅎㅎ
자막 감사합니다.
좋은 영상 감사합니다 더 많이 생각해봐야겠네요!
건축이나 소프트웨어나 하물며 하드웨어나 휴먼빙이나 내면 내부가 중요한거 사실이네요
좋은 영상에 자막까지 덕분에 잘봤습니다.
좋은 영상 공유 감사드려요!
올라 오자마자 봤는데 한글 자막 안달려 있어서 당황했네요 ㅋㅋㅋㅋㅋ 허겁지겁 재업로드 하셨을 모습이 눈에 훤합니다 ㅎㅎ
ㅋㅋㅋ @정우담 님,많은 관심 감사합니다. 원본을 올려버려서 ㅜㅜ 재업했습니다😢
좋은 내용 공유해주셔서 감사합니다.
좋은 영상과 자막 감사합니다! 여기로 이끌어준 알고리즘에게도 감사를 ㅎㅎ 첫번째 파트의 결론이 재밌네요 ㅎㅎ
"장인정신과 경제의 싸움" !!
좋은 영상에 자막까지 정말 감사합니다:)
잘봤습니다!
코린이인데 기초공사가 중요하다는 점을 다시 한번 깨닫고 갑니다 :)
좋은영상 감사합니다
항상 잘보고있습니다
@하뿡님, 잘봐주셔서 감사해요~
좋은 영상 감사합니당
감사합니다~!
감사합니다
감사히 잘 보았습니다. 10:42 부분에 번역에 의견 드립니다
호러블 롱 텀이라는 표현은 "Design Stamina Hypothesis" 라는 (자신이 만든) 지나치게 긴 용어라는 의미로 쓰인듯 합니다.
@Hyunseok Jeong님, 의견 감사합니다^^
8:00
말잘하는 스타 개발자네
11:30
결국 경제적으로도 이점이 있는데!
SI / SM 구분 되는 곳에서는 이게 참 애매하네요.
고객도 판매자도 일회성 비용 절감을 추구할 수밖에 없으니.
개발용역/ 외주운영 답이 없어요. 외부품질 및 가격만이 중요하고 영업쪽이 개발자보다 더더더더더더더 중요할 수밖에 없습니다.
Thanks
이런 영상은 오너들이 뵈야하는 거 아냐?!