코드 속의 마법은 무엇입니까? 왜 피해야 합니까?

나는 소프트웨어를 개발한 지 8년이 넘었는데, 내가 배운 교훈 중 하나는 가능한 한 마법 코드 사용을 피하는 것이다.
그래서...얼마나 이상한 말인가, 그렇지?'마법을 피하라'?이게 도대체 무슨 뜻이야?
내가 이 말들이 나에게 무엇을 의미하는지 설명하는 것을 허락해 주십시오.

코드 속의 마법은 무엇입니까
내가 말한'마법 코드'는 소프트웨어 내부에서 발생하는 일을 가리키며, 개발자가 작성한 직접적이고 의미 있는 성명이 아니다.
다음 예는 다음과 같습니다.

databaseManager = new DatabaseManager();
databaseManager->persist();

이 코드에서, 나는 직접 함수 호출 persist() 을 작성했다.따라서 코드 세그먼트가 실행될 때 컴퓨터가 persist()에 대한 호출을 실행하기를 희망합니다.행위는 코드의 읽기 방식과 밀접하게 관련되어 있다.나는 큰소리로 낭독할 수 있다. 내가 할 말은 발생한 일과 일치한다.
그럼 이거는요?

databaseManager = new DatabaseManager();
magician.call('persist', 'all');

이것은 마법의 첫 번째 예이다. 위의 대상 magician 은 모든 기존 대상을 찾아서 선택한 함수를 호출할 수 있다.따라서 함수persist()는 호출되지만 앞의 코드 세션과 같다.상기 코드에서무엇을 썼는지와 무슨 일이 일어났는지 사이의 관계는 아직 분명하지 않다.이 두 단락의 코드는 같은 결과를 낳았지만, 그것들의 작성 방식은 매우 다르다.
두 번째 예는 매우 편리하다.

public class MyClass {
  int x = 5;

  public static void main(String[] args) {
    MyClass myObj = new MyClass();
    System.out.println(myObj.x);
  }
}

위의 과정은 매우 간단하고 이해하기 쉽다.이것은 x 정수 속성을 포함하는 클래스로 5로 초기화됩니다.main 기능이 인쇄됩니다.
이 수법은 어떻습니까?

public class MyClassWithXFive {
}

믿든 안 믿든 너에게 달렸지만 공류MyClassWithXFive의 행위는 상기MyClass와 완전히 같다.그것은 5로 초기화된 x 정수 속성을 가지고 있으며, 출력된 main 함수를 가지고 있다.
이것은 내가 개발하고 있는 일부 소프트웨어에 규칙이 있기 때문이다(신기한 규칙?)클래스 이름이 "WithXFive"로 끝나면 소프트웨어는 자동으로 5로 초기화된 x 속성을 생성합니다!이 속성의 사용 방법은 앞의 코드 세그먼트와 같습니다.
이것은 코드에서 신기한 행위의 전형적인 예이다. 일부 속성, 일부 정의, 일부 규칙의 출현은 당신이 작성한 코드 때문이 아니라, 클래스나 속성을 위해 선택한 이름 때문이다.
또 몇 가지 유사한 예가 있다.

하나의 속성id을 성명하는데 이 속성은 주어진 클래스

의 주 표식자로 자동으로 사용된다.

접미사Test가 있는 클래스를 성명합니다. 이 클래스는 자동으로 테스트

로 고려되고 실행됩니다.

다른 종류의 마법
다음은 내가 생각하는 코드의'마력'을 열거한 상세하지 않은 목록이다.
1) 앞서 설명한 대로 클래스, 속성 및 파일의 이름으로 인해 발생하는 행위
해상도 덕분에 클래스/속성/파일 이름을 추출하고 특정한 패턴을 찾을 수 있습니다. 이런 신기한 일이 발생할 수 있습니다.일단 이런 패턴을 발견하면 일부 행위를 촉발할 것이다.
이것은 클래스의 이름이 응용 프로그램의 행동을 결정한다는 것을 의미한다.클래스의 이름을 수정할 때 버그를 가져올 수 있습니다.
2) 코드가 특정 디렉토리에 있기 때문에 발생하는 행위
이런 신기한 일이 일어날 수 있는 것은 탐색기 덕분이다. 탐색기는 주어진 디렉터리를 보고, 이 디렉터리의 모든 발견에서 행동을 촉발한다.
이것은 클래스의 위치가 응용 프로그램의 행동을 결정한다는 것을 의미한다.
원본 코드 파일을 이동하면 버그를 가져올 수 있습니다.
3) 자동 생성된 가공소재
이 마법은 당신의 코드를 해석하고 디스크에 계산하고 쓰기 위한 다른 코드 블록을 구축합니다.최종적으로 실행할 때 처리되는 코드는 당신이 작성한 코드가 아니라 생성된 코드입니다.
이 위험성은 비교적 작아서 캐시 목적에 자주 사용된다.
풍자적인 것은 magic strings라는 개념이 있지만, 나는 그것이'마법'이라고 생각하지 않는다.😄 하지만 이것은 또 다른 위험한 마법이다.

왜 소프트웨어 프로젝트에 마법을 사용합니까
나는 대부분의 경우 마법은 단순하기 위해 소프트웨어에 심어져 있다고 믿는다.그것은 개발자들이 절차, 부품, 그리고 일부 boilerplate code 를 작성하는 것을 피할 수 있도록 한다.그것은 중복과 무뇌 코드의 작성을 줄였다.내가 너에게 유일하게 해야 할 일은 너의 파일을 폴더 Z에 추가하는 것이다. 너는 완성했다. 이것은 듣기에 매우 매력적이다. 그렇지?
마법 코드는 특정 시간에 나타날 수 있어 진정한 문제의 우아한 해결 방안으로 삼을 수 있다.소프트웨어에는 모두가 알고 있는 가장 좋은 실천들이 있는데, 그들은 우리에게 무의미한 임무에 시간을 낭비하지 말라고 촉구한다.모든 것을 자동화하는 모토가 그 중의 하나다.
주어진 시간 내에 마법 코드는 이런 문제를 해결하는 좋은 방법으로 보인다.그러나 결점은 나중에 나타난다.

마법 비밀번호 문제
나는 가능한 한 마법을 사용하지 말라고 강력히 건의한다. 왜냐하면 일이 잘못되었을 때 마법을 처리하는 것이 얼마나 어려운지.
제 진술을 설명하기 위해서 랜덤 개발자인 밥이 주연한 이야기를 공유할 수 있도록 허락해 주십시오.
이야기가 시작되었을 때, 밥은 하나의 코드 라이브러리에 고용되었는데, 그 중에서 신기한 행동을 실현했다.이 코드 라이브러리는 웹 응용 프로그램입니다. 팀 담당자는 대부분의 사용자가 브라우저에서 이 프로그램을 사용하기를 원하지만, REST API를 제공합니다.좋은 소식: RESTAPI는 매우 스마트한 방식으로 구축된 것이다. 이것은 한 시스템에 의해 생성된 것이다. 이 시스템은 자동으로 이름이 'Exposed' 로 끝나는 모든 실체를 공개할 것이다.
코드 라이브러리에서 Bob은 다음과 같은 몇 가지 엔티티를 봅니다.

에는 이름에 따라 REST API의 범위에 속하는 솔리드 UserExposed가 있습니다.실제로 Bob은 응용 프로그램에 /users REST API 단점을 볼 수 있다.

ProductExposed도 범위에 있고 Bob도 /products API 엔드포인트를 사용할 수 있다.

공급업체의 실체가 있는데 그 실체는 범위 내에 있지 않다. 왜냐하면 그의 명칭이 규칙과 일치하지 않기 때문이다.

또 하나의 브랜드 실체가 있는데 범위 내에 있지 않다.

Bob이 코드 라이브러리와 API의 구축 방식에 대해 더욱 익숙해진 이상 제품 소유자가 왔다.그는 Bob에게 REST API에 /suppliers와 /brands 두 개의 새 끝점을 만들어 달라고 요구했다.멋있어, 간단해 보이지?Bob은 솔리드를 SupplierExposed 및 BrandExposed 및 API 시스템으로 이름만 바꾸면 됩니다.신기하게 들린다!
그래서 Bob은 IDE를 열고 클래스 이름을 수정하는 작업을 시작했다.Bob은 Brand로 시작하여 클래스의 이름을 BrandExposed로 변경합니다.읊다, 읊조리다API 엔드포인트/brands는 문서가 최신이라도 즉시 사용할 수 있습니다.Bob은 새 코드를 작성할 필요 없이 바로 사용할 수 있습니다.이것은 정말 대단하다!
그런 다음 Bob이 수정Supplier되어 이름SupplierExposed으로 변경됩니다.Bob은 파일을 저장하고 변경 사항을 제출합니다.하지만...아무 일도 없었어.이상했어API 끝점을 실현해야 합니다.그는 무엇을 놓쳤습니까?그는 서류를 꼼꼼히 검사하고 보존하며 잠시 기다렸다...그러나 여전히 /suppliers개의 결승점이 없다.아무것도 아니에요.허공에서 나온 것은 아무것도 없다.
그리고 이건...나쁜 일이 시작된 곳이야.Bob은 왜 작동하지 않는지 이해해야 하기 때문이다.😱
이 시스템은 매우 신기하기 때문에, Bob은 REST API가 생성한 함수가 어디에 있는지 추적하기 어렵다.어떤 것들이 왜 촉발되지 않았는지 찾기가 매우 어렵다.밥은 심지어 언제 촉발해야 할지 모른다.
전통적인 명령식 프로그래밍 문장에서 함수와 변경이 어떻게 발생했는지 쉽게 이해할 수 있습니다.디버거는 심지어 당신을 위해 인쇄할 수 있습니다!하지만 이제 마법은 도착했으니 너(밥)는 더 이상 그것에 의지할 수 없다.신기한 코드는 너의 소프트웨어를 내비게이션하기 어렵게 한다.
한 시간의 노력 끝에 Bob은 코드 라이브러리에서 REST API 단점을 생성하는 구역을 찾았다고 가정합니다.더 큰 문제는 같은 코드가 생성/products,/users,/suppliers개 단점을 책임진다는 것이다!그래서 코드에는 generateName(),loopThroughProperties,loopThroughEligibleObjects() 이런 내용이 가득했다.코드는 매우 추상적이어서 발생하는 일을 추적하여 버그와 연결시키기 어렵다.
만약 Bob이 최종적으로 그가 문제라고 생각하는 근본적인 원인을 찾았다면, 그는 그의 변경 사항이 /suppliers 단점을 복구할 수 있고, 같은 코드로 생성된 모든 다른 단점을 수정하거나 파괴하지 않을 수 있을 것이라고 확보하지 못했다.😱
나는 Bob의 이야기가 코드 중의 마법의 함정인 유니버설 코드, 추상 코드, 실제 잘못된 장면과 연결하기 어렵고 내비게이션, 디버깅과 유지보수가 어렵다고 생각한다.
그나저나 때때로 언급되는 장애물Frameworks의 사용 단점 중 하나다.프레임이 마법에 의존하는 것은 결코 드물지 않다.앞에서 말한 바와 같이 이것은 개발자의 수중에 매우 편리한 자산이 될 수 있지만, 디버깅/확장/갱신이 필요할 때, 일은 엉망이 될 수 있다.

그래서 마법 비밀번호는 피해야 돼요.
마법 암호는 양날의 검이다.그것은 매우 강력한 시스템을 세울 수 있는 거대한 잠재력을 가지고 있다.그것은 캐시와 같은 어떤 상황에서도 성능을 향상시킬 수 있다.
그러나 이러한 장점은 높은 유지보수 비용과 수반된다. 이것이 바로 내가 당신에게 대부분의 상황에서 그것을 사용하지 말라고 건의한 이유이다.
the blog post I wrote 3 years ago "Basic code is easy to maintain"에 따르면, 나는 여전히 우리 대다수의 사람들이 효율이 아니라 간단함을 선택해야 한다고 생각한다.
구글이나 페이스북만 아니면그리고 너는 효율과 복잡성을 선택할 수 있다😁 너는 괜찮을 거야!