가장 논란이 많은 프로그래밍 의견은 무엇입니까?

이것은 확실히 주관적이지만, 그것이 논쟁 적이 지 않도록 노력하고 싶습니다. 사람들이 적절하게 다루면 흥미로운 질문이 될 수 있다고 생각합니다.

이 질문에 대한 아이디어에서 주석 스레드에서 온 내 대답 받는 "당신이 좋아하는 언어에 대해 싫어 무엇입니까 다섯 가지?" 질문 . C #의 클래스는 기본적으로 봉인되어야한다고 주장했습니다.이 질문에 추론을 넣지 않지만이 질문에 대한 답변으로 더 자세한 설명을 작성할 수 있습니다. 의견 (현재 25 의견)에서 토론의 열기에 놀랐습니다.

그래서 어떤 논쟁적인 의견 을 가지고 있습니까? 차라리 상대적으로 거의 기초가없는 종교적인 것으로 보이는 것을 피하고 싶지만 (예 : 중괄호 배치), 예를 들어 "단위 테스팅이 실제로는 도움이되지 않는다"또는 "공공 분야가 정말 좋습니다"와 같은 것들이 있습니다. 중요한 것은 (어쨌든 나에게) 당신은 당신의 의견 뒤에 이유가 있다는 것입니다.

귀하의 의견과 추론을 제시하십시오-나는 사람들이 당신이 그들과 동의하는지에 관계없이 잘 논쟁되고 흥미로운 의견에 투표하도록 권장합니다.

여가 시간에 재미를 위해 코딩하지 않은 프로그래머는 결코 그렇지 않습니다.

가장 똑똑하고 재능있는 사람들조차도 직업이 아니라면 정말 훌륭한 프로그래머가 될 수 없다고 생각합니다. 그들은 측면에서 프로젝트를 거의하지 않거나 여가 시간에 많은 다른 언어와 아이디어를 엉망으로 만듭니다.

(참고 : 좋은 프로그래머가 프로그래밍 외에는 아무것도하지 않지만 9 ~ 5의 프로그램 이상을 수행한다고 말하지는 않습니다)

항상 사용해야하는 "모범 사례"는 "뇌 사용"뿐입니다.

너무 많은 사람들이 너무 많은 악 대차에 뛰어 들어 그것을 보장하지 않는 것들에 방법, 패턴, 프레임 워크 등을 강요하려고합니다. 무언가가 새로운 것이거나 존중받는 사람이 의견을 가지고 있다고해서 모든 것이 맞는다는 것을 의미하지는 않습니다. :)

편집 : 명확히하기 위해-사람들이 모범 사례, 소중한 의견 등을 무시해서는 안된다고 생각합니다. 사람들이 왜이 "사물"이 그렇게 큰지에 대해 생각하지 않고 맹목적으로 뛰어 넘지 말아야한다고 생각합니다. 하고 있는데, 어떤 이점 / 단점을 가져 옵니까?

"구글링"은 괜찮습니다!

그렇습니다. 수년 동안 강렬한 암기 및 / 또는 영광스러운 프로그래밍 서적이 누군가가 몇 초 이내에 액세스 할 수있는 리소스로 떨어지기 시작한다는 것이 일부 사람들의 기분을 상하게한다는 것을 알고 있습니다. 그것을 사용합니다.

비평의 결과로 문제에 대한 인터넷 검색 답변을 너무 자주 듣는다는 말이 들립니다. 우선, 모든 사람이 참조 할 자료가 필요하다는 것을 인정해야합니다. 당신은 모든 것을 알지 못하고 물건을 찾아야합니다. 계속해서 정보를 어디서 구할 수 있습니까? 책에서 찾거나 Google에서 찾거나 환각을 타는 개구리에게서 들었다면 문제가됩니까? 아니요. 정답은 정답입니다.

중요한 것은 자료를 이해하고 성공적인 프로그래밍 솔루션을 끝내기위한 수단으로 사용하며 고객 / 고용주가 결과에 만족한다는 것입니다.

(환상적인 개구리 이야기에서 답을 얻는다면, 모두 같은 도움을 받아야 할 것입니다)

코드에서 대부분의 주석은 실제로 악성 코드 복제 형식입니다.

우리는 대부분의 시간을 다른 사람들 (또는 우리 자신)이 작성한 코드를 유지하는 데 소비하며, 가난하고, 부정확하고, 오래되고, 오도하는 주석은 코드에서 가장 성가신 유물 목록의 맨 위에 있어야합니다.

나는 결국 많은 사람들이 그것들을 비우고 있다고 생각합니다.

코드를 읽을 수있게 만들고, 필요에 따라 리팩토링하고, 관용구와 기발함을 최소화하는 데 집중하는 것이 훨씬 좋습니다.

반면에 많은 과정은 주석이 코드 자체보다 훨씬 더 중요하다는 것을 가르치며 다음 줄로 이어질 수 있습니다.

XML이 과대 평가되었습니다

나는 두뇌를 사용하기 전에 너무 많은 사람들이 XML 악 대차에 뛰어 들었다고 생각합니다 ... 웹용 XML은 그것을 위해 설계 되었기 때문에 훌륭합니다. 그렇지 않으면 어떤 문제 정의 와 디자인 사고가 그것을 사용하기로 결정을 선점해야한다고 생각합니다.

내 5 센트

모든 프로그래머가 동일한 것은 아닙니다

종종 관리자들은 동일한 수준의 경험 등을 가지고 있기 때문에 DeveloperA == DeveloperB라고 생각합니다. 실제로, 한 개발자의 성능은 다른 개발자의 성능의 10 배 또는 100 배일 수 있습니다.

그것에 대해 이야기하는 것은 정치적으로 위험하지만, 때로는 여러 팀원 이 동등한 기술로 보일 지라도 항상 그런 것은 아니라고 지적합니다. 필자는 수석 개발자가 '희망을 넘어서'고 주니어 개발자가 실제 작업을 모두 수행 한 사례를 보았습니다.하지만 크레딧을 얻었습니다. :)

사람들이 왜 Java가 대학에서 가르치는 가장 좋은 "최초의"프로그래밍 언어라고 생각하는지 이해하지 못합니다.

우선, 나는 첫 번째 프로그래밍 언어가 객체와 구문이 아니라 제어 흐름과 변수를 배울 필요성을 강조해야한다고 생각합니다.

또 다른 예로, C / C ++에서 메모리 누수를 디버깅 한 경험이없는 사람들은 Java가 테이블에 가져 오는 것을 완전히 이해할 수 없다고 생각합니다.

또한 자연스럽게 진행되는 과정은 "어떻게 할 수 있습니까"에서 "어떻게 할 수있는 라이브러리를 찾을 수 있을까"에서 다른 방법으로 진행되어야합니다.

하나의 언어 만 알고 있다면 아무리 잘 알고 있더라도 훌륭한 프로그래머는 아닙니다.

일단 C #이나 Java에 능숙 해 지거나 배우기 시작한 다른 언어가 필요하다고 말하는 태도가있는 것 같습니다. 나는 그것을 믿지 않는다-내가 배운 모든 언어는 나에게 다른 모든 것들과 함께 내 작업으로 가져올 수 있었던 프로그래밍에 대해 새로운 것을 가르쳐 주었다. 한 언어로 자신을 제한하는 사람은 결코 자신이 할 수있는만큼 훌륭하지 않을 것이라고 생각합니다.

또한 필자가 정말로 훌륭한 프로그래머가 기대하는 자질과 필연적으로 일치하지 않는 실험에 대한 호기심과 의지가 어느 정도 부족하다는 것을 나타냅니다.

성능 은 중요합니다.

인쇄 문은 코드를 디버그하는 유효한 방법입니다.

코드를 작성하여 코드를 디버깅하는 것이 System.out.println좋습니다 (또는 귀하의 언어에 맞는 인쇄 문). 종종 이것은 디버깅보다 빠를 수 있으며 인쇄 된 출력을 다른 앱 실행과 비교할 수 있습니다.

프로덕션 환경으로 갈 때 인쇄 문을 제거하십시오 (또는 더 나은 경우, 문장을 기록문으로 바꾸십시오).

당신의 직업은 자신을 일에서 벗어나게하는 것입니다.

고용주를위한 소프트웨어를 작성할 때 사용자가 작성하는 소프트웨어는 모든 개발자가 선택할 수 있고 최소한의 노력으로 이해할 수있는 방식으로 작성되어야합니다. 잘 디자인되고, 명확하고 일관되게 작성되고, 깔끔하게 형식화되고, 필요한 곳에 문서화되고, 예상대로 매일 빌드되고, 저장소에 체크인되고, 적절하게 버전이 지정됩니다.

버스에 부딪 히거나, 해고, 해고 또는 직장을 떠날 경우, 고용주는 즉시 통지를 보내 줄 수 있어야하며, 다음 사람이 귀하의 역할을 수행하고 코드를 집어 들고 일주일 내내 달리기. 그가 그렇게 할 수 없다면, 당신은 비참하게 실패한 것입니다.

흥미롭게도, 나는 그 목표를 갖는 것이 저의 고용주들에게 더 가치있는 것으로 나타났습니다. 일회용을 위해 노력할수록 나는 그들에게 더 가치가 있습니다.

1) 비즈니스 애플 리케이션 범위 :

"Enterprise"프레임 워크 전체가 연기와 거울이라고 생각합니다. J2EE, .NET, 대다수의 Apache 프레임 워크 및 이러한 것을 관리하기위한 대부분의 추상화는 해결하는 것보다 훨씬 더 복잡합니다.

지루하고 간단한 작업을 해결하기 위해 "마법"을 수행하는 일반적인 Java 또는 .NET ORM 또는 아마도 현대적인 MVC 프레임 워크를 사용하십시오. 당신은 빨리 확인하고 쓰기가 어려운 막대한 양의 추악한 XML 상용구를 작성하게됩니다. 그 중 절반은 다른 API의 작업, 재활용이 불가능한 인터페이스 및 Java 및 C #의 비 유연성을 극복하기 위해 필요한 클래스를 추상화하기위한 대규모 API가 있습니다. 우리는 단순히 그 대부분을 필요로하지 않습니다.

자체적으로 기술 된 설명자 구문, 지나치게 복잡한 데이터베이스 및 그룹웨어 제품이있는 다른 모든 응용 프로그램 서버는 어떻습니까?

요점은 복잡성 == 나쁜 것이 아니라, 불필요한 복잡성 == 나쁜 것입니다. 필자는 일부가 필요한 대규모 엔터프라이즈 설치에서 일했지만 대부분의 경우 자체 개발 한 스크립트와 간단한 웹 프런트 엔드만으로도 대부분의 사용 사례를 해결하는 데 필요한 모든 것입니다.

이러한 엔터프라이즈 응용 프로그램을 모두 간단한 웹 프레임 워크, 오픈 소스 DB 및 간단한 프로그래밍 구성으로 바꾸려고합니다.

2) n 년의 경험이 요구됨 :

응용 프로그램, API 또는 프레임 워크와 관련된 특정 문제를 처리하기 위해 컨설턴트 또는 기술자가 필요하지 않은 경우 해당 응용 프로그램에 대해 5 년의 경험이있는 사람이 실제로 필요하지 않습니다. 필요한 것은 문서를 읽을 수있는 개발자 / 관리자, 자신이 무엇을하고 있는지에 대한 도메인 지식을 가지고 있으며 빠르게 배울 수있는 사람입니다. 어떤 종류의 언어로 개발해야한다면 괜찮은 개발자가 2 개월 이내에이를 선택할 것입니다. X 웹 서버 관리자가 필요한 경우, 이틀 안에 매뉴얼 페이지와 뉴스 그룹을 읽고 속도를 높여야합니다. 그보다 적은 금액과 그 사람은 그가 지불 한 금액이 아닙니다.

3) 일반적인 "컴퓨터 과학"학위 커리큘럼 :

컴퓨터 과학 및 소프트웨어 공학 학위의 대부분은 황소입니다. 첫 번째 프로그래밍 언어가 Java 또는 C # 인 경우 문제가있는 것입니다. 대수와 수학으로 가득 찬 여러 코스를 얻지 못하면 잘못되었습니다. 함수형 프로그래밍을 탐구하지 않으면 불완전합니다. 사소한 for 루프에 루프 불변량을 적용 할 수 없다면 컴퓨터 과학자로서 염려 할 가치가 없습니다. x 및 y 언어와 객체 방향에 대한 경험이 있다면 s ***로 가득합니다. 실제 컴퓨터 과학자는 사용하는 개념과 구문의 관점에서 언어를보고, 프로그래밍 방법론을 여러 가지 중 하나로보고, 새로운 언어, 디자인 방법 또는 사양 언어 선택의 기본 철학을 잘 이해하고 있습니다. 사소하다.

게터와 세터가 많이 남용

나는 수백만의 사람들이 공공 장소가 악하다고 주장하는 것을 보았습니다. 그래서 그들은 공공 장소를 만들고 그들 모두에게 게터와 세터를 제공합니다. 나는 이것이 필드를 공개하는 것과 거의 동일하다고 생각합니다. 스레드를 사용하거나 (일반적으로 그렇지는 않습니다) 접근자가 비즈니스 / 프리젠 테이션 로직 (적어도 '이상한 것')을 가지고 있다면 약간 다를 수 있습니다.

나는 공공 장소에 찬성하지 않고, 그들 모두를 위해 게터 / 세터 (또는 재산)를 만들고, 그렇게하는 것이 캡슐화 또는 정보 숨기기 라고 주장하는 것에 반대한다 .

최신 정보:

이 답변은 의견에 약간의 논쟁을 불러 일으켰으므로 약간 명확하게하려고 노력할 것입니다 (많은 사람들이 공표 한 것이기 때문에 원본을 그대로 두겠습니다).

우선 : 공공 장소를 이용하는 사람은 감옥에 갈 가치가 있습니다

이제 개인 필드를 만든 다음 IDE를 사용하여 각 필드 마다 게터와 세터 를 자동으로 생성하는 것은 공용 필드를 사용하는 것 만큼이나 나쁩니다 .

많은 사람들이 생각합니다 :

private fields + public accessors == encapsulation

필자는 필드에 대한 (자동 또는 아닌) getter / setter 쌍 생성을 달성하려는 소위 캡슐화에 효과적으로 반대한다고 말합니다.

마지막 으로이 주제에서 Bob 아저씨를 인용하겠습니다 ( "청결 코드"6 장에서 발췌).

변수를 비공개로 유지해야하는 이유가 있습니다. 우리는 다른 사람이 그들에게 의존하기를 원하지 않습니다. 우리는 변덕이나 충동에 따라 유형이나 구현을 자유롭게 바꿀 수 있기를 바랍니다. 그렇다면 왜 그렇게 많은 프로그래머가 자동으로 게터와 세터를 객체에 추가하여 개인 필드 가 마치 공개적인 것처럼 노출 합니까?

UML 다이어그램이 과대 평가되었습니다

물론 복합 패턴에 대한 클래스 다이어그램과 같은 유용한 다이어그램이 있지만 많은 UML 다이어그램에는 절대 가치가 없습니다.

의견 : SQL은 코드입니다. 그것을 그렇게 취급하십시오

즉, C #, Java 또는 기타 선호하는 객체 / 프로 시저 언어와 마찬가지로 읽기 쉽고 유지 관리 가능한 형식 지정 스타일을 개발하십시오.

나는 자유 형식의 조잡한 SQL 코드가 보이면 싫어. 페이지에 두 가지 중괄호 스타일이 모두 표시 될 때 비명을 지르면 JOIN 조건을 모호하게하거나 모호하게 만드는 무료 형식의 SQL 또는 SQL을 볼 때 왜 또는 왜 비명을 지르지 않습니까?

가독성은 코드의 가장 중요한 측면입니다.

정확성보다 훨씬 더. 읽을 수 있으면 쉽게 고칠 수 있습니다. 또한 최적화, 변경, 이해가 용이합니다. 그리고 다른 개발자들도 무언가를 배울 수 있기를 바랍니다.

개발자 인 경우 코드를 작성할 수 있어야합니다

나는 작년에 약간의 인터뷰를했으며 인터뷰의 일부로 사람들이 생각하는 방식과 그들이 화이트 보드에서 간단한 알고리즘을 구현하는 방법을 테스트해야했습니다. 처음에는 다음과 같은 질문으로 시작했습니다.

Pi가 4 * (1-1/3 + 1/5-1/7 + ...) 함수를 사용하여 더 큰 정확도를 제공하는 것으로 추정 할 수 있다면 Pi를 소수점 5 자리의 정확도로 계산하는 함수를 작성하십시오. .

생각해야 할 문제이지만 노련한 개발자에게 손이 닿지 않아야합니다 (약 10 줄의 C #으로 대답 할 수 있음). 그러나 많은 (대행사에 의해 사전 심사를 거친) 후보자들은 답변을 시작하지 못하거나 답변에 대한 방법을 설명조차 할 수 없었습니다. 그래서 얼마 후 나는 다음과 같은 간단한 질문을 시작했습니다.

원의 면적이 반지름의 제곱에 Pi를 곱한 값으로 주어지면 원의 면적을 계산하는 함수를 작성하십시오.

놀랍게도, 후보의 절반 이상이 어떤 언어 로도이 함수를 작성할 수 없었 습니다 (가장 인기있는 언어를 읽을 수 있으므로 의사 코드를 포함하여 원하는 언어를 사용할 수 있습니다). C #에서이 함수를 작성할 수없는 "C # 개발자"가있었습니다.

나는 이것에 놀랐다. 나는 항상 개발자들이 코드를 작성할 수 있어야한다고 생각했었다. 오늘날 이것은 논란의 여지가있는 것으로 보인다. 확실히 인터뷰 후보자입니다!

편집하다:

첫 번째 질문이 좋은지 나쁜지, 인터뷰에서 이와 같이 복잡한 질문을해야하는지에 대한 의견에는 많은 토론이 있습니다. 나는 당신이 게시물의 요점을 크게 놓치고 있다고 말하지 않고 여기서 (이것은 완전히 새로운 질문입니다) 탐구하지 않을 것 입니다.

그렇습니다. 사람들은 이것으로 어떤 진전도 할 수 없다고 말했지만 두 번째 질문은 사소한 것이며 많은 사람들은 그 중 어느 것도 진전을 할 수 없었습니다! 자신을 개발자라고 부르는 사람 은 생각없이 몇 초 안에 두 번째 질문에 대한 답변을 쓸 수 있어야합니다. 그리고 많은 사람들은 할 수 없습니다.

헝가리 표기법의 사용은 죽음으로 처벌되어야합니다.

충분히 논란의 여지가 있습니다.)

디자인 패턴은 디자인보다 더 좋은 디자인을 아프게합니다.

IMO 소프트웨어 디자인, 특히 좋은 소프트웨어 디자인은 패턴으로 의미를 갖기에는 너무 다양합니다. 특히 사람들이 실제로 기억할 수있는 적은 수의 패턴에서 사람들이 실제로 소수 이상의 것을 기억하기에는 너무 추상적입니다. 그래서 그들은별로 도움이되지 않습니다.

반면에 너무 많은 사람들이 개념에 매료되어 어디에서나 패턴을 적용하려고 시도합니다. 일반적으로 결과 코드에서는 모든 (완전히 의미가없는) 싱글 톤과 추상 팩토리 사이의 실제 디자인을 찾을 수 없습니다.

코드가 적을수록 좋습니다.

사용자가 "그렇습니까?"라고 말하고 작업 내용이 보이지 않는 경우 제대로 된 것입니다. 영광은 다른 곳에서 찾을 수 있습니다.

PHP는 짜증나 ;-)

증거는 푸딩에 있습니다.

단위 테스트는 좋은 코드를 작성하는 데 도움이되지 않습니다

유닛 테스트를해야하는 유일한 이유는 이미 작동하는 코드가 깨지지 않도록하기 위해서입니다. 먼저 테스트를 작성하거나 테스트에 코드를 작성하는 것은 어리 석습니다. 코드를 작성하기 전에 테스트를 작성하면 에지 사례가 무엇인지조차 알 수 없습니다. 테스트를 통과했지만 예기치 않은 상황에서 여전히 실패하는 코드가있을 수 있습니다.

또한 우수한 개발자는 응집력을 낮게 유지하여 기존 코드에 문제를 일으키지 않을 새로운 코드를 추가 할 수 있습니다.

사실, 더 일반화하겠습니다.

소프트웨어 엔지니어링의 대부분의 "모범 사례"는 나쁜 프로그래머가 너무 많은 피해를 입지 않도록하기위한 것 입니다.

그들은 나쁜 개발자를 손에 쥐고 멍청한 실수를 저 지르지 못하게합니다. 물론 대부분의 개발자는 나쁘기 때문에 좋은 일이지만 좋은 개발자는 패스를 받아야합니다.

작은 방법을 쓰십시오. 프로그래머들은 여러 가지 다른 일을하는 곳에서 loooong 메소드를 작성하는 것을 좋아하는 것 같습니다.

이름을 지정할 수있는 곳마다 방법을 만들어야한다고 생각합니다.

가비지 코드를 가끔씩 작성해도 괜찮습니다.

때로는 특정 작업을 수행하는 데 필요한 빠르고 가비지 코드 조각 만 있으면됩니다. 패턴, ORM, SRP 등 무엇이든 ... 콘솔 또는 웹 앱을 던지고 인라인 SQL을 작성하고 (좋은 느낌), 요구 사항을 충족시킵니다.

코드 == 디자인

저는 정교한 UML 다이어그램과 끝없는 코드 문서를 좋아하지 않습니다. 고급 언어에서는 코드를 그대로 읽고 이해할 수 있어야합니다. 복잡한 문서와 다이어그램은 더 이상 사용자 친화적이지 않습니다.

다음은 Code as Design 주제에 대한 기사입니다 .

소프트웨어 개발은 ​​직업 일뿐입니다

내가 틀리지 마라, 나는 소프트웨어 개발을 많이 즐긴다. 지난 몇 년 동안 주제에 관한 블로그를 작성했습니다. 평판이 5,000 이상이되도록 여기에서 충분한 시간을 보냈습니다. 그리고 저는 팀원이 환상적이고 일이 흥미로워 서 계약자로서 얻을 수있는 것보다 훨씬 적은 비용으로 일반적으로 60 시간 동안 일을 시작합니다.

그러나 웅대 한 계획에서 그것은 단지 직업입니다.

그것은 가족, 여자 친구, 친구, 행복 등과 같은 많은 것들보다 중요하며, 오토바이 타기, 세일링 요트 또는 스노우 보드와 같은 무제한 현금 공급이 있다면 오히려하고 싶은 다른 것들보다 중요합니다.

나는 종종 많은 개발자들이 개발이 우리 자신의 최종 목표가 아니라 인생에서 더 중요한 것들을 가질 수있게하고 (우리가 좋아하는 일을함으로써) 가질 수 있다는 것을 잊어 버린다고 생각합니다.

또한 소스 제어에 바이너리가있는 데 아무런 문제가 없다고 생각합니다 .. 이유가 좋은 이유가 있다면. 어셈블리가있는 경우 소스가 없으며 각 devs 시스템에서 동일한 위치에있을 필요는 없습니다. 일반적으로 "binaries"디렉토리에 고정하고 상대 경로를 사용하여 프로젝트에서 참조합니다 .

많은 사람들이 같은 문장에서 "소스 제어"와 "이진"을 언급하기 위해 내가 스테이크에 불 태워야한다고 생각하는 것 같습니다. 나는 규칙을 추가 할 수 없다는 엄격한 규칙이있는 장소를 알고 있습니다.

모든 개발자는 최신 컴퓨터의 기본 아키텍처에 익숙해야합니다. 이는 가상 머신을 대상으로하는 개발자에게도 적용됩니다 (메모리 관리 등을 걱정할 필요가 없다는 사실을 몇 번이고 반복해서 들었으므로).

소프트웨어 아키텍트 / 디자이너가 과대 평가되었습니다

개발자로서 저는 Software Architects의 아이디어가 싫습니다. 그들은 기본적으로 더 이상 풀 타임으로 코딩하지 않고 잡지와 기사를 읽은 다음 소프트웨어 디자인 방법을 알려줍니다. 실제로 생활을 위해 풀 타임으로 소프트웨어를 작성하는 사람들 만이 그렇게해야합니다. 5 년 전 건축가가되기 전에 세계 최고의 코더인지 상관하지 않습니다. 귀하의 의견은 저에게 소용이 없습니다.

논란의 여지가 있는가?

편집 (명확하게하기 위해) : 대부분의 소프트웨어 아키텍트가 훌륭한 비즈니스 분석가 (고객과의 대화, 요구 사항 작성, 테스트 등)를 만들고 있다고 생각합니다. 소프트웨어 설계, 상위 레벨 또는 그 밖의 다른 방법으로는 해당되지 않습니다.

개발에 대한 "하나의 크기에 모두 맞는"접근 방식은 없습니다

나는 이것이 상식처럼 보이기 때문에 논란의 여지가 있다는 것에 놀랐습니다. 그러나 인기있는 블로그에는 개발에 대한 "한 가지 크기에 맞는"접근 방식을 홍보하는 많은 항목이 있으므로 실제로는 소수라고 생각합니다.

것들 내가으로 선전되고 본 적이 에 대한 올바른 접근 방법 어떤 프로젝트 - 정보 그것에 대해 알려진 전 - 테스트 주도 개발 (TDD)의 사용과 같은 것들, 도메인 디자인 (DDD)를 구동, 객체 관계형 매핑 (ORM) 방법론부터 아키텍처, 구성 요소에 이르기까지 모든 것을 아우르는 민첩성 (자본 A), 객체 지향 (OO) 등이 있습니다. 물론 시장성있는 두문자어도 좋습니다.

사람들은 심지어 "I 'm Test Driven"또는 이와 유사한 블로그에 배지를 두는 것만으로도 프로젝트 프로젝트의 세부 사항이 실제로 좋은 일 이더라도 단일 접근 방식을 엄격하게 준수하는 것처럼 보입니다 .

그렇지 않습니다.

올바른 방법론, 아키텍처 및 구성 요소 등을 선택하는 것은 프로젝트 별로 수행해야하는 작업이며 작업중인 프로젝트의 유형과 고유 한 요구 사항뿐만 아니라 크기와 기능에 따라 다릅니다. 작업중인 팀의