특히 Haskell에서 대규모 기능 프로그램을 설계 / 구성하는 좋은 방법은 무엇입니까?
나는 많은 튜토리얼을 겪어 보았습니다 (Real World Haskell과 함께 두 번째로 내가 가장 좋아하는 구성표 작성)-대부분의 프로그램은 상대적으로 작고 단일 목적입니다. 또한, 나는 그중 일부가 특히 우아하다고 생각하지 않습니다 (예 : WYAS의 광대 한 조회 테이블).
이제 다양한 소스에서 데이터를 수집하고, 정리하고, 다양한 방식으로 처리하고, 사용자 인터페이스에 표시하고, 유지하고, 네트워크를 통해 통신하는 등 다양한 부분으로 더 큰 프로그램을 작성하려고합니다. 변화하는 요구 사항에 대해 읽을 수 있고, 유지 보수 가능하며, 적응할 수있는 코드와 같은 최고의 구조?
큰 객체 지향 명령 프로그램에 대한 이러한 질문을 다루는 상당히 큰 문헌이 있습니다. MVC, 디자인 패턴 등과 같은 아이디어는 관심사 분리 및 OO 스타일의 재사용 성과 같은 광범위한 목표를 실현하기위한 적절한 처방입니다. 또한 새로운 명령형 언어는 ‘초대 의견으로는 하스켈이 적합하지 않은 것처럼 보이는 리팩토링 스타일’에 적합합니다.
하스켈에 해당하는 문헌이 있습니까? 기능 프로그래밍 (모 노드, 화살표, 응용 프로그램 등)에서 사용 가능한 이국적인 제어 구조의 동물원은 어떻게이 목적에 가장 적합합니까? 어떤 모범 사례를 추천 할 수 있습니까?
감사!
편집 (이것은 Don Stewart의 답변에 대한 후속 조치입니다) :
@dons 언급 : “모나드는 주요 건축 설계를 유형으로 포착합니다.”
제 질문은 순수한 기능 언어로 주요 건축 디자인에 대해 어떻게 생각해야 하는가입니다.
여러 데이터 스트림과 여러 처리 단계의 예를 고려하십시오. 데이터 스트림에 대한 모듈 식 파서를 일련의 데이터 구조에 쓸 수 있으며 각 처리 단계를 순수한 기능으로 구현할 수 있습니다. 하나의 데이터에 필요한 처리 단계는 그 값과 다른 데이터에 따라 다릅니다. 일부 단계에는 GUI 업데이트 또는 데이터베이스 쿼리와 같은 부작용이 따라 와야합니다.
데이터와 구문 분석 단계를 좋은 방법으로 묶는 ‘올바른’방법은 무엇입니까? 다양한 데이터 유형에 적합한 작업을 수행하는 큰 함수를 작성할 수 있습니다. 또는 모나드를 사용하여 지금까지 처리 된 내용을 추적하고 각 처리 단계가 모나드 상태에서 다음에 필요한 것을 얻도록 할 수 있습니다. 또는 크게 별도의 프로그램을 작성하고 메시지를 보낼 수 있습니다 (이 옵션은별로 좋지 않습니다).
그가 연결 한 슬라이드에는 우리가 필요로하는 것들이 있습니다 : “디자인을 타입 / 함수 / 클래스 / 모나드에 매핑하기위한 관용구” 관용구는 무엇입니까? 🙂
답변
Haskell의 대규모 프로젝트 엔지니어링 과 XMonad 의 설계 및 구현에서 이에 대해 조금 이야기합니다 . 대규모 엔지니어링은 복잡성 관리에 관한 것입니다. 복잡성을 관리하기위한 Haskell의 주요 코드 구조화 메커니즘은 다음과 같습니다.
타입 시스템
- 유형 시스템을 사용하여 추상화를 시행하여 상호 작용을 단순화하십시오.
- 유형을 통해 주요 불변량 적용
- (예 : 특정 값은 일부 범위를 벗어날 수 없음)
- 특정 코드는 IO가없고 디스크를 건드리지 않습니다.
- 안전 강화 : 확인 된 예외 (아마도 / 둘 중 하나), 혼합 개념 피하기 (Word, Int, Address)
- 좋은 데이터 구조 (지퍼와 같은)는 예를 들어 범위를 벗어난 오류를 정적으로 배제하기 때문에 일부 테스트 클래스를 불필요하게 만들 수 있습니다.
프로파일 러
- 프로그램의 힙 및 시간 프로필에 대한 객관적인 증거를 제공하십시오.
- 특히 힙 프로파일 링은 불필요한 메모리 사용을 방지하는 가장 좋은 방법입니다.
청정
- 상태를 제거하여 복잡성을 크게 줄입니다. 순전히 기능적인 코드는 구성하기 때문에 확장됩니다. 필요한 것은 일부 코드를 사용하는 방법을 결정하는 유형입니다. 프로그램의 다른 부분을 변경할 때 신비하게 부서지지는 않습니다.
- “모델 / 뷰 / 컨트롤러”스타일 프로그래밍을 많이 사용하십시오. 가능한 빨리 외부 데이터를 순수하게 기능적인 데이터 구조로 구문 분석하고 해당 구조를 조작 한 다음 모든 작업이 완료되면 렌더 / 플러시 / 직렬화합니다. 대부분의 코드를 순수하게 유지
테스팅
- QuickCheck + Haskell Code Coverage는 유형으로 확인할 수없는 것을 테스트하고 있는지 확인합니다.
- GHC + RTS는 GC를 수행하는 데 너무 많은 시간을 보내고 있는지 확인하는 데 좋습니다.
- QuickCheck를 사용하면 모듈에 대해 깨끗하고 직교하는 API를 식별 할 수 있습니다. 코드의 속성을 설명하기 어려운 경우에는 너무 복잡 할 수 있습니다. 코드를 테스트 할 수있는 깔끔한 속성 세트가 될 때까지 리팩토링을 유지하십시오. 그런 다음 코드도 잘 설계되었습니다.
구조용 모나드
- Monads는 주요 아키텍처 디자인을 유형으로 캡처합니다 (이 코드는 하드웨어에 액세스하고이 코드는 단일 사용자 세션 등입니다).
- 예를 들어 xmonad의 X 모나드는 시스템의 어떤 구성 요소에 어떤 상태가 보이는지 정확하게 설계합니다.
타입 클래스와 실존 타입
- 타입 클래스를 사용하여 추상화를 제공하십시오. 다형성 인터페이스 뒤에 구현을 숨기십시오.
동시성 및 병렬 처리
par쉽고 컴포저 블 한 병렬 처리로 경쟁에서 이기기 위해 프로그램에 몰입 하십시오.
리 팩터
- Haskell 에서 많은 리팩토링을 할 수 있습니다 . 유형은 현명하게 유형을 사용하는 경우 대규모 변경 사항이 안전하게 유지되도록합니다. 이것은 코드베이스 확장에 도움이됩니다. 리팩토링으로 인해 완료 될 때까지 유형 오류가 발생하는지 확인하십시오.
FFI를 현명하게 사용하십시오
- FFI를 사용하면 외래 코드를 쉽게 재생할 수 있지만 외래 코드는 위험 할 수 있습니다.
- 반환되는 데이터의 형태에 대한 가정에서 매우주의하십시오.
메타 프로그래밍
- 약간의 템플릿 Haskell 또는 제네릭이 상용구를 제거 할 수 있습니다.
포장 및 유통
- Cabal을 사용하십시오. 자체 빌드 시스템을 굴리지 마십시오. (편집 : 실제로 시작하기 위해 지금 Stack 을 사용하고 싶을 것입니다 .).
- 좋은 API 문서에 Haddock 사용
- graphmod 와 같은 도구는 모듈 구조를 보여줄 수 있습니다.
- 가능한 경우 Haskell 플랫폼 버전의 라이브러리 및 도구를 사용하십시오. 안정된베이스입니다. (편집 : 요즘에도 안정적인베이스를 가동 하기 위해 Stack 을 사용하고 싶을 것 입니다.)
경고
-Wall코드의 냄새를 깨끗하게 유지하는 데 사용하십시오 . 더 많은 확신을 얻으려면 Agda, Isabelle 또는 Catch를 볼 수도 있습니다. 보풀과 같은 검사 는 개선을 제안 할 위대한 hlint를 참조하십시오 .
이러한 모든 도구를 사용하면 구성 요소 간의 상호 작용을 최대한 제거하면서 복잡성을 처리 할 수 있습니다. 이상적으로는 매우 큰 순수 코드 기반을 가지고 있으며 이는 구성하기 때문에 유지 관리가 매우 쉽습니다. 항상 가능하지는 않지만 목표로 삼을 가치가 있습니다.
일반적으로 : 시스템의 논리 장치를 참조 가능한 가장 투명한 투명한 구성 요소로 분해 한 다음 모듈로 구현하십시오. 컴포넌트 세트 (또는 내부 컴포넌트)의 글로벌 또는 로컬 환경은 모나드에 맵핑 될 수 있습니다. 핵심 데이터 구조를 설명하려면 대수 데이터 형식을 사용하십시오. 이러한 정의를 널리 공유하십시오.
답변
Don은 위의 대부분의 세부 사항을 제공했지만 Haskell의 시스템 데몬과 같은 정말 유용한 상태 저장 프로그램을 수행 한 2 센트입니다.
-
결국, 모나드 변압기 스택에 살고 있습니다. 맨 아래에는 IO가 있습니다. 위의 모든 주요 모듈 (파일 의미 모듈이 아닌 추상적 인 의미)은 필요한 상태를 해당 스택의 계층에 매핑합니다. 따라서 모듈에 데이터베이스 연결 코드가 숨겨져 있으면 MonadReader Connection m => …-> m … 유형을 초과하도록 작성하면 데이터베이스 함수는 다른 함수의 함수없이 항상 연결을 얻을 수 있습니다 모듈의 존재를 알고 있어야합니다. 데이터베이스 연결을 수행하는 하나의 계층, 다른 구성, 병렬 및 동기화의 해결을위한 다양한 세마포어 및 mvar, 다른 로그 파일 처리 등을 수행 할 수 있습니다.
-
오류 처리를 먼저 파악하십시오 . 더 큰 시스템에서 Haskell의 가장 큰 약점은 Maybe와 같은 거대 오류를 포함하여 과다한 오류 처리 방법입니다. 누락 된 값을 의미합니다). 먼저 어떻게 할 것인지 파악하고 라이브러리와 다른 코드가 사용하는 다양한 오류 처리 메커니즘에서 어댑터를 어댑터로 설정하십시오. 이렇게하면 나중에 슬픔의 세계를 구할 수 있습니다.
부록 (설명에서 발췌; Lii & liminalisht 덕분에 ) —
큰 프로그램을 스택의 모나드로 분리하는 다양한 방법에 대한 자세한 설명 :
Ben Kolera 는이 주제에 대한 실질적인 소개를 제공하고 Brian Hurt 는 lift사용자 지정 모나드에 모나드 동작 문제에 대한 솔루션을 설명합니다 . George Wilson 은 mtl사용자 정의 모나드 종류가 아닌 필요한 유형 클래스를 구현하는 모나드에서 작동하는 코드를 작성 하는 방법을 보여줍니다 . Carlo Hamalainen 은 조지의 연설을 요약 한 짧고 유용한 메모를 작성했습니다.
답변
Haskell에서 큰 프로그램을 설계하는 것은 다른 언어로하는 것과 다르지 않습니다. 큰 프로그래밍은 문제를 다루기 쉬운 부분으로 나누는 방법과 함께 맞추는 방법입니다. 구현 언어는 덜 중요합니다.
즉, 큰 디자인에서는 유형 시스템을 사용하여 올바른 방식으로 만 조각을 맞추는 것이 좋습니다. 동일한 유형의 것으로 보이는 것을 다르게 만들기 위해 newtype 또는 phantom 유형이 포함될 수 있습니다.
코드를 리팩토링 할 때 순도는 큰 이점이므로 가능한 한 많은 코드를 순수하게 유지하십시오. 순수 코드는 프로그램의 다른 부분과 숨겨진 상호 작용이 없기 때문에 리팩토링하기 쉽습니다.
답변
나는 이 책 에서 처음으로 구조적 기능 프로그래밍을 배웠다 . 정확히 당신이 찾고있는 것이 아닐 수도 있지만 기능 프로그래밍 초보자에게는 스케일과 무관하게 기능 프로그램을 구성하는 것을 배우는 가장 좋은 첫 번째 단계 중 하나 일 수 있습니다. 모든 추상화 수준에서 디자인은 항상 명확하게 배열 된 구조를 가져야합니다.
함수형 프로그래밍 기술
답변
저는 현재 “기능 디자인 및 아키텍처”라는 제목의 책을 쓰고 있습니다. 순수한 기능적 접근 방식을 사용하여 큰 응용 프로그램을 구축하는 방법에 대한 완벽한 기술을 제공합니다. 우주선을 처음부터 제어하기위한 SCADA와 같은 애플리케이션 ‘Andromeda’를 구축하면서 많은 기능 패턴과 아이디어를 설명합니다. 내 기본 언어는 하스켈입니다. 이 책은 다음을 다룹니다 :
- 다이어그램을 사용하여 아키텍처 모델링에 접근
- 요구 사항 분석;
- 임베디드 DSL 도메인 모델링;
- 외부 DSL 설계 및 구현
- 효과가있는 서브 시스템으로서의 모나드;
- 기능적 인터페이스로서의 무료 모나드;
- 화살표가있는 eDSL;
- 자유 모노 eDSL을 이용한 제어 역전;
- 소프트웨어 거래 메모리;
- 렌즈;
- State, Reader, Writer, RWS, ST 모나드;
- 불완전한 상태 : IORef, MVar, STM;
- 멀티 스레딩 및 동시 도메인 모델링;
- GUI;
- UML, SOLID, GRASP와 같은 주류 기술 및 접근 방식의 적용 가능성;
- 불완전한 하위 시스템과의 상호 작용
당신은 책의 코드에 익숙해 질 수 있습니다 여기에 , 그리고 ‘안드로메다’ 프로젝트 코드.
2017 년 말에이 책을 끝 마칠 것으로 예상됩니다. 그렇게 될 때까지 내 기사 “기능 프로그래밍의 설계 및 아키텍처”(Rus)를 읽으 십시오 .
최신 정보
온라인으로 책을 공유했습니다 (처음 5 장). 레딧에 대한 게시물 보기
답변
가브리엘의 블로그 게시물 확장 가능한 프로그램 아키텍처 는 언급 할 가치가 있습니다.
Haskell 디자인 패턴은 하나의 중요한 방식으로 주류 디자인 패턴과 다릅니다.
기존 아키텍처 : 유형 A의 여러 구성 요소를 결합하여 유형 B의 “네트워크”또는 “토폴로지”를 생성합니다.
Haskell 아키텍처 : A 유형의 여러 구성 요소를 결합하여 동일한 유형 A의 새로운 구성 요소를 생성합니다.
외관상으로는 우아한 건축물이 이러한 동질성 감각을 보이는 라이브러리에서 종종 상향식으로 떨어지는 경향이 있다는 사실이 종종 저를 놀라게합니다. Haskell에서 이는 특히 “top-down architecture”로 간주되는 명백한 패턴으로 mvc , Netwire 및 Cloud Haskell 과 같은 라이브러리에서 캡처되는 경향이 있습니다 . 즉,이 답변이이 스레드의 다른 스레드를 대체하려는 시도로 해석되지 않기를 바랍니다. 단지 도메인 전문가가 구조적 선택을 라이브러리에서 추상화하는 것이 이상적입니다. 제 생각에 대형 시스템을 구축하는 데있어 실제로 어려움은 이러한 라이브러리를 모든 실제적인 문제와 비교하여 아키텍처 “좋은 점”으로 평가하는 것입니다.
으로 liminalisht이 코멘트에 언급, 카테고리 디자인 패턴은 비슷한 맥락에서 주제에 가브리엘에 의해 또 다른 게시물입니다.
