나는 이것이 일반적인 질문이 아니기를 바란다. 나는 노련한 조언을 실제로 사용할 수 있습니다.

저는 지난 10-20 년 동안 방대한 코드 기반을 함께 사용했던 상당히 작은 과학자 상점에서 유일한 "SW 엔지니어"로 새로 고용되었습니다. (이것은 거의 쓸모없는 언어로 작성되었습니다 : G2- 그래픽으로 파스칼을 생각하십시오). 프로그램 자체는 복잡한 화학 처리 공장의 물리적 모델입니다. 이를 작성한 팀은 엄청나게 깊은 영역 지식을 가지고 있지만 프로그래밍 기초에 대한 공식 교육은 거의 또는 전혀 없습니다. 그들은 최근에 존재하지 않는 구성 관리의 결과에 대한 몇 가지 어려운 교훈을 배웠습니다. 코드 자체에 문서화되지 않은 "슬러지"가 엄청나게 축적되어 유지 관리 노력도 크게 방해받습니다. 나는 당신에게 상황의 "정치"를 절약 할 것입니다 ( 항상 정치!), 그러나 앞으로 나아 가기 위해 무엇이 필요한지에 대한 의견에 대한 합의는 없습니다.

그들은 현대 소프트웨어 개발의 몇 가지 원칙을 팀에 제시하기 시작했습니다. 코딩 규칙, 수명주기 관리, 고급 디자인 패턴 및 소스 제어와 관련된 업계 표준 사례 및 전략을 소개하고자합니다. 솔직히 말해서, 그것은 어려운 작업이며 어디서부터 시작 해야할지 모르겠습니다.

처음에는 Pragmatic Programmer 또는 Fowler 's Refactoring ( "Code Smells"등) 의 핵심 개념 중 일부를 학습하는 경향이 있습니다 . 또한 여러 민첩한 방법론을 소개하고자합니다. 그러나 궁극적으로 효과적이기 위해서는 5-7 개의 핵심 기본 사항을 연마해야한다고 생각합니다. 다시 말해, 현실적으로 구현을 시작할 수있는 가장 중요한 원칙이나 관행은 무엇이 가장 "벅"입니다.

이것이 저의 질문입니다 : 스파게티를 펴는 데 도움이되는 가장 효과적인 전략 목록에 무엇 을 포함 하시겠습니까?

머리말

이것은 참으로 어려운 일이며, 다루어야 할 근거가 많이 있습니다. 적절한 도구와 교육 자료에 대한 포인터와 함께 팀을위한 다소 포괄적 인 가이드로 겸손히 제안합니다.

다음 사항을 기억하십시오 : 이 지침 은 상황에 따라 채택, 조정 또는 폐기하기위한 것입니다.

주의 : 한 번에 팀에이 모든 것을 덤프하면 실패 할 가능성이 높습니다. 땀에 가장 잘 걸리는 요소를 선택하고 한 번에 하나씩 천천히 소개해야합니다.

참고 : 이 모든 것이 G2와 같은 Visual Programming Systems에 직접 적용되는 것은 아닙니다. 이를 처리하는 방법에 대한 자세한 내용 은 끝에 있는 부록 섹션을 참조하십시오 .

참을성이없는 사람을위한 행정상 개요

• 다음과 같이 견고한 프로젝트 구조를 정의하십시오 .
  • 프로젝트 템플릿 ,
  • 코딩 규칙 ,
  • 익숙한 빌드 시스템 ,
  • 인프라 및 도구에 대한 사용 지침 세트 .
• 좋은 SCM을 설치하고 사용 방법을 알고 있는지 확인하십시오.
• 기술 에 적합한 IDE 를 가리키고 사용법을 알고 있어야합니다.
• 빌드 시스템에서 코드 품질 검사기 및 자동보고 기능 을 구현 하십시오.
• 빌드 시스템을 지속적인 통합 및 지속적인 검사 시스템에 결합하십시오.
• 위의 도움으로 코드 품질 "핫스팟"을 식별 하고 리팩터링하십시오 .

이제 긴 버전의 경우 ...주의, 조심하십시오!

강성은 (종종) 좋다

강성은 종종 당신을 대항하는 힘으로 여겨지기 때문에 이것은 논란의 여지가 있습니다. 일부 프로젝트의 일부 단계에 해당됩니다. 그러나 일단이를 추측을 없애는 프레임 워크 인 구조적 지원으로 간주하면 낭비되는 시간과 노력을 크게 줄일 수 있습니다. 당신을 대항하지 말고 당신을 위해 일하도록하십시오.

강성 = 프로세스 / 프로 시저 .

소프트웨어 개발에는 화학 공장이나 공장에 매뉴얼, 절차, 드릴 및 비상 지침이있는 것과 동일한 이유로 올바른 프로세스와 절차가 필요합니다. 나쁜 결과 방지, 예측 가능성 증가, 생산성 극대화 ...

그러나 강성은 적당히 온다!

프로젝트 구조의 강성

각 프로젝트에 고유 한 구조가있는 경우, 귀하 (및 신규 사용자)는 길을 잃을 수 있으며 프로젝트를 열 때마다 처음부터 다시 선택해야합니다. 당신은 전문 소프트웨어 상점에서 이것을 원하지 않으며 실험실에서도 이것을 원하지 않습니다.

빌드 시스템의 강성

각 프로젝트 가 다르게 보일 경우, 서로 다르게 구축 될 가능성이 높습니다 . 빌드에는 너무 많은 연구 나 추측이 필요하지 않습니다. 당신은 정규 일을하고 세부 사항에 대해 걱정할 필요가 없습니다 수 있도록하려면 : configure; make install, ant, mvn install, 등 ...

동일한 빌드 시스템을 재사용하고 시간이 지남에 따라 발전하게되면 일관된 품질 수준이 보장됩니다.

README프로젝트의 세부 사항을 신속 하게 지적하고 사용자 / 개발자 / 연구자 (있는 경우)를 정상적으로 안내해야합니다.

또한 빌드 인프라의 다른 부분, 즉 다음을 크게 촉진합니다.

• 지속적인 통합 ,
• 지속적인 검사 .

따라서 (프로젝트와 같은) 빌드를 최신 상태로 유지하지만 시간이 지남에 따라 더 엄격 해지고 위반 및 잘못된 관행을보고하는 데 더 효율적입니다.

바퀴를 다시 만들지 말고 이미 한 것을 재사용하십시오.

추천 자료 :

• 지속적인 통합 : 소프트웨어 품질 향상 및 위험 감소 (Duval, Matyas, Glover, 2007)
• 지속적인 제공 : 빌드, 테스트 및 배포 자동화를 통한 Sotware 릴리스 릴리스 (Humble, Farley, 2010)

프로그래밍 언어 선택의 강성

특히 연구 환경에서 모든 팀 (및 더 적은 개발자)이 동일한 언어 및 기술 스택을 사용하도록 기대할 수는 없습니다. 그러나 "공식적으로 지원되는"도구 세트를 식별하고 사용을 권장 할 수 있습니다. 좋은 이론적 근거가없는 나머지는 허용되지 않아야합니다 (프로토 타이핑 제외).

기술 스택을 단순하게 유지하고 필요한 기술의 유지 관리 및 폭을 최소한으로 유지하십시오 : 강력한 핵심.

코딩 규칙 및 지침의 강성

코딩 규칙 및 지침을 통해 팀으로서의 정체성과 공유 용어 를 개발할 수 있습니다 . 소스 파일을 열 때마다 terra incognita 에 실수하지 않습니다 .

단 한 번의 간단한 위반으로 커밋이 거부되는 정도로 삶을 어렵게하거나 금지하는 행동을 명백하게하는 무의미한 규칙은 부담입니다. 하나:

• 잘 생각 - 아웃 지상 규칙 집합은 징징 생각을 많이 빼앗아 : 아무도 어떠한 상황에서도 중단해서는 안;

• 일련의 권장 규칙은 추가 지침을 제공합니다.

개인적 접근 : 코딩 컨벤션에 있어서는 공격적입니다. 일부는 나치 라고도합니다 . 왜냐하면 저는 팀에서 인식 할 수있는 스타일 인 lingua franca 를 가지고 있다고 믿기 때문 입니다. 쓰레기 코드가 체크인되면 할리우드 스타의 얼굴에 찬 상처처럼 보입니다. 검토와 작업이 자동으로 트리거됩니다. 사실, 나는 종종 부적합 커밋을 거부하기 위해 사전 커밋 후크의 사용을 옹호하기까지했습니다. 앞에서 언급했듯이 지나치게 열광적이어서 생산성을 방해해서는 안됩니다. 특히 처음에 천천히 소개하십시오. 그러나 잘못된 코드를 수정하는 데 많은 시간을 소비하여 실제 문제를 해결할 수없는 것이 좋습니다.

일부 언어는 심지어 의도적으로 이것을 시행합니다

• Java는 당신이 쓸 수있는 둔한 쓰레기의 양을 줄 이도록 의도되었습니다 (물론 많은 사람들이 그것을 할 수는 있지만).

• 들여 쓰기에 의한 파이썬의 블록 구조는 이런 의미에서 또 다른 아이디어입니다.

• 그와 함께 가서 gofmt완전히 어떤 논쟁과 노력을 빼앗아 도구 ( 자아를! ) 스타일의 고유 : 실행 gofmt커밋하기 전에.

코드 썩음 이 미끄러지지 않도록하십시오 . 코드 컨벤션 , 지속적인 통합 및 지속적인 검사 , 페어 프로그래밍 및 코드 검토 는이 악마와의 대결입니다.

또한 아래에서 볼 수 있듯이 코드는 documentation 이며 이는 규칙이 가독성과 명확성을 장려하는 또 다른 영역입니다.

문서의 강성

문서는 코드와 함께 진행됩니다. 코드 자체는 문서입니다. 그러나 물건을 만들고 사용하고 유지하는 방법에 대한 명확한 지침이 있어야합니다.

문서에 단일 제어 지점 (예 : WikiWiki 또는 DMS)을 사용하는 것이 좋습니다. 프로젝트를위한 공간,보다 무작위적인 밴터 및 실험을위한 공간을 만듭니다. 모든 공간에서 공통 규칙과 규칙을 재사용하십시오. 그것을 팀 정신의 일부로 만들어보십시오.

코드 및 툴링에 적용되는 대부분의 조언은 문서에도 적용됩니다.

코드 주석의 강성

위에서 언급 한 코드 주석도 문서입니다. 개발자는 코드에 대한 느낌을 표현하는 것을 좋아합니다 (주로 요청하면 자부심과 좌절감). 따라서보다 공식적인 텍스트가 적은 표현이나 드라마로 동일한 의미를 전달할 수있을 때 주석 (또는 코드)으로 불확실한 용어로 이러한 용어를 표현하는 것은 드문 일이 아닙니다. 재미 있고 역사적인 이유로 몇 가지 이야기를 들려도 무방 합니다. 또한 팀 문화 를 발전시키는데도 도움이 됩니다. 그러나 모두가 수용 할 수있는 것과 수용 할 수없는 것을 아는 것이 매우 중요하며, 그 주석 소음은 바로 noise 입니다.

커밋 로그의 강성

커밋 로그는 SCM 수명주기의 성 가시고 쓸모없는 "단계"가 아닙니다. 정시에 집으로 돌아 오거나 다음 작업을 계속하거나 점심으로 떠난 친구들을 따라 잡기 위해 건너 뛰지 마십시오. 그것들은 중요하고, (대부분의) 좋은 와인과 같이 시간이 지날수록 가치가 높아집니다. 그러니 제대로 해 동료가 거대한 커밋 또는 명백하지 않은 해킹을 위해 하나의 라이너를 작성하는 것을 보았을 때 나는 화를 내고 있습니다.

커밋은 이유 때문에 수행되며 그 이유는 항상 코드와 입력 한 커밋 로그 한 줄로 명확하게 표현되지는 않습니다. 그것보다 더 많은 것이 있습니다.

각 코드 줄에는 이야기 와 역사가 있습니다. diff는 역사를 말할 수 있지만 이야기를 써야합니다.

이 줄을 왜 업데이트 했습니까? -> 인터페이스가 변경 되었기 때문에.

왜 인터페이스가 바뀌 었습니까? -> 라이브러리를 정의하는 L1이 업데이트되었으므로.

라이브러리가 업데이트 된 이유는 무엇입니까? -> 기능 F에 필요한 라이브러리 L2 때문에 라이브러리 L1에 의존했습니다.

그리고 기능 X 란 무엇입니까? -> 이슈 트래커의 작업 3456을 참조하십시오.

그것은 나의 SCM 선택이 아니며, 실험실에서도 가장 좋은 것이 아닐 수도 있습니다. 그러나 Git이 권리를 가져오고 사용하여, 더 대부분의 다른 SCM들 시스템보다 좋은 기록을 작성하도록 강요하려고 short logs하고 long logs. 작업 ID (예, 필요)를 연결하고에 대한 일반적인 요약을 남기고 shortlog긴 로그를 확장하십시오. 변경 세트의 스토리 작성 .

로그입니다. 업데이트를 추적하고 기록하기 위해 여기에 있습니다.

경험의 규칙 : 나중에이 변경에 대해 무언가를 검색했다면, 로그가 질문에 대답 할 가능성이 있습니까?

프로젝트, 문서 및 코드가 살아 있습니다

그것들을 동기화 상태로 유지하십시오. 그렇지 않으면 더 이상 공생체를 형성하지 않습니다. 당신이 가지고있을 때 놀라운 일을합니다 :

• 이슈 트래커의 작업 ID에 대한 링크가있는 SCM의 커밋 로그 지우기,
• 이 추적기 티켓 자체는 SCM의 변경 세트 및 CI 시스템의 빌드에 연결됩니다.
• 그리고 이들 모두에 연결되는 문서 시스템.

코드와 문서는 응집력이 있어야합니다 .

테스트의 강성

엄지 손가락의 규칙 :

• 모든 새로운 코드에는 (적어도) 단위 테스트가 제공됩니다.
• 리팩토링 된 레거시 코드는 단위 테스트와 함께 제공됩니다.

물론 이러한 요구 사항은 다음과 같습니다.

• 실제로 귀중한 것을 시험하기 위해 (또는 시간과 에너지를 낭비하는 것),
• 잘 작성하고 주석 처리하십시오 (체크 인하는 다른 코드와 마찬가지로).

또한 문서화되어 있으며 코드 계약을 간략히 설명하는 데 도움이됩니다. 특히 TDD 를 사용하는 경우 . 당신이하지 않더라도, 당신의 마음의 평화를 위해 그것들이 필요합니다. 새 코드 (유지 관리 또는 기능)와 워치 타워를 통합하여 코드 부패 및 환경 오류를 방지 할 때 안전망이됩니다.

물론 더 나아가서 통합 테스트 와 수정 가능한 각 버그에 대한 회귀 테스트 를 수행 해야합니다.

도구 사용시의 강성

가끔 개발자 / 과학자가 소스에서 새로운 정적 검사기를 시도하거나 다른 것을 사용하여 그래프 또는 모델을 생성하거나 DSL을 사용하여 새 모듈을 구현하는 것이 좋습니다. 그러나 모든 팀원이 알고 사용해야 할 정식 도구 세트가있는 것이 가장 좋습니다 .

그 외에도 회원이 모두 원하는 한 회원이 원하는 것을 사용하도록하십시오.

• 생산 ,
• 정기적으로 도움이 필요하지 않음
• 정기적으로 일반 인프라에 적응하지 ,
• 코드, 빌드 시스템, 문서와 같은 공통 영역을 수정 하여 인프라를 방해하지 마십시오 .
• 다른 사람의 작업에 영향을 미치는하지 ,
• 요청 된 작업을 적시에 수행 할 수 있습니다.

그렇지 않은 경우 기본값으로 폴백하도록 강제하십시오.

강성 대 다양성, 적응성, 프로토 타이핑 및 비상

유연성이 좋을 수 있습니다. 누군가 해킹, 퀵-앤-더러운 접근 방식 또는 좋아하는 애완 동물 도구를 사용 하여 작업을 완료하도록하는 것이 좋습니다. 결코 그것이 습관이 될 수 있도록없고, 결코 이 코드가 지원하는 실제 코드베이스가 될 수 있도록합니다.

팀 정신 문제

코드베이스에서 자부심을 개발하십시오

• 코드의 자부심 개발
  • 월 보드 사용
    • 지속적인 통합 게임을위한 리더 보드
    • 문제 관리 및 결함 계산을위한 월 보드
  • 사용하여 이슈 트래커 / 버그 추적기를

비난 게임 피하기

• 지속적인 통합 / 지속적인 검사 게임을 사용하십시오. 잘 운영되고 생산적인 경쟁을 촉진합니다 .
• 결함을 추적하지 마십시오. 좋은 하우스 키핑입니다.
• DO 근본 원인을 식별 : 그냥 미래 교정 프로세스입니다.
• 그러나 비난을 할당 하지 마십시오 : 그것은 비생산적입니다.

개발자가 아닌 코드에 관한 것입니다.

개발자가 코드의 품질을 의식하게하지만 코드를 분리 된 엔티티로 보거나 확장하지 않고 비난 할 수는 없습니다.

역설입니다. 건강한 직장에서는 자아없는 프로그래밍 을 장려해야 하지만 동기 부여 목적으로 자아에 의존해야합니다.

과학자에서 프로그래머로

코드를 소중히 여기고 자부하지 않는 사람들은 좋은 코드를 만들지 않습니다. 이 부동산이 등장하기 위해서는 얼마나 가치 있고 재미 있을지 알아 내야합니다. 전문성과 선을 행하려는 욕망만으로는 충분하지 않습니다. 열정이 필요합니다. 따라서 과학자를 프로그래머 로 전환해야합니다 (대규모로).

어떤 사람은 프로젝트와 코드에 대해 10-20 년이 지나면 누구나 애착을 ​​느낄 것이라고 의견을 주장했다. 어쩌면 내가 틀렸지 만 코드 자체 또는 코드 작성 작업이 아니라 코드의 결과와 작업 및 유산을 자랑스럽게 생각합니다.

경험을 통해 대부분의 연구자들은 코딩을 필수 또는 재미있는 산만으로 간주합니다. 그들은 단지 그것이 작동하기를 원합니다. 이미 그것에 정통하고 프로그래밍에 관심이있는 사람들은 모범 사례 채택 및 기술 전환을 설득하기가 훨씬 쉽습니다. 반쯤 가져와야합니다.

코드 유지 보수는 연구 작업의 일부입니다

누구도 엉터리 연구 논문을 읽지 않습니다. 그렇기 때문에 출판 준비가 완료된 것으로 간주 될 때까지 동료 검토, 교정, 읽기, 수정, 재 작성 및 승인을 거듭했습니다. 논문 과 코드베이스 에도 동일하게 적용됩니다 !

코드베이스를 지속적으로 리팩토링하고 새로 고치면 코드 썩음이 방지되고 기술 부채가 줄어들며 향후 다른 프로젝트의 작업을 재사용하고 조정할 수 있습니다.

왜이 모든 ??!

왜 우리는 위의 모든 것을 귀찮게합니까? 대한 코드 품질 . 아니면 품질 코드 입니까 ...?

이 지침은이 목표를 향해 팀을 이끌 기위한 것입니다. 어떤 측면은 단순히 길을 보여주고 그렇게하도록함으로써 (훨씬 나아짐) 다른 부분은 손으로 가져갑니다 (그러나 사람들을 교육하고 습관을 키우는 방식입니다).

목표가 달성되는 시점을 어떻게 알 수 있습니까?

품질은 측정 가능

항상 양적 으로 측정되는 것은 아니지만 측정 할 수 있습니다. 앞에서 언급했듯이 팀에서 자부심을 키워야하며 진보와 좋은 결과를 보여주는 것이 중요합니다. 정기적으로 코드 품질을 측정하고 간격 간 진행 상황과 그 중요성을 보여줍니다. 행해진 일과 그것이 어떻게 더 나아 졌는지에 대해 회고하십시오.

지속적인 검사를 위한 훌륭한 도구가 있습니다 . Sonar 는 Java 세계에서 인기가 있지만 모든 기술에 적용 할 수 있습니다. 그리고 다른 많은 것들이 있습니다. 코드를 현미경으로 유지하고 성가신 버그와 미생물을 찾으십시오.

그러나 내 코드가 이미 크랩 인 경우 어떻게해야합니까?

위의 모든 것은 Never Land 로의 여행처럼 재미 있고 귀엽지 만 이미 (증기 나 냄새가 많은) 쓰레기 코드가 있고 변경을 꺼리는 팀이있을 때는 쉽지 않습니다.

비밀은 다음과 같습니다 . 어딘가에서 시작해야합니다 .

개인 일화 : 프로젝트에서 우리는 원래 650,000+ Java LOC, 200,000+ JSP 라인, 40,000+ JavaScript LOC 및 400+ MB의 이진 종속성을 갖는 코드베이스로 작업했습니다.

약 18 개월이 지나면 500,000 Java LOC (MOSTLY CLEAN) , 150,000 줄의 JSP 및 38,000 JavaScript LOC이며, 거의 100MB에 달하는 의존성을 갖습니다 (더 이상 SCM에는 없습니다!).

우리는 어떻게 했습니까? 우리는 방금 위의 모든 것을했습니다. 또는 열심히 노력했습니다.

그것은 팀의 노력하지만 우리는 천천히 주입 급하게 동안, 우리의 제품의 심장 박동을 모니터하기 위해 프로세스 규정 및 도구의 파괴력 은 "지방"멀리 : 우리는 모든 개발을 멈추지 않았다 ... 쓰레기 코드, 쓸모없는 종속성을 우리는 때때로 코드베이스에 열중하고 그것을 찢어 버릴 수있는 상대적으로 평화 롭고 조용한시기를 가지고 있지만, 대부분의 경우 우리는 기회가있을 때마다 "검토 및 리팩터링"모드로 기본 설정하여 모두 수행합니다. : 빌드 중, 점심 식사 중, 버그 수정 스프린트 동안, 금요일 오후에 ...

큰 "작업"이있었습니다 ... 빌드 시스템을 8500+ XML LOC의 거대한 Ant 빌드에서 멀티 모듈 Maven 빌드로 전환하는 것이 그 중 하나였습니다. 우리는 다음을 가졌다 :

• 명확한 모듈 (또는 적어도 이미 훨씬 나아졌으며 앞으로도 여전히 큰 계획이 있습니다),
• 자동 종속성 관리 (쉬운 유지 관리 및 업데이트 및 쓸모없는 dep 제거)
• 더 빠르고, 쉽고, 재현 가능한 빌드
• 품질에 대한 일일 보고서.

우리는 의존성을 줄이기 위해 노력했지만 "유틸리티 도구 벨트"를 주입했습니다. Google Guava와 Apache Commons는 코드를 줄이고 코드의 버그를 줄 입니다.

또한 IT 부서에서 새로운 도구 (JIRA, Fisheye, Crucible, Confluence, Jenkins)를 사용하는 것이 기존 도구보다 우수하다고 설득했습니다. 우리는 여전히 우리가 멸시 한 일부 (QC, Sharepoint 및 SupportWorks ...)를 처리해야했지만 더 많은 여유 공간이있는 전반적인 개선 된 경험이었습니다.

그리고 매일, 일을 고치고 리팩토링하는 일만 처리하는 수십 개의 커밋이 있습니다. 우리는 때때로 물건을 깰 수 있습니다 (단위 테스트가 필요하며 물건을 리팩토링 하기 전에 더 잘 작성하십시오 ). 그러나 우리의 사기와 제품에 대한 전반적인 이점은 엄청났습니다. 한 번에 코드 품질 비율의 일부만 얻을 수 있습니다. 그리고 그것이 증가하는 것을 보는 것은 재미있다! !!

참고 : 새롭고 더 나은 것을위한 공간을 만들기 위해 강성을 다시 흔들어야합니다. 일화에서, 우리 IT 부서는 우리에게 어떤 것들을 강요하려고 시도하고 다른 사람들에게는 잘못을 시도하는 데 부분적으로 옳 습니다. 아니면 그들이 옳았을 수도 있습니다 . 모든것은 변한다. 생산성을 높이는 더 좋은 방법임을 입증하십시오. 시운전 및 프로토 타입 이 여기에 있습니다.

최고 품질의 증분 스파게티 코드 리팩토링주기

       +-----------------+      +-----------------+
       |  A N A L Y Z E  +----->| I D E N T I F Y |
       +-----------------+      +---------+-------+
                ^                           |
                |                           v
       +--------+--------+      +-----------------+
       |    C L E A N    +<-----|      F I X      |
       +-----------------+      +-----------------+

툴 벨트에 양질의 도구가 있으면 :

1. 코드 품질 검사기로 코드를 분석 하십시오.

   린터, 정적 분석기 또는 무엇을 가지고 있습니까?

2. 중요한 핫스팟과 낮은 매달린 과일을 확인 하십시오 .

   위반에는 심각도 수준이 있으며 심각도가 높은 클래스가 많은 클래스는 큰 위험 신호입니다. 따라서 라디에이터 / 히트 맵 유형의보기에서 "핫스팟"으로 나타납니다.

3. 핫스팟을 먼저 수정 하십시오.

   비즈니스 가치가 가장 높기 때문에 짧은 시간 내에 귀하의 영향력을 극대화합니다. 이상적으로는 잠재적 인 보안 취약성 또는 충돌 원인이 될 수있는 중대한 위반이 발생하는 즉시 처리해야하며 책임을 유발할 위험이 있습니다 (귀하의 경우 실험실 성능이 저하됨).

4. 자동화 된 코드베이스 스윕으로 저수준 위반을 정리 하십시오 .

   신호 대 잡음비를 향상시켜 레이더에 중대한 위반이 나타날 때이를 확인할 수 있습니다. 그들이 돌보지 않았고 코드베이스가 야생에서 느슨해지면 처음에는 큰 사소한 위반이 종종 발생합니다. 실제 "위험"을 나타내지는 않지만 코드의 가독성과 유지 관리 성이 손상됩니다. 작업을 수행하는 동안 만나거나 가능한 경우 자동 코드 스윕으로 대규모 청소 퀘스트를 통해 문제를 해결하십시오. 훌륭한 테스트 스위트 및 통합 시스템이없는 경우 큰 자동 스윕에주의하십시오. 성가심을 최소화하기 위해 동료들과 적시에 합의해야합니다.

5. 만족할 때까지 반복하십시오 .

   이 제품이 여전히 활성화 된 제품이라면 이상적이지 않아야합니다. 계속 발전 할 것입니다.

집을 잘 지키기위한 빠른 팁

• 고객 지원 요청에 따라 핫픽스 모드 인 경우 :

  • 새로운 문제를 원하지 않게 도입 할 수 있으므로 일반적으로 다른 문제를 해결 하지 않는 것이 가장 좋습니다 .
  • 그것을 이동 , 버그를 죽일에서 얻을 나가 : SEAL 스타일을 하고 패치를 제공. 외과적이고 전술적 인 파업입니다.

• 그러나 다른 모든 경우 에는 파일을 열면 다음을 수행해야합니다.

  • 확실히 : 검토 (메모 작성, 파일 문제 보고서)
  • 아마도 : 청소 (스타일 정리 및 사소한 위반)
  • 이상적으로는 리팩토링 하십시오 (큰 섹션과 해당 네이버를 재구성하십시오).

파일에서 파일까지 일주일을 소비하고 여러 기능 및 모듈에 걸친 수천 가지 수정 사항으로 끝나는 미래에 추적하지 마십시오. 미래 추적이 어려워집니다. 코드에서 하나의 이슈 = 트래커에서 하나의 티켓. 때때로 변경 세트가 여러 티켓에 영향을 줄 수 있습니다. 그러나 너무 자주 발생하면 아마도 뭔가 잘못되었을 것입니다.

부록 : 비주얼 프로그래밍 환경 관리

맞춤형 프로그래밍 시스템의 벽으로 둘러싸인 정원

OP의 G2와 같은 여러 프로그래밍 시스템은 다른 짐승입니다 ...

• 소스 없음 "코드"

  소스 "코드"의 텍스트 표현에 액세스 할 수없는 경우가 있습니다. 독점 바이너리 형식으로 저장되거나 텍스트 형식으로 항목을 저장하지만 숨길 수도 있습니다. 맞춤형 그래픽 프로그래밍 시스템은 반복적 인 데이터 처리 워크 플로의 자동화를 단순화하기 때문에 실제로 연구소에서는 드문 일이 아닙니다.

• 툴링 없음

  그들 자신을 제외하고는. 프로그래밍 환경, 자체 디버거, 자체 인터프리터, 자체 문서 도구 및 형식에 의해 제약을받는 경우가 많습니다. 라이센스가 허용하는 경우 형식을 역 엔지니어링하고 외부 도구를 구축 할만큼 동기를 부여한 사람의 관심을 끌 경우를 제외하고 는 벽으로 둘러싸인 정원 입니다.

• 문서 부족

  종종 틈새 프로그래밍 시스템은 상당히 폐쇄 된 환경에서 사용됩니다. 그들을 사용하는 사람들은 자주 NDA에 서명하고 자신의 행동에 대해 이야기하지 않습니다. 그들을위한 프로그래밍 커뮤니티는 드물다. 따라서 자원이 부족합니다. 당신은 당신의 공식 참조에 갇혀 있습니다.

아이러니 한 (그리고 종종 실망스러운) 비트는 주류 및 범용 프로그래밍 언어를 사용 하여이 시스템이 수행하는 모든 것을 분명히 달성 할 수 있다는 것입니다. 그러나 프로그래밍에 대한 더 깊은 지식이 필요한 반면, 생물 학자, 화학자 또는 물리학 자 (예를 들어 몇 명)가 프로그래밍에 대해 충분히 알기를 기대할 수 없으며, 구현 (및 유지) 할 시간 (및 욕구)이 줄어드는 것을 기대할 수 없습니다. 오래 지속될 수도 있고 그렇지 않을 수도있는 복잡한 시스템. 우리가 DSL을 사용하는 것과 같은 이유로, 우리는 이러한 맞춤형 프로그래밍 시스템을 가지고 있습니다.

개인 일화 2 :사실, 나는 이것들 중 하나에서 일했습니다. OP의 요청과 관련이 없었지만 프로젝트는 상호 연결된 큰 데이터 처리 및 데이터 저장 소프트웨어 (주로 생물 정보학 연구, 건강 관리 및 화장품뿐만 아니라 비즈니스 용)였습니다. 지능, 또는 모든 종류의 연구 데이터 추적 및 데이터 처리 워크 플로 및 ETL 준비를 암시하는 모든 도메인). 이러한 응용 프로그램 중 하나는 드래그 앤 드롭 인터페이스, 버전이 지정된 프로젝트 작업 공간 (메타 데이터 저장을 위해 텍스트 및 XML 파일 사용), 이기종 데이터 소스에 대한 많은 플러그 가능 드라이버 및 비주얼과 같은 일반적인 종과 휘파람을 사용하는 시각적 IDE였습니다. N 개의 데이터 소스에서 데이터를 처리하고 결국 M 개의 변환 된 출력을 생성하는 파이프 라인을 설계하는 캔버스 가능한 반짝이는 시각화 및 복잡한 (대화 형) 온라인 보고서. 사용자의 맞춤형 비주얼 프로그래밍 시스템. 사용자의 요구에 맞는 시스템을 설계하는 과정에서 약간의 NIH 증후군이 있습니다.

그리고 예상 한 바와 같이,이 시스템은 멋진 시스템으로, 때로는 약간은 뛰어나지 만 "명령 줄 도구를 대신 사용하지 않는 이유는 무엇입니까?"라는 궁금증이 생길 수 있습니다. 다른 "최상의"사례를 사용하여 많은 다른 사람들에게 대규모 프로젝트를 수행하는 팀.

좋아, 우린 운명이야! -우리는 어떻게해야합니까?

글쎄, 결국, 위의 모든 내용이 여전히 유효합니다. 더 많은 주류 도구와 언어를 사용하기 위해이 시스템에서 대부분의 프로그래밍을 추출 할 수없는 경우 시스템의 제약 조건에 맞게 조정하면됩니다.

버전 관리 및 스토리지 정보

결국, 가장 제한적이고 벽으로 둘러싸인 환경에서도 거의 항상 버전을 관리 할 수 있습니다. 대부분의 경우이 시스템에는 여전히 자체 버전이 있습니다 (불행히도 다소 기본적이며 이전 버전을 유지하면서 많은 가시성없이 이전 버전으로 되돌릴 수 있습니다). 선택한 SCM과 같이 차등 변경 세트를 정확하게 사용하지 않고 여러 사용자가 동시에 변경을 제출하는 데 적합하지 않을 수 있습니다.

그러나 여전히 이러한 기능을 제공하는 경우 귀하의 솔루션은 위의 사랑하는 업계 표준 지침을 따르고이 프로그래밍 시스템에 전치하는 것입니다 !!

스토리지 시스템이 데이터베이스 인 경우 내보내기 기능이 노출되거나 파일 시스템 레벨에서 백업 될 수 있습니다. 사용자 지정 이진 형식을 사용하는 경우 이진 데이터를 제대로 지원하는 VCS를 사용하여 버전을 간단하게 지정할 수 있습니다. 세밀하게 제어 할 수는 없지만 최소한 재난에 대비할 수있는 정도의 재난이 발생하고 어느 정도의 재해 복구 규정을 준수해야합니다.

테스트 정보

플랫폼 자체 내에서 테스트를 구현하고 외부 도구 및 백그라운드 작업을 사용하여 정기적 인 백업을 설정하십시오. 아마도이 프로그래밍 시스템으로 개발 한 프로그램을 실행하는 것과 동일한 방법으로이 테스트를 실행했을 것입니다.

물론, 이것은 해킹 작업이며 "정상적인"프로그래밍의 일반적인 표준에 맞지 않지만, 전문적인 소프트웨어 개발 프로세스의 유사성을 유지하면서 시스템에 적응하는 것이 좋습니다.

길은 길고 가파르다 ...

틈새 환경과 맞춤형 프로그래밍 시스템에서 항상 그렇듯이 위에서 언급했듯이 이상한 형식, 제한적 (또는 완전히 존재하지 않는) 어수선한 도구 세트와 커뮤니티 대신 공백을 처리합니다.

권장 사항 : 가능한 맞춤형 프로그래밍 시스템 외부에서 위의 지침을 구현하십시오. 이를 통해 적절한 지원과 커뮤니티 추진력을 가진 "공통"도구를 이용할 수 있습니다.

해결 방법 : 이 옵션이 아닌 경우이 전역 프레임 워크를 "상자"에 추가하십시오. 아이디어는이 업계 표준 모범 사례 청사진을 프로그래밍 시스템 위에 겹쳐서 활용하는 것입니다. 다음과 같은 조언이 여전히 적용됩니다 : 구조 및 모범 사례 정의, 적합성 장려.

불행히도, 이것은 당신이 다이빙을하고 엄청난 양의 레그 워크를해야 할 수도 있음을 의미합니다. 그래서...

유명한 마지막 단어와 겸손한 요청 :

• 문서화 당신이하는 모든 일을.
• 경험을 공유 하십시오.
• 어떤 도구를 사용하든 오픈 소스 하십시오.

이 모든 작업을 수행하면 다음을 수행 할 수 있습니다.

• 비슷한 상황에있는 사람들로부터 도움을받을 가능성을 높일뿐 아니라
• 또한 다른 사람들에게 도움을 제공하고 기술 스택에 대한 토론을 장려하십시오.

누가 알다시피, 당신은 Obscure Language X 의 새로운 역동적 인 커뮤니티의 시작 부분에있을 수 있습니다 . 아무것도 없다면 시작하십시오!

• 에 대한 질문 질문 스택 오버플로를 ,
• Area 51 에 새로운 StackExchange 사이트에 대한 제안서를 작성하는 것도 가능 합니다.

어쩌면 그것은 아름다운 내부입니다 ,하지만 아무도 단서가 없다 지금까지, 그래서 도움 이 추한 벽을 가지고 와 다른 사람이 들여다 보자!

바로 그 첫 번째 단계는 것입니다 버전 제어 시스템의 도입 (SVN, 힘내, 의욕, TFS, 등). 리팩토링이 필요한 프로젝트가 있어야합니다.

편집 : VSC 관련-모든 소스 제어 패키지는 일부 제한 사항이 있지만 바이너리를 관리 할 수 ​​있습니다. 시장에 나와있는 대부분의 도구에는 사용자 정의 차등 뷰어 및 편집기를 사용할 수있는 기능이 있습니다. 이진 소스 파일은 버전 관리를 사용하지 않는다는 변명이 아닙니다.

레거시 코드 를 처리 하는 방법에 대한 유사한 게시물 이 있습니다. 레거시 코드 작업에 대한 조언

스파게티 코드로 작업해야 할 때 가장 먼저 작업하는 것은 모듈화 입니다. 선을 그리고 독립적 인 코드베이스 조각을 추출 할 수있는 곳을 찾으십시오. 높은 수준의 상호 연결 및 커플 링으로 인해 크기가 매우 작지는 않지만 찾을 경우 일부 모듈 라인이 나타납니다.

모듈이 있으면 더 이상 전체 지저분한 프로그램을 정리하는 어려운 작업에 직면하지 않습니다. 대신, 몇 개의 작은 독립적 인 지저분한 모듈을 정리해야합니다. 이제 모듈을 선택하고 더 작은 규모로 반복하십시오. 큰 함수를 작은 함수 나 클래스로 추출 할 수있는 장소를 찾으십시오 (G2가 지원하는 경우).

언어가 충분히 강력한 유형 시스템을 가지고 있다면 컴파일러가 많은 노력을 기울일 수 있기 때문에 이것은 훨씬 쉽습니다. 호환성을 의도적으로 깨뜨릴 수있는 곳을 변경 한 다음 컴파일을 시도합니다. 컴파일 오류는 변경해야 할 장소로 직접 연결되며, 오류가 발생하면 모든 것을 발견했습니다. 그런 다음 프로그램을 실행하고 모든 것을 테스트하십시오! 리팩토링시 지속적인 테스트가 매우 중요합니다.

이것이 당신에게 옵션인지는 모르겠지만 보다 전문적인 개발자 를 고용 하도록 설득하기 시작 했습니다 . 이런 식으로 그들은 도메인 문제에 집중할 수 있습니다 (그들이 충분하다고 확신합니다).

나는 그들이 똑똑한 사람이라고 생각하지만 좋은 개발자가 되려면 많은 시간이 필요합니다. 그들은 주요 사업이 아닌 활동에 많은 시간을 할애 할 준비가되어 있습니까? IMHO, 이것이 최상의 결과를 얻는 방법은 아닙니다.

와. 당신이 정말 큰 도전을하고있는 것처럼 들립니다! 다음 줄을 따라 뭔가를 할 것입니다.

• 우선 : Prioritize . 무엇을 먼저 달성하고 싶습니까? 프로젝트의 현재 상태에 가장 중요한 것은 무엇입니까? 도착하는 데 걸리는 시간과 시간을 최대한 활용하는 방법은 무엇입니까?
• 버전 관리 시스템 이 있는지 확인하십시오 . 예를 들어 Git 또는 Mercurial .
• 일종의 지속적인 통합 시스템 (예 : Jenkins )을 가동하십시오.
• 오는 Get 버그 추적 시스템을 설치하고 실행. 사마귀 는 제 생각에는 아주 좋습니다.
• 정적 코드 분석을 살펴보십시오 (현재 작업중인 언어에 사용할 수있는 것이있는 경우).
• 많이 달성하려고 일관성 코드베이스의 일반적인 코드 작성 요령 및 지침에 대한 변수의 이름에서 아무것도에 있습니다.
• 테스트중인 시스템을 확보하십시오 . 이것은 내 의견으로는 이와 같은 큰 레거시 시스템에 매우 중요합니다. 테스트 케이스를 사용 하여 동작이 이상하지 않은지 여부에 관계없이 기존 동작을 문서화하십시오 (일반적으로 코드가 왜 왜, 왜 나쁘거나 나쁜지 또는 두 가지 모두; P라고 보이는 이유가 있습니다). 레거시 코드를 효과적으로 사용하는 Michael Feathers 는이를위한 훌륭한 리소스입니다.

그들은 문제를 해결하는 첫 번째 단계는 당신에게 문제가 있음을 인정하는 것이라고 말합니다. 이를 염두에두고 현재 코드 기반 인 엉킴을 나타내는 종속성 그래프를 생성하여 시작할 수 있습니다. 의존성 다이어그램을 생성하는 좋은 도구? 몇 살이지만 이러한 그래프를 만드는 데 도움이되는 도구에 대한 포인터가 포함되어 있습니다. 나는 포인트를 집으로 몰아 올릴 수있는 한 큰 큰 추한 그래프를 사용합니다. 너무 많은 상호 의존성으로 인해 발생하는 문제에 대해 이야기 하고 Buckaroo Banzai에서 줄을 서십시오 .

당신은 당신이 원하는 모든 해부학을 확인할 수 있으며, 정상적인 변형이있을 수 있지만, 그것이 바로 머리에 닿으면 모두 똑같이 보입니다. 아냐 아냐 아냐 당신은 그것이 무엇에 붙어 있는지 모릅니다.

거기에서 혼란을 바로 잡기위한 계획을 소개하십시오. 코드를 가능한 한 독립적 인 모듈로 나누십시오. 그렇게하는 방법에 대한 제안을 공개하십시오. 여러분이하는 것보다 코드의 역사와 기능을 더 잘 알고 있습니다. 그러나 목표는 하나의 큰 문제를 해결하여 우선 순위를 정하고 정리를 시작할 수있는 몇 가지 작은 문제로 바꾸는 것입니다.

집중해야 할 사항 :

• 모듈 사이에 깔끔한 인터페이스를 만들어 사용하십시오. 구식 코드는 필연적으로 이러한 멋진 새 인터페이스를 계속 사용하지 않을 수 있습니다. 이것이 해결하려는 문제입니다. 그러나 모든 사람들이 앞으로 새로운 인터페이스 만 사용하도록 동의하십시오. 인터페이스에없는 것이 필요한 경우 인터페이스를 수정하고 주변을 둘러 보지 마십시오.

• 동일한 기능이 반복 된 사례를 찾으십시오. 통일을 향해 노력하십시오.

• 이러한 변화는 인생을 더 쉽고 어렵게 만드는 것이 아니라는 것을 때때로 상기 시키십시오. 전환은 고통 스러울 수 있지만 좋은 목적을위한 것이며, 모든 사람이 탑승할수록 혜택이 더 빨리 올 것입니다.

에보고 한 후 Gensym의 G2 이 문제를 접근하는 방법은 다음과 같습니다 어떻게 코드베이스의 대부분에 따라 크게 좌우 될 것처럼 조금 그것은 본다 :

아니면 이거:

이것에 비해, 99 병의 맥주 제공 :

beer-bottles()

i:integer =99;
j:integer;
constant:integer =-1;

begin
for i=99 down to 1
    do
    j = (i+constant);
        if (i=1) then begin
            post"[i] bottle of beer on the wall";
            post" [i] bottle of beer";
            post" Take one down and pass it around ";
            post" No bottle of beer on the wall"; 
        end 
        else begin
            post"[i] bottles of beer on the wall";
            post" [i] bottles of beer";
            post" Take one down and pass it around ";
            if (i=2) then 
                post" [j] bottle of beer on the wall"
           else
                post" [j] bottles of beer on the wall"; 
           end
    end
end

후자의 경우 실제로 알려진 양인 소스 코드로 작업하고 있으며 다른 답변 중 일부는 소스 코드 를 처리하는 데 매우 현명한 조언 을 제공 합니다.

대부분의 코드 기반이 후자이거나 크기 조정 가능한 청크 인 경우에도 극도로 전문화되어 있거나 더 나쁘기 때문에 리팩토링 할 수없는 코드가 있다는 흥미로운 문제가 발생합니다. 제거 할 수는 있지만 제대로 문서화 되어 있지 않으면 언뜻보기에 보이지 않는 중요한 코드를 제거하는지 ( 스크 램 작업 라인을 따라 무언가를 생각 하는지) 알 수 없습니다.

ElYusubov가 지적한 것처럼 온라인에서 일종의 버전 제어를 얻는 것이 가장 우선 순위가 높지만 8.3 버전 이후 버전 제어가 지원 된 것으로 보입니다 . G2는 서로 다른 몇 가지 언어 방법론의 조합이므로 다른 것을 찾아서 작동시키는 것과는 반대로 제공되는 버전 관리를 사용하는 것이 가장 효과적 일 수 있습니다.

다음으로, 일부는 리팩토링을 시작하기를 옹호 할 가능성이 있지만, 코드를 만지기 전에, 특히 개발 한 코드 및 시각적 다이어그램을 다룰 때 작업중인 시스템을 완전히 이해하도록 강력히 옹호합니다. 소프트웨어 엔지니어링 방법론에 대한 정식 교육 (또는 배경)이없는 개발자 이것에 대한 추론은 몇 가지가 있지만, 가장 명백한 이유는 잠재적으로 100 인년 이상의 가치가있는 응용 프로그램을 사용하고 있으며 실제로 무엇을하고 있는지 알고 있는지 확인해야한다는 것입니다. 거기에 문서가 있습니다. 시스템이 어느 산업에 배치되어 있는지 말하지 않았지만 내가 G2에 대해 읽은 내용을 바탕으로 생명 안전에도 영향을 줄 수있는 미션 크리티컬 애플리케이션이라고 생각하는 것이 안전 해 보입니다. 따라서 정확히 무엇을하고 있는지 이해하는 것이 매우 중요합니다. 사람들이 코드의 역할을 결정할 수 있도록 문서를 작성하기 위해 팀의 다른 사람들과 함께 문서화되지 않은 코드가 있습니다.

다음으로 코드 테스트와 시각적 다이어그램을 가능한 많이 둘러싼 단위 테스트를 시작하십시오. G2를 사용 하여이 작업을 수행하는 방법에 대해서는 약간의 무지를 인정해야하지만이를 구현하기 위해 자체 테스트 프레임 워크를 만드는 것이 좋습니다. 또한 팀의 다른 구성원에게 코드 품질과 관련된보다 엄격한 엔지니어링 실무에 사용할 수 있도록하기위한 이상적인 시간입니다 (즉, 모든 코드에는 단위 테스트 및 문서가 있어야 함).

상당한 양의 코드에 대해 단위 테스트가 완료되면 haylem 이 제안한 방식으로 리팩토링에 접근 할 수 있습니다 . 그러나 전문가 시스템을 개발하고 시스템을 리팩토링하는 데 도움이되는 것을 다루어야한다는 점을 명심해야합니다. 이것은 실제로 매우 일반적인 코드를 작성 하지 않는 것으로 말할 수있는 환경 입니다.

마지막으로 코드와 다이어그램 품질이 최고가 아니기 때문에 다른 팀 구성원의 의견에주의를 기울여야합니다. 궁극적으로 그들은 당분간 애플리케이션보다 자신이하는 일에 대해 더 많이 알고있을 가능성이 높기 때문에 변경 사항을 작성하기 전에 앉아서 애플리케이션을 이해하는 것이 무엇보다 중요합니다.

일반적으로 귀하가 미리들은 불만은 중요한 문제와 관련이 없습니다. 결국, 모든 소프트웨어 프로젝트에서 이러한 불만을 듣는 것은 전적으로 정상입니다.

코드를 이해하기 어려운가요? 검사. 대규모 코드베이스? 검사.

진짜 문제는 사람들이 떠나고, 새로운 사람이 조직에 합류 할 때 전형적인 혼란이 있다는 것입니다. 또한 비현실적인 기대와 코드 품질 문제가 있습니다.

다음은 순서대로 다루는 것입니다.

1. 서버 및 로컬 버전의 백업
2. 버그 추적기 설정
3. 버전 관리 시스템 설정
4. FAQ / 위키 설정
5. 모든 과학자 / 프로그래머의 첫 브리핑
   • 그들에게 80/20 규칙을 상기 시키십시오. 버그의 20 %가 문제의 80 %를 담당합니다.
   • 가장 큰 문제에 집중하고 개선 요청 등을 계속 유지하십시오.
   • 여기서 목표는 큰 목록을 가진 사람들을 놀라게하는 것이 아니라 달성 가능한 작은 승리의 목록을 만드는 것입니다. 결국, 당신은 또한 당신의 가치를 증명해야합니다.
6. 빌드 시스템 설정
   • 안정적인 빌드를 시작하십시오 (시간이 걸릴 수 있음).
   • 모든 프로젝트를 식별하고 이름을 짓습니다.
   • 순환 종속성 식별
   • 일부 오픈 소스 프로젝트의 바이너리가있는 경우 소스를 얻으십시오.
7. API, 서비스와 같은 G2 코드를 모듈화 할 수있는 방법 식별
8. G2 코드를 테스트하고 문서화하는 방법을 식별하십시오.
9. 코드 검토 시스템 설정
10. 두 번째 브리핑
    • 이상적인 모듈은 무엇입니까?
    • 오래된 코드를 제거하는 방법
    • 기존 코드를 새 모듈로 감싸는 방법 (Strangler 패턴 http://agilefromthegroundup.blogspot.com.au/2011/03/strangulation-pattern-of-choice-for.html 참조 )
11. 더 나은 프로그래머로 구성된 균열 팀을 식별하고 그들과 협력하여 모듈을 포장하십시오.
12. 커뮤니케이션 및 문서화를 개선하기 위해이 단계에 코드 검토가 있습니다. 이 단계에서 쉽게 유지하십시오. 프로세스 문제를 정리하십시오.
13. 다른 프로그래머에게 시스템을 롤아웃하십시오. 균열 팀 구성원이 나머지 동료 멘토가되도록하십시오. 스케일링은 여기서 문제입니다. 당신은 효과적으로 관리 역할에 있습니다.

이와 같은 질문은 Software Carpentry 프로젝트가 존재 하는 모든 이유 입니다.

지난 14 년 동안 우리는 과학자와 엔지니어에게 기본 소프트웨어 개발 기술 (버전 제어, 테스트, 코드 모듈화 방법 등)을 가르치고 있습니다. 우리의 모든 자료는 Creative Commons 라이센스에 따라 무료로 제공되며, 사람들이 시작하는 데 도움을주기 위해 매년 수십 개의 무료 2 일 워크샵을 운영합니다.

이를 바탕으로 로버트 글래스 (Robert Glass) 의 소프트웨어 엔지니어링의 사실과 오류에 대한 가장 좋은 출발점은 아마도 시작이라고 생각합니다 . 단순한 의견 이상의 것.
특정 관행과 관련하여 사람들이 가장 기꺼이 채택하려는 두 가지는 버전 관리 및 단위 테스트입니다. 일단 배치되면 Michael Feathers가 레거시 코드로 효과적으로 작업하기 에서 설명하는 일종의 체계적인 리팩토링 문제를 해결할 수 있습니다 .
더 이상 Pragmatic Programmer ( 권장 사항 이 많고 초보자가 실제로 연습하기가 어렵습니다)를 권장하지 않으며 McConnell의 Code Complete 라고 생각합니다. 시작하기에는 너무 많습니다 (기본 사항을 익힌 후 6 개월 또는 1 년 내에 제공하는 것이 좋습니다).

나는 또한 매우 폴 뒤부아 '우수 논문 추천 할 것입니다 "과학 프로그램의 정확성을 유지" ( 과학 및 공학 컴퓨팅 논리적 일관성에 12 개의 사례를 결합하는'심층 방어 '접근 방식을 설명 월 - 2005 년 6 월) 방법.

우선 상황을 정리해야한다고 생각합니다. 그들이 당신에게서 무엇을 원하십니까?

• 그들이 고대의 언어를 배우기를 원하지는 않을 것입니다. 왜냐하면 이것이 막 다른 골목처럼 보일 것입니다. 현재 과학자들이 떠나거나 모든 패치 코드가 점점 더 자주 실패합니다.
• 과학자들 (또는 그들 중 일부)은 새로운 언어와 많은 프로그래밍 패러다임을 배울 준비가되어 있습니까? 아니면 그들은 장기적으로 프로그래밍과 과학 활동을 분리하고 싶거나 필요한 경우 더 많은 프로그래머를 원합니까? 이것은 합리적이고 효율적인 전문 지식 분리입니다.

여기서 핵심 요구 사항은 "지식을 시스템에 저장"하는 것이므로이를 발굴해야합니다!

첫 번째 과제는 문서를 작성하는 것입니다.

기존 시스템의 도움으로 새로운 작업 인 것처럼 구조와 요구 사항을 분석하십시오. 먼저 가르치는 대신 ASK를 요청하기 때문에 기뻐할 것입니다. 프로그래머의 관점에서 "충분히 체계적인 배경 지식을 얻을 수 있습니다."무슨 일이 벌어지고 있습니까? " 문서 (시스템 정적 구조, 워크 플로우, 구성 요소, 문제)는 즉시 가치가 있으며 아마도 당신보다 더 관련성이 높은 정보를 표시 할 것입니다 (일부 사람들은 "AHA!"를 가지고 일부 코드를 즉시 수정하기 시작할 수 있습니다 ) ...

그런 다음 어디로 가고 싶은지 물어보아야합니까?

그들이 G2에서 멀어 질 준비가되어 있다면, 그들이보고 싶은 시스템 (플랫폼, 언어, 인터페이스, 일반 구조)? 가능한 경우 대상 구조를 가지면서 원래 구성 요소를 유지하면서 시스템 주변에서 외부 랩퍼를 작성하기 시작할 수 있으므로이 대상 환경에서 새 구성 요소를 구현할 수있는 일종의 프레임 워크를 천천히 시작합니다. 핵심 서비스 (지속적 데이터 연결 및 "툴킷": 핵심 계산, 도면, ... 라이브러리)를 찾아야하므로 새로운 플랫폼과 언어로 친숙한 환경을 제공하여 사용자 또는 이전 코드를 하나씩 가져 와서 새로운 환경에서 다시 구현하십시오. 준비가되면 새로운 언어를 알게됩니다. 서비스 계층 (주로 사용자가 만든 것이 유감입니다)이 새 구성 요소를 호스팅 할 준비가되었습니다.

그들이 움직이지 않으면 G2를 배우고 거기에서 모듈 식 프레임 워크를 작성해야합니다. 어쨌든, 언어는 단지 데이터와 알고리즘 트리의 직렬화 일뿐입니다 ...

문서를 분석하고 작성하는 동안 GoF 디자인 패턴을 읽고 사용하고 광고하십시오! :-)

... 내 2 센트

동료들에게 Robert Martin의 SOLID 원칙에 대한 일련의 프레젠테이션을 마쳤습니다. 이 원칙이 G2로 얼마나 잘 변환되는지는 잘 모르겠지만 5 ~ 7 개의 핵심 기본 요소를 찾고 있기 때문에 처음부터 잘 설정된 것으로 보입니다. 7로 반올림하려면 DRY로 시작하여 Fail-Fast를 던질 수 있습니다.

유일한 생산 문제는 변경 관리 문제처럼 들립니다. 그것이 사실이고 소프트웨어가 그렇지 않으면 목적을 수행하는 경우, 내가 줄 첫 번째 조언은 너무 많은 일을하라는 충동에 저항하는 것입니다.

소스 제어, 리팩토링,보다 숙련 된 개발자가 모두 좋은 제안이지만, 이것이 처음이라면 이런 종류의 문제를 느리게 움직여야하고 통제 된 변경을하는 것은 충분히 강조 할 수 없습니다.

혼란을 겪고 싶은 충동은 때때로 크지 만, 리버스 엔지니어링을 충분히 마칠 때까지 교체 버전을 적절하게 테스트 할 수 있다는 것을 알고 매우 조심해야합니다.

그러한 상황에서 일하기위한 가장 중요한 원칙은 다음과 같습니다.

1. 인내심을 가지십시오. 발굴에 20 년이 걸렸던 구멍은 몇 주 안에 채워지지 않을 것입니다.

2. 긍정적. 불평하고 불평하려는 유혹에 저항하십시오.

3. 실용적이 되십시오. 하루에 달성 할 수있는 긍정적 인 변화를보고 오늘 그렇게하십시오. 버전 관리 시스템이 있습니까? 그것을 구현하고 사람들을 훈련 시키십시오. 그런 다음 테스트를 자동화 할 수 있는지 확인하십시오 (단위 테스트 또는 이와 유사한 것). 헹구기. 반복.

4. 모델이 되십시오. 민첩성을 통해 민첩성이 어떻게 작동하는지 사람들에게 보여주십시오. 위의 첫 세 점은 Good Guy가되기위한 열쇠이며, 효과적인 Agile의 전임자입니다. 제 생각에는 훌륭한 개발자는 똑똑 할뿐만 아니라 모범 직원과 동료이기도합니다.

5. 영토를 매핑하십시오. 거대한 레거시 코드베이스를 매핑하는 기술이 있습니다. 레포를 복제하고 작업 복사본을 만든 다음 무언가를 변경하고 다른 것이 무엇인지 확인하려고합니다. 커플 링 (글로벌 스테이트 또는 깨진 API를 통해, 또는 일관된 API 또는 프로그래밍 할 추상화 또는 인터페이스가 없음을 통해)을 조사하고 변경 사항이 발생할 때 중단되는 코드를 읽음으로써 부스러기를 발견하고, 팀의 다른 사람들로부터 통찰력을 얻었습니다 (5 년 전 보스 X가 요구했기 때문에 결코 효과가 없었습니다!) 시간이 지남에 따라 영토의 정신지도를 얻을 수 있습니다. 그것이 얼마나 큰지 알면지도를 작성하고 집에 돌아갈만큼 충분히 알게됩니다. 다른 사람들이 거대한 코드베이스의 영역을 매핑하고 팀의 기술 지식을 구축하도록 권장하십시오. 어떤 사람들은 "문서"를 듣습니다 민첩하지 않기 때문입니다. 도대체 무엇이. 나는 과학적인 환경에서도 일하고 ​​문서는 왕에게있어 민첩한 표현이 저주받습니다.

6. 작은 앱을 빌드하십시오. 레거시 코드베이스로 작업 할 때 펄프에 착수합니다. 나는 작은 도우미 앱을 만들어서 정신을 돌려받습니다. 아마도 이러한 앱이 거대한 G2 코드베이스를 읽고 이해하고 수정하는 데 도움이 될 것입니다. 환경에서 작업하는 데 도움이되는 미니 IDE 또는 파서 도구를 만들 수 있습니다. 메타 프로그래밍 및 툴 구축은 레거시 코드베이스가 부과하는 거대한 교착 상태에서 벗어날 수있을뿐만 아니라 뇌에 G2 언어의 제약이없는 비행 능력을 제공하는 경우가 많습니다. 도구와 도우미를 가장 빠르고 최상의 언어로 작성하십시오. 저에게 해당 언어에는 Python 및 Delphi가 포함됩니다. Perl 사용자이거나 실제로 C ++ 또는 C #에서 프로그래밍을 좋아하는 경우 해당 언어로 도우미 도구를 작성하십시오.

1. 개정 관리 : 도메인 전문가에게 되돌릴 수있는 이점을 보여주고 누가 무엇을 변경했는지 등을 확인할 수 있습니다. (이것은 모든 이진 파일에서는 더 어렵지만 내용이 실제로 코드 인 경우 분명히 일종의 G2-to- diff를 가능하게하는 텍스트 변환기)

2. 지속적인 통합 및 테스트 : 도메인 전문가가 엔드 투 엔드 테스트 (이미 어딘가에 입력 및 예상 출력이 있어야하므로 더욱 쉬워 짐) 및 소규모 단위 테스트 (스파게티 코드에 많은 글로벌 변수가 포함되므로 더 세게) 거의 모든 기능과 사용 사례를 다룹니다.

3. 공통 코드 를 재사용 가능한 루틴 및 컴포넌트로 리팩토링하십시오 . 개정 관리 기능이없는 소프트웨어를 사용하지 않는 사람들은 한 번에 100 줄을 복사하여 붙여 넣어 일상을 만들 것입니다. 그것들을 찾아 리팩토링하여 모든 테스트가 통과하고 코드가 짧아짐을 보여줍니다. 또한 아키텍처를 배우는 데 도움이됩니다. 어려운 아키텍처 결정을 시작해야 할 때 운이 좋으면 100KLOC로 떨어질 수 있습니다.

정치적으로 ,이 프로세스에서 기존 타이머의 저항을 찾으면 컨설턴트를 고용하여 좋은 소프트웨어 방법론에 대해 이야기하십시오. 도메인 전문가가 동의하지 않더라도 귀하의 의견에 동의하는 좋은 회사를 찾고 컨설턴트가 필요로하는 것을 구매하도록하십시오. (결국 그들은 당신을 고용 했으므로 소프트웨어 엔지니어링 전문 지식이 필요하다는 것을 분명히 알 것입니다.) 이것은 돈 낭비입니다. 물론 그 이유는 새로운 핫샷 프로그래머 프로그래머가 그들은 무언가를해야하므로 무시할 수 있습니다. 그러나 경영진이 컨설턴트에게 5000 달러를 지불하고 필요한 것을 말하면 더 많은 믿음을 갖게 될 것입니다. 보너스 포인트: 컨설턴트가 원하는 것보다 두 배나 많은 변화를 조언하면 도메인 전문가와 함께 "좋은 사람"이 될 수 있으며 컨설턴트가 제안한 것의 절반 만 바꾸도록 타협 할 수 있습니다.

"프로그램 자체는 복잡한 화학 처리 공장의 물리적 모델입니다 ..."

"G2는 코드가 아니라 일부 GUI로 작성된 자동화 된 코드와 비슷하기 때문에 ..."– Erik Reppen

소프트웨어의 주요 목표가 복잡한 화학 플랜트 또는 그 일부 를 시뮬레이션 (아마도 최적화, 매개 변수 추정 실행)하는 것으로 가정하면 다소 다른 제안을하고 싶습니다.

당신은, 본질, 핵심 수학적 모델을 추출하기 위해 높은 수준의 수학적 모델링 언어를 사용하는 것이 잘 할 수 에서 손으로 코딩 소프트웨어입니다.

모델링 언어는 문제 설명을 문제 해결에 사용 된 알고리즘에서 분리하는 것입니다. 이 알고리즘은 일반적으로 주어진 클래스 (예 : 화학 공정)의 대부분의 시뮬레이션 / 최적화에 적용 할 수 있으며,이 경우 실제로는 사내에서 다시 발명하고 유지해서는 안됩니다.

업계에서 널리 사용되는 3 가지 상용 패키지는 다음과 같습니다. gPROMS, Aspen Custom Modeller 및 (모델에 공간 도메인을 따라 분포 된 현상이 포함되지 않은 경우) Dymola와 같은 Modelica 기반 소프트웨어 패키지가 있습니다.

이러한 모든 패키지는 "확장"을 지원하는 방식으로, 사용자 정의 프로그래밍이 필요한 모델의 일부가있는 경우 해당 모델의 방정식으로 참조 할 수있는 객체 (예 : .DLL)로 캡슐화 할 수 있습니다. 모델. 한편, 대부분의 모델은 과학자들이 직접 읽을 수있는 형태로 간결하게 유지됩니다. 이것은 회사의 지식과 지식을 포착하는 훨씬 더 좋은 방법입니다.

이러한 프로그램의 대부분은 또한 외부에서 호출함으로써 모 놀리 식 코드의 '작은 시작'및 작은 부분 (하위 모델)을 해당 형식으로 포팅 할 수 있어야합니다. 이것은 작업 시스템을 유지 관리하고 한 번에 하나씩 확인하는 좋은 방법 일 수 있습니다.

완전한 면책 조항 : 저는 gPROMS를 담당하는 회사에서 8 년간 소프트웨어 엔지니어로 일했습니다. 그 당시 나는 작고 깔끔하게 시작하여 영리한 솔루션이나 알고리즘을 구현했지만 몇 년 동안 확장과 수정을 통해 몇 년 동안 폭발적으로 발전한 맞춤형 소프트웨어 (예 : 학계 출신)의 예를 보았습니다. 깨끗하게 유지하는 소프트웨어 엔지니어. (나는 여러 분야의 팀을 좋아합니다.)

언어 나 키 라이브러리와 같은 소프트웨어 개발 초기에 특정 키 선택이 잘못되어 오랫동안 고통을 겪는 경향이 있다는 경험이 있습니다. 그들 주위에 소프트웨어. 몇 년 동안 순수한 코드 청소에 직면 할 수있는 것처럼 들립니다. (나는 숫자를 사용하는 것을 주저하지만 10 + 사람 년을 생각하고 있습니다 .G2에서 Eclipse / Java 빠른 스마트와 같은 우수한 자동 리팩토링 도구를 지원하는 코드로 이식 할 수없는 코드는 아마도 훨씬 더 많습니다.)

내 기본 상태는 "작업 시스템 리팩토링 및 유지"이지만, 문제가 "너무 큰"경우에는보다 급진적 인 변경 / 재기록이 전체적으로 더 빨라집니다. (그리고 더 현대적인 기술로 넘어가는 것과 같은 추가적인 이점도있을 수 있습니다.) 저는 새로운 소프트웨어 플랫폼으로 포팅 한 경험이 있지만, 수집 한 것에서부터 수학적 모델링 패키지에 이르기까지 훨씬 더 극적이라고 말합니다.

약간의 관점을 제시하기 위해 크기 축소에 놀랄 수 있습니다. 예를 들어, 200,000 LoC는 실제로 5,000 줄의 방정식으로 표현 될 수 있습니다. C와 같이 작성된 비교적 작은 기능 모듈 (예 : 물리적 특성 계산-화학 공정에 따라 선반 패키지가 다시 제공 될 수 있음). 이는 문자 그대로 알고리즘 솔루션 코드를 버리고 수학 솔버의 범용 '스택'이 어려운 작업을 수행하게하기 때문입니다. 시뮬레이션이 실행되면 코드 라인을 변경하지 않고도 프로세스 최적화와 같이 훨씬 더 많은 작업을 수행 할 수 있습니다.

마지막으로 말할 것입니다. 다양한 수학적 모델 (및 알고리즘)에 대한 신뢰할만한 문서가 코드 자체라면, 과학자와 원저자에게 도움이 될 것입니다. 그들 중 일부는 이동했을 수 있습니다. 그들은 수학적 모델링 언어가 이러한 모델을 포착 할 수있는 매우 자연스러운 방법이라는 것을 알아야합니다.

마지막으로, 내 대답이 점수를 벗어 났을 수 있으므로 이미 여기에서 참조한 좋은 책 목록에 한 권 더 책을 추가하고 싶습니다. Clean Code by Robert Martin. 배우고 적용하기 쉽지만 회사에서 새 코드를 개발하는 사람들에게 큰 차이를 만들 수있는 단순하고 정당한 팁으로 가득합니다.

나는 다음을 버릴 것이다.

1. 여기에 한 명의 프로그래머가 있습니다. 나사 정치. 그들은 그들의 거래를 알고 있습니다. 당신은 당신을 알고 있습니다. 화를 내야 할지라도 그 영토를 표시하십시오. 그들은 과학자입니다. 그들은 거의 같은 일을하고 있기 때문에 그런 종류의 일을 존중해야합니다. 가능한 모든 수단을 통해 지금 경계를 표시하십시오. 이것이 내가 고칠 것입니다. 이것이 내가 책임질 수없는 것입니다.

2. 과학자들은 알고리즘을 작성 / 테스트합니다. 1-3 개 언어로 자신의 알고리즘을 작성하고자하는 과학자들은 모두 핵심 코드로 변환하는 데 동의 할 수 있습니다. 그것은 그들의 물건을 테스트합니다. 그 외에도 중요한 과학과 건축에 대한 신의 지식을 분리하는 데 도움이 될 것입니다. 코드베이스가 호스로 연결되어 있습니다. 수행해야 할 슬래시와 번이 많이 있습니다. 그들에게 가장 잘 알고있는 것을 사용하여 가장 잘하는 것을 할 수있는 작업 버전을 제공 할 수있는 옵션을 제공하십시오. 책임은 있지만 함께 작업 할 수있는 상자에 지식을 담으십시오.

3. 가능하면 일급 기능을 갖춘 이벤트 중심의 언어를 사용하십시오. 다른 모든 것이 실패하면 실제로 트리거되는 인터페이스 및 상태 메커니즘을 사용하여 이벤트를 트리거하거나 일부 객체에 콜백을 던지는 것은 피의 의미가 없으며 전혀 가능성이없는 코드에 무릎을 꿇을 때 시간을 절약 할 수 있습니다 의지. 과학자들은 파이썬을 좋아하는 것 같습니다. 저수준 수학 집약적 인 C 물건을 붙이는 것이 어렵지 않습니다. 그냥 말해

4. 이 문제 나 비슷한 문제를 해결 한 사람을 찾으십시오. 연구에 진지한 시간을 보내십시오. 이 사람들은 누군가에게서 G2에 대해 들었습니다.

5. 디자인 패턴. 어댑터. 그들을 사용하십시오. 이런 상황에서 많이 사용하십시오.

6. 과학에서 무엇을 할 수 있는지 배우십시오. 더 많이 알수록 코드의 의도를 더 잘 파악할 수 있습니다.

먼저 분석을 수행하십시오.

무엇을 가르 칠지 결정하기 전에 약간의 분석을 할 것입니다. 가장 큰 문제가있는 부분을 파악하십시오. 그것들을 사용하여 어떤 관행을 우선시할지 결정하십시오.

한 번에 몇 가지 변경 사항 만 소개하십시오 (유사한 상황에서 2 주마다 2-3 번의 연습을 수행했습니다) .

SDLC의 프로그래밍 스타일에 대한 변경 수준에 따라 관행을 ~ 3으로 제한합니다. 그들이 그들에게 익숙해지기 시작할 때까지 (나는 새로운 접근법을 배우는 아이디어에 더 익숙해 져서 1-2 주마다 1 개의 새로운 변화를 도입 할 것입니다). 성공의 기준이 무엇인지 식별하는 것도 좋습니다. 연습이 성취해야 할 것 (팀 사기와 같은 부드러운 목표 일지라도). 그렇게하면 효과가 있는지 아닌지를 알 수 있습니다.

• 변경 횟수를 제한하는 이유는 무엇입니까?

이 사람들이 더 나은 프로그래머가되고 싶어하고 학습에 개방되어 있다고 가정하더라도 사람들이 새로운 개념을 배우고 적용 할 수있는 속도와 속도에는 한계가 있습니다. 특히 CS 기반이 없거나 이전에 소프트웨어 개발 수명주기에 참여한 경우.

매주 마무리 모임을 추가하여 해당 관행이 그들에게 어떤 영향을 미쳤는지 논의하십시오.

회의는 잘 진행된 작업과 필요한 작업을 논의하는 데 사용되어야합니다. 그들이 목소리를 내고 협력 할 수있게하십시오. 발생한 문제를 논의하고 계획을 세우고 다음 변경 사항을 미리 봅니다. 회의를 관행과 적용에 집중하십시오. 그들이 관행을 적용함으로써 볼 수있는 이점에 대해 약간의 복음을 전하십시오.

특정 관행이 우선합니다.

IMO (Version Control System)를 올바르게 사용하면 다른 모든 것보다 우선합니다. 모듈화, 커플 링 / 결합 및 기능 / 버그 티켓 추적에 대한 교훈이 뒷받침됩니다.

작동하지 않는 사례를 제거하십시오.

작동하지 않는 관행을 제거하는 것을 두려워하지 마십시오. 비용이 높고 혜택이 적거나 거의 없다면 연습을 제거하십시오.

개선은 과정입니다.

지속적이고 일관된 개선이 프로세스라는 것을 전달하십시오. 가장 큰 문제를 파악하고 해결책을 적용한 후 대기 / 코치 한 다음 반복하십시오. 운동량이 증가 할 때까지 처음에는 고통스럽게 느낍니다. 다가오는 개선과 이미 성공한 개선에 모두 집중하십시오.

첫 번째 단계는 새로운 소프트웨어 방법론에 투자 할 필요성을 팀에 판매하는 것입니다. 귀하의 진술에 따르면 팀에는 아무런 합의가 없으며 코드의 "업그레이드"가 느리게 진행될 수 있도록해야합니다.

나는 개인적으로 배운 어려운 교훈들을 개인적으로 받아들이고 소프트웨어 산업의 문제에 대한 해결책으로 당신이 원하는 각각의 주요 개념들을 소개하고자한다.

예를 들어 두 명의 개발자가 서로 다른 사본을 사용하여 테스트되지 않은 하이브리드 릴리스-> 버전 제어, 분기 및 테스트 소개를 배포했습니다.

누군가 이해하지 못하고 중단을 일으킨 DDD를 도입 한 몇 줄의 코드를 제거했습니다.

어려운 교훈이 충분히 자세하게 나와 있지 않다면,이 규율을 지키지 않았을 때 어떻게 잘못되었는지에 대한 자신의 예를 보여주십시오.

소스 코드 제어는 이미 여러 번 언급 한 1 단계입니다. 함께 일하는 사람들은 전문 개발자가 아닐 수 있지만 많은 엔터프라이즈 또는 민첩한 점보 점보에 응답하지 않습니다. 그들은 저수준 코드 원숭이가 아니며 '당신의 길'을 비행하도록 강요함으로써 그들을 그렇게 취급하려고합니다.

당신은 무엇을 조사해야합니다. 그들이 소스 코드 컨트롤을 사용하지 않았다면 올바른 버전의 코드를 식별하고 (가능한 경우) 가능한 모든 결과물을 찾는 데 오랜 시간이 걸릴 것입니다. 그런 다음 동료들에게 소스 코드 제어를 사용하는 방법을 가르치고 시간 가치가 있다는 것을 확신시켜야합니다. 혜택으로 시작하십시오!

그렇게하는 동안 다른 낮은 매달린 과일을 찾아 그 문제를 해결하십시오.

무엇보다도 자신이해야 할 말을 듣고 상황을 개선하기 위해 노력합니다. 그들이하는 일에 우표를 붙이려 고해도 걱정하지 마십시오.

행운을 빕니다!