[Flutter] 소프트웨어 엔지니어링

플러터 엔지니어링 책을 읽게된 계기

지금까지 모바일 개발을 진행하면서 책을 읽으면 개발을 진행한 경험이 많이 없다.

공식문서와 블로그, AI 등 인터넷에서 개발 관련 자료들을 찾아 학습하였고 그것을 개발에 대입하였다.

하지만 플러터라는 프레임워크에 대해서 깊게 들어가본 경험이 없다고 생각한다.

이런 부분의 아쉬움을 달래기 위해 플러터 엔지니어링이라는 책을 구매하였다.

중급자를 위한 책이며, 아키텍처와 엔지니어링에 초점을 맞춰져 있는 책이다.

또한, 애플리케이션 개발 생명주기(LIfe-Cycle), 아키텍처, 설계, 보안 테스트, CI/CD, Native 연동 방식, 위젯 구성 원리등 초급자가 어려울만한 내용들을 주제로 다루고 있다.

이 책의 대상 독자는

책의 첫부분을 보면 작가와 번역가들의 말이 나온다.

그 내용은 플러터를 어느 정도 사용한 독자를 대상으로 하고 플러터를 엔지니어링 관점으로 접근한 책이라는 것.

만약 내가 플러터 개발의 경험이 없다면 이 책을 이해하기 어려울 것이다.

책의 구성

플러터 엔지니어링 기초

• 기본 원리, 작동방식, 적용 방식 등

아키텍처

• 동시성, 병렬성, 의존성 주입, 상태관리
• 아키텍처 전략적 사고, 의사 결정 안내

프로세스

• 규칙, 가이드라인, 지속적인 전달 및 통합
• 테스트 방법로, 효과적인 문서 작성 방법

윤리적인 엔지니어링

• 보안, 취약점

고급 UI

• User Interface, Shador, internationalization
• custom paintin, localization

1.1 소프트웨어 엔지니어링

• 직관적인 사용자 경험, 효율적인 개발 기간, 확장성을 갖고 있음
• Native 개발이 플랫폼 가이드 라인에 중점을 둔다면 Flutter는 자신만의 브랜딩과 사용자 경험을 우선한다.
  • 이 말은 사용성에 초점을 둔다는 것.

• 제약 및 조합 프로그래밍
  • 플러터 설계 방식은 컴포지션 방식(유연하고 독창적인 UI)에 있다.
    • 컴포지션 방식, 간단한 위젯을 결합하여 복잡한 위젯을 만드는 것. 예, TextButton = Material, Inkewll,Padding 이 결합
• Flutter Layout System
  • 플러터는 제약 프로그래밍 방식으로 그려진다.
    • A는 B보다 크고, C는 D 가운데에 배치 된다.
    • 크기와 관련된 제약조건을 부모에서 자식으로 전파 자식 위젯이 제약조건을 충족하도록 크기 조정하여 단방향으로 UI를 효율적으로 배치한다.
    • 이러한 방식 덕분에 반응형 UI와 일관된 레이아웃을 보장한다.
• 명령형 및 선언형 프로그래밍
  • 모바일 애플리케이션 비즈니스 로직은 단계, 조건, 루프 과정을 포함할때가 많다.
  • 명령형은 시퀀스를 자연스럽게 표현하여 로직 작성을 높이고 유지보수성을 높인다.
  • Unit Test가 명령형 시퀀스 예시로 잘볼수있다
  • build 메서드는 중첩된 생성자와 함께 단일 표현식으로 구성된다.
    • 이 뜻은 build 메서드는 보통 하나의 return으로 UI를 표현
    • 여러줄의 로직이 아니라 위젯트리를 하나 반환하는 식
    • 위젯을 생성자 호출 방식으로 위젯안 위젯을 중첩하여 하나만 반환
  • 함수형 및 객체 지향 프로그래밍
    • 함수형 프로그래밍은 순수 함수, 같은 입력을 받으면 항상 같은 결과 출력 사이드 이펙트가 없고 결과는 매개변수에 따라 변경된다. 유지보수, 단순화 , 촤적화
    • 예, StatelessWidget과 같은 순수 함수와 유사한 위젯을 통해 함수형 프로그래밍이 가능 Icon 위젯은 매개변수를 시각적으로 출력해 매핑하는 함수 활용 가능
    • 불변 데이터 구조 강조
      • 위젯클래스 계층과 rect, textstyle 같은 지원 클래스는 불변성을 활용해 UI 신뢰성을 높임
    • Dart Iterable API
      • map, reduce, where 함수 등 Framework에서 리스트의 값을 활용하는 데 자주 사용되는 예시
    • 클래스 상속과 동적 프로토타입을 모두 활용한다.
      • 핵심 API는 클래스 계층 구조로 구축하여 Render object 기본 클래스가 고수준의 기능을 정의하고 RenderBox와 같은 하위 클래스가 특화하는 별도의 기능을 정의해 위치를 표시
      • ScrollPhyics 클래스는 런타임에 앱 상황에 맞춰 유연하게 변화한다. 구조에 맞춰 컴포넌트를 추상화한다.

플러터 엔지니어링 핵심 개념

추상화와 캡슐화

복잡한 UI 디자인을 다루기 쉬운 구성 요소로 만들고 위젯의 내부 상태를 효과적으로 보호함

유지보수성과 사용성 개선

• 추상화
  • 복잡한 시스템을 더 관리하기 쉬운 모델로 단순화
  • 복잡한 UI 엘리먼트를 관리하기 쉬운 위젯으로 단순화
    • ListView, 스크롤 가능한 목록 기능을 쉽게 사용하기 위해 컴포넌트로 추상화
• 캡슐화
  • 데이터와 관련된 연산과 함께 데이터 무결성 보호
  • 플러터에서 위젯 개발로 적용되며, Container 위젯 구현을 예시 Container 위젯은 디자인과 기능을 정의하는 다양한 속성을 캡슐화 개발자는 정의된 속성과 메서드를 활요해 Container를 사용

이벤트 기반 프로그래밍

• 플러터에서 사용자 상호작용은 이벤트 중심 접근 방식으로 처리
  • Listenable 클래스, 애니메이션 시스템의 기반으로 애니메이션 상태 변화를 이벤트로 처리. 구독 모델을 제공해 여러 수신 코드가 특정 이벤트에 반응하는 콜백을 등록할 수 있게함. 기본 데이터나 상태 변화와 동기화되도록 프레임워크의 반응형적인 특성 반영
  • GestureDector 같은 위젯과 상태 관리 도구도 이벤트를 활용해 사용자 입력에 반응

반응형 프로그래밍

• UI 개발 동작 특성을 이끄는 핵심 개념
• 위젯이 변화에 반응하고 사용자 상호작용이나 내부 데이터 변화에 따라 상태와 UI를 업데이트
• 위젯의 생성자에 제공된 새로운 입력이 즉시 해당 위젯의 재구성을 일으켜 하위 위젯 트리로 전파
• 반대로 하위 위젯 변화는 이벤트 핸들러와 상태 업데이트를 통해 트리 위로 전파하여 상위 위젯에 전달
• 다트의 스트림 지원을 활용해 반응형 프로그래밍 모델을 제공
  • SteramBuilder는 이 모델에서 중요한 역할 제공

  Stream<int> stockPriceStream = getStockPriceUpdates();
  
  StreamBuilder<int>(
    stream: stockPriceStream,
    builder: (context, snapshot) {
      if (!snapshot.hasData) return CircularProgressIndicator();
      return Text('현재 주가: ${snapshot.data}');
    },
  );
  
  

  • Stream이 “데이터를 계속 흘려보내고”
  • 위젯이 그 Stream을 “구독(subscribe)”하고
  • 데이터가 바뀔 때마다 “자동으로 다시 빌드(rebuild)”되는 것.

제네릭 프로그래밍

• 제네릭을 사용하여 타입 안정성을 높임
• DropdownButton<T>, T는 데이터 소스의 타입을 나타냄 State<T>, GlobalKey<T> 에서도 제네릭 사용 T는 관련된 위젯이나 상태의 타입을 나타냄.

동시성 프로그래밍

• 다트의 비동기 기능인 Future와 Stream으로 처리됨.
• 네트워크에서 데이터를 가져오거나 장기 실행 작업을 처리할 때 매우 중요.

응집도와 결합도

• 소프트웨어 엔지니어링에서 응집도와 결합도는 유지보수성과 효율성에 중요.
• 응집도
  • 내부의 강도, 모듈의 요소들이 핵심 목적과 얼마나 밀접하게 관련되어 있는지 설명
  • 이상적인 모듈은 높은 응집도를 보인다.
• 결합도
  • 모듈간의 상호 의존성을 나타냄.
  • 낮은 결합도를 유지하려면 모듈의 상호의존을 최소한으로 하여 변경이 될때 부작용 최소화’
• 높은 응집도
  • 특정 기능에 집중된 위젯을 설계해 놓은 높은 응집도를 달성
  • Text 위젯은 기본 스타일을 적용해 텍스트 문자열을 표시하는 기능 담당
  • Image 위젯은 이미지를 표시하는데 전념
  • 책임이 명확하고 목표가 잘 정의되어 있을수록 응집도 높음.
• 낮은 결합도
  • 위젯이 최소한의 의존성만 유지, 독립적으로 작용
  • Material Design에서 시각적 레이아웃 구조로 제공하는 Scaffold 위젯은 FloatingActionButton과 독립적으로 작동 버튼의 아이콘이나 색을 변경해도 Scaffold에 영향을 미치지 않음.
  • 테마는 시각 스타일링에 영향, 기능 영향 없음
  • 위젯은 콜백과 이벤트 값이 정해진 채널로 솥애햐아혐, 이를 통해 위젯은 변경할때 불필요한 효과를 최소화
  • 독립적으로 작동하는 위젯을 만들어야 함.
    • 결제 시스템에 활용할 위젯은 UserDashboard위젯과 결합하지 않아야함.
    • ChatScreen위젯은 메시징 기능만 처리함.
  • 하나의 위젯을 변경하면 불필요하게 다른 위젯에 영향을 미치는가?
  • 각 위젯의 목적과 기능이 잘 정의되고 독립적인가?

관심사 분리와 모듈화

• 소프트웨어 공학에서 코드 조직화, 유지보수성, 확장성을 크게 향상하는 기초 개념

관심사 분리

• 다른 측면의 관심사를 다루는 독립적인 부분으로 분할하는 설계 원칙
• 한 번에 한 영역에 집중하게 하여 프로그램 복잡성을 단순화.
• 상호의존성이 낮아지며 유지보수성 향상
• 예를 들어, 플러터 기반의 할 일 앱에서 SoC(관심사 분리)를 구현하려면, TaskListWidget과 같은 위젯으로 작업을 표시하는 별도의 UI 레이어를 만들고, 비즈니스 로직은 할일 관련 작업을 처리하는 TaskManager 클래스로 캡슐화 가능
• 동시에 데이터 처리는 DatabaseService에 관리.
• 사용자 관리는 LoginService와 같이 재사용 가능한 구성요소를 만들어 모듈화.
• 플러터에서는 모듈화 개념이 기능별 패키지 아키텍처와 함께 사용되며, 모듈이 종종 위젯 형태로 나타낼 수 있음.

모듈화

• 독립적인 기능을 캡슐화하는 별개의 모듈로 나누는 것을 의미.
• 개별 구성 요소의 텍스트, 디버깅, 업데이트가 쉬워짐
• 플러터 위젯은 기본적으로 모듈화, UI나 기능적인 측면을 캡슐화. 사용자 인터네피읏, 비즈니스 로직, 데이터를 구분

디자인 패턴과 전략

• 객체 생성 관리, 객체 간의 통신 작용, 복잡한 상호작용 구성등 설계 문제에 적용할 수 있는 템플릿 역할
• 재사용성, 유지보수성, 유연성
• 플러터에서 훌륭한 사례는 빌더 패턴
  • ListView.builder 위젯에서 빌더 패턴을 사용 위젯 생성 과정에서 빌더 패턴을 자주사용하며 복잡한 객체 구성과 표현을 분리해 동일한 구성 프로세스로 다양한 표현.

효율성, 확장성, 트레이드오프

• 플러터에서 효율성, 확장성, 트레이드오프의 복잡성을 이해해야됨.
• 애플리케이션이 어떻게 자원을 활용하는지(효율성), 확장에 어떻게 적용하는지(확장성), 요구사항 사이의 미세한 균형을 어떻게 관리해야하는지(트레이드오프)
• 재정적인 측면, 자원할당, 인적 노력 등 다양한 요소 포함.
• 상태 관리 기술이나 외부 패키지 통합과 같은 선택을 저울질할 때 플러터에서 특히 중요.
  • 단순성 때문에 setState를 선택하면 확장성에 문제가 발생할 수 있지만, BLoC 같은 고급 방법은 처음에는 복잡하지만 확장성과 유지관리 측면에서 장기적인 이점 제공
  • cached_network_image 라이브러리를 사용하면 효율성과 좋은 사용자 경험을 얻을 수 있지만 업데이트에 따라 유지관리와 호환성에 영향 받을 수 있는 의존성 추가 발생
• 플러터로 개발할때 상황에 따라 다르다라는 점이 매우 중요
• 사용의 용이성, 확장성, 유지보수성 같은 요소를 끊임없이 고민 균형 고려

검증, 확인, 시프트 레프트

• 검증 과 확인 ㅁ도레은 시스템이 모든 명세를 충족하고 목적을 달성하는지 확인하는 과정
• 검증은 시스템이 구축되었고 요구사항을 충족하는지 확인하는 것, 정적테스트
• 확인은 요구사항을 만족하는 올바른 시스템이 만들어졌느지 확인하는 것, 동적 테스트

V & V 모델

1. 요구사항 분석
   1. 애플리케이션 목표와 사용자 문제 이해
2. 애플리케이션 아키텍처
   1. 상태 관리와 내비게이션 전략을 포함한 전체구조 정의
3. 기능 설계
   1. 애플리케이션의 기능의 구현 계획을 상세히 기술, 비즈니스 로직과 인터페이스 포함.
4. 단위 설꼐
   1. 기능을 더작고 테스트 가능한 단위로 분해, 개별 함수나 위젯 대상으로 함.

테스트 단계

1. 단위 테스트
   1. 개별 단위나 구성 요소, 비즈니스 로직의 기능을 검증
2. 위젯 테스트
   1. 위젯이 올바르게 렌더링 되고 기대한 대로 작동하는 지 전체 위젯 구성 요소가 작동하는지 확인
3. 통합 테스트
   1. 애플리케이션 내 결합된 유닛이나 위젯간의 상호작용을 평가해 전체 아키텍처가 작도오디느지 확인.
4. 사용자 인수 테스트
   1. 사용자 요구 충족하는 확인하여 검증

시프트 레프트 (Shifting left)

• 초기 테스트 처럼 개발 생명주기의 앞 단계에 많은 시간을 들이면, 이후 비용과 시간을 많이 줄일 수 있음.
• 문제를 발견한 시점이 도입시점과 가까울수록 비용이 적음
• 디버깅의 복잡성과 사용자 경험에 미치는 잠재적 영향 때문에 뒤로갈수록 비용시간이 올라감.
• 플러터에서 시프트 레프트는 구문 오류와 잠재적 버그를 조기에 발견하도록 정적 코드 분석을 포함하는 것을 의미.
• 코드 리뷰가 필숮거이며, CI 파이프라인에 자동화를 통합해 단위, 위젯, 통합 테스트를 일관되게 실행
• 기능 플래그와 A B 테스트로 새로운 기능을 프로덕션 환경에서 선택적으로 테스트해 광범위한 문제의 위험을 줄임.

플러터 개발 생명주기

• 플러터 개발을 시작하기 전 소프트웨어 개발 생명주기(Software Development Life Cycle)를 이해해야 함.
• SDLC는 애플리케이션을 구축하고 제공하는 데 필요한 일련의 단계를 정의하는 구조화된 프레임워크
• 개발자와 이해관계자에게 로드맵을 제공해 전반에 걸쳐 품질, 횽류성, 예측 가능성을 보장.
• 다야한 SDLC가 있으며 장단점이 이씅ㅁ.

Waterfall model

• 선형 순차적으로 이루어진 모델
• 단계별 접근 방식을 따르며 정확한 요구사항과 통제된 환경에서 효율적

Agile Model

• 유연성과 적응성 강조
• 스프린트라는 작은 주기로 나눠 지속적인 피드백과 서비스를 가능

Spiral model

• 에자일과 워터폴을 결합한 형태
• 리스크 평가를포함하며, 위험성이 높은 프로젝트에 적합.

SDLC 핵심 단계

• 분석
  • 플러터 애플리케이션의 특정 요구와 목표를 이해, 상세한 요구사항과 목표 정의
• 설계
  • 전체 시스템 아키텍처 설계, 사용자 저니 맵 흐름, 상태 관리 접근 방식, 전체 UI/UX 디자인 결정
• 개발
  • 코딩 개발, 기능 구현, 설계 명세서 준수, 단위 테스트, 위젯 테스트
• 테스트
  • 통합 테스트, 베타 테스트 포함
  • 모든 기능 검증
• 배포
  • 배포를 효율적으로 하고자 CI CD 파이프라인 설정을 이단계에 포함
• 유지보수
  • 업데이트 ,버그 수정, 피드백 반영, 충돌 보고, 버그 분석, 성능 측정

SDLC를 플러터 개발에 적용할 때

• 플러터의 고유 기능을 최대한 활용을 하려면 고려해야할 사항이 있음.
• 다양한 플랫폼을 지원하므로 확장 가능성 염두
• 핫 리로드 기능은 빠른 프로토 타이핑과 반복 피드백을 유도하깅 ㅔ효과적
• 애니메이션과 반응성에 관한 성능 요구사항도 중요.

• 적절한 위젯과 상태관리도구를 선택해야함.
• 널 안정성과 같은 다트 언어의 기능과 윚세의 계층 구조 및 코드의 모범 사례를 적용해 명확성과 효율성 확보
• 다양한 기기에서 성능을 최적화 하는 성능 테스트도 포함
• 배포 단계에서 플러터의 다중 플랫폼 코드베이스 공유 기능을 활용해 여러 플랫폼에 효율적으로 배포 가능
• CI / CD 파이프라인을 구축해 멀티 플랫폼의 배포를 효율적으로 관리

플러터 엔지니어링 대 프로그래밍

• 플러터 엔지니어링과 프로그래밍은 프로젝트 내에서 서로 다른 역할과 책임을 나타냄.
• 프로그래밍은 주로 특정 기능을 구현하는 코드 작성하는 작업, 코드 구현과 문제 해결에 초점.
• 플러터 엔지니어는 코드를 작성하고, 시스템 아키텍처와 UI를 설계하며, 프로젝트 구조와 확장성에 관한 전략적 결정을 내립니다.
• 이런 의사결정은 코드 품질, 프로젝트 관리, 혁신에 중점을 두며 중요한 역할을 하게됨.

멀티 플랫폼 접근 방식

• 플러터는 고품질의 인터페이스를 쉽게 개발하는 기능을 제공하는 패러다임을 제시
• 생산성, 창의성, 효율성에 중점을 둔 플러터는 기존 방식을 뒤엎어 쉽게 개발에 접근 가능하게 함.
• 픽셀이 있는 곳이라면 어디든 플러터 활용할 수 잇으며 단일 코드 기반에서 멀티 플랫폼 소프트웨어를 빌드하는 기존 인식을 바꿈.

결론

• 추상화, 캡슐화, 디자인 패턴등 중요한 패러다임을 다뤘음.
• 프로그래밍과 엔지니어링의 차이를 알았음.