Hacker News 의견

• 프로젝트 관리 위험과 소프트웨어 엔지니어링 위험을 구분해야 함. 엔지니어링 기술이 관리 위험을 해결하지 못하는 경우가 많음.
• 코드 품질, 조직화, 테스트, 문서화, 표준 도구 사용이 양쪽 모두에 도움이 됨.
• "버스에 치이다" 가설을 자주 사용하게 되는 이유는 재현 가능하고 이해하기 쉬운 소프트웨어를 만들기 위함임.
• 부정적인 의미를 피하기 위해 "복권에 당첨되다"라는 표현을 사용하는 것이 좋음.
• 아키텍처를 위한 아키텍처는 최악임. 불필요하게 복잡성을 증가시킴.
• 좋은 아키텍처의 궁극적인 목표는 비용 절감임. 개발 및 유지보수에 더 많은 시간이 소요된다면 실패한 아키텍처임.
• 2010년에 출판된 책이 얼마나 살아남았는지 궁금함.
• "Design It" 책은 워크숍 활동이 기술자들에게 유용하고, 특정 기술 아키텍처 스타일에 치우치지 않아 좋음.
• John Ousterhout의 'A Philosophy of Software Design' 책이 유용함. 이해하기 쉬운 조언과 예시가 많음.
• "리스크 의존적"이라는 용어가 더 나은 명칭일 것 같음. 프로그래머들이 "[X]-기반"이라는 표현을 좋아하는 이유가 궁금함.
• 특정 책은 모르지만, 저자의 "지적 통제"에 대한 글이 매우 통찰력 있음.
• 몇 년 전 회사에서 책 클럽을 했는데, 매우 반복적임을 느꼈음.
• 비중 있는 오픈 소스 프로젝트를 시작하는 사람이나 솔로프리너에게 좋은 자원인지 궁금함. 솔로 개발자에게 유용한 책이나 자원을 추천해달라는 요청.
• 소프트웨어 아키텍처는 일반적인 아키텍처와 비슷하지만, 소프트웨어에는 Isaac Newton 같은 인물이 없어서 시민 공학이 존재하지 않음. 가장 가까운 인물은 Claude Shannon임.
• 임의의 용어를 읽는 것에 지침. 수학적 모델을 원함. 모호한 인간이 만든 용어는 아이디어를 번역하려는 해킹에 불과함.