GN⁺: 우리가 소프트웨어를 망가뜨리고 있음
(antirez.com)- 우리는 기능을 추가하거나 특정 부분을 최적화할 때 복잡성을 더 이상 고려하지 않음으로써 소프트웨어를 망가뜨리고 있음
- 우리는 복잡한 빌드 시스템으로 소프트웨어를 망가뜨리고 있음
- 우리는 터무니없는 의존성 사슬로 모든 것을 비대하게 만들고 취약하게 만들면서 소프트웨어를 망가뜨리고 있음
- 우리는 새로운 프로그래머들에게 "Don’t reinvent the wheel!"이라고 말함으로써 소프트웨어를 망가뜨리고 있음. 그러나 바퀴를 재발명하는 것은 사물이 어떻게 작동하는지 배우는 방법이자 새로운 다른 바퀴를 만드는 첫 단계임
- 우리는 더 이상 API의 하위 호환성을 고려하지 않음으로써 소프트웨어를 망가뜨리고 있음
- 우리는 이미 작동하는 것들을 재작성하도록 몰아붙임으로써 소프트웨어를 망가뜨리고 있음
- 우리는 모든 새로운 언어, 패러다임, 프레임워크가 나올 때마다 뛰어듦으로써 소프트웨어를 망가뜨리고 있음
- 우리는 기존의 복잡한 라이브러리를 다루는 어려움을 직접 구현하는 것과 비교할 때 항상 과소평가함으로써 소프트웨어를 망가뜨리고 있음
- 우리는 XYZ의 사실상 표준이 우리의 특정 용도에 맞춰 직접 구현할 수 있는 것보다 언제나 더 낫다고 여기면서 소프트웨어를 망가뜨리고 있음
- 우리는 코드 주석이 쓸모없다고 주장함으로써 소프트웨어를 망가뜨리고 있음
- 우리는 소프트웨어를 순수한 공학적 학문으로만 착각함으로써 소프트웨어를 망가뜨리고 있음
- 우리는 더 이상 축소가 불가능한 시스템을 만들어 소프트웨어를 망가뜨리고 있음: 어떤 시스템에서든 단순한 것은 단순하게 달성되어야 하는 것임
- 우리는 가능한 한 빨리 코드를 만들어내려 하면서 가능한 한 잘 설계된 코드를 만들려는 노력은 하지 않음으로써 소프트웨어를 망가뜨리고 있음
- 우리는 소프트웨어를 망가뜨리고 있으며, 남게 될 것은 더 이상 해킹의 즐거움을 주지 않을 것임
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 인터뷰, 이력서 기반 개발, 빈번한 직업 이동, 성장 투자 사기, 메트릭 게임, 승진 추구, 스프린트 연극, 조직 차트의 모든 수준에서의 허풍, 산업의 무관심