다른 프로그래머들에게 의존성을 극명하게 만드는 프로그래밍 패러다임이 있습니까?


26

다양한 아티팩트를 연결하는 미로와 같은 종속성을 가진 여러 스트림과 계층을 통해 여러 시스템을 소스로 제공하는 데이터웨어 하우스에서 작업합니다. 거의 매일 나는 다음과 같은 상황에 처하게됩니다 : 나는 무언가를 실행하고, 작동하지 않고, 많은 코드를 겪지 만 몇 시간 후에 나는 내가 아는 것의 작은 부분에 대한 프로세스 맵을 개념화 할 수 있음을 깨달았습니다. 나중에 하루가 필요하므로 누군가에게 물어 보고이 스트림을 먼저 실행해야한다고 말하고 여기에서 확인 하면 (다른 코딩 된 종속성의 거대한 스택 중 일부로 보이는 임의의 부분을 나타냄) 이것을 보았다. 엄청나게 실망 스럽습니다.

만약 팀에게 재귀 수준의 코드 나 심지어는 데이터에 깊이 포함시키지 않고 객체들 간의 의존성을보다 가시적이고 명확하게하기 위해 더 많은 노력을 기울 였다면 아마도 좋은 생각 일 것입니다. 잘 알려진 시도되고 테스트 된 소프트웨어 패러다임을 참조하여 다른 스트림에 의해 채워져 있기 때문에 존재해야합니다. 그러면 내 업무와 다른 모든 사람들이 훨씬 간단해질 수 있습니다.

이것의 이점을 우리 팀에 설명하는 것은 어렵습니다. 그들은 전체 시스템을 새로운 방식으로 개념화 할 수있는 이점을 보는 관점에서 현재의 방식대로 물건을 받아들이고 '큰 생각'을하지 않는 경향이 있습니다. 그들은 거대한 시스템을 모델링 할 수 있다면 실제로 그것을 보지 못합니다 이를 통해 효율적으로 메모리 비 효율성, 고유 제한 조건의 스트림 중지 및 키 복제, 무의미한 데이터를 경험할 가능성이 줄어 듭니다. 원래 비전에 맞게 설계하기가 훨씬 쉽고 나중에 이러한 모든 문제가 발생하지 않기 때문입니다. 우리는 지금 경험하고 있는데, 과거의 직업과는 다른 것이지만 필연적이라고 생각합니다.

그렇다면 누구나 의존성을 강조하고 이상적인 이상적인 시스템 준수를 보장하기 위해 시스템의 일반적인 개념 모델을 홍보하는 소프트웨어 패러다임을 알고 있습니까? 현재 우리는 큰 혼란을 겪고 있으며 모든 스프린트는 "이것과 여기 저기 여기에 추가"하는 것처럼 보이며 나는 실제로 사물이 떨어지기 시작하는 것에 대해 걱정하는 유일한 사람입니다.


2
"다양한 아티팩트를 연결하는 미로 같은 의존성"의 종류를 분명히 설명해 주시겠습니까? 그것들은 Maven과 같은 빌드 도구로 해결할 수있는 빌드 종속성입니까? 그것들은 입력 의존성인데, 이러한 인공물 중 하나가 명확하지 않거나 분명하지 않은 입력에 의존합니까? 데이터베이스 테이블 간의 주요 종속성입니까?
FrustratedWithFormsDesigner

시스템은 PLSQL, Unix bash, OWB 등이므로 모든 종류의 종속성이 있습니다. 때로는 특정 형식, 특정 장소, 특정 모듈에서 특정 형식의 데이터가 필요하지만 코드에서 원격으로 명확하지 않고 코드의 산을 통과하여 두 가지 방법으로 만 식별 할 수 있습니다. 아마도 일부 데이터에는 시스템의 일부에 구분되는 세미 콜론이 있음을 알기 위해 재귀 적으로 호출 된 코드의 10 층에 묻혀 있기 때문에 참조되고 있거나 다른 사람에게 매번. 독립을 장려하지 않습니다.
Christs_Chin

4
말 그대로 그들 모두
Miles Rout

3
작은 접선 : Haskell이 게으 르기 때문에 코드를 작성할 때 작업 순서를 효과적으로 지정하지 않습니다. 종속성 만 지정하십시오. 함수 C는 함수 A와 B의 결과에 따라 다릅니다. 따라서 A와 B는 C보다 먼저 실행되어야하지만 A가 먼저 실행되거나 B가 먼저 실행되면 동일하게 작동 할 수 있습니다. 방금 흥미 롭다고 생각했습니다.
GlenPeterson

1
디자인 패턴이라는 책이 있습니다 (책은 짜증나지만 싱글 톤에 대한 부분을 제외하고는 대부분 말이 좋습니다). 종속성 관리에 대한 여러 섹션이 있습니다.
ctrl-alt-delor

답변:


19

발견 가능성

그것의 부재는 많은 조직을 괴롭 힙니다. Fred가 다시 만든 도구는 어디에 있습니까? Git 리포지토리에서 확인하십시오. 어디에?

떠오르는 소프트웨어 패턴은 Model-View-ViewModel입니다. 처음에는이 패턴이 완전한 미스터리입니다. 나는 그것을 아내에게 "신비한 힘을 통해 서로 대화하는 탁자 위에 떠있는 5 개의 위젯"이라고 설명했다. 패턴을 이해하고 소프트웨어를 이해합니다.

많은 소프트웨어 시스템은 자체 설명이 필요하거나 코드에서 자연스럽게 나온다고 가정하기 때문에 아키텍처를 문서화하지 못합니다. 그렇지 않습니다. 잘 정의 된 아키텍처를 사용하지 않으면 새로운 사람들이 길을 잃을 것입니다. 문서화되지 않은 (또는 잘 알려진) 새로운 사람들은 길을 잃을 것입니다. 그리고 몇 달 동안 코드에서 벗어난 퇴역 군인들도 길을 잃을 것입니다.

합리적인 조직 구조를 마련하고 문서화하는 것은 팀의 책임 입니다. 여기에는 다음과 같은 것들이 포함됩니다

  • 폴더 구성
  • 프로젝트 참조
  • 클래스 문서 (무엇을, 무엇을, 그것이 존재하는지, 어떻게 사용하는지)
  • 프로젝트, 모듈, 어셈블리 등 모든 문서

팀이 지속적으로 바퀴를 재발 명하지 않도록 물건을 구성하고 발견 할 수있게하는 것은 팀의 책임입니다.

그런데, "코드는 자체 문서화되어야한다"는 개념은 부분적으로 만 정확합니다. 주석으로 모든 코드 줄을 설명 할 필요가 없도록 코드가 명확해야한다는 것은 사실이지만 클래스, 프로젝트, 어셈블리, 인터페이스 등과 같은 아티팩트 간의 관계는 명백하지 않으며 여전히 문서화해야합니다.


3
그러나 디자인 패턴에 너무 의존하는 사람들은 문제의 일부입니다. 그들은 문서를 보지 않고 코드를 작성하는 사람들입니다. 다른 사람들은 코드를 보면서 자신이 무엇을했는지 이해할 것이라고 가정합니다. 또한 소프트웨어 디자인 패턴은 아키텍처가 아닙니다 (대부분의 경우).
Robert Harvey

1
Fred가 다시 만든 도구는 어디에 있습니까? Git 리포지토리에서 확인하십시오. 어디에? -맞아! MVC 패턴은 프론트 엔드 개발에 너무 구체적이며 패턴은 팀의 모든 사람이 알고있는 경우에만 유용하므로 문제가 명확하지 않은 종속성에서 명백하게 드러납니다. 그들. 그러나 문제는 이것이 사실이 아니라고 전제합니다. 따라서 나는 당신이 사용할 다른 학습 된 개념적 프레임 워크가 필요하지 않은 종속성을 설명하는 확실한 방법을 홍보하기를 희망합니다.
Christs_Chin

7
이것을 "문서"라고합니다. 그 외에도 모든 사람이 지원하는 합리적인 종속성 프레임 워크가 필요합니다. 불행히도 프로젝트에 드롭 할 수있는 상용구 템플릿이 없습니다. 소프트웨어의 조직 구조는 현명한 아키텍처의 도움으로 팀 자체가 만들어내는 것입니다.
Robert Harvey

5
@RobertHarvey : 최근에 들었습니다. "문서가 필요없는 코드를 작성합니다." 잘못된. 설명서없이 코드를 작성하고 있습니다.
gnasher729

3
여기 좋은 것들이 있습니다. NB는 주석이 필요없는 코드 작성 과 지원 문서 작성에 차이가 있습니다.
Robbie Dee

10

이러한 종류의 문제에 접근하는 가장 좋은 방법은 점진적입니다. 좌절하지 말고 폭 넓은 건축 변경을 제안하십시오. 그것들은 결코 승인되지 않으며 코드는 결코 개선되지 않을 것입니다. 그것은 당신이 할 수있는 올바른 넓고 쓸만한 아키텍처 변경을 결정할 수 있다고 가정합니다.

무엇 이다 가능성은 방금 해결 특정 문제가 당신을 도움이 것이 작은 변화를 결정할 수 있다는 것입니다. 의존성 반전, 문서 추가, 인터페이스 생성, 의존성 누락 경고 스크립트 작성 등을 제안 할 수 있습니다. 대신 작은 변화를. 더 나은 점은 회사 문화에 따라 원래 작업의 일부로 그러한 개선을 허용하거나 심지어 기대할 수도 있습니다.

이러한 작은 변화를 작업의 정기적 인 부분으로 만들고 예를 들어 다른 사람들도 그렇게하도록 격려하면 시간이 지남에 따라 실제로 더해집니다. 허용되지 않는 하나의 큰 변경 사항을 고집하는 것보다 훨씬 효과적입니다.


2
증분 변경이라는 아이디어에 동의합니다. 문제는 이미 조직의 일부 원칙이 없다면 혼란을 더 많이 만들 수 있다는 것입니다. 단일 프로젝트, 클래스 또는 기타 아티팩트 (다른 ​​모듈이 의존하는)를보다 합리적인 위치로 이동시키는 효과를 고려하십시오.
Robert Harvey

1
좋은 물건. 저의 수고는 종종 부지런한 영혼들에 의해 덜 어려워 졌는데, 여기에는 혼돈으로부터 질서를 만들기 위해 도구 / 위젯을 추가하는 데 어려움이 있습니다. 나는 다량의 문서와 다량의 종이를 좋아하지는 않지만, 잘 쓰여진 치트 시트 나 글 머리 기호로 된 문제 / 기능 목록이 크게 도움이 될 수 있습니다.
로비 디

승인 될 가능성이있는 작은 변경 사항을 제안하면 +1입니다. 나는 그것을 경험했고 그것은 더 많은 영향력을 가진 사람이되는 데 도움이되었고, 그 후 나의 제안은 더 많은 영향을 미쳤다.
RawBean

2

건축물.

모든 소프트웨어의 모든 측면에 적용되는 검색 가능성 및 유지 관리 가능성 문제를 해결하는 단일의 구체적이고 보편적 인 원칙 또는 관행은 없습니다. 그러나 프로젝트를 제정신으로 만드는 것의 광범위한 용어 는 아키텍처입니다.

아키텍처는 아키텍처 결정이 내려지고 문서화되는 방법의 지정을 포함하여 잠재적 (또는 역사적) 혼란의 각 지점을 중심으로 한 의사 결정의 전체입니다. 개발 프로세스, 폴더 구조, 코드 품질, 디자인 패턴에 관한 모든 것, 등등 갈 수있는 모든 것들 아키텍처,하지만 그들 중 하나 입니다 아키텍처가.

이상적으로는 이러한 규칙이 단일 한 마음으로 통합됩니다 .

소규모 팀은 확실히 협업을 통해 아키텍처를 만들 수 있습니다. 그러나, 다양한 의견과 함께, 이것은 빠르게 이어질 수있는 매우 당신의 정신을 유지하는 역할을하지 않는 정신 분열증 아키텍처. 아키텍처와 그 내부의 많은 TLA 및 패턴이 모두 단일 한 마음으로 팀의 성공을 이룰 수 있도록하는 가장 간단한 방법 은 단일 마음이 그들에게 책임을 지도록하는 것입니다.

자, 그 필요에 "건축가"필요하지 않습니다 교황을 . 또한 일부 팀은 숙련 된 사람이 이러한 결정을 내리기를 원할 수 있지만, 가장 중요한 요점은 특히 팀이 성장함에 따라 누군가 가 아키텍처를 소유해야한다는 것입니다. 누군가 팀의 맥박을 잡고, 건축 토론을 중재하고, 의사 결정을 문서화하고, 의사 결정을 모니터링하고 아키텍처와 그 정신을 준수하기 위해 앞으로 노력합니다.

나는 모든 사람이 모든 결정을 내리는 것을 좋아하지 않습니다. 하지만,에 "건축가"또는 건축 토론을 완화하고 의사 결정을 문서화하기위한 책임이있다 "기술 제품 소유자"를 식별하는 더 큰 악을 억제한다 : 책임의 확산 것과 리드 전혀 식별 할 수있는 구조.


식별 가능한 아키텍처가없는 책임의 확산을 식별하는 데있어 절대적으로 정확합니다. 최근이 문제를 해결하기위한 결정이 내려졌습니다. 나는 항상 이것에 대한 좋은 해결책은 일종의 하네스 역할을하는 다른 소프트웨어 시스템을 통해 전체 분산 시스템을 만드는 것이라고 생각합니다. 시스템에 무엇이 들어가는 지 결정하지만 건축가가 프로그래밍하는 방법에 따라 어디에 있는지 결정합니다. 여러 가지 다른 시스템과 기술에 대한 하나의 견해를 갖고 일부 시스템 아키텍처 다이어그램을 통해 탐색 할 수 있습니다.
Christs_Chin

이 답변에서 귀하의 요점은 OP가 말하고있는 유형의 유형을 퇴치 / 예방하는 가장 좋은 방법이라고 생각합니다. OP와 마찬가지로 엉망 상속에도 적용됩니다.
GWR

1

소프트웨어 공학에 오신 것을 환영합니다 (두 가지 의미에서);) 이것은 좋은 질문이지만, 여러분이 알고있는 것처럼 쉬운 대답은 없습니다. 시간이 지남에 따라 더 나은 관행으로 발전하여 사람들이 더 능숙하게 훈련하는 경우입니다 (정의상 업계의 대부분의 사람들은 평범한 역량입니다).

학문으로서의 소프트웨어 엔지니어링은 먼저 그것을 구축하고, 편의성 및 필요성에 따라 사고 방식으로 설계해야합니다. 그것은 짐승의 본성 일뿐입니다. 물론 앞서 언급 한 코더가 기술 부채를 도입하는 비용으로 단기간에 필요한 기능을 신속하게 해결하는 기능 솔루션을 신속하게 배치함에 따라 해킹은 시간이 지남에 따라 해킹됩니다.

사용해야하는 패러다임은 본질적으로 더 나은 사람을 확보하고, 잘 지내고있는 사람들을 훈련 시키며, 계획 및 아키텍처보다 시간이 걸리는 것의 중요성을 강조하는 것입니다. 모 놀리 식 시스템으로 작업 할 때 쉽게 "민첩한"사람이 될 수는 없습니다. 약간의 변경이라도 적용하려면 상당한 계획이 필요할 수 있습니다. 훌륭한 고급 문서화 프로세스를 구축하면 주요 사람들이 코드를보다 빨리 파악할 수 있습니다.

집중할 수있는 아이디어는 시스템의 핵심 부분을 모듈화되고 분리되고 읽기 쉽고 유지 보수가 가능한 방식으로 (시간이 지남에 따라 점차적으로) 분리 및 리팩토링하는 것입니다. 비결은 현존하는 비즈니스 요구 사항에 따라 작동하므로 가시적 인 비즈니스 가치를 제공하는 동시에 기술 부채를 줄일 수 있습니다. 따라서 해결책은 부분적으로는 실무와 기술을 향상시키고 부분적으로 장기 아키텍처 사고로 나아가려고 노력하는 것입니다.

코딩 기술 관점보다는 소프트웨어 개발 방법론 관점에서이 질문에 대한 답을 얻었으므로 실제로 이것은 코딩의 세부 사항이나 건축 스타일보다 훨씬 큰 문제이기 때문입니다. 실제로 변화를 계획하는 방법에 대한 질문입니다.


6
나는 당신이 말하는 것을 들었지만, 당신의 대답은 궁극적으로 불만족스럽고 솔직히 약간 모욕적입니다. 더 나은 사람들을 고용하는 것보다 더 큰 문제입니다. 내가 일하는 작은 상점에서도 우리는이 문제로 어려움을 겪고 있으며 이는 단순한 사람들의 문제가 아니라고 생각합니다. 특정 기술적 어려움이 있다고 생각합니다.
Robert Harvey

1
기술적 인 측면이 있다는 데 동의하지만 변화를 계획하기위한보다 강력한 방법론에 중점을 둔 것에 비하면 상대적으로 미미하다고 생각합니다. 나는 이것이 더 많은 계획 및 분석, 초기 계획 및 분석, 더 나은 계획 및 분석 으로의 문화적 전환만큼이나 디자인 패턴에 관한 것으로 보지 않습니다 .
브래드 토마스

좋아, 나는 내 자신의 답변을 비교로 게시 할 것입니다. 나는 그것이 있다고 생각하지 않습니다 아무것도 소프트웨어 패턴 할 수 있습니다.
Robert Harvey

브래드, 답변 주셔서 감사합니다. 이 문제에 대해 혼자 알고있는 것은 아닙니다. 우리 팀에서는 이렇게 보입니다. 또한 Robert Harvey에 동의합니다.이 문제는 널리 퍼져 있으며 새로운 유형의 소프트웨어 나 새로운 작업 방식에 해결책이 있다는 믿음을 포기하고 싶지 않습니다.
Christs_Chin

2
정확히 나의 경험 : 당신은 팀원들이 그들이하고있는 일을 이해하도록해야합니다. MVVM과 MVC를 혼합하는 사람들, WPF 컨트롤을 Windows Forms (또는 VB6)에서 일반적인 방식으로 사용하는 사람들, 객체 지향에 대한 기본적인 이해없이 C #으로 프로그래밍하는 사람들을 봅니다 ... 다시 가르쳐주세요. 좌절하십시오. 그들에게 다시 가르치십시오 ... 종종 포기할 생각. 그리고 그들을 다시 가르치는 ...
Bernhard Hiller

1

나는 @RobertHarvey의 관습에 대한 아이디어를 좋아하고 그들이 도움이된다고 생각합니다. 또한 @KarlBielefeldt의 아이디어가 "당신이 원하는대로 문서화"하는 것이 좋으며, 이것이 문서를 최신 상태로 유지할 수있는 유일한 방법이기 때문에 이것이 필수적이라는 것을 알고 있습니다. 그러나 가장 중요한 아이디어는 코드의 모든 부분을 찾고 빌드하고 배포하는 방법을 문서화하는 것이 중요하다는 것입니다.

최근에 코드를 생성하는 XML 구성이 완전히 문서화되지 않은 중요한 오픈 소스 프로젝트를 이메일로 보냈습니다. 관리자에게 "이 XML 코드 생성 프로세스는 어디에 문서화되어 있습니까? 테스트 데이터베이스 설정은 어디에 문서화되어 있습니까?" "그렇지 않아." 기본적으로 단일 기고자 프로젝트이며 이제 이유를 알고 있습니다.

당신이 그 사람이고 당신이 이것을 읽고 있다면, 나는 당신이 무엇을하고 있는지 정말 감사합니다. 나는 당신의 수고의 열매를 실제로 숭배합니다! 그러나 당신이 정말로 창조적 인 것들을 어떻게 구성하는지 문서화하는데 1 시간을 썼다면, 나는 당신을 도울 수있는 새로운 기능들을 코딩하는 데 며칠을 보낼 수도 있습니다. "문서 부족이 문제가되지 않는다"는 벽돌 벽에 직면했을 때, 나는 시도조차하지 않을 것이다.

비즈니스에서 문서 부족은 시간과 에너지를 낭비하는 것입니다. 이와 같은 프로젝트는 종종 더 많은 비용을 지불하는 컨설턴트에게 농사를 짓게됩니다. "모든 부분이 어디에 있으며 어떻게 결합되어 있는지"와 같은 기본 사항을 파악할 수 있습니다.

결론적으로

필요한 것은 기술이나 방법론이 아니라 문화의 변화입니다. 사물이 어떻게 구축되고 왜 중요한지를 문서화한다는 공동의 신념. 코드 검토의 일부 여야하며 프로덕션으로 이동하기위한 요구 사항은 인상과 관련이 있습니다. 모두가 그것을 믿고 그에 따라 행동하면 상황이 바뀔 것입니다. 그렇지 않으면 실패한 오픈 소스 기여와 같습니다.


2
문화 문제의 일부는 "사용자 스토리의 일부가 아닌 경우 (즉, 이해 관계자 가치에 직접 기여하지 않는 경우) 중요하지 않다"는 민첩한 믿음에 있다고 생각합니다. 호그 워시. 관련 대화 : 민첩하게, 프로젝트 시작시 기본 인프라 작업은 어떻게 계획되고 할당됩니까?
Robert Harvey

@RobertHarvey 예. 우리 팀의 모든 사람들은 믿을 수 없을만큼 밝고 쉽게 갈 수 있습니다. 스크럼 마스터와 프로젝트 관리자는 의도가 좋으며 주도적이며 관행은 내가 일한 가장 민첩합니다. 그러나 아마도 당신이 제안한 바로 그 이유 때문에 문서가 부족합니다. 또한 문서가 작성 될 때 의사 소통의 효과에있어 무작위성 (randomity)의 의사 소통의 층이 도입되어 해당 개념을 식별하고 설명 할 수 있으며 그러한 과제를 수행해야한다는 태도는 말할 것도 없다. 일반적으로 그것은 단지 "somone"입니다
Christs_Chin

@GlenPeterson 예, 이것이 도움이 될 것에 동의합니다. 그러나 그것이 구축되어야 할뿐만 아니라 문서로서 어떻게 그리고 자격을 갖추어야 하는지를 명시해야한다. 예를 들어 최근의 예에서 누군가 시스템에서 식별 할 수있는 새로운 번호 목록을 포함 시켰습니다. 그게 다야. 이 숫자들이 어떻게 시스템에 들어가는 지, 어디에, 왜, 누구에 의해, 얼마나 자주 또는 유용한 지에 대한 언급은 없었습니다. 어느 시점에서 우리 시스템이 어떤 숫자로 관련성이 있는지 궁금해하지 않았습니다. 그러나 나는 종종 그들이 어디로 들어가고, 어디로 가고, 어떻게되는지 궁금해했다. 여전히 미스터리입니다.
Christs_Chin

1
@Christs_Chin 많은 의사 소통은 맥락에 기초합니다. 이러한 맥락이 없으면 대부분의 커뮤니케이션은 거의 의미가 없습니다. 네 아픔이 느껴져. 그러나 나는 다른 사람들이 당신을 이해할 수 있도록 글을 쓰는 것이 어렵다고 생각합니다. 때때로 시스템의 초기 사양에는 끔찍한 구식이더라도 이해해야 할 맥락이 있으며, 일반적으로 상황에 도움이됩니다.
GlenPeterson

1

특정 상황에 대한 조언을 제공하지 않고 제기 된 질문에 답변하려면 :

순수 기능 프로그래밍 으로 알려진 프로그래밍 패러다임 은 함수의 출력에 영향을 미치는 모든 것을 입력 매개 변수에 지정해야합니다. 숨겨진 의존성이나 전역 변수 또는 코드 기반에서 보이지 않게 작용하는 다른 신비한 힘은 없습니다. "먼저이 작업을 수행해야합니다"시간적 연결이 없습니다.


0

각 데이터웨어 하우스는 다르지만 더 쉽게 작업 할 수 있도록 할 수있는 작업이 많이 있습니다.

우선, 데이터베이스의 모든 행에는 DATE_ADDEDDATA_UPDATED 열이 있으므로 데이터베이스에 추가 된시기와 변경된시기를 확인할 수 있습니다. 또한 SOURCE_CODE 열이있어서 모든 데이터 비트가 시스템에 입력 된 위치를 추적 할 수 있습니다.

다음으로 정렬, 테이블 일치, 슬라이서 및 dicers와 같은 모든 데이터웨어 하우스에서 실행되는 공통 도구가있었습니다.

맞춤형 코드는 최소한으로 유지 된 후에도 다양한 코딩 및보고 스타일을 확인해야했습니다.

ETL 제품군에 대해 이미 잘 알고 있다고 가정하겠습니다 . 요즘 약 10 년 전에 게임에있을 때는 없었던 많은 기능들이 요즘 무료로 제공됩니다.

보다 친숙하고 위생 화 된 버전의 데이터웨어 하우스를 제공하기 위해 데이터 마트 를 살펴볼 수도 있습니다 . 물론 은색 총알은 아니지만 데이터웨어 하우스를 재구성 / 수정하는 대신 특정 문제를 해결하는 데 도움이 될 수 있습니다.


응답 주셔서 감사합니다. 예, 우리는 이러한 모든 필드를 사용하지만 스트림, 레이어 및 시스템 간의 종속성이 아니라 단일 행의 식별 만 지원합니다. 당신은 ETL 제품군에 대해 맞습니다. 우리는 지원이 중단되었지만 대신 PLSQL로 돌아가는 잘 알려진 ETL 도구로 업그레이드하는 중이었습니다. 코드를 작성하는 것은 좋지만 유지 관리 성과 코드 수준에서 전체 시스템을 이해하는 것은 절대적으로 끔찍합니다.
Christs_Chin

1
스테이징 테이블이나 플랫 파일을 통해 데이터를 엔드 투 엔드로 추적 할 수있는 것이 가장 이상적입니다.
Robbie Dee

0

귀하의 사례와 얼마나 관련성이 있는지 모르겠습니다. 종속성을보다 가시적이고 일반적인 코드 유지 관리로 만드는 몇 가지 전략이 있습니다.

  • 전역 변수를 피하고 대신 매개 변수를 사용하십시오. 이것은 언어 간 통화에도 적용됩니다.
  • 변수 값을 가능한 많이 변경하거나 변경하지 마십시오. 가능하면 값을 변경해야 할 때 새 변수를 만들고 사용하십시오.
  • 코드를 모듈화하십시오. 간단한 문장으로 실제로 어떤 부분을하고 있는지 설명 할 수 없다면 조건을 만족하는 모듈로 나누십시오.
  • 코드 부분의 이름을 올바르게 지정하십시오. 코드의 일부를 간단한 용어로 실제로 설명 할 수 있으면 해당 용어는 해당 부분의 이름이됩니다. 따라서 코드는 모듈 / 클래스 / 함수 / 프로 시저 / 방법 등의 이름을 통해 자체 문서화됩니다.
  • 코드를 테스트하십시오. 코드의 엔티티가 이전 포인트에서 설명한대로 이름을 정당화하는지 테스트하십시오.
  • 코드에 이벤트를 기록하십시오. 최소한 두 가지 수준의 로그를 유지하십시오. 첫 번째는 항상 활성화되어 있으며 (생산 중일지라도) 중요한 이벤트 만 기록합니다. 다른 하나를 사용하여 기본적으로 모든 것을 기록하지만 켜거나 끌 수 있습니다.
  • 적절한 도구를 찾아 사용하여 코드베이스를 탐색, 유지 관리 및 개발하십시오. Visual Studio Code의 간단한 "모든 검색"옵션조차도 특정 경우에있어 내 삶을 훨씬 쉽게 만들어주었습니다.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.