Conversation
tttghost
added
the
Street Coder: The Rules to Break and How to Break
|
우측에 있는 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds summary and reflection documents for Chapters 4 and 5 of 'Street Coder'. The review feedback suggests correcting a section reference in Chapter 4, moving the discussion on regular expressions to the appropriate chapter, and refining technical terminology in Chapter 5 to accurately reflect the concept of 'seams' rather than 'deadlock'.
| 다른 분들은 AI와 테스트를 어떤 비중으로 함께 쓰고 계신지, 그리고 그 과정에서 느낀 장단점이 있다면 함께 이야기해 보면 좋겠습니다. | ||
|
|
||
| ## 감상평 | ||
| 13.4에서 "요즘은 자동 테스트가 수동 테스트보다 비용이 더 낮다"는 말이 인상적이었습니다. |
There was a problem hiding this comment.
현재 문서의 제목은 '4장'이지만 본문에서는 '13.4'절을 언급하고 있습니다. 책의 1.3.4절('자동 테스트는 수동 테스트보다 저렴하다')의 내용을 의도하신 것이라면, 번호를 '1.3.4'로 수정하는 것이 정확하겠습니다.
| 13.4에서 "요즘은 자동 테스트가 수동 테스트보다 비용이 더 낮다"는 말이 인상적이었습니다. | |
| 1.3.4에서 "요즘은 자동 테스트가 수동 테스트보다 비용이 더 낮다"는 말이 인상적이었습니다. |
| 정규식 부분도 찔렸습니다. | ||
| 그동안 그냥 "갖다 쓰는 도구"로만 봤습니다. 필요하면 검색해서 복붙하고, 동작하면 그만이라는 식이었습니다. | ||
| 기본 문법이라도 제대로 이해해두면 상황에 맞게 조합하거나 변형할 수 있을 텐데, 그걸 안 해왔다는 것을 깨달았습니다. |
There was a problem hiding this comment.
정규식(Regular Expression)에 대한 내용은 책의 3장(3.10절)에서 다루고 있습니다. 현재 4장 요약 문서에 해당 내용이 포함되어 있는데, 장별로 내용을 구분하신다면 3장 쪽으로 옮기는 것을 검토해 보세요.
| 리팩터링을 하는 이유는 결국 미래를 위한 것이라는 생각이 들었습니다. | ||
| 지금 조금 귀찮아도 나중에 더 간결하고 재사용 가능하게 두는 것, 안 하면 언젠가 터지고 그 피해는 인계받는 사람에게 돌아간다는 점이 와닿았습니다. | ||
|
|
||
| 책에서는 리팩터링할 때 공통 코드를 추출해서 기존 코드와 새로운 코드 사이에 "중간 교착점"을 만들어가라고 합니다. |
There was a problem hiding this comment.
'교착점'은 일반적으로 'Deadlock'을 의미하는 기술 용어입니다. 리팩터링의 맥락에서 'Seams'를 설명하신 것이라면 '접점' 또는 '솔기'라는 용어를 사용하는 것이 독자에게 더 정확한 의미를 전달할 수 있습니다.
| 책에서는 리팩터링할 때 공통 코드를 추출해서 기존 코드와 새로운 코드 사이에 "중간 교착점"을 만들어가라고 합니다. | |
| 책에서는 리팩터링할 때 공통 코드를 추출해서 기존 코드와 새로운 코드 사이에 "접점"을 만들어가라고 합니다. |
| 요즘도 테스트 코드를 직접 작성하시나요? AI의 발전에 따라 테스트 작성 방식이 어떻게 달라졌는지 궁금합니다. | ||
| 저는 평소에 테스트 코드를 거의 짜지 않다가, AI가 발전하면서 AI의 도움을 받아 조금씩 짜보고 개념을 이해해 나가는 정도로 활용하고 있습니다. | ||
| 다른 분들은 AI와 테스트를 어떤 비중으로 함께 쓰고 계신지, 그리고 그 과정에서 느낀 장단점이 있다면 함께 이야기해 보면 좋겠습니다. |
There was a problem hiding this comment.
클로드 쓰기 전에는 테스트 코드와 함께 로직 처리 코드를 함께 작성하는게 습관이었는데
그게 제가 직접 하는 것에서 클로드가 대신 해주는 것으로 바뀐 것 정도입니다.
다시 말해 클로드가 나오기전, AI가 나오기 전에도 테스트 코드를 작성해야 하는 이유와 그 의미가 무엇이냐에 대한 본질은 변하지 않은 것 같습니다.
저는 그나마 AI가 다 해주는 시대에 테스트 코드 작성에 대한 부분은 살아 남아서 다행이라고 생각하고 있긴 합니다.
| AI가 리팩터링을 상당 부분 대신해주는 시대가 되면서, 개발자가 리팩터링을 바라보는 관점 자체가 달라지고 있다고 느꼈습니다. | ||
| 다른 분들은 실무에서 AI에게 리팩터링을 맡기는 비중이 어느 정도이신가요? | ||
| 또 "AI에게 맡길 수 있는 리팩터링"과 "사람이 직접 해야 하는 리팩터링"을 나누는 본인만의 기준이 있으신지 궁금합니다. |
There was a problem hiding this comment.
저는 사람이 작성한 코드에 대해 리팩터링 조금 시켜보고 든 생각은, 처음부터 AI로 만든 프로젝트는 리팩터링을 하는게 의미가 없다 쪽으로 생각이 바뀌었습니다.
리팩터링을 하는 의미는 사람이 코드를 봐야 했기 때문인데, 사람이 코드를 볼 필요가 없다면 리팩터링도 시키거나 하는게 의미가 없다 입니다.
이건 지난 academic conference 때 여러 차례 논의되었던 내용이기도 하죠.
리팩터링을 사람이 하느냐 AI가 하느냐에 대한 기준에 대한 거라면
"리팩터링은 할 필요가 없다."의 의견입니다.
| 위협 모델링 파트에서 "한쪽에서 얻은 정보로 다른 곳을 공격한다"는 내용이 인상적이었습니다. | ||
| 솔직히 저는 사이트마다 비밀번호를 거의 비슷한 패턴으로 쓰고 있는데, 다른 분들은 사이트별로 비밀번호를 다르게 관리하거나 보안에 특별히 신경 쓰는 부분이 있으신가요? |
There was a problem hiding this comment.
책에서 나온 대로 사람들은 같은 비밀번호를 쓰는 습관이 있기 때문에 딱히 신경쓰는 건 없습니다.
주로 구글이나 네이버 로그인 방식에 패스키-얼굴인식 방식의 보안 인증을 쓰기 때문에
강제로 어떤 사람이 저를 협박해서 제 휴대폰을 가지고 제 얼굴을 인식을 해서 뭔가 털어가지 않는 이상
물리적으로 보안 위협이 불가능한 방식이라고 생각하고 있습니다.
2 participants
책을 읽으면서 ai에 대해 지속적으로 언급이 나오는데
책 내용보다 현재 ai상황이 더 진보되어 있어서 읽는데 재미있는 요소였습니다.