"Simple is robust"라는 말이 마음에 듦. 시스템의 복잡성이 적을수록 변경이 용이함을 의미함. 미래를 위한 계획은 확장 가능한 코드보다는 직관적인 코드로 세워야 함. 예를 들어, 상황이 요구할 때만 추상화하고, 단순한 중복을 권장하며, 초기에는 모놀리스를 사용하고, 수평 확장보다는 수직 확장을 우선시함. 여러 0-1 시스템을 구축하면서 이러한 공통점을 발견함.
테스트나 관찰 가능성에 대한 언급이 없다는 점이 놀라움. 테스트는 유지 비용이 들지만, 코드를 제거할 때 문제가 발생할 위험을 줄여줌. 외부 호출자에게 서비스를 노출할 때는 일부 호출을 폐기 예정으로 표시하고, 여전히 호출되는지 관찰하는 강력한 방법이 필요함. 최근에 GraphQL 리졸버를 반자동으로 제거했으며, 사용 빈도에 대한 메트릭을 통해 삭제할 수 없는 리졸버를 파악함. GraphQL에는 폐기 예정 주석이 있지만, 서비스에서는 특별히 처리하지 않았음. 관찰 가능성을 추가하여 폐기 예정 함수가 호출되었는지 플래그를 설정하고, 충분히 오랜 기간 동안 프로덕션에서 실행한 후 외부에 노출된 코드를 안전하게 삭제할 수 있음.
"삭제를 위한 설계"를 홍보하게 됨. 과거에는 모든 상황을 계획하고 모든 필요를 충족시키는 작품을 만들 수 있다고 생각했지만, 미래의 필요를 예측하는 것은 어려움. 언젠가는 내가 만든 것이 누군가에게는 쓸모없는 것이 될 것이고, 그들이 그것을 철거하는 것이 정당화될 것임. 따라서 제거하기 쉽게 만드는 데 노력을 기울여야 함. 이는 종종 결합을 줄이는 결과를 가져오지만, 모든 것을 메타 구성 가능한 프레임워크로 분리하려는 젊은 개발자와는 다름. 때로는 논리적으로 이해하기 쉬운 경우 긴밀한 결합이 더 나음.
코드를 삭제하기 쉽게 작성하려면 의존성을 피하기 위해 반복하고, 관리하기 위해 반복하지 말아야 함. 코드의 계층을 나누고, 간단하게 구현할 수 있지만 사용하기에는 불편한 부분으로 간단한 API를 구축해야 함. 코드를 분리하고, 작성하기 어려운 부분과 변경 가능성이 높은 부분을 나머지 코드와 서로 분리해야 함. 모든 선택을 하드코딩하지 말고, 런타임에 몇 가지를 변경할 수 있도록 해야 함. 개인적인 경험으로는 삭제하기 쉬운 코드는 계층화되고 모듈화되어 있어 확장하기도 쉬움.
계산 물리학 학생들에게 가장 좋은 계산은 신경 쓸 필요가 없는 것이라고 말해옴.
개인적으로 코드를 비즈니스 로직과 실제 구현으로 나눔. 비즈니스 로직은 그 특성상 중복될 수 있지만, 너무 많은 기술적 세부 사항이 중복되어서는 안 됨. 비즈니스 로직을 직접 처리하지 않고 애플리케이션 독립적으로 유지하는 한, 비즈니스 로직은 원하는 만큼 엉망일 수 있음. 문제가 발생하고 잘 되지 않는 경우, 전체 구현을 삭제할 수 있는 옵션이 있으며, 이를 수정하고 실제 사양을 구현에서 찾으려고 강요받지 않음.
첫 번째 문단의 명백한 실수: 코드 재사용의 문제는 나중에 마음을 바꾸는 데 방해가 된다는 것임. 이는 일반적으로 잘못된 주장임. 마음을 바꾸고 코드가 열 곳에 복사되어 붙여넣기 되었다면, 열 곳을 변경해야 함. 반면, 코드가 함수에 있다면 한 번만 변경하면 됨. 열 번의 호출 중 하나가 변경되지 않아야 한다면, 여전히 복사하여 붙여넣기할 수 있으며, 함수를 더 일반적으로 만들 수도 있음. 길을 건널 때 주위를 살피지 않는 것처럼, 복사하여 붙여넣기는 거의 항상 나쁜 생각임.
나쁜 코드는 제거하기 어렵기 때문에 오래 남아 있다는 훌륭한 상관관계가 있음.
소프트웨어를 가능한 한 기본 상태로 사용하고, 커스터마이징을 깊게 하지 말라는 것인지 궁금함.
Hacker News 의견
"Simple is robust"라는 말이 마음에 듦. 시스템의 복잡성이 적을수록 변경이 용이함을 의미함. 미래를 위한 계획은 확장 가능한 코드보다는 직관적인 코드로 세워야 함. 예를 들어, 상황이 요구할 때만 추상화하고, 단순한 중복을 권장하며, 초기에는 모놀리스를 사용하고, 수평 확장보다는 수직 확장을 우선시함. 여러 0-1 시스템을 구축하면서 이러한 공통점을 발견함.
테스트나 관찰 가능성에 대한 언급이 없다는 점이 놀라움. 테스트는 유지 비용이 들지만, 코드를 제거할 때 문제가 발생할 위험을 줄여줌. 외부 호출자에게 서비스를 노출할 때는 일부 호출을 폐기 예정으로 표시하고, 여전히 호출되는지 관찰하는 강력한 방법이 필요함. 최근에 GraphQL 리졸버를 반자동으로 제거했으며, 사용 빈도에 대한 메트릭을 통해 삭제할 수 없는 리졸버를 파악함. GraphQL에는 폐기 예정 주석이 있지만, 서비스에서는 특별히 처리하지 않았음. 관찰 가능성을 추가하여 폐기 예정 함수가 호출되었는지 플래그를 설정하고, 충분히 오랜 기간 동안 프로덕션에서 실행한 후 외부에 노출된 코드를 안전하게 삭제할 수 있음.
"삭제를 위한 설계"를 홍보하게 됨. 과거에는 모든 상황을 계획하고 모든 필요를 충족시키는 작품을 만들 수 있다고 생각했지만, 미래의 필요를 예측하는 것은 어려움. 언젠가는 내가 만든 것이 누군가에게는 쓸모없는 것이 될 것이고, 그들이 그것을 철거하는 것이 정당화될 것임. 따라서 제거하기 쉽게 만드는 데 노력을 기울여야 함. 이는 종종 결합을 줄이는 결과를 가져오지만, 모든 것을 메타 구성 가능한 프레임워크로 분리하려는 젊은 개발자와는 다름. 때로는 논리적으로 이해하기 쉬운 경우 긴밀한 결합이 더 나음.
코드를 삭제하기 쉽게 작성하려면 의존성을 피하기 위해 반복하고, 관리하기 위해 반복하지 말아야 함. 코드의 계층을 나누고, 간단하게 구현할 수 있지만 사용하기에는 불편한 부분으로 간단한 API를 구축해야 함. 코드를 분리하고, 작성하기 어려운 부분과 변경 가능성이 높은 부분을 나머지 코드와 서로 분리해야 함. 모든 선택을 하드코딩하지 말고, 런타임에 몇 가지를 변경할 수 있도록 해야 함. 개인적인 경험으로는 삭제하기 쉬운 코드는 계층화되고 모듈화되어 있어 확장하기도 쉬움.
계산 물리학 학생들에게 가장 좋은 계산은 신경 쓸 필요가 없는 것이라고 말해옴.
개인적으로 코드를 비즈니스 로직과 실제 구현으로 나눔. 비즈니스 로직은 그 특성상 중복될 수 있지만, 너무 많은 기술적 세부 사항이 중복되어서는 안 됨. 비즈니스 로직을 직접 처리하지 않고 애플리케이션 독립적으로 유지하는 한, 비즈니스 로직은 원하는 만큼 엉망일 수 있음. 문제가 발생하고 잘 되지 않는 경우, 전체 구현을 삭제할 수 있는 옵션이 있으며, 이를 수정하고 실제 사양을 구현에서 찾으려고 강요받지 않음.
첫 번째 문단의 명백한 실수: 코드 재사용의 문제는 나중에 마음을 바꾸는 데 방해가 된다는 것임. 이는 일반적으로 잘못된 주장임. 마음을 바꾸고 코드가 열 곳에 복사되어 붙여넣기 되었다면, 열 곳을 변경해야 함. 반면, 코드가 함수에 있다면 한 번만 변경하면 됨. 열 번의 호출 중 하나가 변경되지 않아야 한다면, 여전히 복사하여 붙여넣기할 수 있으며, 함수를 더 일반적으로 만들 수도 있음. 길을 건널 때 주위를 살피지 않는 것처럼, 복사하여 붙여넣기는 거의 항상 나쁜 생각임.
나쁜 코드는 제거하기 어렵기 때문에 오래 남아 있다는 훌륭한 상관관계가 있음.
소프트웨어를 가능한 한 기본 상태로 사용하고, 커스터마이징을 깊게 하지 말라는 것인지 궁금함.