가장 유감스러운 디자인이나 프로그래밍 결정은 무엇입니까? [닫은]

어떤 종류의 디자인 결정을 내리고 어떻게 역효과를 겪었는지 듣고 싶습니다. 나쁜 디자인 결정으로 인해, 나는 그 나쁜 결정을 영원히 지원해야했습니다. 이것은 하나의 단일 디자인 실수가 당신을 영원히 괴롭힐 수 있음을 깨달았습니다. 나는 경험이 많은 사람들에게 어떤 종류의 실수를 경험했으며 무엇을 배웠는지 알고 싶습니다.

나는 이것이 다른 프로그래머들이 그 결정을 반복하지 않도록 도와줌으로써 많은 도움이 될 것이라고 확신합니다.

경험을 공유해 주셔서 감사합니다.

YAGNI를 무시 하고 반복해서 ...

"나중에하겠습니다"
"나중에"오지 않습니다.

C ++, 다이아몬드 모양의 다중 가상 상속 . 당신은 아이디어를 얻습니다.

응용 프로그램의 구성 가능성이 좋습니다. 구성이 너무 많으면 사용하고 유지해야하는 악몽이 있습니다.

내 실수 중 하나에서 나는 DB 정규화를 맹목적으로 따라서는 안된다는 것을 알게되었습니다. 당신은 할 수 있으며 어떤 상황에서는 테이블을 평평하게 만들어야합니다.

나는 (모델을 통해) 많은 테이블을 관리하게되었고 성능은 테이블을 약간 편평하게하는 것만 큼 좋지 않았다.

상태 등을 위해 데이터베이스에서 단일 문자 사용 다소 난독 화되거나 부족합니다 (상태가 아니라 다른 것). 사람이 읽을 수있는 버전을 넣고 Java 모델 (내 경우에는)이 일치하는 열거 형을 갖는 것이 훨씬 좋습니다.

나는 이것이 불필요하고 맹목적인 최적화의 한 형태라고 생각합니다. 마치 단일 문자를 사용하는 것이 요즘 세상을 구할 것입니다. 부울 / 비트를 지원하지 않는 데이터베이스의 Y / N 부울 외에.

적절한 Data Access Layer를 개발하지 않고 내 코드의 모든 곳에서 SQL을 사용하는 것만으로 "빠른"실행이 가능합니다. 나중에 프로젝트가 확장되고 요구 사항이 변경되면서 악몽이되었습니다. 당시 DAL이 무엇인지 몰랐습니다.

... 20 년이 넘는 "경험"을 가진 프로그래머가 여전히이 작업을 수행하고 있음에도 불구하고 다행입니다.

나는 같은 프로젝트에서 건축가, 개발자 및 PM이 될 수 있다고 생각합니다.

밤에 3 시간 자고 2 개월간 그냥 할 수 없다는 걸 가르쳐주었습니다.

Java IDE 작성을위한 MFC (Microsoft Foundation Classes) 선택

그것은 내 결정 이 아니 었지만 (나중에 회사에 합류했습니다) 어딘가에서 모든 로그 메시지를 번역하는 것을 포함하여 i18n을 조금 멀리 가져갔습니다.

결과 :

• 새로운 로깅을 추가하기가 더 힘들다
• 번역 비용 증가
• 나중에 로그를 읽기가 더 어렵습니다.

죄송합니다.

바퀴 재발견

너무 많은 디자인을하고 있습니다. 많은 단일 UML 다이어그램, 특히 모든 단일 작업에 대한 시퀀스 다이어그램을 작성하면 결국에는 쓸모가없는 것으로 나타났습니다. 결국 불필요하게 세부적인 디자인 / 다이어그램을 건너 뛰고 직접 코딩을 시작함으로써 상당한 시간이 절약 될 수 있음이 밝혀졌습니다.

믿는 고객은 원하는 것을 알고 나서 확인하기 전에 너무 많은 일을합니다.

내 최악의 디자인 결정? 1980 년대로 돌아가서 런타임에 해석 될 데이터 입력 화면을위한 일종의 템플릿을 만들 겠다는 아이디어를 얻었습니다. 나쁘지 않은 결정 : 입력 화면을 쉽게 디자인 할 수있었습니다. 기본적으로 데이터 입력 화면과 유사한 파일을 만들면 레이블과 입력 필드를 구분하고 입력 필드가 알파벳인지 숫자인지를 식별하는 특수 코드가 있습니다. 그런 다음이 파일에 몇 가지 특수 코드를 추가하여 어떤 유효성 검사를 수행해야하는지 결정했습니다. 그런 다음 화면의 조건부 작성을 허용하기 위해 더 많은 코드를 추가하고 일부 조건이 true 일 때만 필드 X를 포함하는 등의 작업을 수행했습니다. 그런 다음 입력의 간단한 처리를 위해 더 많은 코드를 추가했습니다. 기타 결국 우리는 화면 템플릿을 새로운 프로그래밍 언어로 바꾸었고 표현식, 제어 구조 및 i / o 라이브러리로 완성했습니다. 그리고 무엇을 위해? 우리는 FORTRAN을 재발 명하기 위해 많은 노력을 기울였습니다. 우리는 더 나은 디자인과 테스트를 거친 언어를위한 컴파일러로 가득한 선반을 가지고있었습니다. 실제로 전문 지식이있는 제품을 만들기 위해 많은 노력을 기울 였다면 그 회사는 오늘날에도 여전히 사업을하고있을 것입니다.

모든 현명한 사람이 요구 사항이 확실히 변경 될 것이라고 말할 수있는 환경에서 YAGNI ( 객체 지향 개발의 함정 에 열거 에 의한 디자인 이라고 함)를 과도 하게 적용합니다. 그리고 반복적으로 변경하십시오.

당신이 (하드 -) 코드 모두를 한 경우 정확히 말한다 사람을 치는 전류 요구 사항-하면서 "이 더 일반적인 수 없습니다?" YAGNI 망치를 사용하면 요구 사항이 급격히 변하지 만 (합리적으로 예상 할 수있는 방식으로), 적응하는 데 2 ​​주가 걸리는 것과 20 분이 걸리는 것의 차이 일 수 있습니다.

업데이트 : 명확히하기 위해 여기에 발생한 일과 그리 멀지 않은 가상의 예가 있습니다. 스택 오버플로는 배지를 지원하도록 설계되었지만 처음에는 4 개의 배지만 생각할 수 있다고 가정합니다. 작은 숫자 인 4 개만으로 사이트의 모든 로직에서 정확히 4 개의 배지를 지원하도록 하드 코딩 되었습니다. 데이터베이스, 사용자 정보, 모든 표시 코드에서. 당신이 생각할 수없는 어떤 배지도 "Ya ain't'll need"때문에. 그런 다음 사이트가 게시되고 사람들이 새로운 배지를 제안하기 시작한다고 가정 해 봅시다. 각 배지추가하는 데 최대 2 주가 소요됩니다. 그러나 여전히 "Ya ai n't need not a badges"는 오늘날의 목록보다 더 이상 배지가 필요하지 않으므로 일반적인 배지 컬렉션을 지원하기위한 리팩토링은 없습니다. 이러한 일반 컬렉션이 더 이상 시간이 걸렸습니까? 많지 않다면.

YAGNI는 중요한 원칙이지만, 잘못된 디자인과 부적절한 하드 코딩을 변명하기 위해 사용해서는 안됩니다. 균형이 있고 경험이 있으면 접근하고 있다고 생각합니다.

무능한 인적 자원

잘못된 사람들과 옳고 큰 것을 만들려고 노력합니다!
그들이 불필요한 자아 PM의 역할을하더라도 (특히 무능력이 더 오래 지속될 수있는 대기업에서는 너무 흔하다).

매번 기술 부채를 만들거나 절차 코드를 작성하거나 테스트 작성을 건너 뛸 때마다 돌진하기 때문에. 거의 필연적으로 나는 이것이 길 아래로 나를 고통스럽게 만듭니다.

사용하여 SQL 서버 Intergration 서비스 (SSIS)를.

나는 나의 최악의 적에게 그것을 원하지 않는다.

지난 2 개월 동안 여러 개의 SSIS 패키지를 구축 한 후에 내가 개발 한 패키지가 배포 및 배포가 불가능하다는 사실을 알게되었습니다. 특히 웹이 아닌 비 SQL Server 라이센스 환경에서.

48 시간 이내에 SSIS 패키지를 순수한 .NET POCO 코드로 다시 쓰거나 마감일을 놓치면 상황이 매우 나빠질 수 있습니다.

OLEDB 어댑터 및 SQL Adapaters를 사용하여 순수한 .NET 코드로 12 시간 이내에 3 개의 SSIS 패키지 (테스트 및 개발에 2 개월이 걸렸습니다)를 다시 작성할 수 있다는 사실에 놀랍습니다.

SSIS는 배포 할 수 없으며 클라이언트 컴퓨터에 SQL Server 라이센스가 설치되어 있지 않은 경우 (특히 DTSPipeline.dll) 클라이언트 컴퓨터에서 패키지를 실행하지 않습니다. 미리 알아두면 좋을 것입니다. MSDN에 고지 사항이 표시됩니다 (세부 사항). SQL-LICENSED 머신 전용 코드를 사용하여 인터넷 전체에 예제 코드가있는 경우에는 좋지 않습니다. 기본적으로 SSIS 패키지를 프로그래밍 방식으로 실행하려면 SQL 서버와 통신 할 웹 서비스를 만들어야합니다. 실행 머신에 SQL 라이센스가 설치되어 있지 않으면 순수 .NET 코드에서 실행할 수 없습니다. 비현실적입니까? Microsoft는 실제로 SQL 서버 설치가 필요한 시스템에서 SSIS를 사용할 것으로 예상합니까? 두 달의 완전한 낭비.

우리 회사는이 작은 글씨 "gotcha"때문에 SSIS를 다시는 사용하지 않을 것입니다.

배포 메커니즘 / 모델을 가능한 빨리 정의하지 않았습니다.

'재미있는'부활절 달걀을 2 주 동안 휴가를 가기 전에 쓴 코드에 던졌습니다. 나는 내가 돌아 왔을 때 그것을 읽을 수있는 유일한 사람이라고 생각했다.

말할 필요도없이, 제 상사는 제가 자리를 비운 동안 그것을 검토했을 때 감명받지 않았으며, '동부 알'중 하나가 ASCII로 재미있게 만화 화 된 그의 얼굴과 관련되었을 때 감명받지 않았습니다.

음 ...

일반적인 ol 'CSS 폴더에 ASP.Net 테마를 사용하면 정상적으로 작동합니다.

올바른 길이 아닌 일부 코드가 작동하도록 빠른 길을 가십시오 (일반적인 것이지만이를 추상화하고 따라서 '올바른'답변이라고합니다).

우리 회사에는 폭포 형 개발 모델이 있으며, 비즈니스 사용자와 비즈니스 분석가가 프로젝트 요구 사항을 정의합니다. "큰"프로젝트 중 하나에서 요구 사항 스택을 얻었으며 구현 요구 사항 , 특히 회계 시스템에서 사용하는 데이터베이스 스키마와 관련된 정보가 포함 된 여러 요구 사항을 발견했습니다 .

비즈니스 사용자에게 구현이 내 도메인이라고 설명했으며 요구 사항에 포함되어서는 안됩니다. 그들은 결국 비즈니스이기 때문에 요구 사항을 바꾸고 싶지 않았으며, 회계사가 회계 소프트웨어를 설계하는 것이 합리적입니다. 토템 여론 조사가 너무 낮은 저개발 개발자로서, 나는 think 대신에 지불 해야 합니다 . 내가 싸운만큼 요구 사항을 다시 작성하도록 설득 할 수 없었습니다. 너무 많은 번거 로움을주는 변경 사항에 너무 많은 서류와 빨간 테이프가 있습니다.

그래서 나는 그들이 요청한 것을 주었다. 최소한 그것은 작동 하지만 데이터베이스는 이상하게 설계되었습니다.

• 불필요한 정규화가 많이 있습니다. 5 개 또는 10 개의 필드를 포함하는 단일 레코드가 3 개 또는 4 개의 테이블로 분할됩니다. 나는 그것을 다룰 수 있지만 개인적으로 모든 1 : 1 필드를 단일 테이블로 가져오고 싶습니다.

• 부적절한 비정규 화가 많습니다. 송장 데이터보다 많은 송장 데이터를 저장하는 테이블이 있습니다. 플래그가 InvoiceData 테이블과 논리적으로 관련되지 않은 경우에도 InvoiceData 테이블에 여러 가지 기타 플래그를 저장합니다. 각 플래그에는 매직, 하드 코딩 된 기본 키 값 및 InvoiceData 테이블에서 널로 지정된 다른 모든 필드가 있습니다. 플래그는 테이블에서 레코드로 표시되므로 플래그를 자체 테이블로 가져 오는 것이 좋습니다.

• 보다 부적절한 비정규 화가 많이 발생합니다. 특정 앱 전체 플래그는 부적절한 테이블에 열로 저장되므로 앱 플래그를 변경하면 테이블의 모든 레코드를 업데이트해야합니다.

• 기본 키에는 메타 데이터가 포함되어 있습니다. varchar 기본 키가 "D"로 끝나는 경우 한 세트의 값을 사용하여 송장을 계산하고, 그렇지 않으면 다른 세트로 계산합니다. 이 메타 데이터를 별도의 열로 가져 오거나 값 세트를 가져와 다른 테이블로 계산하는 것이 더 합리적입니다.

• 외래 키는 종종 두 개 이상의 테이블로 이동하므로 "M"으로 끝나는 외래 키는 모기지 계정 테이블에 연결될 수있는 반면 "A"로 끝나는 외래 키는 자동 계정 테이블에 연결될 수 있습니다. MortageData와 AutoInsuranceData의 두 테이블로 데이터를 분할하는 것이 더 쉬울 것입니다.

나의 모든 제안은 많은 울부 짖음과 치아의 뭉개 짐으로 격추되었다. 이 앱은 설계된대로 작동하며 큰 진흙 덩어리 인 반면 모든 불쾌한 해킹, 특수 사례 및 이상한 비즈니스 규칙은 냉소적으로 유머러스하게 소스 코드에 문서화됩니다.

클라이언트가 새로운 .NET 프레임 워크 버전으로 업그레이드하기에는 너무 번거롭기 때문에 이전 기술을 고수하지만 실제로는 일부 (시간 절약) 구성 요소를 사용할 수 없으므로 소프트웨어를 개발하는 데 더 많은 개발 시간이 필요합니다 최신 프레임 워크 버전.

대학으로 돌아가서 수석 디자인 프로젝트를하고있었습니다. 다른 남자와 나는 웹 기반 버그 추적 시스템을 작성하고있었습니다. 우리는 자바 서블릿으로 일을 해왔고 합리적으로 효과가 있었지만 약간의 이유 때문에 예외 처리를 오류 처리 메커니즘으로 사용하는 대신에 오류 코드를 사용합니다.

우리가 한 학년을위한 프로젝트를 발표했을 때 교수 중 한 명이 불가피한 질문을했습니다. "다시 해봐야한다면 어떻게해야합니까?" 나는 즉시 답을 알았습니다. "예외를 사용하겠습니다. 그것이 바로 거기에 있습니다."

내가 선택한 방법은 아니지만 행 기반 XML 파일을 열 기반 HTML 보고서로 변환하기 위해 XSLT를 만들었습니다.

IE에서만 작동했으며 작동 방식을 완전히 해독하는 것은 불가능했습니다. 우리가 그것을 확장해야 할 때마다, 엄청나게 어려웠고 나이가 들었습니다.

결국, 나는 같은 일을 한 작은 C # 스크립트로 대체되었습니다.

필요하더라도 신기술을 배우기 위해 모든 신기술을 사용하려고 노력하는 것

비즈니스 모델을 평가할 시간이 충분하지 않았습니다. 나는 고객이 요청한 것을했지만 6-12 개월 후에 우리는 다르게해야한다는 결론에 도달했습니다.

사양이없는 설계

요구 사항에 따라 응용 프로그램의 하위 섹션을 구현했습니다.

요구 사항이 부풀어 오르고 금도금되었으며 내 코드가 과도하게 설계되었습니다. 당시에 추가 한 내용 만 작업 할 수 있도록 하위 섹션을 설계했지만 처음부터 일반 지원을 포함하지 않고 다른 모든 항목을 추가 할 계획입니다.