Hacker News 의견

• Jonathan Blow의 강연을 떠올리게 함. 소프트웨어는 관리하지 않으면 다른 모든 것처럼 쇠퇴함

  • 소프트웨어 기술은 겉보기에는 발전하는 것처럼 보이지만 실제로는 쇠퇴 중임
  • 하드웨어 개선과 머신러닝이 발전의 환상을 주지만, 소프트웨어의 근본적인 견고성과 신뢰성은 악화됨
  • 현대 소프트웨어 개발은 불필요하게 복잡해져 간단한 작업도 어렵게 만듦
  • 이러한 복잡성은 프로그래머의 생산성을 감소시키고 세대 간 지식 전수를 방해함
  • 사회는 버그가 많고 신뢰할 수 없는 소프트웨어를 정상으로 받아들이게 됨
  • 운영 체제에서 개발 도구까지 모든 수준에서 소프트웨어 시스템을 단순화하지 않으면 문명은 역사적 붕괴와 유사한 기술적 퇴보의 위험에 직면함

• Dieter Rams의 "좋은 디자인의 10가지 원칙"을 떠올리게 함

  • 좋은 디자인은 혁신적임
  • 좋은 디자인은 제품을 유용하게 만듦
  • 좋은 디자인은 미적임
  • 좋은 디자인은 제품을 이해하기 쉽게 만듦
  • 좋은 디자인은 눈에 띄지 않음
  • 좋은 디자인은 정직함
  • 좋은 디자인은 오래 지속됨
  • 좋은 디자인은 마지막 세부 사항까지 철저함
  • 좋은 디자인은 환경 친화적임
  • 좋은 디자인은 가능한 한 적은 디자인임

• 2000년대에 회사에서 일했던 경험을 공유함

  • 수십 대의 컴퓨터로 작업을 수행하고, 서버 룸을 구축하고, 3TB의 데이터를 저장할 SAN을 구축함
  • 자체 개발한 VB6 작업 스케줄러로 Object Rexx 스크립트를 실행하는 컴퓨터 간 작업을 조율함
  • 내부 로드 밸런서, 웹 서버, 메일 서버, FTP 서버를 사용하여 파일을 송수신하고 자체 소프트웨어를 사용함
  • 이제는 yaml 파일과 클라우드 서비스를 통해 일주일 이내에 전체 설정을 재현할 수 있음
  • 서버 아키텍처가 "추상화"됨
  • 역호환성에 대한 비판, Windows의 문제점 중 하나로 지적됨
  • Apple은 역호환성을 깨고 5개의 프로세서를 이동하며 ARM 칩에서 32비트 코드 호환성을 제거함

• 상반된 의견들이 많음

  • 역호환성을 유지하면서 복잡성을 피해야 함
  • 거대한 종속성 트리를 피하고 스스로 바퀴를 재발명해야 함
  • 모든 요구를 충족시키는 유일한 방법은 모든 사람이 코드를 작성하지 않는 것임
  • 하루에 한 번쯤은 그렇게 되기를 바라는 마음이 있지만 자랑스럽지는 않음

• 첫 직장에서의 경험을 공유함

  • C로 소프트웨어를 작성했으며, 상업용 소프트웨어를 현실적으로 작성할 수 있는 유일한 언어였음
  • 빌드를 할 수 있는 사람은 한 명뿐이었고, 상업용 빌드 도구를 사용했으며, 그 도구를 사용할 수 있는 유일한 사람이었음
  • 빌드는 몇 시간이 걸렸음
  • 우리는 잘하고 있다고 생각함

• 소프트웨어를 파괴하는 이유에 대한 의견

  • XYZ의 사실상의 표준이 우리에게 맞춤화된 것보다 낫다고 항상 생각함으로써 소프트웨어를 파괴함
  • 일반적인 접근 방식은 많은 문제에 대한 얕은 해결책을 쉽게 전환할 수 있음
  • 기술자들은 이러한 접근 방식을 좋아하며, 특히 직업을 자주 바꾸기 때문에 몇 가지를 가지고 있음
  • 그러나 맞춤형 솔루션이 일반적인 것보다 훨씬 더 성능이 좋음

• 모든 진술은 거래임

  • 모든 경우에 무언가를 희생하여 다른 것을 얻음
  • 때로는 바퀴를 재발명하지 않는 것이 타당함
  • 때로는 학습을 위해 바퀴를 재발명해야 함
  • 전체적으로 우리는 파괴하는 것보다 더 많은 것을 창조하고 있음
  • 부정적인 입장을 취할 필요성을 느끼지 않음

• antirez를 존경하지만, 이 게시물은 토론에서 유지되지 않을 좋은 소리의 짧은 진술로 가득 차 있다고 생각함

  • 예: 초보자는 바퀴를 재발명해서는 안 됨
  • 그들은 주어진 맥락에서 사용 가능한 도구를 사용해야 함
  • 그들이 실험하고 싶다면 자신만의 컴파일러를 작성해야 함
  • 그러나 그것을 생산에 사용해서는 안 됨
  • 역 API 호환성은 대부분의 경우 비즈니스 결정임
  • "우리는 소프트웨어를 파괴하고 있다"로 모든 문장을 시작하는 것은 도움이 되지 않음
  • 이것은 실제보다 훨씬 더 암울하게 들림

• 복잡성/종속성 그래프에 대한 의견

  • 무작위 애플리케이션의 복잡성/종속성 그래프가 절대적으로 미쳤음
  • 펌웨어와 OS를 포함하지 않지만, 충분히 가까움
  • 전이적 종속성 문제를 해결해야 함
  • OS(Win32 API, Linux syscalls)를 C로 작성하는 모든 것의 유일한 하드 종속성으로 간주함
  • Java/Python으로 전환하면 이 레이어를 제어할 수 없음
  • 모든 라이브러리에 의존하지 않고 특정 상황에 맞는 몇 백 줄의 코드를 작성하는 것이 필요함
  • 유지 보수 부담이 증가하지만, 종속성도 유지 보수가 필요함
  • 잘못된 API를 가질 수 있으며, 호환성을 무작위로 깨거나, 버려지거나, 악성 소프트웨어가 될 수 있음
  • 유용한 프로젝트의 개인적인 최대 라인 수는 5-10KLOC의 Java/JS/Python임
  • 몇 시간 내에 검토할 수 있으며 몇 년 후에 쉽게 수정할 수 있음

• 소프트웨어를 파괴하는 요소들

  • Leetcode 인터뷰, 이력서 기반 개발, 빈번한 직업 이동, 성장 투자 사기, 메트릭 게임, 승진 추구, 스프린트 연극, 조직 차트의 모든 수준에서의 허풍, 산업의 무관심