협업하는 개발자의 필수역량 중에 하나가 Git을 잘 사용하는 것인 세상이 되었다

Git을 쓰지 않는 회사를 찾기 힘들게 된 것 같다. 물론 모든 회사가 Git 을 쓰지는 않겠지만 적어도 Git 보다 좋은 평을 듣는 Source Vesion Control 프로그램은 듣지 못한 것 같다 

그리고 협업 툴이라는 것은 기본적으로 무엇이 되었든 공통 규칙 즉 Convension 이라는 것이 필요하다. 협업을 한다는 것은 의사소통비용이 소비되기 때문에 사람과 사람간에 의사소통을 잘하는 것으로도 일을 잘한다는 말을 들을 수 있다고 본다 

서두는 여기까지 하고 어떻게 하면 Good Commit Message 를 작성할 수 있는지 그리고 왜 Good Message 를 쓸 줄 알아야 하는지 그 이유와 결론을 내보자 

Good Commit Message를 작성하는 방법이라는 물음으로 아래 블로그글을 참고 해봤다 

 

좋은 git 커밋 메시지를 작성하기 위한 7가지 약속 : TOAST Meetup

git커밋

meetup.toast.com

 

ull.im

울려 퍼지다.
반향하다.
공명하다.

blog.ull.im

두 블로그 모두 공통의 영문 블로그를 참고하고 있다 (https://chris.beams.io/posts/git-commit/

일단 고려사항을 정리하면 

  1. 언어적 특성 
    1. 영어 or 한글 
  2. 문장의 구성
    1. 글을 남기는 방법 : 자세하게가 아닌 간결하게 작성하는 것은 한영 구분이 없다 (오픈소스는 전세계에서 사용하는 도구) 
    2. 기본적으로 형태 : 명령문의 형태를 가지고 있다 

개발자가 왜 글쓰기를 고민해야 하지? 라는 물음을 한다면 일단 좋은 Git Commit을 써야 하는 이유부터 생각해 보자 

  • Commit Log 의 가독성을 위해서 
  • 더 나은 협업과 리뷰 프로세스를 가진 팀이 되기 위해서 
  • 더 쉬운 코드 유지보수를 하기 위해 히스토리 관리를 하기 위해서 

이런저런 이유를 나열 하면 끝이 없을 것 같고 크게 가독성 / 조직 화합 / 유지보수성 이 3가지를 생각했다

즉, 내가 한 일을 잘 나타내기 위해 작성하는 짧은 글쓰기로서 필요하다고 주장한다 

위 블로그의 내용의 기반이 영어로 되어있고 내용을 읽어보면 내가 딱히 수정을 하거나 더 요약할 필요성을 느끼지 못해 그렇다면 영어가 아닌 한글로 Commit Log를 남기려면 어떻게 해야할까? 라는 질문으로 수정해본다

먼저 좋은 Git Commit Messge를 위한 보편적인 노력으로 나열해 보면 

  1. 제목과 본문을 한 줄 띄워 분리하기
  2. 제목은 글 기준 25자 이내로 
  3. 제목 끝에 . 금지 
  4. 제목은 명령조로 
  5. 본문은 36자 마다 줄 바꾸기 
  6. 본문은 어떻게 보다 무엇을, 왜에 맞춰 작성하기 

1. 제목과 본문을 한 줄 띄워 분리하기 

  • 꿀팁과 같은 내용으로 제목 + 빈줄 + 설명문으로 구성하면 log 내용을 한줄로 보기로 출력하면 제목만 볼 수 있어서 좋다. 만약 줄 바꿈이 되지 않으면 설명문까지 모두 한줄에 포함되어 나오기 때문에 가독성이 저하된다
  • git log --oneline / git shortlog 
    • 이 명령어로 보면 가독성 차이를 알 수 있다 

2. 제목은 글 기준 25자 이내로 

  • 영문기준 50자로 가이드 되어 있어 한글 기준으로 절반으로 줄이면 좋을 것 같다 

3. 제목 끝에 . 금지 

  • 문법적인 접근으로 제목에는 보통 점을 찍지 않는다 

4. 제목은 명령조로 

  • 영어에서 가져와서 첫 단어를 동사원형으로 쓰기 위함이다 
  • 명령문보다는 설명문의 느낌으로 하자 
    • "인증 메소드 고쳐라" 가 아닌 "인증 메소드 고쳤다" 의 느낌 
    • "인증 메소드 수정" 으로 한글에서는 문장보다 구문이 낫다 

5. 본문은 36자 마다 줄 바꾸기

  • git 은 자동으로 메시지 내용은 줄 바꿈을 해주지 않는다 
  • 영문기준 72자 이기 때문에 한글로는 절반인 36자로 잡았다 
  • 가독성을 위해 끊이 쓰기를 하는 것이다 

6. 본문은 어떻게 보다 무엇을, 왜에 맞춰 작성하기 

  • 이 부분은 내용 전달에 대한 부분이라 글쓰기를 하는 방법으로 보인다 
  • 무엇을? 왜? 와 같은 부분은 결론을에 대한 접근 방법이고 어떻게? 는 과정에 대한 접근이라면 간결한 의미 전달을 위해 결론 부터 쓰는 접근으로 이해된다 

추가로 영어일 경우 문법적으로 아래를 권장한다고 한다 

  1. 동명사 보다는 명사를 사용
    1. ing 를 붙이기 보다는 순수 명사 그대로 쓰기 
  2. 부정문 Don't 를 사용하기 
    1. 명령조 어투에서 반대인 부정 명령구를 써서 부연 설명없이 간단하게 부정하기 
  3. 오타 수정과 같은 경우 correct miss spelled 가 아닌 그냥 Fix typo로 쓰기 
    1. 사소한 것에 대해 구구절절 설명할 필요는 없다

이제 좋은 Commit Message를 위한 영어 동사를 한글로 변환한다면 어떻게 접근하고 사용해야 될까? 

일단 영어 방법의 경우 위의 블로그 설명대로 동사로 시작하는 convention을 적용해도 전혀 손색이 없어 보인다. 한글일 때도 한번 동일하게 접근해보자 

ex) Fix 를 사용하기 - 이 경우 올바르지 않은 동작을 고친 경우에 사용하게 된다 

  1. Fix 회원 가입 
  2. 고침 회원가입
  3. 수정 회원 가입 
  4. 회원 가입 수정  

위의 예시는 Fix를 나타내고 싶은데 한글과 어울림이 애매한 어투가 느껴진다 

일단 4번의 경우가 가장 일반적인 한글 사용법으로 보인다. 즉 명령조로 시작하니 한글 구조에서 어색함이 느껴진다. 그렇다고 평서문의 느낌으로 단순한 구문인 회원 가입 수정이라고 목적어 + 서술어로 표현하니 이 또한 동사원형 표현법과 비교해 어색함이 느껴진다

영어의 동서원형이 제목과 같은 키워드 성격이 있어서 처음부터 눈에 들어오는 부분이 있어 생각의 연결성을 이어주었으나 한글은 실제 행위의 서술어가 마지막에 있어 문장 전체를 보아야 정확히 의미 전달이 종료된다 

영어의 동사원형을 말머리에 썼을 때 어떻게 눈에 들어오는 지 나열해보고 그 통일성 있는 규칙에서 차이를 발견해 보자 

Make config object read-only
make 'floating patch' message informational
Make values optional in ViewPropTypes
make read() be called indefinitely if the user wants so
make IsolateData store ArrayBufferAllocator

이런 형태를 보면 차이가 느껴지는가? 실제 내용을 떠나서 막연히 뭔가 만들었구나 하고 생각이 시작 된다. 조금만 더 명분을 찾아 보자 

언어적인 Convention을 만드려는 이유는 무엇인가? 

주관적인 생각이지만 의사소통 비용을 줄이기 위함이라고 생각한다. 사람간의 대화에 있어 의사소통 비용이라는 것은 때로는 피로감을 만들 수 있다.

즉, 이번에 이 얘기를 했으니 다음에 또 반복해서 하지 말자식의 약속을 암묵적으로 하게되면 적어도 까먹지 않게 일정한 패턴을 가지거나 암기하기 쉬운 구조가 있어야 한다 (방정식의 풀이를 가르쳐 줄 때 "근의 공식"을 써라 이런 대화도 비슷한 이치) 

아래와 같은 형태는 어떠한가? 

[수정] 회원 가입의 버그를 수정

명령문처럼 어떤 작업이었는지 한 눈에 읽히고자 했고 어설픈 영어 번역을 할 필요없이 국어적인 주어 / 목적어 / 서술어로 제목 키워드를 보충 설명이 되었다고 보이는가? 

동사원형이 아닌 명사로 행위의 목적이 무엇인지 표현했다

간단하면서 한 줄로 명확하게 의미 전달을 하고자 한다면 그리고 제목과 본문 중에 더 중요한 내용이 제목이라면 블로그의 글쓴이가 작문이 아니라 패턴으로 접근해야 한다는 말이 공감이 되었다 

 "결국 커밋 로그 메시지의 작성은 작문이 아니라 패턴으로 접근해야 합니다. 자신의 커밋이 가진 특징을 패턴에 대입시켜 단어들을 뽑아내는 것이죠. 작문의 결과로 보면 너무 단순해서 부족해 보일지 몰라도, 여러 사람들에게 쉽게 읽히고 쉽게 이해되도록 하기에는 패턴화된 단순한 문장이 훨씬 낫습니다"

출처: <https://blog.ull.im/engineering/2019/03/10/logs-on-git.html>

작성한 당사자가 아닌 제 3자가 이해할 수 있는 문장을 만드는 것 자체가 쉬운일이 아닌 것이고 그것이 필요한 이유는 의사소통 비용을 줄이기 위함이라면 최선의 단어를 쓰는 것과 최선의 문장 혹은 문단을 고민해서 남에게 보여주는 부분은 코딩을 잘해서 보여주기 위함과 비슷한 이치를 가진다 

좋은 Message를 작성해서 내가 한 일에 대해 의미 전달을 잘 하는 것으로 내가 작성한 변수 혹은 함수나 인터페이스를 통해 더 발전된 협업과 대화를 하고자 함이기 때문에 같이 프로그래밍 일을 하는 사람의 기본 소양으로도 부합된다  

다만 차이가 있다면 컴퓨터 언어적 이쁜 코드를 작성하는 것이 아니라 함축적이지만 이해하기 쉬운 패턴으로 의미를 전달하는 방법이 중요한 차이점이라면 그 차이가 이 글의 질문이었던 Good Commit Message 에 대한 답이 되었을까?

질문 : 좋은 커밋 메시지는 무엇인가요? 
대답 : 함축적이지만 이해하기 쉬운 패턴으로 만들어진 문장 or 문단 

마지막으로 한글과 영어로 구분한 예시 표로 마무리한다

아래의 내용을 보면 중복되는 의미의 단어들도 많이 보인다. 해당 부분은 센스있게 자주 쓰이는 단어를 쓰면 되겠다

단어

한글

영어

Fix

[고침] 통계 캐시 버그를 수정

[고침] 로그 항목을 변경

[고침] 깨진 검색 경로를 고침

Fix stat cache

Fix changelog entry

Fix broken jsiexecutor search path.

보통 올바르지 않은 동작을 고친 경우에 사용합니다.

Add

[추가] 에러 내용을 추가

[추가] ListView 미사용 문구를 추가

Add error description to Image onError callback

Add displayName to ActivityIndicator

Add deprecation notice to SwipeableListView

코드나 테스트, 예제, 문서 등의 추가가 있을 때 사용합니다

Remove

[삭제] 불필요한 문구 삭제

[삭제] 사용하지 않는 파일 삭제

Remove unnecessary italics from child_process.md

Remove useless additionnal blur call

Remove unneeded .gitignore entries

Remove unused variable

Remove duplicated buffer negative allocation test

코드의 삭제가 있을 사용합니다. Clean’이나 Eliminate’를 사용하기도 합니다. 보통 A 앞에 unnecessary, useless, unneeded, unused, duplicated’가 붙는 경우가 많습니다.

Use

[사용] message 전달에 가짜 Event 사용

[사용] error 내용 전달에 객체 writer 사용

Use fake MessageEvent for port.onmessage

Use object writer for thrown errors

Use ru_stime for system CPU calculation

Use relative path for SCRIPTDIR

특별히 무언가를 사용해 구현을 하는 경우입니다.

Refactor

[개선] 쓰레드 관리 체게를 개선

Refactor tick objects prune function

Refactor thread life cycle management

Refactor QueryWrap lifetime management

Refactor argument validation

Refactor thread life cycle management

Refactor MockNativeMethods in Jest

전면 수정이 있을 때 사용합니다.

Simplify

[단순화] 쓰지 않는 검사를 단순화 시킴

[단순화] GetCPUInfo 반복을 개선

Simplify code and remove obsolete checks

Simplify the setup of async hooks trace events

Simplify heap space iteration

Simplify TriggerNodeReport()

Simplify AliasedBuffer lifetime management

Simplify loop arithmetic in GetCPUInfo

복잡한 코드를 단순화 할 때 사용합니다. Refactor의 성격이 강하나 이보다는 약한 수정의 경우 이용하면 좋습니U.

Update

[수정] acorn 버전을 수정

Update acorn to 6.1.0

개정이나 버전 업데이트가 있을 때 사용합니다. Fix와는 달리 Update는 잘못된 것을 바로잡는 것이 아니라는 점에 주의해야 합니다. 원래도 정상적으로 동작하고 있었지만, 수정, 추가, 보완을 한다는 개념입니다. 코드보다는 주로 문서나 리소스, 라이브러리등에 사용합니다.

Improve

[향상] http/1 호환성을 향상

Improve compatibility with http/1

Improve Unicode handling

Improve test coverage in perf_hooks

Improve validation of report output

Improve performance of test-crypto-timing-safe-equal-benchmarks

Improve color detection

Improve Android Network Security config

Improve Accessibility

Improve iOS's accessibilityLabel performance by up to 20%

향상이 있을 때 사용합니다. 호환성, 테스트 커버리지, 성능, 검증 기능, 접근성 등 다양한 것들이 목적이 될 수 있습니다.

Make

[변경] 읽기 전용 설정의 속성을 변경

Make config object read-only

make 'floating patch' message informational

Make values optional in ViewPropTypes

make read() be called indefinitely if the user wants so

make IsolateData store ArrayBufferAllocator

주로 기존 동작의 변경을 명시합니다.

새롭게 뭔가를 만들었을 때는 Make 대신, Add 사용해야 합니다.

Implement

[향상] 캐시를 사용해서 get data 속도를 향상

Implement requiresMainQueueSetup in RCTTVNavigationEventEmitter to satisfy Xcode warning

Implement an in-memory cache store to save parsed and validated documents and provide performance benefits for repeat executions of the same document

코드가 추가된 정도보다 더 주목할 만한 구현체를 완성시켰을 때 사용합니다.

Revice

[문서수정] Readme.md 파일을 수정

Revise deprecation semverness info in Collaborator Guide

Update와 비슷하나 문서의 개정이 있을 때 주로 사용합니다.

Correct

[타입변경] 회원 Id 리턴 타입을 문자열에서 정수로 변경

Correct grammatical error in BUILDING.md

Correct parameters, return types in crypto.md

Correct styling of _GitHub_ in onboarding doc

Correct buffer changelog ordering

Correct async_hooks resource names

주로 문법의 오류나 타입의 변경, 이름 변경 등에 사용합니다.

Ensure

[성능보장] 탐색 알고리즘의 복잡도를 nlogn 보장  

[기능보장] 에러를 던졌을 알람발생을 보장

Ensure quiet always takes precedence

Ensure cookies with illegal characters are not sent to okhttp

Ensure require.main for CJS top-level loads

Ensure Stream.pipeline re-throws errors without callback

Ensure options.flag defaults to 'r' in readFile

무엇이 확실하게 보장받는다는 것을 명시합니다. if 구문처럼 조건을 확실하게 주었을 때에도 사용 될 수 있습니다. ‘Make sure’도 같은 용도로 사용될 수 있습니다.

Prevent

[방지] 회원 검색 로직에서 무한루프를 방지

Prevent multiple connection errors

Prevent constructing console methods

Prevent event loop blocking

Prevent a potential error in event handling if Object.prototype is extended.

Prevent an infinite loop when attempting to render portals with SSR.

특정한 처리를 못하게 막습니다

Avoid

[회피] 불필요한 밸리데이션 체크를 회피

Avoid flusing uninitialized traces

Avoid overrun on UCS-2 string write

Avoid race condition in OnHeaderCallback

Avoid memory leak on gc observer

Avoid materializing ArrayBuffer for creation

‘Prevent’는 못하게 막지만, ‘Avoid’는 회피합니다. if 구문으로 특정한 동작을 제외시키는 경우에도 사용 할 수 있습니다.

Move

[이동] Member Package 위치를 Account 이동

Move test-process-uptime to parallel

Move function from header to source file

Move async hooks trace events setup to pre_execution.js

move initialization of node-report into pre_execution.js

코드의 이동이 있을 때 사용합니다.

Rename

[이름변경] Member 클래스 이름을 Members 복수로 변경

Rename node-report to report

Rename location to trigger

Rename node-report suite to report

이름 변경이 있을 때 사용합니다.

Allow

[허용] 서비스 레이어의 로깅을 필수로 하도록 허용

Allow the output filename to be a {Function}

Allow Node.js-like runtimes to identify as Node.js as well.

Allow passing parseOptions to ApolloServerBase constructor.

Allow an optional function to resolve the rootValue, passing the DocumentNode AST to determine the value.

Make와 비슷하지만, 허용을 표현할 때 사용합니다.

Verify

[검증추가] 메모리 누수 방지를 위한 방어코드를 추가

Verify heap buffer allocations occur

검증 코드를 넣을 때 주로 사용합니다.

Set

[속성변경] 회원 가입 상태 확인 배치 스케줄러의 시간을 12시간으로 변경

Set tls.DEFAULT_ECDH_CURVE to 'auto'

변수 값을 변경하는 등의 작은 수정에 주로 사용합니다.

Pass

[전달] 회원가입 API 요청값을 응답값에도 재활용하도록 전달

Pass the response toolkit to the context function.

파라메터를 넘기는 처리에 주로 사용합니다.

'Developer > Git' 카테고리의 다른 글

Git Repository 등록방법  (0) 2018.07.15

T 아카데미 

https://tacademy.sktechx.com/live/player/onlineLectureDetail.action?seq=129 



Props 


리액트 네이티브를 아직 많이 다루어 보지 않았지만 형태를 보다보면 extends Component(상속) 를 해서 사용자 정의 Component를 만들 수있는 것으로 보인다.   


Props 은 Property의 약자로 보이나 C#의 Property와는 비슷한듯 하면서 차이가 있는 것 같다 이해가 되면 그 부분은 따로 남기자. 

아래 공식문서에 있는 코드를 보면 


import React, { Component } from 'react';

import { AppRegistry, Image } from 'react-native';


export default class Bananas extends Component {

  render() {

    let pic = {

      uri: 'https://upload.wikimedia.org/wikipedia/commons/d/de/Bananavarieties.jpg'

    };

    return (

      <Image source={pic} style={{width: 193, height: 110}}/>

    );

  }

}


이것만 보고 어떤 느낌인지 알겠는가?? 먼저 만들어진 공식문서에는 parameter 란 표현이 있다 이런 인자값의 내용이 바뀌는 것에 대응하는 parameter 부분이 props 이 된다. (리액트 네이티브 제작 원론 이라는 책을 보면 정적인 Component를 동적으로 변화시키기 위해 props을 사용할 수 있는 것으로 표현하고 있다. 


React Native에서 Image 태그만 보고 HTML의 img 태그를 떠올리기 쉽다 물론 React의 개념으로는 Image - img 가 대응하고 동일한 웹페이지를 보여주는 것은 맞지만 import { AppRegistry, Image } from 'react-native'; 구문을 보면 Image는 react-native의 Component 이다. 

즉 Component 라는 생각을 가지고 접근하면 Image라는 Componenet는 source, style이라는 속성을 가지고 있다고 볼 수 있다. 


위의 코드에서도 source={pic} 로 사용되고 중괄호 속의 {pic} 의 부분은 동적으로 들어갈 수 있다. 

여기까지의 내용으로 정리하자면 props 이라는 것은 하나의 특징을 가지고 있다. 

Componet안에 사용자 정의 속성을 만들어서 해당 부분을 동적으로 사용(바인딩) 할 수 있다. 


공식문서의 예를 하나 더 보자 점점 C#의 속성이랑 비슷한 느낌이 들기 시작한다 


import React, { Component } from 'react';

import { AppRegistry, Text, View } from 'react-native';


class Greeting extends Component {

  render() {

    return (

      <Text>Hello {this.props.name}!</Text>

    );

  }

}


export default class LotsOfGreetings extends Component {

  render() {

    return (

      <View style={{alignItems: 'center'}}>

        <Greeting name='Rexxar' />

        <Greeting name='Jaina' />

        <Greeting name='Valeera' />

      </View>

    );

  }

}


Greeting 이라는 사용자 정의 Componenet를 만들었다. 그리고 default Component에서 불러냈으며 name이라는 Props을 각각의 Componet에서 사용하고 있다. View Componet는 HTML의 div와 대응하기 때문에 일정 영역에(Center Style 속성을 사용 중이다) 단순히 텍스트로 이름들이 출력된다. 


여기서는 this의 props에 접근하고 그것의 이름은 name으로 정했다 즉 Greeting 이라는 Componenet를 사용할 때 name 속성에 값을 넣으면(지금은 문자열) 해당 Component가 출력될 때 변경되는 값을 동적으로 보여준다 즉 Component를 동적으로 재사용할 수 있게 된다는 것이다. 


공식문서에서 이해된 내용을 정리하면 

1. Component 안에 사용자 정의 속성을 만들 수 있다. 

2. Parameter 라고 설명한 이유를보면 Component를 사용할 때 해당 속성에 값을 실어 보낼 수 있다. Componet != (일반적인)Class 로 보이지는 않는다. 다만 class extends Componet 는 XML 처럼 component를 사용할 수 있고 속성을 매개변수로 값을 실어서 보낼 수 있다.  


name을 props으로 사용했고 Greeting 이라는 Componenet를 커스터마이징해서 사용 했다. 이 Component는 Class 처럼 재사용이 가능하고 필요에 따라 수정하거나 값을 바꺼서 동적인 화면을 구성할 수 있다. 


마지막으로 한줄로 정리 

Props 는 react-native의 Componet를 사용자 정의로 해서 재사용가능하게 만들 수 있고 해당 Componenet를 사용할 때 속성을 동적인 화면으로 보일 수 있게 해준다. 


자마린은 종말될 것으로 예언하고 있다 




'Developer > Mobile(React Native)' 카테고리의 다른 글

강의 공부 자료  (0) 2018.07.27
React Native -Props-  (0) 2018.07.17
리액트 네이티브 개발자와 대화  (0) 2018.06.29
React Native의 성능관점에서 장점  (0) 2018.06.28
개발환경(Windows)  (0) 2018.06.28

처음에 Git 에서 프로젝트를 생성하고 연결할 때 Expo와 같은 툴로 프로젝트를 생성하고 나서 이미 만들어진 개발 프로젝트를 원격저장소와 연결하려고 하면 오류가 난다 master에 올리려는데 제대로 올라가지 않는 경우가 있다 


일단 해결한 방법은 git에 아래와 같이 reset을 해서 빈 폴더를 연결하고 나서 expo의 프로젝트 안의 파일을 복사에서 넣은 다음에 push 하는 방식으로 프로젝트를 초기 생성했다 


Git에 대해 조금더 공부가 필요하다...


git remote add {upstream} https://github.com/SickRage/SickRage.git
git fetch {upstream}
git checkout master
git branch -u {upstream}/master
git reset --hard {upstream}/master
git pull

출처 : https://github.com/SickRage/SickRage/wiki/FAQ's-and-Fixes#update-problems-try-this

'Developer > Git' 카테고리의 다른 글

Good Commit Message  (1) 2021.02.06




'Developer > Mobile(React Native)' 카테고리의 다른 글

강의 공부 자료  (0) 2018.07.27
React Native -Props-  (0) 2018.07.17
리액트 네이티브 개발자와 대화2  (1) 2018.07.17
React Native의 성능관점에서 장점  (0) 2018.06.28
개발환경(Windows)  (0) 2018.06.28

React Native는 진화된 하이브리드 앱 개발 프레임워크다 

기존의 웹에서 하이브리드를 지원하기 위해 다양한 개발방법이 나타났다 

React Native와 비교할 군은 크게 2가지 이다. 


1. HTML5 웹 앱 

   기본적으로 HTML CSS Javascrip를 통해 만든다 

   따로 앱스토어에서 설치하지 않아도 되지만 DOM이라는 웹 문서를 로딩하는 것이 성능적으로 최악의 단점이다. 

   네이티브 기능을 사용하지 못하고 웹브라우저에서 보는 것과 비슷하다 


2. WebView 기반의 하이브리드 앱 

   단순히 모바일 플랫폼만 공유되는 것이 아니라 Web 기술과 Native 기술도 혼합되어 있다 

   네이티브 앱처럼 동작하는 것처럼 보일 수 있으나 Native 위의 WebView에서 호출하는 구조이다.  느리다고 한다 


React Native의 React는 기본적으로 1. React 웹 앱 기반이다. 즉 HTML과 CSS JavaScript를 사용한다. 

단, 차이가 있다 아래는 그 차이가 기존 웹 앱의 성능을 개선한 점을 설명한다. 


React Native가 다른 웹앱 or 하이브리드 앱보다 성능적으로 좋은 이유 


1. 기존 웹 처럼 HTML을 사용하지만 실제로 호출되는 것은 Native Module 이다. 

   <div> <span> 등 HTML의 태그 형식을 따르지만 실제로 보여지는 것은 Native View의 Component로 치환된다. 

   실제 코딩도 HTML과 똑같지 않고 치환되는 Tag 선언을 따른다. 즉 네이티브를 호출할 수 있는 React Native만의 문법이 있다. 

   내부에서는 Native를 호출해서 구현하기 때문에 빌드과정에서 Object C나 Java 코드와 같은 Native Code와 매칭된다. 


2. 기존의 Native앱은 Compile 과정을 거치기 때문에 변경사항이 생기면 새로 Compile을 거쳐 수정사항을 반영하는 시간이 있었다 

   React Native는 이런 Recompile 거치지 않고도 View의 Tag를 변경해서 Reload 만으로 수정사항을 확인할 수 있다 이것은 개발 생산성과 연관이 있다. 


3. Native Code로 치환되고 그것과 Bridge로 연결된다는 이점은 필요한 Native Module을 직접 제작하거나 다른 사람이 만든 Module을 재활용할 수 

   있다는 이점이 있다.

   React Native는 Java나 Object-C, Swift로 만든 Module과 연결되기 때문에 자유도가 높은 Native 개발이 가능하다. 단 웹언어외에 Native 언어로도 

   구현을 해야 한다는 개발자의 역량에 대한 부담이 생긴다. 이것은 장점이자 단점이다.  


4. 위에서 웹 언어의 DOM 문서의 로딩이 오래 걸린다는 단점을 지적했다. 그 부분을 개선하기 위해 React Native는 Virtual DOM이라는 기술이 도입되었다

   이 기술은 간단히 말하면 해당 페이지의 모든 DOM을 로딩하는 것이 아니라 변경사항이 생긴 DOM 부분만 로딩해서 반영한다. Virtual DOM은

   WebView 그리고 웹앱의 단점을 커버해줄 것으로 보인다 단 객관적인 비교 수치나 테스트는 해봐야 알 것 같다 


5. WebView를 거치지 않고 Native Module을 호출할 수 있기 때문에 WebView에 의한 지연이 개선되었고 내부에서 JS Thread와 UI Thread가 단일 Process

  로 동작하는 것이 아니라 병렬과 비동기로 동작 하도록 설계되었기 때문에(이 부분은 확인해 볼 것) 단일 Thread의 단점을 커버해준다. 즉 이런 부분을 

  보면 기존의 하이브리드 앱과 웹앱의 단점을 모두 개선하려고 노력한 부분이 느껴진다.   

'Developer > Mobile(React Native)' 카테고리의 다른 글

강의 공부 자료  (0) 2018.07.27
React Native -Props-  (0) 2018.07.17
리액트 네이티브 개발자와 대화2  (1) 2018.07.17
리액트 네이티브 개발자와 대화  (0) 2018.06.29
개발환경(Windows)  (0) 2018.06.28

React Native 란? 

JavaScript 기반의 React를 사용해서 모바일 앱을 제작할 수 있는 오픈소스 프로젝트 (또는 어플리케이션 개발 프레임워크)

단순히 라이브러리라고 하기에는 개발 방법에 대한 구체적인 방법과 지원해주는 API들이 있으니 프레임워크라고 생각 할 수 있다 다만 React Native는 자체적으로 Native App 개발에 대한 컴파일러나 인터프리터가 해석해서 개발자가 작성한 코드가 프레임워크에 의해서 Callee(피호출자)로 동작하는게 아니라 실제 Native API를 Caller로서 동작하기에 API들을 호출하기 위한 집합 즉 라이브러리 성격이 강하다. 

위의 구분을 타이트하게 잡을 필요는 없을 것 같다 MFC도 Win32API를 감싼 라이브러리로 해석되지만 개발 프레임워크로도 불린다. 즉 개발규칙의 자유도가 저수준인지 고수준인지에 대한 구분정도에서 프레임워크와 라이브러리를 구분하면 될 것이다. 

관련 링크 : http://web-front-end.tistory.com/63 (그나마 구분이 가는 내용)



특징 (https://facebook.github.io/react-native/)

1. React Native는 모바일 웹앱, HTML5앱, 또는 Web View 기반의 하이브리드앱이 아니라 실제 Native 성격의 앱 개발이 가능하다 


2. JavaScript Code가 변했을 때 다시 빌드를 하지 않아도 재로딩만으로도 변경된 코드를 적용가능하다 


3. 필요한 경우 JavaScript Code에서 연결되는 Bridge를 통해 Object C, Swift, JAVA로 작성된 Native Module를 작성하거나 호출할 수 있습니다. 



필수설치 모듈 (Windows에서 Android App 개발) 

1. Chocholatey (https://chocolatey.org/)  -> 이걸안쓰면 Yarn 이라는 Package Manager도 있다 

  

 - Package Manager로 인터넷 연결이 되어 있으면 쉽게 Node.js, Python2 를 설치 가능 

   choco install -y nodejs.install python2 jdk8

   Node.js (오프라인 설치 : https://nodejs.org/en/download/)

   Python2 (오프라인 설치 : https://www.python.org/downloads/windows/)


2. NPM 설치 (Node.js command prompt) 

   npm install -g react-native-cli


3. JDK8 설치 

   Java Develop Kit (http://www.oracle.com/technetwork/java/javase/downloads/index.html)

   최신버전인 10버전으로 설치를 진행해봤으나 React Native 빌드시 Java 버전 오류 발생으로 8로 다운그래이드

   JAVA_HOME 환경변수로 등록

 

3. Android Studio 

   Android Studio (https://developer.android.com/studio/)

  • Android SDK
  • Android SDK Platform
  • Performance (Intel ® HAXM)
  • Android Virtual Device

4. Android SDK Manager 

    Android 6.0 (Marshmallow)  

  • Google APIs
  • Android SDK Platform 23
  • Intel x86 Atom_64 System Image
  • Google APIs Intel x86 Atom_64 System Image

   Android SDK Build-Tools (Marshmallow의 API 레벨이 23이다 안드로이드는 플랫폼(OS)과 API 레벨이 같이 올라간다)

  • 23.0.1

   ANDROID_HOME 환경변수로 등록


5. 애뮬레이터 설치  

  Android Studio 에서 Android Virtual Device Manager -> Create Virtual Device 

  주의사항 : HAXM 이 설치 되어야 하며 그 기술을 사용하려면 Intel Virtualization Technology 기능이 켜져 있어야 함 

                해당 기능이 꺼저있으면 경고문구가 나오고 Mainboard의 BIOS 메뉴에서 켜줘야 함


6. 편집기 설치 

   Visual Studio Code 설치 (https://code.visualstudio.com/docs?start=true)

   확장기능 설치해서 툴 기능 강화 

   디버깅이 지원된다. (필수) 

(https://www.vobour.com/vscode-%EC%B6%94%EC%B2%9C-%EC%9D%B5%EC%8A%A4%ED%85%90%EC%85%98%EA%B3%BC-%EC%84%B8%ED%8C%85-vscode-recommended-e)


7. Expo 설치 (https://expo.io/tools#xde) 

   Expo는 필수설치는 아니지만 쉽게 빌드해서 스마트폰까지 배포가 가능하다 

   Expo를 사용하면 장점 

   - 지원해주는 Library 설치

   - 쉽게 빌드 

   - 쉽게 배포?? 아닐 수 도 있음 

(이것은 수정하고자 한다. 따로 네이티브 모듈을 붙여서 배포하려면 expo에서 detach를 해야 한다고 한다. 이런 제한된 기능 때문에 데모앱을 만들기에 좋고 실제 서비스 앱용으로는 적합하지 않을 수 있다. )  

   - Expo에서 개발자 옵션에서 핫 리로딩을 키려면 Ctrl + M 을 누른다


8. Git을 통한 소스버전 관리 설치 

   Git (https://git-scm.com/downloads)

   VS Code에서 GitHub 연동으로 버전관리 설정 


9. 단위 테스트를 위한 Jest 연동 

   JavaScript Unit Test (http://jestjs.io/)


10. Create Project (Example)

   프로젝트를 설치할 경로를 정하고 (ex: C:\dev 생성)

   

   react-native init AwesomeProject


11. Run react-native App 

   애뮬레이터가 켜저있는 상태에서 command 명령 실행

  

   cd AwesomeProject 

   react-native start         (이것은 npm start로 해도 동일하고 하지 않아도 아래 run-android를 하면 동일하게 시작된다.) 


   새로 cmd 창을 뛰어서 아래 명령어로 빌드 한다

   

   react-native run-android (공식 문서에는 이 명령어만 되어 있음 실행시 node.js 구동)

   

   Hello world 같은 화면이 구동되면서 기본 셋팅 완료


12. react-native 확인 -> 기본설치 되는 폴더의 설치되어 있는 node module에 가면 있다   

   C:\WeatherProject\node_modules\react-native

오픈소스를 봐야하는 일이 많아졌다 

이전과는 다른 차원이다... 

그래서 앞으로 가이드라인을 잡아보고자 한다 


Open Source 접근 방법


경험적 발견

- 다른 사람의 소스를 본다는 것 

- 구조화된 형태를 가지고 있음 

- 확장성에 대한 규칙과 패턴이 소스에 있음


발전적 발견 

- 라이브러리와 같은 형태로 사용하는 방법에 대해 배움

- 오픈 소스의 형태들 통해 내가 해야 하는 것에 대한 문제해결의 아이디어를 얻을 수 있음    



CFCMD 라는 4가지 규칙을 만들겠다 


C : Concept - 해당 기능이 뭘 요구하고 뭘 보여주는지 생각한다 즉 why와 How에 대한 내용을 정리한다 


F : Find - UI 화면이나 기능 구조 혹은 개요와 같은 내용을 찾는다 


C : Classify - 기능이나 구조를 분리해서 본다 각각의 블럭들을 나누고 그 블록의 제목을 정한다 (기능과 구조의 분할 or 분류) Divide


M : Merge - 각각 분리된 기능이나 구조를 다시 합친다 혹은 어떻게 합쳤을까? 에 대해 고민한다 (집약 or 통합) Integrate 


D : Draw - 분리하고 합친 내용을 표가 되는 ERD가 되든 뭔가 설명할 수 있는 그림으로 그린다 (산출물) Output


5가지 규칙을 만들었고 관련 내용으로 정리를 한다 


그리고 선행 학습으로 UML이나 ERD 책 좀 보자...  

'Developer > 오픈소스' 카테고리의 다른 글

오픈소스 관련 사이트  (0) 2017.10.28

http://www.kossa.kr/



http://www.oss.kr/oss_business10_62


'Developer > 오픈소스' 카테고리의 다른 글

오픈소스 분석 방법  (0) 2017.12.11

+ Recent posts