생각 없이 배우는 것은 노동력을 잃는 것입니다. 배우지 않은 생각은 위험하다.
과거의 프로그래머 닌자들은 이러한 트릭을 사용하여 코드 관리자의 정신을 갈고닦았습니다.
코드 검토 전문가는 테스트 작업에서 이를 찾습니다.
초보 개발자는 때때로 프로그래머 닌자보다 더 잘 사용합니다.
주의 깊게 읽고 자신이 누구인지 알아보세요. 닌자인가요, 초보자인가요, 아니면 코드 리뷰어인가요?
아이러니가 감지되었습니다.
많은 사람들이 닌자의 길을 따르려고 노력합니다. 성공하는 사람은 거의 없습니다.
코드를 최대한 짧게 만드세요. 당신이 얼마나 똑똑한지 보여주세요.
미묘한 언어 기능을 안내해 드립니다.
예를 들어 삼항 연산자 '?' 를 살펴보세요. :
// 잘 알려진 자바스크립트 라이브러리에서 가져옴 나 = 나 ? 나는 <0? Math.max(0, len + i) : i : 0;
멋지죠? 그렇게 쓴다면 이 선을 넘어 i 의 가치가 무엇인지 이해하려고 노력하는 개발자는 즐거운 시간을 보낼 것입니다. 그런 다음 당신에게로 와서 답을 구하십시오.
짧은 것이 항상 더 낫다고 말해주세요. 그들을 닌자의 길로 안내하십시오.
도는 말없이 숨어 있습니다. 오직 도(道)만이 잘 시작되고 잘 완성된다.
코드를 더 짧게 만드는 또 다른 방법은 어디에서나 단일 문자 변수 이름을 사용하는 것입니다. a , b 또는 c 와 같습니다.
진짜 숲 속의 닌자처럼 짧은 변수가 코드에서 사라진다. 누구도 편집기의 "검색"을 사용하여 이를 찾을 수 없습니다. 그리고 누군가가 그렇게 한다고 해도 그들은 이름 a 또는 b 무엇을 의미하는지 "해독"할 수 없을 것입니다.
…하지만 예외가 있습니다. 진짜 닌자는 "for" 루프에서 i 카운터로 사용하지 않습니다. 어디든 있지만 여기는 아닙니다. 주위를 둘러보면 더 많은 이국적인 글자들이 있습니다. 예를 들어 x 또는 y .
루프 카운터로 사용되는 이국적인 변수는 루프 본문이 1~2페이지를 차지하는 경우 특히 좋습니다(가능하면 더 길게 만드세요). 그러면 누군가가 루프 내부를 자세히 들여다보면 x 라는 변수가 루프 카운터라는 것을 빨리 알아낼 수 없을 것입니다.
팀 규칙에서 한 글자로 된 모호한 이름의 사용을 금지하는 경우에는 이름을 줄이고 약어를 만드세요.
이와 같이:
list → lst .
userAgent → ua .
browser → brsr .
…등
정말 좋은 직관을 가진 사람만이 그러한 이름을 이해할 수 있을 것입니다. 모든 것을 단축해 보세요. 합당한 사람만이 코드 개발을 지지할 수 있어야 합니다.
큰 광장에는 모퉁이가 없다
큰 그릇이 마지막으로 완성되고,
위대한 음표는 정제된 소리이며,
위대한 이미지에는 형태가 없습니다.
이름을 선택할 때 가장 추상적인 단어를 사용하십시오. obj , data , value , item , elem 등과 같습니다.
변수의 이상적인 이름은 data 입니다. 가능한 모든 곳에서 사용하세요. 실제로 모든 변수에는 데이터가 들어 있습니다. 그렇죠?
…하지만 data 이미 수집된 경우에는 어떻게 해야 할까요? value 시도해 보세요. 또한 보편적입니다. 결국 변수는 결국 값을 얻습니다.
유형에 따라 변수 이름을 지정합니다: str , num …
한번 시도해 보세요. 젊은 동수라면 이런 이름이 닌자에게 정말 유용한지 궁금할 것입니다. 실제로 그렇습니다!
물론, 변수 이름은 여전히 의미가 있습니다. 변수 내부에 문자열, 숫자 또는 기타 항목이 무엇인지 알려줍니다. 그러나 외부인이 코드를 이해하려고 시도하면 실제로 정보가 전혀 없다는 사실에 놀라게 될 것입니다! 그리고 궁극적으로 잘 생각한 코드를 변경하지 못할 것입니다.
값 유형은 디버깅을 통해 쉽게 알아낼 수 있습니다. 그런데 변수의 의미는 무엇입니까? 어떤 문자열/숫자를 저장합니까?
좋은 명상 없이는 알아낼 방법이 없습니다!
…하지만 그런 이름이 더 이상 없다면 어떨까요? 숫자만 추가하세요: data1, item2, elem5 …
진정으로 세심한 프로그래머만이 귀하의 코드를 이해할 수 있어야 합니다. 그런데 그걸 어떻게 확인하나요?
방법 중 하나는 date 및 data 와 같은 유사한 변수 이름을 사용하는 것입니다.
가능한 곳에 섞으세요.
이러한 코드를 빠르게 읽는 것은 불가능합니다. 그리고 오타가 나면… 음… 우리는 오랫동안 갇혀서 차를 마실 시간입니다.
말할 수 있는 도는 영원한 도가 아니다. 이름 붙여질 수 있는 이름은 영원한 이름이 아니다.
같은 것에 비슷한 이름을 사용하면 삶이 더욱 흥미로워지고 대중에게 창의성을 보여줄 수 있습니다.
예를 들어 함수 접두사를 고려해보세요. 함수가 화면에 메시지를 표시하는 경우 - displayMessage 와 같이 display… 로 시작하세요. 그런 다음 다른 함수가 화면에 사용자 이름과 같은 다른 내용을 표시하면 show… (예: showName )로 시작하세요.
그러한 기능들 사이에는 미묘한 차이가 있지만 아무 것도 없다는 것을 암시하십시오.
팀의 동료 닌자들과 약속을 하세요. John이 자신의 코드에서 display... 기능을 "표시"하기 시작하면 Peter는 render.. 사용할 수 있고 Ann은 paint... 사용할 수 있습니다. 코드가 얼마나 더 흥미롭고 다양해졌는지 주목해 보세요.
...그리고 이제 해트트릭이군요!
중요한 차이점이 있는 두 기능의 경우 동일한 접두사를 사용하세요!
예를 들어, printPage(page) 함수는 프린터를 사용합니다. 그리고 printText(text) 함수는 텍스트를 화면에 표시합니다. 익숙하지 않은 독자가 비슷한 이름의 함수 printMessage 에 대해 잘 생각해 보도록 하세요. “메시지를 어디에 넣나요? 프린터로? 아니면 화면으로?”. 정말 빛나게 하려면 printMessage(message) 새 창에 출력해야 합니다!
전체가 나누어지면 부분이 생긴다.
이름이 필요합니다.
이미 충분한 이름이 있습니다.
언제 멈춰야 할지 알아야 합니다.
꼭 필요한 경우에만 새 변수를 추가하세요.
대신 기존 이름을 재사용하세요. 그냥 새로운 값을 쓰면 됩니다.
함수에서는 매개변수로 전달된 변수만 사용하려고 합니다.
그러면 현재 변수에 정확히 무엇이 들어 있는지 식별하기가 정말 어려워집니다. 그리고 그것이 어디서 왔는지도요. 목적은 코드를 읽는 사람의 직관력과 기억력을 키우는 것입니다. 직관력이 약한 사람은 코드를 한 줄씩 분석하고 모든 코드 분기를 통해 변경 사항을 추적해야 합니다.
이 접근 방식의 고급 변형은 루프나 함수 중간에 값을 비슷한 값으로 은밀하게(!) 바꾸는 것입니다.
예를 들어:
함수 닌자Function(elem) {
// elem을 사용하는 20줄의 코드
elem = 클론(요소);
// 20개 라인이 추가되었습니다. 이제 요소의 복제본으로 작업합니다!
} 함수의 후반부에서 elem 사용하여 작업하려는 동료 프로그래머는 놀랄 것입니다. 디버깅 중에만 코드를 검토한 후에 그들은 복제본을 사용하여 작업하고 있음을 알게 될 것입니다!
코드에서 정기적으로 나타납니다. 숙련된 닌자에게도 치명적입니다.
변수 이름 앞에 밑줄 _ 및 __ 넣습니다. _name 또는 __value 와 같습니다. 당신이 그 의미를 알고 있다면 좋을 것입니다. 아니면 특별한 의미 없이 그냥 재미로 추가하는 것이 더 좋습니다. 아니면 다른 장소에서 다른 의미를 갖습니다.
한 번의 총으로 두 마리의 토끼를 죽일 수 있습니다. 첫째, 코드가 길어지고 가독성이 낮아지고, 둘째, 동료 개발자가 밑줄이 무엇을 의미하는지 파악하는 데 오랜 시간을 소비할 수 있습니다.
똑똑한 닌자는 코드의 한 지점에 밑줄을 넣고 다른 곳에서는 이를 피합니다. 이는 코드를 더욱 취약하게 만들고 향후 오류가 발생할 가능성을 높입니다.
여러분의 실체가 얼마나 훌륭한지 모두가 보게 해주세요! superElement , megaFrame 및 niceItem 과 같은 이름은 확실히 독자에게 깨달음을 줄 것입니다.
실제로 한 손에는 super.. , mega.. , nice.. 라는 내용이 쓰여 있지만 다른 손에는 세부 정보가 표시되지 않습니다. 독자는 자신의 유급 근무 시간 중 한두 시간 동안 숨겨진 의미를 찾아 묵상하기로 결정할 수도 있습니다.
빛 속에 있을 때는 어둠 속에서 아무것도 볼 수 없습니다.
어둠 속에서는 빛 속에서 모든 것을 볼 수 있습니다.
함수 내부와 외부의 변수에 동일한 이름을 사용하십시오. 간단합니다. 새로운 이름을 만들려는 노력이 없습니다.
사용자 = authenticateUser()를 허용하십시오;
함수 렌더링() {
사용자 = anotherValue()를 보자;
...
...많은 줄...
...
... // <-- 프로그래머는 여기서 사용자와 작업하고 싶어하며...
...
} render 내부로 뛰어든 프로그래머는 아마도 외부 렌더를 섀도잉하는 로컬 user 있다는 것을 알아차리지 못할 것입니다.
그런 다음 그들은 authenticateUser() 의 결과인 외부 변수라고 가정하여 user 와 작업을 시도할 것입니다. 함정이 발생했습니다! 안녕하세요 디버거님...
아무것도 변하지 않는 것처럼 보이는 기능이 있습니다. isReady() , checkPermission() , findTags() 처럼… 외부 아무것도 변경하지 않고 계산을 수행하고 데이터를 찾아 반환한다고 가정합니다. 즉, "부작용"이 없는 것입니다.
정말 아름다운 비결은 주요 작업 외에 "유용한" 작업을 추가하는 것입니다.
동료 is.. , check.. 또는 find... 변경 사항이라는 함수를 보고 어리둥절한 표정을 짓는 것은 여러분의 이성의 경계를 확실히 넓힐 것입니다.
또 다른 놀라운 방법은 비표준 결과를 반환하는 것입니다.
당신의 독창적인 생각을 보여주세요! checkPermission 호출이 true/false 가 아닌 검사 결과가 포함된 복잡한 객체를 반환하도록 합니다.
if (checkPermission(..)) 작성하려고 하는 개발자는 이것이 왜 작동하지 않는지 궁금해할 것입니다. 그들에게 "문서를 읽어보세요!"라고 말하세요. 그리고 이 글을 주세요.
대도(大道)는 도처에 흐르고,
왼쪽에도 오른쪽에도.
이름에 적힌 내용으로 기능을 제한하지 마세요. 더 넓어지세요.
예를 들어, validateEmail(email) 함수는 (이메일의 정확성을 확인하는 것 외에도) 오류 메시지를 표시하고 이메일을 다시 입력하도록 요청할 수 있습니다.
추가 작업은 함수 이름에서 명확하지 않아야 합니다. 진정한 닌자 코더라면 코드에서도 이러한 내용이 명확하지 않게 됩니다.
여러 작업을 하나로 결합하면 코드가 재사용되지 않도록 보호됩니다.
다른 개발자가 이메일을 확인하기만 하고 메시지를 출력하지 않기를 원한다고 상상해 보십시오. 두 가지를 모두 수행하는 함수 validateEmail(email) 은 적합하지 않습니다. 그래서 그들은 그것에 관해 무엇이든 물어봄으로써 당신의 명상을 깨뜨리지 않을 것입니다.
위의 모든 "조언"은 실제 코드에서 나온 것입니다. 때로는 숙련된 개발자가 작성하기도 합니다. 어쩌면 당신보다 경험이 더 많을 수도 있습니다 ;)
그 중 일부를 따라해 보세요. 그러면 여러분의 코드는 놀라움으로 가득 차게 될 것입니다.
그 중 많은 것을 따르면, 당신의 코드는 진정한 당신의 것이 될 것이며, 누구도 그것을 바꾸고 싶어하지 않을 것입니다.
모두 따라해 보세요. 여러분의 코드는 깨달음을 찾고 있는 젊은 개발자에게 귀중한 교훈이 될 것입니다.