웹 개발 당신이 피해야 할 10 가지 코딩 안티 패턴
웹 사이트 또는 응용 프로그램의 아키텍처를 설계하거나 효과적인 코딩 워크 플로를 자주 설정하면 반복되는 문제를 처리 할 수 있습니다. 우리는 반드시 이러한 소프트웨어 설계 문제를 처음부터 다시 해결할 필요는 없습니다. 아키텍처 수준의 솔루션을 재사용 할 수 있습니다. 같은 방식으로 마이크로 레벨의 코드 스 니펫.
디자인 패턴은 일반적으로 재사용 가능한 솔루션 특정 시나리오의 경우 일반적으로 발생하는 문제를 해결하기 위해 편리하게 사용하십시오., 코드를 최적화하는 데 크게 도움이 될 수 있습니다..
디자인 패턴은 잘 테스트 된 수식을 사용하여 개발 프로세스를 개선하는 데 큰 도움이되지만 때로는 잘못된 패턴도 있습니다. 이것을 안티 패턴이라고합니다..
반 패턴이란 무엇입니까??
용어 “반 패턴” 1998 년 안티 패턴 (AntiPatterns)이라는 책에 실 렸습니다. 처음에는 유용 해 보였던 재사용 솔루션, 그러나 나중에 나온다. 선보다 더 해를 입히는 것.
예를 들어 올바른 컨텍스트, 설정 또는 시간 (과거에 효과적이었던 솔루션이 현재에는 항상 작동하지 않을 수도 있음) 또는 다른 경우 전체 패러다임에서 패턴을 사용하지 않는 경우와 같이 다른 이유로 인해 발생할 수 있습니다. 처음부터 나빴어..
반 패턴도 자주 호출됩니다. 실패의 패턴. 좋은 소식은 그들을 인식하고 피할 수 있음.
이 글에서는 웹 개발에서 일반적으로 사용되는 10 가지의 반 패턴을 살펴보고 잘 짜여진 코드가 있다고 생각하게 만듭니다. (이 게시물에 나열된 반 패턴은 위에서 언급 한 책에서 찾을 수있는 반 패턴과 반드시 동일하지는 않습니다.)
1. 조기 최적화
좋은 타이밍은 코드 최적화에서 중요한 요소입니다. 우리는 반 패턴을 쉽게 재현 할 수 있습니다. “조숙 한 최적화”, 우리가 원하는 것을 정확히 알기 전에 작은 효율성에주의를 기울이고 개발 프로세스 초기에 너무 빨리 최적화한다면.
Donald Knuth의 유명한 인용문에 따르면 “조숙 한 최적화는 모든 악의 뿌리이다.“, 이는 과장 될 수 있지만 조기 최적화가 나중에 발생할 수있는 심각한 문제를 보여줍니다..
효과적인 아키텍처를 설정하기 전에 성능을 최적화하면 낮은 코드 가독성, 하다 디버깅과 유지 보수가 더 힘들다., 과 불필요한 부분을 추가하다 우리 코드에.
조기 최적화를 방지하려면 YAGNI (You 're Gonna Need It) 프로그래밍 원칙을 따르는 것이 좋습니다. “실제로 필요로 할 때 항상 물건을 구현하며, 필요할 때만 예견 할 수 있습니다..”
2. 바퀴의 재발견
그만큼 “바퀴의 재발 명” 반 패턴은 때로는라고도합니다. “진공 상태에서의 설계”. 우리가 원할 때 일어난다. 우리 스스로 모든 것을해라. 과 처음부터 모든 것을 써라., 이미 존재하는 메소드, API 또는 라이브러리를 찾지 않고.
바퀴를 재발 명하는 것은 단지 시간을 낭비하는 것이 아닙니다. 특히 기본 기능을위한 사용자 지정 솔루션은 표준 기능과 거의 비슷합니다. 많은 개발자와 사용자가 이미 테스트를 마쳤습니다..
3. 의존성 지옥
그 반대의 “바퀴의 재발 명” 반 패턴은 또 다른 일반적인 반 패턴입니다. “의존성 지옥”.
처음부터 모든 것을 작성하는 대신 다른 라이브러리의 특정 버전에 의존하는 너무 많은 제 3 자 라이브러리, 우리는 업데이트하기를 원할 때 거의 보조 할 수없는 상황에 쉽게 빠질 수 있습니다. 왜냐하면 이러한 종속 종속성이 많은 경우에 있기 때문입니다 서로 양립 할 수없는.
의존성은 패키지 관리자를 사용하여 해결할 수 있습니다. 상호 의존성을 현명하게 업데이트한다.. 우리가 문제로 너무 많이 압도 당하면 리팩토링이 좋은 아이디어가 될 수 있습니다..
4. 스파게티 코드
“스파게티 코드” 아마도 가장 유명한 코딩 반 패턴 일 것입니다. 그것은 적절한 아키텍처가 없기 때문에 디버그하거나 수정하기 어려운 응용 프로그램.
빈약 한 소프트웨어 설계의 결과는 스파게티 한 그릇과 구조가 유사한 일련의 코드입니다.. 엉키고 뒤얽힌. 스파게티 코드의 가독성은 매우 낮습니다. 정확히 작동하는 방식을 이해하는 것은 거의 불가능한 임무입니다.
스파게티 코드는 일반적으로 다른 나쁜 코딩 사례의 조합, 적절한 조건 블록을 포함하지 않는 코드, 다른 goto 문을 포함하는 많은 goto 문, 예외 및 스레드가있는 코드, 객체 간의 관계가 최소한이고, 재사용 할 수없는 함수 또는 메소드가 있거나 올바르게 문서화되지 않은 코드 조금도.
5. 순열에 의한 프로그래밍
“순열에 의한 프로그래밍” 또는 “사고에 의한 프로그래밍” 작은 수정을 연속적으로 시도하고 하나씩 테스트하고 평가 한 다음 문제의 해결 방법을 찾기 위해 처음 시도 할 때 발생합니다..
순열에 의한 프로그래밍은 쉽게 할 수 있습니다. 우리 코드에 새로운 버그를 소개한다., 더 나쁜 것은 여전히 우리가 반드시 인식하지 못하는 버그입니다. 대부분의 경우 솔루션이 가능한 모든 시나리오에서 작동하는지 여부를 예측하는 것도 불가능합니다..
6. 복사 및 붙여 넣기 프로그래밍
“복사하여 붙여 넣기 프로그래밍” (DRY) 코딩 원칙을 따르지 않을 때 발생하며 일반적인 솔루션을 만드는 대신 기존 코드 스 니펫을 다른 위치에 삽입 한 다음 나중에 해당 컨텍스트에 맞게 편집합니다..
이 연습 반복적 인 코드 결과, 삽입 된 코드 부분은 일반적으로 사소한 불일치 만 다를뿐입니다..
복사 및 붙여 넣기 프로그래밍은 초보 개발자 만이 아니며 숙련 된 프로그래머도 마찬가지입니다. 특정 작업을 위해 미리 작성되고 잘 테스트 된 코드 스 니펫을 사용하십시오., 쉽게 이어질 수있는 의도하지 않은 반복.
7. 카고 - 컬트 프로그래밍
의 이름 “화물 컬트 프로그래밍” 특정 민족 지학 현상에서 온다. “화물 컬트”. 카고 숭배는 제 2 차 세계 대전 후 남태평양에 나타났습니다. 선진 문명과의 강제 접촉은 원주민들이 코카콜라, TV, 화물선으로 섬으로 가져온 냉장고와 같은 제조 제품이 초자연적 인 것으로 만들어 졌다고 생각하게 만들었습니다 행동 양식; 서양인의 풍습과 유사한 마법의 의식을 수행하면 물건으로 가득 찬화물이 다시 올 것입니다.
우리가 카톨릭 컬트 프로그래밍의 반 패턴을 저 지르면 기본적으로 동일하게 적용됩니다. 우리는 다른 사람들에게 잘 작동하는 프레임 워크, 라이브러리, 솔루션, 디자인 패턴 등을 사용합니다., 왜 우리가 그렇게하는지 이해하지 않고, 또는 기술이 정확히 어떻게 작동하는지.
대부분의 경우 개발자는 의식을 잃지 않고 그 시간에 엉덩이를 의식적으로해라.. 이 방법은 응용 프로그램을 너무 부풀게 만들뿐 아니라 코드에 새로운 버그를 쉽게 도입 할 수 있기 때문에 좋지 않습니다..
8. 용암 흐름
우리는 “용암의 흐름” 우리가 필요로 할 때 반 패턴 중복되거나 품질이 낮은 부분이있는 코드 처리 그 완전한 것 같다. 그러나 우리는 그것이 무엇을하는지 또는 어떻게 그것이 전체 적용에 영향을 미치는지 완전히 이해하지 못한다. 이로 인해 위험한 것으로 제거됩니다..
일반적으로 레거시 코드, 또는 코드는 다른 사람이 작성했습니다. (보통 적절한 문서없이) 또는 프로젝트가 개발 단계에서 생산 단계로 너무 빨리 이동 한 경우.
반 패턴의 이름은 화산에서 유래하는 용암과 유사합니다. 즉 처음에는 너무 많은주의를 기울이지 않고 신속하고 유동적으로 움직이지만, 나중에 굳어지고 제거하기가 어려워집니다.
이론적으로, 우리는 용암 흐름을 제거 할 수 있습니다. 광범위한 테스트 과 리팩토링, 하지만 실제로는, 구현은 종종 어렵거나 심지어 불가능합니다.. 용암 흐름은 일반적으로 고성능 비용이 있기 때문에 처음부터 잘 설계된 아키텍처와 올바른 워크 플로우를 설정하여 용암 흐름을 예방하는 것이 좋습니다.
9. 하드 코딩
“하드 코딩” 대부분의 웹 개발 서적이 서문에서 우리에게 경고하는 잘 알려진 반 패턴입니다. 하드 코딩은 다음과 같은 불행한 사례입니다. 구성 또는 입력 데이터를 저장합니다., 파일 경로 또는 원격 호스트 이름, 소스 코드에서 구성 파일, 데이터베이스, 사용자 입력 또는 다른 외부 소스에서 가져 오는 것이 아닙니다..
하드 코드의 주요 문제점은 특정 환경에서만 제대로 작동합니다., ~에서 조건이 바뀔 때마다, 우리는 수정해야한다. 대개 여러 개의 다른 장소에있는 소스 코드.
10. 소프트 코딩
하드 코딩의 함정을 피하기 위해 열심히 노력한다면, 우리는 다른 반 패턴을 쉽게 구할 수 있습니다. “소프트 코딩”, 정반대입니다..
소프트 코딩, 우리는 소스 코드에 있어야 할 것들을 외부 소스에 넣습니다., 예를 들어 비즈니스 로직을 데이터베이스에 저장합니다. 우리가 그렇게하는 가장 일반적인 이유는 앞으로 비즈니스 규칙이 바뀔 것이라는 두려움 때문입니다. 따라서 코드를 다시 작성해야합니다..
극단적 인 경우, 소프트 코딩 된 프로그램은 너무 추상적이어서 복잡하게되어 이해하기가 거의 불가능하다. (특히 새 팀 구성원의 경우) 유지 보수 및 디버그하기가 어렵다..
