타입으로 견고하게 다형성으로 유연하게 1주차 - 조현우 #447
Conversation
aquamagic9
requested review from
wooyaggo86,
jongfeel,
TaeHyoungKwon,
jintaeyeong,
hemil0102,
ymkim97,
fkdl0048,
tttghost and
dhlee3994
|
우측에 있는 |
| + 매개변수에 의한 다형성 | ||
| + 오버로딩에 의한 다형성 | ||
| ### 논의 내용 | ||
| 1. 책에서는 트위터의 예시로 동적 타입 언어인 루비를 사용하였다가 서비스가 커지고 난 후에는 정적 타입 언어인 스칼라로 옮겼다고 했는데 이렇게 개발 언어 자체를 바꾸는 경험을 하신 경우가 있으신지 궁금하고 어떤 이유로 바꾸었는지도 궁금합니다. 또한 바꿀 때 가장 주의해야 할 사항은 어떤 게 있을지 궁금합니다. |
There was a problem hiding this comment.
저는 그런 경험은 없지만
정적 언어, 동적 언어의 개발 경험과 특징을 알고 있다 보니
사람들이 많이 쓰고 운영 쪽에 서비스가 유지보수가 되고 인력들이 투입되고 있는 상황으로 가는 거면
결국 정적 언어로 바꾸는게 장기적인 유지보수 비용적인 측면에서 더 이득이라고 봅니다.
아마 태형님이 회사에서 이런 과정을 거치고 있는 걸로 알고 있습니다.
There was a problem hiding this comment.
개발 언어 자체를 바꾸는 경험을 하신 경우가 있으신지 어떤 이유로 바꾸었는지도 궁금합니다.
파이썬2버젼 장고로 작성된 레거시 시스템을 자바 스프링으로 다시 만드는 작업을 하고 있습니다.
저희 팀에서 이 서비스를 다시 만들기로 한 가장 큰 이유는 유지보수성이 매우 떨어졌기 때문 입니다. 유지보수성이 떨어진 이유는 파이썬과 장고의 높은 구현 자유도가 문제 였는데요. 레이어 구분이 없고, 작성자 간 코드 작성 스타일의 차이도 많이나면서, 코드가 읽기 힘들어졌는데, 이때 동적타이핑이 오히려 유지보수에 많은 해가 되었습니다
다만, 자바로 바꾼 이유는 자바가 위의 문제점들을 다 커버하기 때문이 아니라(저는 자바를 싫어합니다 ㅎㅎ), 회사의 채용 상황, 팀의 개발자 구성원을 고려 했을 때, 파이썬 3버젼을 올리는 선택보다 자바를 선택하는게 더 이득이라는 생각 때문 이였습니다
또한 바꿀 때 가장 주의해야 할 사항은 어떤 게 있을지 궁금합니다.
주의 해야할 것 이라고 적어주신게 조금 모호해서, 만약 동적 타이핑 언어를 사용하다가, 정적 타이핑 언어로 변경한다고 했을 때, 주의해야하거나 고려해야할 점에 대해서 회사 입장에서 답변 하자면, 회사에서 쓰는 정적 타이핑 언어를 그냥 사용하는게 제일 좋을 것 같습니다 그 이유는 무언가 특별한 서비스를 만드는게 아닌 보통의 웹 백엔드 API 서버를 만드는 것이고, 팀원들이 유지보수성에 대한 이해도가 있다면, 솔직히 그냥 타입체커가 있는 아무 언어의 아무 프레임워크를 선택해도 문제 없을거 같고, 가급적이면 회사에서 쓰는 것을 주로 쓰는게 회사 입장에서 가장 좋을 것 같습니다
요즘에 개발언어들이 동적언어는 정적언어들의 특징을 가져오고, 정적언어들은 동적언어들의 특징들을 가지고 오면서, 그 경계가 분명히 있지만, 조금씩 흐려지고 있다고 생각합니다 그래서 제 개인적으로는 회사의 입장이 아니라면, 그냥 개인이 가장 선호하고, 익숙한 언어와 프레임웍을 사용해도 왠만한 보통의 웹 백엔드 API 서버를 구축하는데 전혀 문제 없다고 생각하긴 합니다
| 2. 뛰어난 성능. 프로그램 실행 시간이 짧다. | ||
| + 타입 검사를 통해 얻은 정보를 바탕으로 실행 중에 할 일을 줄일 수 있다. 타입검사를 통과하면 실행 중에는 타입 안전성을 보장하기 때문에 실행 중 추가적인 검사가 필요 없다. | ||
| ### 1.5 타입 추론 | ||
| 정적 타입 언어에는 불편한 점도 있다. 그 중 하나가 타입 표시다. 타입 검사기가 변수나 함수의 타입을 알 수 있도록 개발자가 타입 표시를 제공해야 한다. 타입 추론은 타입 검사기가 더 똑똑해져서 타입 표시 없이도 타입 검사를 할 수 있게 되는 것이다. |
There was a problem hiding this comment.
시작이 정적타입 언어여서 그런지 딱딱 타입을 적어주는 것이 좋았습니다.
오히려 적지 않으면 (동적타입언어) 불안했던 경험이 있습니다.
비슷하지 않을 수도 있지만 접근제한자 같은 경우에도 private를 꼭 붙여주는 편 입니다.
| + 매개변수에 의한 다형성 | ||
| + 오버로딩에 의한 다형성 | ||
| ### 논의 내용 | ||
| 1. 책에서는 트위터의 예시로 동적 타입 언어인 루비를 사용하였다가 서비스가 커지고 난 후에는 정적 타입 언어인 스칼라로 옮겼다고 했는데 이렇게 개발 언어 자체를 바꾸는 경험을 하신 경우가 있으신지 궁금하고 어떤 이유로 바꾸었는지도 궁금합니다. 또한 바꿀 때 가장 주의해야 할 사항은 어떤 게 있을지 궁금합니다. |
There was a problem hiding this comment.
오 재밌는 논의 주제인 것 같아요. 저는 하나의 프로젝트에서 개발 언어를 바꾼 경험은 없어서 저도 궁금하네요👍
| + 매개변수에 의한 다형성 | ||
| + 오버로딩에 의한 다형성 | ||
| ### 논의 내용 | ||
| 1. 책에서는 트위터의 예시로 동적 타입 언어인 루비를 사용하였다가 서비스가 커지고 난 후에는 정적 타입 언어인 스칼라로 옮겼다고 했는데 이렇게 개발 언어 자체를 바꾸는 경험을 하신 경우가 있으신지 궁금하고 어떤 이유로 바꾸었는지도 궁금합니다. 또한 바꿀 때 가장 주의해야 할 사항은 어떤 게 있을지 궁금합니다. |
There was a problem hiding this comment.
문장을 더욱 매끄럽게 다듬어 드릴게요.
다듬은 문장:
"저는 한 번, 안드로이드 앱을 Flutter로 새롭게 개발하는 프로젝트를 옆에서 지켜본 적이 있습니다. 이 프로젝트의 가장 큰 목적은 iOS까지 지원 범위를 확장하기 위해서였습니다. 즉, 크로스 플랫폼 개발과 네이티브 iOS 개발 사이에서 고민하다가, 팀원들이 이미 Flutter에 익숙했기 때문에 크로스 플랫폼 방식을 선택하게 된 것입니다.
이 과정에서 가장 주의해야 할 점은 비용과 시간이었습니다. 생각보다 개발 기간이 길어지는 경우가 많았고, '이미 알고 있는 기술이니까 금방 끝나겠지' 하는 안일한 생각으로 인해 프로젝트 예측이 어려웠습니다. 특히, 기존 코드를 완전히 새로 작성하는 과정에서 예상치 못한 문제들이 발생할 수 있기 때문에 신중한 계획이 필요합니다.
타입으로 견고하게 다형성으로 유연하게 1장_타입 검사 훑어보기 정리