Add chapter1 two discusstions and overview link

[jongfeel]

올해도 즐거운 마음으로 첫 모임을 시작하게 될 것 같습니다.

전반적으로 내용이 쉬운 편이고 설명이 장황했지만
핵심 적인 내용인 타입추론이나 다형성 같은 내용은 다시 리뷰해 볼 수 있었던 시간이었습니다.

[github-actions]

우측에 있는 Projects, Milestone, Development를 확인 후 할당 해주세요~! 🙇

[hemil0102]

안녕하세요! 아래 논의 주제에 답변을 적어봅니다~

이 책에서 설명해주는 타입 검사기가 해주는 역할이 좋아 보이는데, 이를 극대화해서 접할 수 있는 도구는 Chat AI 기능이 있는 IDE 라고 생각됩니다. 우리가 미처 몰랐던 문법을 알려주기도 하고, 더 효율적이고 클린한 코드 방식을 알려주기도 하며 미리 짤 코드를 preview 해주고 그 코드를 통째로 붙여넣기 하듯이 코드 작성도 가능합니다. 타입 검사기는 여기서도 항상 유용하지만, 얼마만큼 유용하다고 생각하는지 얘기해 보면 좋을 것 같습니다. 저의 경우 IDE 가 타입 추론을 추천해서 항상 var type으로 코드를 바꾸라고 하는데, 저는 이 기능을 끄고 씁니다. 왜냐하면 타입 추론은 책의 설명대로 타입을 읽을 수 없으므로 유지보수성에 문제가 생기기 때문입니다.

이 부분은 제가 xcode를 사용하면서는 만나보지 못한 문제인 것 같습니다만, 생각해보면 var type 변수가 변경되지 않는 어떤 값이라면 let으로 바꾸라고는 했던 것 같은데 이 부분도 타입 검사 내용과 연관된거라 볼 수 있을까요?

1.8의 다형성 설명에서 타입 검사의 위험한 기능을 통해 원칙을 파괴하는 예로 코틀린의 !! 연산자를 예로 들었습니다. 개발자 마다 유용하고 좋은 문법이다라고 할 수 있고, 꼭 그 문법을 쓰지 않고도 가독성 있는 코드로 짤 수 있기도 합니다. 저는 프로그래밍 언어가 지원하는 문법이라면 사용하는 쪽을 택하고 거기에 가독성 문제가 있다면 안쓰는 쪽인데 다른 분들은 어떤 성향인지 얘기해 보면 좋겠습니다.

이 부분은 xcode의 스토리보드 IBOutlet에서 UILabel이나 어떤 레이아웃 적인 요소를 정의할 때 항상 !를 붙이는 것을 기본으로 설계되어 있는 것이 떠오릅니다. 이유는 정확히 알아낸바 없지만, 무조건 필수적으로 적용되어야할 레이아웃 요소라면, 적용되지 않았을 때 알아차릴 수 있어야 하므로 nil 값일 때 에러가 발생해야하고, !을 붙이면 nil을 만났을 때 무조건 에러가 날 것이기 때문입니다. 따라서 레이아웃 요소에 !표는 무조건 존재한다는 것을 보장하기 때문에 붙어 있는 것이라고 생각을 했습니다. 그리하여 !는 무조건 존재하는 어떤 데이터를 명시하기 위해서 개발자에게 "무조건 존재해야 한다는 것을 인지해" 라는 의도로 존재할 수 있다고 봅니다.

[TaeHyoungKwon]

저도 새로나온 문법이 있다면 관심있게 지켜본다음에, 이 문법을 적용할만한 상황이 생겼을 때, 적극 활용해보려고 하는 편 입니다 언어의 새버젼에 나오는 문법들이 뜬금없이 생기는 것들이 아니라, 오픈 소스를 기준으로 많은 사람들의 논의 끝에 결정된 것이 반영된 것이기 때문에 충분히 신뢰할만하다고 생각됩니다

다만, 맥락에 어울리지 않게 신기술이다, 새로운 문법이다라고 막무가내로 적용하는 것은 피해야할 것 같습니다

[ymkim97]

저는 가독성을 크게 신경 쓰는 편이라 가독성이 좋은지 먼저 판단 후, 문법을 적용하는 것 같습니다.

[aquamagic9]

저는 아직 부족하다보니 가독성보다는 일단 경험을 해보는 쪽을 선택하는 것 같습니다. 하지만 태형님 말씀을 들어보니 막무가내로 적용을 하지는 않았나 스스로 점검이 필요한 것 같습니다.

[TaeHyoungKwon]

저도 똑같이 타입검사기의 역할이 AI가 접목된 IDE와 결합하면서 제공하는 기능이 매우 막강하다고 생각하고, 실제도움을 많이 받고 있습니다

저는 개인적으로 java에서 var 같은 키워드를 사용하는 것을 선호 합니다 굳이 명시적으로 타입을 표시하지 않아도 되는 경우라면(표시하지 않아도 리턴되는 타입이 너무 명확할 때), 유연하게 타입을 추론하도록 하는게, 오히려 가독성에 더 도움이 되는 경우가 많았던 것 같습니다

[ymkim97]

확실히 요즘 AI 까지 곁들인 IDE로 인해 없었을때 비해 생산성이 매우 올란 것이 느껴집니다.
대신 아직 주니어인만큼 단순 반복 작업 정도에만 쓰려고 합니다.
지금까지 var가 저에게는 크게 도움이 되지 않는다고 생각해서 쓰지 않았는데, 그래도 사람들이 많이 쓰는거 같아 리턴 타입이 아주 명확한 경우에는 써보면서 다시 생각해보려고 합니다.

[ymkim97]

확실히 요즘 AI 까지 곁들인 IDE로 인해 없었을때 비해 생산성이 매우 올란 것이 느껴집니다.
대신 아직 주니어인만큼 단순 반복 작업 정도에만 쓰려고 합니다.
지금까지 var가 저에게는 크게 도움이 되지 않는다고 생각해서 쓰지 않았는데, 그래도 사람들이 많이 쓰는거 같아 리턴 타입이 아주 명확한 경우에는 써보면서 다시 생각해보려고 합니다.

[ymkim97]

저는 가독성을 크게 신경 쓰는 편이라 가독성이 좋은지 먼저 판단 후, 문법을 적용하는 것 같습니다.

[tttghost]

프로그래밍 언어의 문법은 한 번 사용해보고 유용하면 선호하는 편입니다.
특히, 한 번만 쓰일 데이터를 위해 클래스를 만드는 대신 익명타입을 선호하는데,
간결하고 효율적으로 데이터를 처리할 수 있어 코드 생산성과 가독성을 높일 수 있기 때문입니다.

[wooyaggo86]

질문을 제대로 이해했는지 모르겠네요. 타입 검사기가 AI가 작성해준 코드에서 얼마나 유용한가? 라는 질문으로 이해하고 답변 쓰겠습니다. 제 생각은 이렇습니다. AI보다는 타입검사기를 더 신뢰(?)하기 때문에, 타입검사기로 한번더 코드를 검사하고 수정할 수 있는 방식으로 활용할 것 같고 실제로 그렇게 사용하고 있습니다. 미래에 AI가 정말 더 정교해지고 타입검사기가 필요하지 않아도 된다.. 라는 시대가 온다면... 무언가 두렵네요..

[wooyaggo86]

저도 가독성에 문제가 있다면 안쓰는 쪽입니다. 근데 가독성이라는게 참 어려운 것 같아요. c++ 삼항 연산자의 경우 처음 봤을때는 이런 어려운 문법이 있다고 생각했는데, 이제 익숙해지니까 명확하게 논리구조를 나타내는 걸로 보이구요. 저는 이런 상황이면 코드베이스의 컨벤션을 주로 따라가는 성향입니다.

[aquamagic9]

저는 아직 부족하다보니 가독성보다는 일단 경험을 해보는 쪽을 선택하는 것 같습니다. 하지만 태형님 말씀을 들어보니 막무가내로 적용을 하지는 않았나 스스로 점검이 필요한 것 같습니다.