최소 놀라움의 원칙에 모든 영광을! ❤

PoLA은 내가 가장 좋아하는 원칙 중 하나이며 KISS principle만큼, 아마도 더 많이 알려졌으면 합니다. 또한 만들고 싶고 다른 사람들이 사용해야 하는 모든 것에 대해 생각하는 재미있는 방법이기도 합니다.

폴라를 만나보세요

그 이면의 아이디어는 간단합니다. 당신이 만드는 모든 것이 놀랍거나 부정적으로 놀라지 않아야 합니다. 인간이 도입한 버그를 피하고 좋은 사용자 경험을 제공하는 데 도움이 될 수 있는 가능한 적은 WTF. 이것은 기본적으로 일관성, 일반적인 사용자 기대 및 사용자 경험을 따르는 것을 의미합니다. 원칙은 KISS와 유사하게 보편적으로 적용할 수 있으며 소프트웨어 개발자로서 인터페이스, 코드 동작 또는 소프트웨어 아키텍처 토론을 정의하는 데 자주 사용합니다.

예

유명한 Javascript 비교 연산자==에서 이를 보여드리겠습니다. 비교는 값 "" , [] 및 0 에 대해 다음과 같이 작동합니다.

>> [] == 0
true

>> "" == 0
true

>> "" == []
true

이러한 값의 경우 transitive relation 처럼 작동합니다. 그러나 "" 를 "0" 로 바꾸면 "0" == [] 는 실제로 false 를 반환합니다.

>> [] == 0
true

>> "0" == 0
true

>> "0" == []
false

필요한 모든 Javascript 세부 정보를 알고 있다면 이 동작이 이해가 될 수 있지만 나머지 인류에게는 그게, 음... 전혀 그렇지 않습니다. 그리고 그것이 요점입니다. 그것은 구체적으로 어떻게 최소한의 놀라움의 원칙을 깨뜨립니까?

마지막 문장은 true이어야 나머지 비교의 동작을 따라야 한다고 말할 수도 있지만, 실제로 가장 놀라움의 원칙을 따르려면 나머지 비교는 첫 번째 문장에서 true 반환되지 않아야 한다고 생각합니다. 장소. 그들은 예외를 던지거나(실제로 비교할 수 없는 것을 비교) returnundefined(이러한 비교의 결과를 실제로 정의해서는 안 됨)하거나 그냥 returnfalse(정말 같지 않음)해야 합니다. 올바른 솔루션이 때때로 컨텍스트에 따라 달라지기 때문에 이것은 실제로 PoLA를 멋지게 보여줍니다.

공정한 Javascript에는 덜 놀라운 동작이 있는 엄격한 연산자===도 있지만 PoLA를 실제로 보여주지는 않겠죠? 그리고 ==는 다른 프로그래밍 언어에서 온 사람이 가장 먼저 사용하는 것입니다.

그래서...

PoLA는 간단하지만 정말 강력한 원칙입니다. PoLA를 염두에 두고 설계할 때 버그와 문제를 줄이는 더 많은 관점을 명시적으로 고려하는 것이 도움이 됩니다.

PoLA 위반 사례가 있습니까? 그들은 일반적으로 배운 훌륭한 교훈입니다.