한때 마음에 들었던 프로그래밍 관행에 대해 마음이 바뀌 었습니까? [닫은]

프로그래밍 할 때 우리 모두는 우리가 사용하고 의존하는 관행과 패턴을 개발합니다. 그러나 시간이 지남에 따라 우리의 이해, 성숙도, 심지어 기술 사용이 변경됨에 따라 우리가 한때 훌륭하다고 생각했던 일부 관행이 그렇지 않거나 더 이상 적용되지 않는다는 것을 깨닫게됩니다.

한때 자주 사용했지만 최근 몇 년 동안 변경된 사례는 Singleton 객체 패턴을 사용하는 것입니다 .

내 자신의 경험과 동료들과의 긴 토론을 통해 싱글 톤이 항상 바람직한 것은 아니라는 것을 깨달았습니다. 싱글 톤은 테스트를 더 어렵게 만들 수 있고 (모킹과 같은 기술을 억제함으로써) 시스템 부분 사이에 바람직하지 않은 결합을 만들 수 있습니다. 대신, 이제는 신경 쓰지 않거나 알 필요가없는 시스템 부분에서 싱글 톤의 특성과 존재를 숨기는 객체 팩토리 (일반적으로 IoC 컨테이너 사용)를 사용합니다. 대신, 이러한 개체에 대한 액세스 권한을 얻기 위해 공장 (또는 서비스 로케이터)에 의존합니다.

자기 계발 정신으로 커뮤니티에 대한 나의 질문은 다음과 같습니다.

• 최근에 어떤 프로그래밍 패턴이나 관행을 재고하고 이제 피하려고하십니까?
• 무엇으로 교체하기로 결정 했습니까?

//Coming out of university, we were taught to ensure we always had an abundance 
//of commenting around our code. But applying that to the real world, made it 
//clear that over-commenting not only has the potential to confuse/complicate 
//things but can make the code hard to follow. Now I spend more time on 
//improving the simplicity and readability of the code and inserting fewer yet 
//relevant comments, instead of spending that time writing overly-descriptive 
//commentaries all throughout the code.

단일 리턴 포인트.

나는 루틴에 필요한 정리가 간과되지 않도록 보장 할 수 있었기 때문에 각 메소드에 대해 단일 리턴 포인트를 선호했습니다.

그 이후로 저는 훨씬 더 작은 루틴으로 이동했습니다. 따라서 정리를 간과 할 가능성이 줄어들고 실제로 정리 의 필요성 이 줄어 듭니다. 그리고 조기 반환이 코드의 명백한 복잡성 (중첩 수준)을 감소 시킨다는 것을 알게되었습니다. 단일 반환점의 아티팩트 ( "결과"변수 유지, 플래그 변수 유지, 아직 완료되지 않은 상황에 대한 조건절 유지)는 코드가 실제보다 훨씬 더 복잡해 보이게하고 읽기 및 유지 관리를 어렵게 만듭니다. 초기 출구와 더 작은 방법이 갈 길이다.

• 첫 번째 시도에서 완벽하게 코딩하려고합니다.
• 코딩하기 전에 완벽한 OO 모델을 만들려고합니다.
• 유연성과 향후 개선을 위해 모든 것을 설계합니다.

한마디로 오버 엔지니어링 .

헝가리 표기법 (양식 및 시스템 모두). 나는 모든 것을 접두사로 사용했습니다. strSomeString 또는 txtFoo. 이제 someString 및 textBoxFoo를 사용합니다. 새로운 누군가가 와서 픽업하기가 훨씬 더 읽기 쉽고 쉽습니다. 추가 보너스로 일관성을 유지하는 것은 사소한 일입니다. 컨트롤을 camelCase하고 유용하고 설명적인 이름을 추가합니다. Forms Hungarian은 항상 일관성이 없다는 단점이 있으며 Systems Hungarian은 실제로 많은 것을 얻지 못합니다. 모든 변수를 함께 묶는 것은 특히 최신 IDE의 경우 그다지 유용하지 않습니다.

"완벽한"아키텍처

저는 몇 년 전에 THE 아키텍처를 생각해 냈습니다 . 100 % 느슨하게 결합 된 레이어, 광범위한 델리게이트 사용, 경량 오브젝트가되도록 기술적으로 최대한 밀어 붙였습니다. 기술의 천국이었습니다.

그리고 그것은 쓰레기였습니다. 아키텍처의 기술적 순수성은 결과에 대한 완벽 함을 목표로 개발 팀의 속도를 늦추고 거의 완전한 실패를 달성했습니다.

이제 기술적으로 완벽하지 않은 아키텍처가 훨씬 단순 해졌고 제공 속도가 급증했습니다.

카페인 사용. 그것은 한때 나를 깨우고 영광스러운 프로그래밍 분위기로 유지했습니다. 이제는 아무 일도하지 않으며, 없으면 두통이 생깁니다.

코드 주석 처리. 나는 코드가 소중하고 자신이 만든 아름다운 보석을 삭제할 수 없다고 생각했습니다. 이제는 주석 처리 된 코드를 삭제합니다. 주석 처리 된 코드는 그대로두기에는 너무 위험하기 때문에 첨부 된 TODO 또는 NOTE가없는 경우 삭제합니다. 재치로, 주석 처리 된 부분이 많은 오래된 클래스를 보았는데 왜 그런지 혼란 스러웠습니다. 거기에 있었습니까 : 그들은 최근에 주석을 달았습니까? 이것은 개발 환경 변경입니까? 이 무관 한 차단을하는 이유는 무엇입니까?

코드를 주석 처리하지 않고 대신 삭제하는 것을 진지하게 고려하십시오. 필요한 경우 여전히 소스 제어에 있습니다. 그래도 YAGNI.

#region 지시문의 남용 / 남용. 사소한 일이지만 C #에서는 이전에 클래스를 구성하기 위해 #region 지시문을 모든 곳에서 사용했습니다. 예를 들어 모든 클래스 속성을 한 지역에 함께 그룹화합니다.

이제 나는 오래된 코드를 되돌아보고 대부분 그저 짜증이납니다. 나는 그것이 정말로 대부분의 경우 일을 더 명확하게 해주지 않는다고 생각하며 때때로 그들은 당신을 느리게 만듭니다. 그래서 나는 이제 마음을 바꾸었고 잘 짜여진 클래스가 지역 지시 없이 대부분 깨끗하다고 ​​느낍니다 .

일반적으로 폭포 개발, 구체적으로는 완전하고 포괄적 인 기능 및 디자인 사양을 작성하는 관행으로, 어떻게 든 정식이 될 것으로 예상되고 그 구현이 정확하고 수용 가능할 것으로 기대합니다. 나는 그것이 스크럼으로 대체되는 것을 보았습니다. 단순한 사실은 고객의 요구와 욕구의 변화하는 특성으로 인해 고정 된 사양을 효과적으로 쓸모 없게 만든다는 것입니다. 문제에 제대로 접근하는 유일한 방법은 반복적 인 접근 방식입니다. 물론 스크럼이 은색 총알은 아닙니다. 나는 그것이 오용되고 남용되는 것을 여러 번 보았다. 그러나 그것은 폭포를 이깁니다.

충돌하지 않습니다.

좋은 생각 같지 않나요? 사용자는 충돌하는 프로그램을 좋아하지 않으므로 충돌하지 않는 프로그램을 작성하고 사용자는 프로그램을 좋아해야합니다. 그것이 내가 시작한 방법입니다.

요즘 나는 그것이 작동하지 않으면 작동하는 척해서는 안된다고 생각하는 경향이 있습니다. 좋은 오류 메시지와 함께 가능한 한 빨리 실패하십시오. 그렇지 않으면 프로그램은 나중에 몇 가지 명령만으로도 충돌이 심해지지만 디버그하는 데 한 시간이 걸리는 설명이없는 널 포인터 오류가 발생합니다.

내가 가장 좋아하는 "충돌 방지"패턴은 다음과 같습니다.

public User readUserFromDb(int id){
    User u = null;
    try {
        ResultSet rs = connection.execute("SELECT * FROM user WHERE id = " + id);
        if (rs.moveNext()){
            u = new User();
            u.setFirstName(rs.get("fname"));
            u.setSurname(rs.get("sname"));
            // etc
        }
    } catch (Exception e) {
        log.info(e);
    }
    if (u == null){
        u = new User();
        u.setFirstName("error communicating with database");
        u.setSurname("error communicating with database");
        // etc
    }
    u.setId(id);
    return u;
}

이제 사용자에게 오류 메시지를 복사 / 붙여 넣기하도록 요청하고이를 사용자에게 보내는 대신 로그 항목을 찾으려고 로그를 살펴 봐야합니다. (유효하지 않은 사용자 ID를 입력했기 때문에 로그 항목이 없습니다.)

디자인 패턴을 알아볼 때마다 적용하는 것이 합리적이라고 생각했습니다 .

내가 실제로 외국 프로그래밍 언어에서 스타일을 복사하고 있다는 사실을 거의 알지 못했지만, 내가 사용하는 언어는 훨씬 더 우아하고 쉬운 솔루션을 허용했습니다.

여러 (매우) 다른 언어를 사용하여 눈을 뜨고 다른 사람들의 해결책을 내 문제가 아닌 문제에 잘못 적용 할 필요가 없다는 것을 깨달았습니다. 이제 Ruby와 같은 언어로 적용된 팩토리 패턴을 보면 떨립니다.

강박 테스트. 나는 테스트 우선 개발의 광적인 지지자였습니다. 일부 프로젝트의 경우 이는 많은 의미가 있지만, 모든 단일 기능에 대해 단위 테스트를 작성하는 교리를 엄청나게 고수하는 것이 실행 불가능할뿐만 아니라 많은 프로젝트에 해롭다는 것을 깨달았습니다.

사실, 무엇이든 몹시 고수하는 것은 해로울 수 있습니다.

이것은 작은 일이지만 : 중괄호가 어디로 가는지 (같은 줄 또는 다음 줄에서?) 신경 쓰고, 코드의 최대 줄 길이, 변수에 대한 명명 규칙 및 기타 스타일 요소를 제안했습니다. 모든 사람이 나보다 이것에 더 신경을 쓰는 것 같아서 요즘 같이 일하는 사람의 흐름을 따라갑니다.

편집 : 물론 내가 가장 신경 쓰는 사람 일 때 (또는 그룹의 스타일을 설정하는 위치에있는 사람 일 때) 예외입니다. 그럴 때는 내가 원하는대로 해!

(이것은 일관된 스타일이없는 것과는 다릅니다. 코드베이스에서 일관된 스타일이 가독성을 위해 매우 중요하다고 생각합니다.)

아마도 내가 마음을 바꾼 가장 중요한 "프로그래밍 관행"은 내 코드가 다른 모든 사람보다 낫다는 생각 일 것입니다. 이것은 프로그래머 (특히 초보자)에게 일반적입니다.

유틸리티 라이브러리. 나는 언젠가 다른 곳에서 사용할 수 있다는 이론과 함께 다양한 도우미 메서드와 클래스로 어셈블리를 가지고 다녔습니다.

실제로는 제대로 구성되지 않은 기능이 많은 거대한 네임 스페이스를 방금 만들었습니다.

이제 저는 그것들을 제가 만든 프로젝트에 그대로 둡니다. 모든 가능성에있어서 저는 그것을 필요로하지 않을 것입니다. 그리고 만약 필요하다면 나중에 재사용 가능한 것으로 리팩토링 할 수 있습니다. 때로는 공통 어셈블리로 추출 할 수 있도록 // TODO로 플래그를 지정합니다.

내가 코딩 한 것보다 더 많은 것을 디자인합니다. 잠시 후 분석 마비로 바뀝니다.

데이터 세트를 사용하여 비즈니스 논리를 수행합니다. 이것은 코드를 데이터베이스에 너무 빡빡하게 묶고, 또한 DataSet은 일반적으로 SQL에서 생성되어 상황을 더욱 취약하게 만듭니다. SQL 또는 데이터베이스가 변경되면 DataSet이 접촉하는 모든 것으로 흘러가는 경향이 있습니다.

개체 생성자 내에서 비즈니스 논리를 수행합니다. 상속과 오버로드 된 생성자를 만드는 기능은 유지 관리를 어렵게 만드는 경향이 있습니다.

축약 변수 / 메서드 / 테이블 / ... 이름

이름의 길이에 대한 제한이없는 언어로 작업 할 때에도 항상이 작업을 수행했습니다 (아마도 255 개 정도 였을 것입니다). 부작용 중 하나는 (비표준) 약어를 설명하는 코드 전체에 흩어져있는 많은 주석이었습니다. 물론 어떤 이유로 든 이름이 변경된 경우 ...

이제 나는 좋은 설명적인 이름을 사용하여 진짜라고 부르는 것을 선호합니다. 표준 약어 만 포함 합니다. 쓸모없는 주석을 포함 할 필요가 없으며 코드가 훨씬 더 읽기 쉽고 이해하기 쉽습니다.

엔터프라이즈 라이브러리와 같은 기존 데이터 액세스 구성 요소를 도우미 메서드의 사용자 지정 계층으로 래핑합니다.

• 누구의 삶을 더 쉽게 만들지 않습니다
• 버그가있을 수있는 더 많은 코드
• 많은 사람들이 EntLib 데이터 액세스 구성 요소를 사용하는 방법을 알고 있습니다. 현지 팀 외에는 아무도 사내 데이터 액세스 솔루션을 사용하는 방법을 알고 있습니다.

1984 년 스몰 토크를 읽다가 객체 지향 프로그래밍에 대해 처음 들었지만 1992 년 cfront C ++ 컴파일러를 사용하기 전까지는 oo 언어에 접근 할 수 없었습니다. 마침내 1995 년에 스몰 토크를 사용하게되었습니다. 저는 oo를 기대했습니다. 소프트웨어 개발을 절약 할 수 있다는 아이디어를 얻었습니다.

이제 저는 oo를 몇 가지 장점이있는 하나의 기술로 간주하지만 도구 상자에서 하나의 도구에 불과합니다. 나는 대부분의 작업을 파이썬으로하고, 종종 클래스 멤버가 아닌 독립형 함수를 작성하고, 종종 과거에 클래스를 만들었던 튜플이나 목록에 데이터 그룹을 수집합니다. 데이터 구조가 복잡하거나 데이터와 관련된 동작이 필요한 경우에도 클래스를 생성하지만 저항하는 경향이 있습니다.

나는 시간이있을 때 Clojure에서 어떤 작업을하는 데 실제로 관심이 있는데, oo 기능을 제공하지 않지만 올바르게 이해하면 Java 객체를 사용할 수 있습니다. oo가 죽었다고 말할 준비가 안됐는데 개인적으로 예전 팬이 아니에요.

C #에서 _notation 개인 멤버에 합니다. 나는 지금 그것이 추악하다고 생각합니다.

그런 다음 this.notation개인 회원으로 변경 했지만 사용에 일관성이 없어서 그만 두었습니다.

구현하기 전에 대학에서 권장하는 디자인 방법을 중단했습니다. 혼란스럽고 복잡한 시스템에서 일하면서 태도를 바꿔야했습니다.

물론 저는 여전히 코드 연구를하고 있습니다. 특히 이전에 한 번도 다루지 않은 코드를 만질 때, 일반적으로 저는 먼저 무언가를 시작하기 위해 가능한 한 작은 구현에 집중하려고합니다. 이것이 주요 목표입니다. 그런 다음 점차 논리를 다듬고 디자인이 저절로 나타나도록합니다. 프로그래밍은 반복적 인 프로세스입니다. 이며 민첩한 접근 방식과 많은 리팩토링으로 매우 잘 작동합니다.

코드는 처음에 생각했던 모든 것을 보지 않습니다. 매번 일어난다 :)

나는 계약에 의한 설계에 큰 관심을 보였습니다. 이것은 내 모든 기능의 시작 부분에 많은 오류 검사를 두는 것을 의미했습니다. 관심사 분리의 관점에서 계약은 여전히 ​​중요하지만 코드가 수행하지 않아야하는 작업을 시행하기보다는 단위 테스트를 사용하여 수행하는 작업을 확인하려고합니다.

더 간결하기 때문에 많은 메서드 / 클래스에서 정적을 사용합니다. 시험을 쓰기 시작했을 때 연습이 매우 빠르게 바뀌 었습니다.

확인 된 예외

종이에 대한 놀라운 아이디어-계약을 명확하게 정의하고 실수의 여지가 없으며 일부 예외 조건을 확인하는 것을 잊었습니다. 처음 들었을 때 팔렸다.

물론 실제로는 그렇게 엉망이되었습니다. 레거시 검사 예외를 주요 기능 중 하나로 숨기는 Spring JDBC와 같은 라이브러리를 오늘날 가지고있는 시점까지.

가치있는 것은 하나의 특정 언어로만 코딩되었습니다. 제 경우에는 C가 최고의 언어라고 믿었고 다른 언어로 코딩 할 이유가 없었습니다.

그 이후로 다양한 언어와 그 언어가 제공하는 이점 / 기능에 감사하게되었습니다. 작은 것을 빠르게 코딩하려면 Python을 사용합니다. 대규모 프로젝트에서 작업하려면 C ++ 또는 C #으로 코딩합니다. 뇌종양을 개발하고 싶다면 Perl로 코딩 합니다.

리팩토링을해야했을 때 바로 시작하여 새로운 디자인을 구현하고 작동 할 때까지 연결을 수정하는 것이 더 빠르고 깔끔하다고 생각했습니다. 그런 다음 새 디자인을 향해 느리지 만 안정적으로 진행하기 위해 일련의 작은 리팩토링을 수행하는 것이 더 낫다는 것을 깨달았습니다.

아마도 내 코딩 관행과 다른 것에서 변경된 가장 큰 것은 인터넷에서 다운로드 한 외부 클래스와 라이브러리를 응용 프로그램의 동작과 기능에 대한 기반으로 받아들이는 것입니다. 내가 대학에 다닐 때 학교에서 우리는 우리 자신의 코드를 통해 상황을 개선하고 문제를 해결하기 위해 언어에 의존하는 방법을 알아 내도록 격려 받았습니다. 사용자 인터페이스 및 서비스 / 데이터 소비의 모든 측면이 발전함에 따라 이것은 더 이상 현실적인 개념이 아닙니다.

언어에서 절대 변경되지 않는 특정 사항이 있으며,이 코드를 더 간단한 트랜잭션과 적은 수의 코드 줄로 감싸는 라이브러리를 갖는 것은 축복입니다. 데이터베이스에 연결하는 것은 항상 동일합니다. DOM 내에서 요소를 선택해도 변경되지 않습니다. 서버 측 스크립트를 통해 이메일을 보내는 것은 변경되지 않습니다. 이 시간을 반복해서 작성해야하는 것은 애플리케이션의 핵심 로직을 개선하는 데 사용할 수있는 시간을 낭비합니다.

모든 클래스 멤버를 초기화합니다.

나는 모든 클래스 멤버를 일반적으로 NULL로 명시 적으로 초기화했습니다. 나는 이것을 깨달았다 :

• 일반적으로 모든 변수는 읽기 전에 두 번 초기화됩니다.
• 대부분의 언어에서 자동으로 변수를 NULL로 초기화하기 때문에 바보입니다.
• 실제로 대부분의 언어에서 약간의 성능 저하를가합니다.
• 더 큰 프로젝트에서 코드를 부 풀릴 수 있습니다.

여러분과 마찬가지로 저도 앱의 다양한 구성 요소 간의 결합을 줄이는 데 IoC 패턴을 수용했습니다. 각 구성 요소를 가능한 한 독립적으로 유지할 수있는 한 유지 관리 및 부품 교체가 훨씬 간단 해집니다. 또한 데이터베이스 관리 작업을 단순화하기 위해 NHibernate와 같은 더 많은 객체 관계형 프레임 워크를 활용하고 있습니다.

간단히 말해서 "미니"프레임 워크를 사용하여 소프트웨어를보다 빠르고 효율적으로 구축 할 수 있습니다. 이러한 미니 프레임 워크는 많은 시간을 절약하고 올바르게 수행하면 애플리케이션을 매우 간단하게 유지 관리 할 수 ​​있습니다. 승리를위한 플러그 앤 플레이!