프로그래밍에 대한 7가지 오해를 피하십시오!-일반적인 문제-php.cn

사람들이 자신의 실수에 대해 공개적으로 이야기하는 경우는 거의 없습니다.

성인은 아무도 없는데 어떻게 흠이 없을 수 있겠습니까? 말하기는 어렵지만 과거의 실수를 반성하면 적어도 단기적으로는 미래에 같은 실수를 저지르는 것을 방지할 수 있습니다.

모하메드 바로우마는 경력 5년의 전문 프로그래머이지만 누구와 마찬가지로 실수를 합니다.

그는 이렇게 말했습니다. "보통 나는 내가 무엇을 잘못했는지 바로 깨닫지 못합니다. 올바른 일 처리 방법을 접하고 나서야 내가 어떤 실수를 했는지 알 수 있습니다."

원문과 결합하면, 이 글은 그가 저지른 일곱 가지 주요 오해를 요약한 것입니다.

1. 적합한 ORM을 사용하지 않으면

데이터 액세스 계층 코드는 항상 지저분하고 지루합니다. 불행하게도 이 사실은 끝까지 발견되지 않는 경우가 많습니다.

모하메드와 ORM은 사이가 좋지 않습니다. ORM(Object Relational Mapping)은 Object Relational Model의 약자입니다. 그 기능은 관계형 데이터베이스와 개체 간의 매핑을 만들어 프로그램이 설명 개체를 조작하여 데이터베이스를 조작할 수 있도록 하는 것입니다.

모하메드는 처음 간단한 내부 회계 애플리케이션을 만들 때 기본 프로그램을 완성하는 데에도 많은 코드를 작성해야 한다는 사실을 깨달았습니다. 그래서 그는 ADO.NET에 몰입하기 시작했고 목적에 맞게 매우 특별하고 사용자 정의된 테이블 스키마를 사용하여 직접 만든 ORM을 수동으로 작성했습니다.

일정 기간 동안 이 ORM은 매우 잘 작동했지만 몇 달 후 회사의 비즈니스 요구 사항이 변경되어 전체 테이블 스키마가 변경되고 ORM이 반복적으로 수정되었습니다. 이 프로세스는 너무 고통스러워 Mohamed는 마침내 강력한 형식의 데이터 세트 어댑터를 선택했습니다.

이 문제는 해결되었지만 작업을 완료하는 데 더 적합한 ORM(예: NHibernate)을 찾을 수 있다면 적어도 사용자 수가 늘어나더라도 Mohamed는 걱정할 필요가 없습니다. 데이터베이스 공급자 변경.

2. 제네릭 사용법을 배우지 않았습니다

전문 프로그래머로서의 Mohamed Barouma의 경력은 Net 1.1에서 시작되었습니다. 당시 Net 1.1의 주요 문제점은 제네릭 지원이 없다는 것이었습니다. 즉, 강력한 형식의 목록을 가질 수 없고 지루한 ArrayList에 만족해야 했습니다. 그러나 Arraylist를 사용하여 Java 코드에서 유형 변환 및 박싱을 수행하면 읽기 및 쓰기가 매우 어려워집니다.

So Net 1.1 프로그래머는 CodeSmith를 사용하여 강력한 형식의 컬렉션 목록을 생성했습니다.

하지만 코드베이스가 커짐에 따라 맞춤 생성 목록 자체가 관리하기 어려운 괴물이 됩니다. 목표를 달성하기 위해 자주 객체를 생성하거나 메소드를 호출하는 한, 나중에 코드를 수정하여 혼란과 오류를 일으키게 됩니다.

Net 2.0으로 전환하고 제네릭이 출시되자마자 사용하기 시작하면 유지 관리가 어려운 사용자 정의 컬렉션 목록을 점점 더 많이 만드는 대신 모든 것이 사라질 것입니다.

3. 절대로 "바퀴 재발명"을 포기하지 마세요

이것은 "바퀴 재발명"(Reinvent The Wheel)이라는 공통된 주제입니다. 새로운 프로그래머는 항상 현재 구현이 충분하지 않다고 생각하여 "바퀴를 재발명"하는 것을 좋아하므로 처음부터 모든 것을 다시 작성해야 합니다.

왜 '바퀴만들기'라고 하나요? 수천년 전에 실제 바퀴가 둥글기로 결정된 것처럼 많은 데이터베이스가 오래 전에 성숙되어 사용하기 쉬웠지만 여전히 "바퀴 만들기"에 끈기 있게 노력하는 수많은 프로그래머가 있으며 일부 나방은 불꽃 속으로 날아갑니다. 벌레가 나무로 날아가는데, 어떤 사람들은 독특하고 혁신적입니다. 이것이 바로 '바퀴 만들기'의 마법 같은 매력입니다.

그 중에는 Windows Forms UI 컨트롤이 너무 단순하기 때문에 자신의 UI 컨트롤을 다시 작성하고 싶어하는 Mohamed도 있습니다. 결국 그가 만든 GUI 도구는 상용화된 닷넷 UI 제어 시스템에 쉽게 패배했고, 신인 프로그래머가 만든 또 다른 '바퀴'는 코드의 바다에 빠져들고 말았다.

4. 문서가 지나치게 간소화되지 않음

이 업계에 갓 입문한 많은 프로그래머는 코드가 수행하는 작업을 간단한 영어로 설명하기 때문에 처음에는 코드 문서가 좋다고 느낄 것입니다. 그러나 실제로 이러한 문서는 몇 가지 코드 변경 후에는 일반적으로 폐지가 되거나, 오래되거나, 오래되거나, 완전히 잘못된 문서가 됩니다.

종종 사람들은 XML 문서와 같은 코드 문서를 작성하는 데 많은 시간을 소비하다가 코드가 변경되면 문서를 업데이트해야 한다는 사실을 깨닫게 됩니다. 기능이 변경되었을 수 있기 때문입니다. 코드 업데이트는 필요하지만 XML 문서 업데이트는 그렇지 않습니다. 부담스럽고 시간이 많이 걸리며 쓸모가 없습니다.

결국 XML 문서를 반복적으로 변경하다 보면 사람들은 점차 인내심을 잃고 다른 일로 넘어가게 됩니다.

5. 자동화된 빌드를 사용하지 않음

애플리케이션 배포 및 패키징은 프로그래밍보다 상대적으로 쉽기 때문에 우선순위가 매우 낮은 경우가 많습니다. 하지만 곧 이 조악한 빌드는 작동하지 않을 것이며 온갖 종류의 불만을 제기하게 될 것입니다.

"전제 조건이 누락되었습니다. 어떻게 해결할 수 있나요?"

"dll이 업데이트되지 않았습니다. 패치를 제공해 주실 수 있나요?"

"내 아이콘이 왜 없어졌나요?"

곧바로 테이블에 눈사태처럼 전화가 왔어요. 이것은 Mohamed에게 실제 경험이었고 그날 그를 지치게 만들었습니다. 프로그래밍 때문이 아니라 재배치 및 재포장이라는 정신없는 과정 때문이었습니다.

이 모든 것에서 자동화된 스크립트를 작성하면 어느 정도 시간을 절약할 수 있습니다. 그렇지 않으면 나중에 디버깅하는 데 낭비되는 시간이 절약할 수 있는 시간보다 확실히 몇 배 더 많아질 것입니다. 소프트웨어는 한 번의 클릭으로 구축되어야 하며, 그렇지 않으면 낭비입니다.

6. 시각적 검사와 디버깅에만 의존할 필요가 없습니다

Visual Studio를 사용하면 사람들이 코드를 쉽게 디버깅하고 동적 검사를 수행할 수 있으며, 양식을 만들고 출력을 표시하는 것도 매우 간단해집니다. 그러나 디버거에 너무 중독되면 이러한 이점은 단점으로 변할 것입니다.

왜? 애플리케이션이 실행되고 45분 후에 메소드가 호출된다고 상상해 보십시오. 디버깅을 시작하기 전에 45분을 기다리시겠습니까?

그러면 애플리케이션을 독립적으로 호출할 수 있는 하위 모듈로 나누십시오. 오류 출력을 생성하는 입력 값을 입력하고 거기서부터 테스트를 시작합니다.

7. 단위 테스트 없음

많은 프로그래머는 이렇게 생각했을 것입니다. "내 응용 프로그램은 사소하고 수동 테스트로 쉽게 다룰 수 있습니다. 단위 테스트는 크고 복잡한 작업을 위한 것이지 내 프로그램을 위한 것이 아닙니다. "

상상하실 수 있듯이 이는 우려 사항이 분리되지 않고 리팩터링이 어렵고 완전히 유지 관리할 수 없는 코드 기반을 직접 생성하게 됩니다.

"Creepy-footing"은 어떤 변경이라도 파괴적인 변경으로 이어질 수도 있고 그렇지 않을 수도 있기 때문에 코드를 조금이라도 수정하는 것을 두려워하는 많은 초보 프로그래머들 사이에서 거의 흔한 문제입니다. 그 결과, 결국 손을 떼게 되었고, 발생한 문제들은 해결되지 못했습니다. 이 레거시 코드로 작업하는 것은 지루하고 스트레스가 많을 뿐만 아니라 정신적으로도 스트레스를 받습니다.

하지만 단위 테스트를 사용하면 코드 수명이 크게 늘어날 수 있습니다. 모하메드는 단위 테스트의 "기술"을 배우고 학교 첫날부터 단위 테스트를 연습할 수 있기를 희망하지만 안타깝게도 학교에서는 이를 가르치지 않습니다.

세상에는 수많은 시행착오를 통해 수많은 흥미로운 혁신과 발명이 탄생하지만, 그래도 기본적인 실수는 피하는 것이 필요합니다. 프로그래밍 생활을 하면서 또 어떤 우스꽝스러운 "일반적인 오해"를 겪었나요? 아니면 당혹스러운 "치명적인 오해"를 일으켰습니까? 프로그래밍 학습 경험을 공유하려면 아래에 메시지를 남겨주세요.