가장 인기있는 "모범 사례"는 무엇이며 왜 그럴까요? [닫은]

"모범 사례"는 우리 산업의 모든 곳에 있습니다. "코딩 모범 사례"에 대한 Google 검색에서 거의 150 만 개의 결과가 나타납니다. 이 아이디어는 많은 사람들에게 위로를 가져다주는 것 같습니다. 지시 사항을 따르면 모든 것이 잘 될 것입니다.

모범 사례 에 대해 읽을 때 ( 예 : 최근 에 Clean Code 에서 몇 개를 읽음) 긴장이됩니다. 이것이 항상 이 방법을 사용해야 한다는 것을 의미합니까 ? 조건이 첨부되어 있습니까? 좋은 습관 이 아닐 수있는 상황이 있습니까? 문제에 대해 더 많이 배울 때까지 어떻게 알 수 있습니까?

Clean Code에 언급 된 몇 가지 관행 은 나와 맞지 않았지만 그것이 잠재적으로 나쁘거나 개인적인 편견인지 아닌지 솔직히 확신하지 못합니다. 기술 업계의 저명한 많은 사람들 이 모범 사례가 없다고 생각하는 것 같습니다 . 따라서 적어도 잔소리가 의심 스럽기 때문에 좋은 회사가되었습니다.

내가 읽은 모범 사례의 수는 여기에 나열하거나 개별 질문을하기에 너무 많기 때문에 일반적인 질문으로 표현하고 싶습니다.

일반적으로 "모범 사례"로 분류 된 코딩 관행은 특정 상황에서 차선책이거나 심지어 해로울 수 있습니까? 그러한 상황은 무엇이며 왜 실천이 열악합니까?

구체적인 예와 경험에 대해 듣고 싶습니다.

이 말로 머리에 못을 박았다고 생각합니다

나는 액면가로 물건을 가져가는 것을 싫어하고 비판적으로 생각하지 않습니다.

나는 그것이 존재하는 이유에 대한 설명이없는 거의 모든 모범 사례를 무시합니다.

Raymond Chen 은이 기사 에서 다음 과 같이 말합니다.

좋은 조언에는 근거가 포함되어 있으므로 나쁜 조언이 될 때 알 수 있습니다. 왜 무언가를해야하는지 이해하지 못한다면,화물 컬트 프로그래밍의 함정에 빠졌으며, 더 이상 필요하지 않거나 심지어 해로운 상태가 되어도 계속 그렇게 할 것입니다.

이것을 링에 넣을 수도 있습니다.

Premature optimization is the root of all evil.

아뇨.

완전한 인용문 :

"우리는 시간의 97 % 정도의 작은 효율성을 잊어야한다. 조기 최적화는 모든 악의 근원이다. 그러나 우리는 그 중요한 3 %의 기회를 포기해서는 안된다."

즉 , 설계 프로세스 전체 에서 구체적이고 전략적인 성능 향상 을 활용할 수 있습니다 . 이는 성능 목표와 일치하는 데이터 구조 및 알고리즘을 사용함을 의미합니다. 이는 성능에 영향을 미치는 디자인 고려 사항을 알고 있음을 의미합니다. 그러나 또한 그렇게 할 때 엄청나게 최적화하지 않으면 유지 관리 비용을 대가로 약간의 이익을 얻을 수 있습니다.

응용 프로그램을 잘 설계해야하므로 응용 프로그램에 약간의 부하를 가한 후에도 다운되지 않고 응용 프로그램을 다시 작성할 수 있습니다. 축약 된 인용문의 위험은 너무 자주 개발자가이를 수행하기에는 너무 늦을 때까지 성능에 대해 전혀 생각하지 않는 변명으로 사용한다는 것입니다. 사소한 것에 초점을 맞추지 않는다면 처음부터 좋은 성능으로 구축하는 것이 좋습니다.

임베디드 시스템에서 실시간 애플리케이션을 구축한다고 가정 해 봅시다. "초기 최적화는 모든 악의 근원"이기 때문에 프로그래밍 언어로 Python을 선택합니다. 이제 파이썬에 반대하는 것은 없지만 해석 된 언어입니다. 처리 능력이 제한되어 있고 실시간 또는 거의 실시간으로 일정량의 작업을 수행해야하고 작업에 더 많은 처리 능력이 필요한 언어를 선택하는 경우, 당신은 엄청나게 무너집니다. 이제 유능한 언어로 시작해야합니다.

기능 / 방법 당 하나의 리턴.

바퀴를 재발 명하지 마십시오 . 널리 사용되는 교리입니다. 적절한 솔루션이 존재하면 자신 만의 솔루션을 만드는 대신 솔루션을 사용하는 것이 좋습니다. 노력을 절약하는 것 외에도 기존 솔루션은 처음에 생각했던 것보다 더 잘 구현 (버그 프리, 효율적, 테스트) 될 것입니다. 여태까지는 그런대로 잘됐다.

문제는 100 % 적합한 솔루션이 거의 없다는 것입니다. 80 % 적합한 솔루션이 존재할 수 있으며 사용하는 것이 좋습니다. 그러나 60 % 정도는 어떻습니까? 40 %? 선은 어디에서 그리나요? 선을 그리지 않으면 "바퀴 재발견"을 피하기 위해 10 %의 기능을 사용하기 때문에 부풀린 라이브러리를 프로젝트에 통합 할 수 있습니다.

바퀴를 재발견하면 원하는 것을 정확하게 얻을 수 있습니다. 또한 바퀴 만드는 법도 배웁니다. 수행함으로써 학습을 과소 평가해서는 안됩니다. 그리고 결국, 커스텀 휠은 상용 휠보다 낫습니다.

"모든 단위 테스트."

나는 모든 코드가 단위 테스트를해야한다고 들었습니다. 메소드에 대한 테스트가있는 경우 해당 메소드의 출력 또는 구조에 대한 변경은 두 번 (코드에서 한 번, 테스트에서 한 번) 수행해야합니다.

따라서 단위 테스트는 코드의 구조적 안정성에 비례해야한다고 생각합니다. 아래에서 위로 계층 시스템을 작성하는 경우 데이터 액세스 계층에서 wazoo를 테스트합니다. 내 비즈니스 로직 계층은 꽤 잘 테스트되고 프레젠테이션 계층에는 몇 가지 테스트가 있으며 뷰에는 테스트가 거의 또는 전혀 없습니다.

항상 인터페이스에 프로그래밍하십시오.

때로는 하나의 구현 만있을 수 있습니다. 인터페이스 추출 과정을 필요로 할 때까지 인터페이스 추출 프로세스를 지연 시키면 필요하지 않은 경우가 종종 있습니다.

오픈 소스를 사용하지 마십시오 (또는 .NET 개발자를위한 비 Microsoft)

Microsoft가 개발하지 않은 경우 여기에서 사용하지 않습니다. ORM-EF를 사용하고 싶습니다, IOC-Unity를 사용하고 싶습니다-기록하려는 엔터프라이즈 로깅 응용 프로그램 블록. 더 나은 라이브러리가 많이 있지만 여전히 개발 세계의 달러 메뉴에서 주문을 계속하고 있습니다. "McDonald 's Nutritional Guidelines"라고 생각하는 Microsoft Best Practices를들을 때마다 맹세합니다. 물론, 당신이 그들을 따르면 아마 살 것이지만 영양 실조와 과체중이 될 것입니다.

• 참고이되지 않을 수도 있습니다 당신의 가장 좋은 방법,하지만 일반적인 하나의 거의 모든 곳에서 내가 작업 한 다음입니다.

객체 방향

코드가 "객체 지향"이기 때문에 마술처럼 좋다는 가정이 있습니다. 그래서 사람들은 객체 지향적 인 기능을 클래스와 메소드로 짜 넣습니다.

모든 코드에 주석을 달아야합니다.

아닙니다. 언젠가 당신이 명백한 코드를 가지고 있다면, 예를 들어 setter는 특별한 것을 할 때까지 주석을 달지 않아야합니다. 또한 왜 이것을 언급해야합니까?

/** hey you, if didn't get, it's logger. */
private static Logger logger = LoggerFactory.getLogger(MyClass.class);

방법론, 특히 스크럼. 어른들이 "Scrum Master"라는 문구를 사용한다고 들었을 때 똑바로 얼굴을 유지할 수 없습니다. 나는 개발자 시위에 너무 지쳐서 Methodology X의 일부 측면이 회사를 위해 일하지 않고 Guru So-and-So에게만 들려야합니다. "방법론 X. Padawan 학습자, 스크럼이 더 어려워 야합니다!"

민첩한 방법론 (많은 것들)에는 많은 지혜가 있지만, 종종 많은 분뇨에 갇혀 개그 반사에 맞설 수 없습니다. Wikipedia의 스크럼 페이지 에서이 비트를 가져옵니다 .

Scrum에는 많은 역할이 정의되어 있습니다. 모든 역할은 개발 과정에 관여하는 특성에 따라 돼지와 닭의 두 가지 그룹으로 나뉩니다.

정말? 돼지와 닭 이라고요? 매혹적인! 이것을 내 상사에게 던지기를 기다릴 수 없다 ...

객체 관계형 매핑 ... http://en.wikipedia.org/wiki/Object-relational_mapping

데이터에서 추상화되기를 원치 않으며 정확한 제어 및 최적화를 잃고 싶지도 않습니다. 이 시스템들에 대한 나의 경험은 극도로 열악했다 ...이 추상화 계층들에 의해 생성 된 질의들은 내가 오프쇼어링에서 본 것보다 훨씬 나쁘다.

영어 문장처럼 함수 이름 작성

Draw_Foo()
Write_Foo()
Create_Foo()

등등. 이것은 멋지게 보일지 모르지만 API를 배울 때 고통 스럽습니다. "Foo로 시작하는 모든 것"에 대한 색인을 검색하는 것이 얼마나 쉬운가요?

Foo_Draw()
Foo_Write()
Foo_Create()

기타

MVC-MVC 접근 방식에서 많은 웹 디자인 문제를 해결하는 것이 단순성 또는 구조보다는 프레임 워크 (레일 등)를 행복하게 만드는 것보다 더 자주 발견됩니다. MVC는 단순성에 비해 과도한 비계를 중요하게 생각하는 "아키텍처 우주 비행사"가 선호합니다. ymmv.

클래스 기반 OO-제 생각에는 변경 가능한 상태의 복잡한 구조를 권장합니다. 몇 년 동안 클래스 기반 OO에서 찾은 유일한 강력한 사례는 OO 책의 1 장을 구성하는 각질 "모양-> 사각형-> 사각형"예입니다.

야 그니

( 넌 필요 없어 )

이 접근 방식은 기존 코드베이스에서 기능을 구현해야했던 시간과 시간이 많이 들었습니다.이 계획을 신중하게 계획하면 이러한 기능이 미리 포함되었을 것입니다.

내 아이디어는 종종 YAGNI 때문에 거부 당했으며, 대부분 누군가가 그 결정에 대해 나중에 지불해야했습니다.

(물론 잘 설계된 코드베이스는 나중에 기능을 추가 할 수는 있지만 현실은 다르다고 주장 할 수 있습니다)

SQL의 경우

1. 트리거를 사용하지 마십시오
2. 뷰 뒤에 항상 테이블 숨기기

순서대로 :

1. 그것들은 그 자리에있는 기능입니다. 테이블에 대한 여러 업데이트 경로가 있거나 100 % 감사가 필요합니까?

2. 왜? 계약을 유지 관리하기 위해 리팩토링을하고 싶지만 테이블 변경 사항과 일치하도록보기를 변경했을 때가 아닙니다.

편집하다:

3 번 : 존재하지 않는 * 1/0을 시도하십시오. 효과가있다. 열 목록은 SQL 표준에 따라 평가되지 않습니다. 191 화

주로 디자인 패턴. 사용률이 너무 높거나 적습니다.

단일 책임 원칙

^{( "모든 수업은 하나의 책임만을 가져야합니다. 즉, 모든 수업은 변경해야 할 이유가 하나뿐이어야합니다")}

동의하지 않습니다. 메소드 는 변경해야 할 이유가 하나만 있어야 한다고 생각하고 클래스의 모든 메소드는 하나와 논리적 관계를 가져야 하지만 클래스 자체는 실제로 여러 가지 (관련) 작업을 수행 할 수 있습니다 .

내 경험에 따르면,이 원칙은 너무 열심 적으로 적용되기 때문에 많은 작은 1 가지 방법 클래스가 생깁니다. 내가 일한 민첩한 상점들이이 일을 해냈습니다.

.Net API의 작성자 가 List.Sort (), List.Reverse (), List.Find () 등이 아니라 이러한 사고 방식 을 가지고 있다고 가정하면 ListSorter, ListReverser 및 ListSearcher 클래스가 있습니다!

더 이상 SRP (이론 자체로는 끔찍한 것은 아님) 에 대해 논쟁하는 대신 , 나는 오래 지속 된 일화 경험을 공유 할 것입니다.

내가 일을 한 곳에서, 나는 아주 간단한 썼다 최대 흐름 해결사 노드, 그래프하는를 해결하기 위해 그래프 제작자 / 솔버를 사용하는 그래프 제작자, 그래프 해결사, 그리고 클래스 : 다섯 개 가지 클래스로 구성 실제 문제. 특별히 복잡하거나 긴 것은 없었습니다 (솔버는 ~ 150 라인에서 가장 길었습니다). 그러나 클래스에 "책임"이 너무 많은 것으로 결정되어 동료가 코드 리팩토링을 설정했습니다. 그들이 끝났을 때, 나의 5 개의 수업은 25 개의 수업으로 확장되었고, 그의 총 코드 라인은 원래의 3 배 이상이었습니다. 코드의 흐름은 더 이상 명확하지 않았으며 새로운 단위 테스트의 목적도 아니 었습니다. 나는 이제 내 코드가 무엇을하는지 알아내는 데 어려움을 겪었다.

같은 장소에서, 거의 모든 클래스는 하나의 메소드만을 가졌습니다 ( "책임 성"만). 프로그램 내에서의 흐름을 따르는 것은 거의 불가능했으며, 대부분의 단위 테스트는 이 클래스 가 다른 클래스의 코드라고 불리는 테스트로 구성되었으며 두 가지 목적 모두 나에게 미스터리였습니다. 말 그대로 수백 개의 클래스가 있었으며 (IMO) 수십 개가 있어야했습니다. 각 클래스는 하나의 "thing" 을 수행했지만 "AdminUserCreationAttemptorFactory" 와 같은 이름 지정 규칙을 사용하더라도 클래스 간의 관계를 파악하기가 어려웠습니다.

다른 곳 ( 클래스- 만해야하는 방법론-일정한 사고 방식을 가짐 )에서 특정 작업 중에 95 %의 시간이 걸리는 방법을 최적화하려고했습니다. (어리석게) 조금 최적화 한 후, 왜 그것이 bajillion 시대라고 불리는 지에 관심을 돌 렸습니다 . 클래스의 루프에서 호출되었습니다 ... 다른 클래스의 루프에서 메소드가 호출되었습니다. 또한 루프에서 호출되었습니다 ..

모두 13 단계에 걸쳐 5 단계의 루프가 존재한다고한다. 어떤 클래스가 실제로하고 있는지는 그것을보고 판단하기가 불가능했습니다. 어떤 메소드를 호출했는지, 어떤 메소드를 호출했는지 등의 정신 그래프를 스케치해야했습니다. 그것이 하나의 방법으로 묶여 있다면, 우리의 문제 방법이 즉시 명백한 5 개의 루프 레벨 안에 중첩되어 약 70 줄에 불과했을 것입니다.

13 개의 클래스를 하나의 클래스로 리팩토링하라는 요청이 거부되었습니다.

Clean Code에 대해 언급했지만 좋은 아이디어가 포함되어 있지만 모든 메소드를 하위 메소드로 리팩토링하고 하위 메소드로 리팩토링하는 것에 대한 집착이 너무 멀리 있다고 생각합니다. 두 줄짜리 방법 대신에 20 개의 원 라이너를 선호합니다. 분명히 누군가는 그것이 깨끗하다고 ​​생각하지만 나에게는 원래 버전보다 훨씬 나빠 보입니다.

또한 다음과 같은 간단한 기본 사항을 대체합니다.

0 == memberArray.length

클래스 자체의 메소드를 호출하는 클래스 내에서

isEmpty()

의심스러운 "개선"IMHO입니다. 추가 : 차이점은 첫 번째 검사가 정확히 말한 것을 수행한다는 것입니다. 배열 길이가 0인지 여부를 확인합니다. 좋습니다 isEmpty(). 배열 길이도 확인할 수 있습니다. 그러나 다음과 같이 구현할 수도 있습니다.

return null != memberArray ? 0 == memberArray.length : true;

즉, 암시 적 null 검사가 포함됩니다! 배열이 null 인 경우 무언가가 비어있는 경우 공용 메소드의 경우 좋은 동작 일 수 있지만 클래스 내부에 대해 이야기 할 때 이것은 좋지 않습니다. 외부 캡슐화 는 필수이지만 클래스 내부 는 클래스 내에서 무슨 일이 일어나고 있는지 정확히 알아야합니다. 클래스 자체를 캡슐화 할 수 없습니다 . 암시적인 것보다 명시적인 것이 좋습니다.

긴 방법을 분석하거나 논리적 비교를하는 것이 좋지 않다는 것은 아닙니다. 물론 그것은 달콤한 맛이있는 곳에서 어느 정도해야할지 는 분명 맛의 문제입니다. 긴 방법을 세분화하면 더 많은 방법이 나오고 무료로 제공되지 않습니다. 모든 것이 단일 방법으로 이루어 졌다면 한 눈에 볼 수있을 때 실제로 진행중인 작업을 확인하려면 소스 코드를 뛰어 넘어야합니다.

심지어 어떤 경우에는 1- 라인 방법이 너무 짧아서 방법이 될 자격이 없다고 말할 수 있습니다.

"의견에 자유 로워"

주석은 확실히 좋은 것이지만 너무 많지 않으면 충분하지 않은 것만 큼 나쁘다. 왜? 사람들은 불필요한 의견이 너무 많으면 의견을 조정하는 경향이 있습니다. 완벽하게 자체 문서화 코드를 가질 수 있다고 말하지는 않지만 설명을 위해 주석이 필요한 코드를 작성하는 것이 좋습니다.

유해한 것으로 간주되는 GoTo

상태 머신을 구현하는 경우 GOTO 문은 "구조화 된 프로그래밍"접근 방식보다 더 의미가 있습니다 (가독성 및 효율적인 코드). 새 직장에서 작성한 첫 번째 코드 조각에 단 하나의 고토 문 만이 포함되어있을 때 일부 동료들은 정말 걱정했습니다. 다행스럽게도이 사례에서는 실제로 최상의 솔루션이라는 것을 알기에 충분히 지능적이었습니다.

규칙에 대한 현명하고 문서화 된 예외를 허용하지 않는 "모범 사례"는 무섭습니다.

코드를 테스트 할 수 있도록하는 희생

내 코드를 테스트 할 수 있도록 많은 농구 대를 뛰어 넘었지만 선택을하지 않으면 내 척하지는 않습니다. 그러나 나는 사람들이 이것이 "모범 사례"라는 생각을 강요하는 것을 종종 듣는다. 이러한 관행에는 다음이 포함됩니다 (.Net의 언어로 작성되었지만 다른 언어에도 적용됨) .

• 모든 클래스를 위한 인터페이스 만들기 이 두 배로 처리하는 클래스 (파일)의 수, 중복 코드를. 예, 인터페이스 프로그래밍 은 좋지만 공개 / 개인 지정자가 의도 한 것입니다.
• 시작할 때 인스턴스화되지 않은 모든 클래스에는 팩토리가 필요합니다. 분명히, new MyClass()팩토리를 작성하는 것보다 훨씬 간단하지만, 이제는 팩토리를 만드는 방법을 개별적으로 테스트 할 수 없습니다. 이 사실이 아니라면, 나는 지금하는 팩토리 클래스 수의 1/20 만 만들 것입니다.
• 모든 클래스를 공개로 설정하면 클래스에 액세스 지정자를 갖는 목적을 완전히 상실합니다. 그러나 비공개 프로젝트는 다른 프로젝트에서 액세스 (및 테스트) 할 수 없으므로 다른 옵션은 모든 테스트 코드를 동일한 프로젝트로 이동하여 최종 제품과 함께 릴리스하는 것뿐입니다.
• 의존성 주입. 분명히 다른 모든 클래스에 필드를 사용하고 생성자 매개 변수를 사용하면 필요할 때 만드는 것보다 훨씬 많은 작업이 필요합니다. 그러나이 클래스를 더 이상 테스트 할 수 없습니다.
• Single Responsibility Principle (단일 책임 원칙) 으로 인해 두통이 너무 많아서 본인의 대답으로 옮겼습니다 .

이 문제를 해결하려면 어떻게해야합니까? 우리는 언어 구조에 급격한 변화가 필요합니다 :

• 수업을 조롱 할 수있는 능력이 필요합니다
• 우리는 다른 프로젝트에서 내부 클래스의 개인 메소드를 테스트 할 수있는 능력이 필요합니다 (이는 보안 취약점처럼 보일 수 있지만 테스터가 테스터 클래스의 이름을 강요하면 문제가 발생하지 않습니다) .
• 의존성 주입 (또는 서비스 위치)과 기존 팩토리 패턴과 동등한 것이 언어 의 핵심 부분 이어야합니다 .

간단히 말해, 우리 는 테스트 가능성을 염두에두고 처음부터 설계된 언어 가 필요 합니다 .

응용 프로그램을 계층으로 분리 데이터 계층, 비즈니스 계층, UI 계층

내가 이것을 싫어하는 주된 이유는이 방법을 따르는 대부분의 장소가 매우 부서지기 쉬운 프레임 워크를 사용하여 수행하기 때문입니다. IE UI 계층은 비즈니스 계층 개체를 처리하기 위해 수동으로 코딩되며, 비즈니스 계층 개체는 비즈니스 규칙 및 데이터베이스를 처리하기 위해 수동으로 코딩되며, 데이터베이스는 SQL이며 이미 변경을 싫어하는 "DBA"그룹에 의해 상당히 취약하고 관리됩니다.

왜 이것이 나쁜가요? 가장 일반적인 개선 요청은 "X 화면에 Y가있는 필드가 필요합니다."일 가능성이 높습니다. 쾅! 모든 단일 레이어에 영향을 미치는 새로운 기능이 있으며, 다른 프로그래머와 레이어를 분리하면 여러 사람과 그룹과 관련하여 매우 간단한 문제로 큰 문제가되었습니다.

또한, 나는 이런 식의 논쟁에 몇 번이나 있었는지 모른다. "이름 필드는 최대 길이 30으로 제한됩니다. UI 계층입니까, 비즈니스 계층입니까, 아니면 데이터 계층 문제입니까?" 그리고 백개의 논증이 있으며 정답은 없습니다. 대답은 동일하며 모든 레이어에 영향을 미칩니다. UI 바보를 만들고 모든 레이어를 거치지 않고 데이터베이스에서 실패해야하므로 사용자가 항목이 너무 길다는 것을 알 수 있습니다. 변경하면 모든 레이어 등에 영향을 미칩니다.

"층"도 누출되는 경향이 있습니다. 프로세스 / 시스템 경계 (IE 웹 UI 및 비즈니스 백엔드 로직)에 의해 계층이 물리적으로 분리 된 경우 모든 것이 합리적으로 작동하도록 규칙이 복제됩니다. 즉, 일부 비즈니스 로직은 "비즈니스 규칙"이지만 UI에 응답 할 수 있어야하기 때문에 UI에있게됩니다.

사용 된 프레임 워크 또는 사용 된 아키텍처가 작은 변경 및 유출에 탄력적이며, 즉 메타 데이터를 기반으로하고 모든 계층을 통해 동적으로 조정되면 덜 고통 스러울 수 있습니다. 그러나 대부분의 프레임 워크는 모든 작은 변경에 대해 UI 변경, 비즈니스 계층 변경 및 데이터베이스 변경이 필요하며 기술이 생성하는 것보다 더 많은 작업과 적은 도움을 필요로하는 엄청난 고통입니다.

아마 이것 때문에 비틀 거릴 것이지만, 거기에 있습니다 :)

자바 빈즈

Java에서 JavaBeans 사용 내 질문보기 왜 JavaBeans 대신 불변 POJO를 사용해서는 안됩니까? StackOverflow에.

사용자 사례 / 사용 사례 / 페르소나

나는 당신이 익숙하지 않은 산업을 프로그래밍 할 때 이것들의 필요성을 이해하지만, 그것들이 완전한 힘으로 구현되면 너무 회사가되어 시간 낭비가된다고 생각합니다.

80 자 / 라인 제한은 바보입니다

GUI 측면에서 가장 느린 러너 속도 (화면 해상도 제한 등)에 맞게 일부 타협이 필요하지만 그 규칙이 코드 형식에 적용되는 이유는 무엇입니까?

참조 ... 맨 오른쪽 픽셀 경계 외부의 가상 화면 공간을 관리하기 위해 만들어진 가로 스크롤 막대라는이 작은 발명품이있었습니다. 구문 강조 및 자동 완성과 같은 뛰어난 생산성 향상 도구를 개발 한 개발자는 왜이를 사용하지 않습니까?

물론, VT220 터미널의 피곤하고 오래된 한계를 따르는 * nix 공룡이 종교적으로 사용하는 CLI 편집기가 있지만 왜 우리는 같은 표준을 유지합니까?

80 문자 제한을 조이십시오. 공룡이 하루 종일 emacs / vim을 해킹 할 수있는 서사시라면 라인을 자동으로 감싸거나 CLI IDE에 가로 스크롤 기능을 제공하는 확장 기능을 만들 수없는 이유는 무엇입니까?

1920x1080 픽셀 모니터는 결국 표준이 될 것이며 전 세계 개발자들은 여전히 ​​프로그램을 시작했을 때 장로들에게 무엇을했는지를 제외하고는 왜 그런지에 관계없이 동일한 한계에 처해 있습니다.

80 개 문자 제한은 없습니다 가장 좋은 방법이지만 프로그래머의 아주 소수의 틈새 연습과 같은 취급 할 필요가 있습니다.

편집하다:

많은 개발자들이 마우스 스크롤이 필요하기 때문에 가로 스크롤 막대를 좋아하지 않는다는 것을 이해할 수 있습니다. 현대식 디스플레이를 사용하는 사람들에게는 열 너비 제한을 80보다 큰 수로 늘리지 않겠습니까?

800x600 컴퓨터 모니터가 대부분의 사용자에게 표준이되었을 때, 웹 개발자는 대다수를 수용하기 위해 웹 사이트 너비를 늘 렸습니다.

측정, 측정, 측정

따라서 미세 측정, 거리,하지만에 대한 분리 에 대한 작품뿐만 아니라 연속적인 제거를 측정, 성능 버그. 내가 사용하는 방법은 다음과 같습니다.

측정 측정 "지혜"의 출처를 추적하려고했습니다. 키가 충분한 비누 통을 가진 사람이 그것을 말했고, 이제는 여행합니다.

선생님은 소문자로 모든 식별자 (상수 제외)를 시작하도록 요구합니다 (예 :) myVariable.

나는 그것이 사소한 것처럼 보이지만 많은 프로그래밍 언어 는 대문자로 시작 하는 변수가 필요 합니다. 나는 일관성을 중요하게 생각하므로 대문자로 모든 것을 시작하는 것이 습관입니다.

싱글 톤 사용

하나의 인스턴스 만 있어야 할 때. 나는 캔트 동의 더. 싱글 톤을 사용하지 말고 한 번만 할당하고 필요에 따라 포인터 / 객체 / 참조를 전달하십시오. 이것을하지 않을 이유는 전혀 없습니다.

부호없는 int를 반복자로 사용

부호있는 int를 사용하는 것이 훨씬 안전하고 버그가 덜 발생한다는 것을 언제 알게 될까요? 4-5가 4294967295라는 사실을 간과하기 위해 배열 인덱스가 양수 일 수 있다는 것이 왜 그렇게 중요합니까?

메소드는 단일 화면보다 길어서는 안됩니다

나는 단일 책임 원칙에 완전히 동의하지만 사람들은 왜 "기능 / 방법이 최고 수준의 논리적 세분성에서 단일 책임을 가질 수 없다"는 의미로 인식 하는가?

아이디어는 간단하다. 기능 / 방법은 하나의 작업을 수행해야합니다. 해당 기능 / 방법의 일부를 다른 곳에서 사용할 수있는 경우 자체 기능 / 방법으로 잘라내십시오. 프로젝트의 다른 곳에서 사용할 수있는 경우 자체 클래스 또는 유틸리티 클래스로 이동하여 내부적으로 액세스 가능하게하십시오.

코드에서 한 번만 호출되는 27 개의 도우미 메서드가 포함 된 클래스를 갖는 것은 바보, 공간 낭비, 불필요한 복잡성 증가 및 막대한 시간 싱크입니다. 바쁜 리팩토링 코드를보고 싶지만 많이 생산하지 않는 사람들에게는 더 좋은 규칙처럼 들립니다.

여기 내 규칙이있다.

무언가를 달성하기위한 함수 / 메서드 작성

코드를 복사 / 붙여 넣기하려는 경우 해당 코드에 대한 함수 / 메소드를 만드는 것이 더 좋은지 스스로에게 물어보십시오. 함수 / 메소드가 다른 함수 / 메소드에서 한 번만 호출되는 경우, 실제로 함수 / 메소드가 처음에 있어야 할 시점이 있습니까 (향후 더 자주 호출 될 것임). 디버깅하는 동안 함수 / 메서드에 더 많은 점프를 추가하는 것이 중요합니까 (즉, 추가 된 점프로 인해 디버깅이 더 쉬워 지거나 더 어려워 집니까)?

200 줄 이상의 기능 / 방법을 면밀히 조사해야하지만 일부 기능은 한 줄의 작업 만 수행하고 프로젝트의 나머지 부분에서 추상화 / 사용할 수있는 유용한 부분이 포함되어 있지 않다는 것에 전적으로 동의합니다.

API 개발자의 관점에서 보았습니다 ... 새로운 사용자가 코드의 클래스 다이어그램을 보려는 경우, 프로젝트 전체에서 해당 다이어그램의 몇 부분이 의미가 있고 몇 개만 존재하는지는 알 수 있습니다. 프로젝트 내부의 다른 부분에 대한 도우미.

두 프로그래머 중 하나를 선택한다면 : 첫 번째 프로그래머는 너무 많은 것을 시도하는 함수 / 메서드를 작성하는 경향이 있습니다. 두 번째는 모든 기능 / 방법의 모든 부분을 가장 세분화 된 수준으로 나눕니다. 첫 손을 아래로 선택하겠습니다. 첫 번째는 더 많은 작업을 수행하고 (즉, 더 많은 응용 프로그램을 작성), 코드는 디버깅하기가 더 쉬워지고 (디버깅 중 함수 / 방법의 점프가 적어지기 때문에) 바쁜 작업을 수행하는 데 시간을 덜 낭비하게됩니다. 코드는 코드 작동 방식을 완벽하게 비교합니다.

불필요한 추상화를 제한하고 자동 완성을 오염시키지 마십시오.