레이블이 sw engineering인 게시물을 표시합니다. 모든 게시물 표시
레이블이 sw engineering인 게시물을 표시합니다. 모든 게시물 표시

[컴][유틸] Mermaid - markdown 형식으로 diagram 을 그릴 수 있다.

글로 그림 / 차트 그리기 / chart / draw chart / 챠트 / diagram / 다이어그램 / visio 대안

Mermaid

markdown 같은 형식으로 flow chart 를 그릴 수 있다.
vscode 에서 plugin 을 지원한다.

현재 지원하는 Diagrams

  • Flowchart
  • Sequence diagram
  • Class Diagram
  • State Diagram
  • Entity Relationship Diagram
  • User Journey
  • Gantt
  • Pie Chart

[컴][툴] github issue 를 활용하는 방법

github issue / github 사용법 / github 로 개발하는 방법 / github 로 collaborator 로 이슈 해결 / 협업 툴 / 그룹 웨어 / vscode 에서 github 를 사용하는 방법 /triaging / triage



github issue 를 활용하는 방법

vscode team 의 github 활용방법

vscode Wiki 를 읽으면 vscode team 이 어떻게 github 를 사용하는지 알 수 있다.
  • https://github.com/microsoft/vscode/wiki/Issues-Triaging
    • close 할 때 이유를 label 로 달아준다.(예를 드려면 duplicate)등
    • issue 를 분류할때 type label 을 사용한다. type label 에 특정 색으로 통일. (vscode team 은 grey 를 사용, bug 같이 특정 의미가 들어가면 grey+red 등으로 만듦)
    • feature area 라는 것을 둬서, 기능에 따른 분류를 하고, 그에 따라 label 을 배정했다. 그리고 이것도 마찬가지로 색을 통일했다.
    • iteration 이나 release 를 표현하기 위해 milestone 을 사용한다.
      • iteration 은 대체로 1개월 주기이다.(참고)
      • 주로 Backlog milestone 에 있는 issue 들이 바로 iteration milestone 으로 가게 된다. (iteration milestone 은 November 2019 처럼 날짜를 사용)
      • Backlog 에 있는 것중 Roadmap 에 부합하는 녀석들이 iteration 으로 넘어간다.
      • 만약 Backlog 에 있는 것이 Roadmap 과 전혀 관련없는 것이 명확하다면 close 한다.
      • Backlog Candidate 는 community 가 원하는 기능중에 vscode team 이 작업하지 않으려 한것들에 대한 투표를 진행한다. upvote 가 20개 이상이면 이것은 Backlog 로 옮겨진다.
    • important issue 에 대한 정의를 적어놓고, 부합되면 important label 을 붙인다.
    • 도움을 요청하는 label 도 있다.
      • investigation-wanted 는 재현을 할 수 없거나, 세팅등이 너무 오래걸려서 재현할 시간이 없거나 하면 이 label 을 사용한다.
      • help-wanted 는 community 에 도움을 요청하기 위한 용도
    • bug 를 wont-fix label 을 붙이고 close 하는 경우
      • 비용대비 효용이 없을때 wont-fix 를 사용한다.
    • upstream issue 
      • 이슈가 package 나 library 에 연관돼서 생기고, 이것만 고쳐서는 안되는 이슈인 경우 `upstream` 을 붙인다. 그래서 package 나 library 가 이슈를 인지해서 이것을 issue 로 처리하면 close 한다. 또는 이것이 고쳐질 가능성이 없어도 close 한다.
  • https://github.com/microsoft/vscode/labels
  • https://github.com/microsoft/vscode/milestones
  • https://github.com/microsoft/vscode/projects
  • https://github.com/microsoft/vscode/wiki/Roadmap
    • Roadmap wiki 를 계속해서 update 해 나간다. 그래서 그 해에 골들을 세운다.
    • 최소 1달에 1번 roadmap 을 review 하고 update 한다.
  • https://github.com/microsoft/vscode/wiki/Development-Process
    • 매 iteration 전에, 이번 iteration 에서 어떤 기능에 우선순위를 둘 것인지를 정하고, 어떤 버그를 고칠 것인지 정한다.
    • 고치려고 하는 bug 에는 milestone 을 붙인다.
    • 새로운 기능에는 issue 를 새로 만든다.
      • 그리고 plan-item 이라는 label 을 붙인다.
      • plan-item 에는 자세한 checklist 를 넣게 된다.(예시)
    • 이렇게 bug, plan-item, feature-request 에 milestone 을 할당한다.
    • iteration
      • 첫주차 : 이전 iteration의 결과를 지켜보고, critical issue 들을 해결한다.
      • 2주차: 개발
      • 3주차: 개발
      • 4주차: 마무리
        • 기능테스트등을 하고, 문서를 update 한다.
        • insider channel 에서 가능한 pre-release 를 만든다. 그리고 user 에게 test 를 요청한다.
    • iteration milestone 이 할당된 후에 우선순위와 관련된 label 을 추가한다.
      • importatant 가 가장 먼저 해결된다.
    • iteration plan : iteration 마다 iteration plan 이라는 이슈를 하나 만들고, 그 안에서 issue 들을 모아서 checklist 로 관리한다. 각각의 item 들은 하나의 issue 이다. 이것은 관리자가 처리해야 하는 issue 같은 느낌이다.
  • Issue Tracking · microsoft/vscode Wiki · GitHub
    • 여러 repository 에 대한 label 을 일괄적으로 관리하기 위해 Github Label Manager 를 사용한다.


See Also

  1. gatsby: https://www.gatsbyjs.org/contributing/triaging-github-issues/
  2. gitlab: https://docs.gitlab.com/ee/development/contributing/issue_workflow.html





[컴] 조직 개편, 정비시 CIO 로서 역할과 관련된 tips


cio /cto / 관리자에게 도움이 되는 글 / 팁들 / 팁 / it 문화를 받아드릴때 주의해야 하는점.

조직 개편, 정비시 CIO 로서 역할과 관련된 tips

조직의 개편에서 놓치면 안되는 것들에 대한 것들이다. 요즘의 회사들이 IT 와 연관성이 많아지면서, 조직의 구조나 문화가 달라지고 있다. 관련돼서 도움이 될만한 이야기이다. 

성공을 위해 필요한 3가지 리더십 자질

출처 : The 2018 State CIO Survey - NASCIO 에서

  1. 소통자(communicator)
  2. 관계 관리자(Relationship manager)
  3. 전략가(Strategist)
  4. 동기부여자(Motivator)
  5. 외교에 능한사람(diplomat)
  6. 변화 관리자(Change Manager)
  7. 협상가(Negotiator)
  8. 조력자(Facilitator)
  9. 기술 전문가(Technologist)
  10. 교육자(Educator)

딜로이트 컨설팅의 CTO 빌 브릭스의 충고

  1. CIO는 애자일 기법 도입과 변화와 관련해 다른 임원과 부서로부터 필요한 것이 무엇인지 파악해야 한다
  2. 새로운 시스템안에서 성과측정을 위한 새로운 지표를 수립하여 측정해야 한다고 조언

카네기 멜론 대학교의 테퍼 경영대학원 비즈니스 기술 조교수 얀 황

  1. 적절한 목표를 수립하기 위해 CIO가 이해관계자에 집중해야 한다
  2.  특정 비즈니스 프로세스를 구조조정하려는 경우라도 CIO는 그 변화가 생태계 전체에 미치는 영향에 대해 생각해 보아야 한다. 프로세스 호환성, 보안공백 등.
  3. 임원들이 당면한 구조조정 요건을 넘어 좀더 장기적인 게임을 해야 한다
    1. CIO는 IT와 비즈니스 니즈가 지속적으로 빠르게 변화하기 때문에 최소한 1-2년 전에 무엇이 효과가 있을지 고려해야 한다
  4. 모두가 새로운 구조에 맞추도록 해야 한다. 따라서 직원에게 기술뿐 아니라 문화 변동에 대해서도 교육하는 프로그램이 필요하다. 그렇지 않으면 가치를 창출할 수 없다
    1. 직원들이 새롭게 구성된 덜 위계적인 구조 내에서 일하는 방식, 이런 환경에서 직원들이 교육하는 방식 등이 충돌을 일으켰다

References


  1. 조직 개편·정비, 'CIO 과제'로 부상 중··· 피해야 할 7가지 실수 - CIO Korea, 2020-01-29

[컴] 해외 유명 IT 기업 연봉


넷플릭스 연봉 / netflix 복지 / netflix salayr /

넷플릭스 연봉


대략 $300,000 달러/연






[컴] 딜로이트의 2018년 글로벌 CIO 설문 조사 결과

리딩그룹 / 디지털 리딩 / IT회사 / 선두기업

딜로이트의 2018년 글로벌 CIO 설문 조사 결과


디지털 선도 기업(digital vanguard organizations)은 2가지 차별화된 특징을 갖고 있다.
  1. 명확하게 정의된 디지털 전략 a clearly defined digital strategy 
  2. 신기술 활용과 디지털 역량 구축 작업을 IT 조직이 이끌도록 한다 an IT organization viewed by the business as a leader in harnessing emerging technologies and building digital capabilities.
  • 디지털 선도 기업은 글로벌 IT 기업 중 9.7%만이 해당한다.
  • 디지털 선도 기업의 디지털 리더가 다른 기업과 다른점 
    • 업무 우선순위priorities
    • 마음가짐mindsets
    • 문화적 특성cultural attributes

디지털 선도기업의 특징

  1. 성장에 대한 마음가짐Growth mindset
  2. 확대/축소적 관점
  3. 최고의 인재를 유입시키는 문화
    •  디지털 리더 조직의 절반 이상(55%)이 창의적이고 의욕을 고취하는 환경 덕분에 인재를 유지할 수 있었다고 답했다.
    • 조직 문화가 최고의 기술 인재를 유입, 유지, 참여시키는 데 핵심이라는 사실을 알고 있다.
    • 디지털 리더 조직의 절반 이상(55%)이 창의적이고 의욕을 고취하는 환경 덕분에 인재를 유지할 수 있었다고 답했다.
  4. 탄탄한 기술 기반
  5. 강력한 참여 계획

References

  1. '디지털 선도' 기업의 5가지 특징 - CIO Korea, 2019-05-09
  2. 5 ways leading organizations excel at digital | CIO, 2019-05-03

[컴][interview] 면접 실패 사례 - 회사 입장

인터뷰 / 인터뷰의 잘못 된 점 / interview / 고용 / 면접방법의 잘못 / 실패사례 / 아마존 프라임 에어 창업자 실패 / 데니얼 부시뮬러 / 고용을 잘못 한 사례 / 드론


인터뷰 실패 사례


개인적으로 이런 글들을 좋아한다. 우린는 사실 측정할 수 없는 것들을 측정하려 많은 노력을 한다. 그리고 그 측정방법이 옳았다는 것을 증명하기 위해 잘된 경우들만을 늘어놓는다.

하지만 경험 해 본 우리는 그것이 전적으로 옳지 않다는 것을 안다. 하지만 믿을 만한 근거를 제시하기가 쉽지 않다.

그런 의미에서 이런 글들이 많아져야만 우리는 더 나은 방법을 찾을 수 있다고 생각한다.

from: ref. 1, Robert Sweeney, Founder and CEO at Facet

I turned down Daniel Buchmueller for a job at Netflix. After a 60 minute interview I was on the fence, so I concluded that he "wasn't senior enough." He went to Amazon instead where he co-founded Amazon Prime Air (their drone delivery service) and was #2 on Fast Company's "Most Creative People" list. At some point, we programmers are going to have to admit that we really can't judge another programmers technical abilities in a 60 min interview. We end up hiring programmers that are good at interviewing, but not necessarily good at doing the job. And we miss out on engineers like Daniel.

해석

나는 넷플릭스에 있을 때 Daniel Buchmueller 를 채용하지 않았다. 1시간의 인터뷰를 한 후에도 나는 확신이 들지 않았다. 그래서 나는 그가 senior 에 적합하지 않다고 결론 내렸다.

그는 대신에 Amazon 에 갔고, 그는 Amazon Prime Air (그들의 드론 배달 서비스)를 공동설립 했고 Fast Company 의 "가장 창조적인 사람" 리스트에서 2위를 차지했다.

어떤 점에서 우리 프로그래머들은 우리가 다른 프로그래머들의 기술적인 역량을 60분의 면접후에 판단할 수 없다는 것을 인정해야만 한다.

우리는 "면접에서 좋아 보이지만 일을 잘하지는 않는 프로그래머들"을 고용하는 것을 관뒀다.   그리고 우리는 (여전히?) Daniel 같은 엔지니어를 놓친다.


Refrences

  1. Robert Sweeney on LinkedIn, 2019-05-03

[컴] 소프트웨어 팀장(Leader) 가 하지 말아야 하는 행위

PL업무 / sw 개발 / 프로젝트 리더

소프트웨어 팀장(Leader) 이 하지 말아야 하는 행위

‘팀 플레이’라는 안티패턴

  • 팀에 인원이 너무 많은 경우, 개발자들이 서로 반목하면서 동일한 코드를 업데이트하려 경쟁하게 된다.
    --> 검토할 코드가 많아지고, 그 누구도 코드를 일일이 검토해 통합하기 원하지 않게 된다.
  • 마이크로서비스 아키텍처를 구성하는 것은 개발자에게 숨쉴 공간을 준다. 독립적으로 자신이 맡은 코드 작업을 할 수 있다.

‘분할 관리’라는 안티패턴

  • 더 중앙에서 통제를 하고, 더 중앙에서 테스트를 하는 것이 필요하다.
  • 일부 개발자를 지정, 부분들이 가능한 원활하게 함께 작동할 수 있도록 통합을 지속적으로 모니터링하는 일을 맡긴다. 
  • 부분들이 함께 작동하도록 만드는 일은 부분들을 구현하는 것만큼 힘든 일이다. 
  • 개발자들을 동일한 방향으로 계속 유도하는 것 자체가 하나의 ‘일’이다.

‘비전을 따르라’는 안티패턴

  • 모든 개발자가 이런 상상 후, 단 몇 줄의 코드로 모든 기능을 구현하는 ‘초능력’에 대해 상상한다.
  • 계획 수립은 번거로운 일이다. 그러나 나중에 코드를 디버깅하는 것보다 빨리 할 수 있다. 때로는 다짜고짜 저지르기보다 그저 앉아 있는 게 나을 수 있다. 

‘교과서대로’라는 안티패턴

  • 스펙을 만드는 데 몇 달을 소비하고도, 모든 것이 거의 마무리되었을 때 새로운 각도나 문제를 발견하게 된다.
  • 유능한 관리자는 방법론을 선택한 후, 이 방법론이 실패할 가능성에 대비한다.
  • 어느 누구도 항상 성공할 수는 없다. 대비가 중요하다.  

‘프로세스 신뢰’라는 안티패턴

  • 창의성을 방해할까 두려워 세부 사항을 계속 추적하지 않으면 악성 결과가 초래될 수 있다.
  • 책임자는 항상 지연을 초래하는 많은 장벽, 장애물, 문제에 직면하게 된다. 책임자의 도전과제는 효율적으로 일어나는 일을 모니터링하고, 현명한 결정을 내리기에 충분한 정도로 세부사항을 계속 추적하는 방법을 찾는 것이다.
  • 소프트웨어 개발 매트릭스가 부정확할 수 있다.
  • 그러나 지나치게 많은 기대를 하지 않으면, 누가 무슨 일을 하고 있는지 추적할 수 있도록 도와준다.

‘측정하지 않은 것은 관리할 수 없음’이라는 안티패턴

  • 적합한 점수를 파악하는 것은 애초 문제를 해결하는 것만큼 어렵다.
  • 정말 지독한 팀은 더 정확한 평가를 위해 서로를 경쟁시키기도 한다. 이는 팀웍이나 협업에 도움이 되지 않는다.
  • 가장 큰 위험은 개발자들이 힘든 일이나 예측하기 어려운 일을 피하게 되는 것이다.
  • 분기말, 연말에 충분한 점수를 얻게 되지 못할까 우려하는 행태가 번기는 것이다.
  • 해결책은 이런 매트릭스를 지나치게 신뢰하지 않는 것이다. 점수를 추적 관리할 수는 있다. 그러나 이런 점수를 절대적인 척도로 간주해서는 안 된다.

'어리석은 일관성은 편협한 사람들의 망상’이라는 안티패턴

  • 코드에 어느 정도 일관성이 있을 때, 패턴과 시각적인 리듬의 예측성이 높을 때, 코드를 더 쉽게 판독할 수 있다.
  • ESLint 등을 이용하자.

‘기준이 구원자’라는 안티패턴

  • 실행 코드의 품질에 거의 영향을 주지 않는 기준을 강제하는 것은 좋지 않다. 
    • 필자생각: 코드의 일관성을 유지하는 것과의 균형을 잡는 것이 중요할 듯 하다.
  • 스페이스의 위치 같은 것은 사람을 위한 것이다. 사람들이 지나치게 많은 것을 주장하지 않도록 만드는 데 목적이 있다. 
  • 기준을 사용하고 싶다면, 적용하기 쉽고, 실제 유의미한 세부 사항만 신경 쓰도록 단순하게 만들어야 한다

‘스택 단순화’라는 안티패턴

  • 코드 기반의 ‘순정함’을 유지하면, 그 대가로 속도와 효율성을 잃게 된다. 
  • 사용자를 만족시킬 수 있다면, 코드 기반의 이탈을 어느 정도 용인하는 것이 합리적이다. 
  • 절충의 가치가 있는 때를 파악하는 것이 핵심이다.

‘개발자가 직접 도구를 선택’이라는 안티패턴

  • 나중에 문제가 발생한다. 코트린(Kotlin)을 좋아하는 개발자가 팀을 떠나고, PHP를 좋아하는 사람이 코드를 물려 받으면 이를 해독할 수가 없다.
  • 적합한 스킬을 가진 사람들로 팀을 구성해 유지하는 경우에도, 자바스크립트 개발자들은 스위프트(Swift)로 작성된 코드를 확인할 때 고생을 하게 된다.
  • 지나치게 개방적으로 모든 것을 수용해서는 안 된다.

‘성공의 열쇠는 동기 부여’라는 안티패턴

  • 동료가 한 장의 티켓을 여러 티켓으로 분리해야 한다고 주장하는 것을 보았다. 봉급에서 보상을 받기 위해서이다. 이 동료는 풀 리퀘스트, 지원 티켓, 애자일 매트릭스를 ‘조종’하는 데 있어 ‘달인’이었다.
    • 필자생각: 소프트웨어 개발에 경영을 위한 측정을 하겠다는 생각은 어리석다. 왜냐면 그것은 개발자 마음대로 쪼개고 늘리고 할 수 있는데다, 복잡도는 높다. 그래서 룰을 만들어도 쉽게 룰을 피해갈 수 있으며, 완벽한 룰을 만들면 할 수록 개발은 유연성을 잃고, 제대로 된 개발을 할 수 없게 되기 때문이다.
  • 개발자들에게 진짜 동기를 부여하는 것은 수수께끼 같은 난제이다. 
  • 개발자들은 흔히 자신만의 생각을 갖고 있으며, 누구보다 도구를 잘 이해한다. 
  • 우리가 할 수 있는 최선은 ‘파트너십’에 대한 의식을 불어넣고, 큰 그림을 이해하도록 만드는 것이다. 
  • 그런 후, 이들이 추상적인 목표를 여러 수 많은 깨끗한, 테스트가 완료된, 버그가 거의 없는 코드로 바꿔 놓도록 바래야 한다.

리더를 위한 3가지 팁[ref.2]

  1. 약점을 드러내라.
  2. 조직원을 일괄적으로 대하자.
  3. 사람들이 일을 하는 방식, 선호하는 업무, 이를 가장 효과적으로 처리하는 방법을 파악하고, 영향을 줘서 성과를 내도록 인도하자. 자신의 스타일을 강요하지 말자.
  4. 안정감과 소속감을 부여하자.
    • 직원들이 혼동하지 않도록 하는 것
    • 자신이 하겠다고 말한 일을 하는 것
    • ‘우리’ 같은 소속감을 느끼는 표현을 사용하는 것
    • 다른 사람들의 정체성을 배려한 문화적 겸양을 실천하는 것
    • 진심 어린 칭찬을 많이 하는 것
ref. 3 을 참고한다면, 적어도 서구권에서 리더는 좀 더 assertive(확신적인) 가 되어야 할 듯 하다.

References

  1. SW 프로젝트를 산으로… 서툰 리더십 행태 11가지 - CIO Korea
  2. 기고 | 리더와 관리자의 차이··· 3가지 팁 - CIO Korea, 2020.01.20
  3. The bamboo ceiling - Indian v Chinese bosses in America Inc | Business | The Economist, 2020-02-29





[컴] 테크기업에게 무엇이 적합할까 Teams ? slack ?



테크기업에게 적합한 협업툴

ref. 1 에서 UC 는 microsoft teams 같은 tool 을 이야기 하는듯 하고, 협업툴(team collaboration tool)은 "슬랙" 같은 tool 을 이야기 한다.

테크기업에게 협업툴이 더 잘 맞을 것이라는 이야기가 있어서 가져와 봤다.

451 리서치(451 Research)의 수석 애널리스트 라울 카스타논 마르티네즈

마르티네즈는 "비즈니스 특성상 UC(Unified Communication, 통합 커뮤니케이션)보다 협업 솔루션이 더 잘 맞는 곳들도 있다. 스타트업이나 디지털 네이티브 기업들이 그 예다. 단순히 직원 가운데 IT 전문가 비율이 높아서만은 아니다. 지식 노동자의 비중이 높을수록, 그리고 엔지니어 및 개발자 직원 기반이 강세일수록 협업 솔루션이 더 적합하다. 이들의 커뮤니케이션 방식에 더 잘 맞기 때문이다. 이런 이유로 UC에서 협업 툴로 이전하는 기업들도 많을 것이라 생각한다"고 말했다.[ref. 1]

“There are some companies that because of the nature of their business, could be well suited for that,” Castañón Martínez said, such as startups or digital native companies. “Not just because they tend to be more tech-savvy or tech-oriented than other companies, but mainly because of the type of workers. If they have a higher percentage of knowledge workers, and they are in a stage where they might have a strong employee base of engineers and developers, it just makes sense because that is how they communicate. So, I think that we might see some shift in that sense.”

Teams Demo


Slack Demo



개인적인 의견

개인적으로 둘다 안사용하는 것보다는 좋다고 생각한다.

하지만 굳이 선택을 하라면, slack 쪽이 더 좋다. 확장성도 좋고, 사용성도 좋다. Teams 는 써보지 않았지만, demo 비디오로 봤을때 기존의 우리가 많이 사용하던 tool 이다. 그것의 장점은 정리가 잘 될 수 있다라고 생각하는데(물론 요새 많이 바뀌었긴 하지만)문제는 대다수의 사람들을 그 정리된 interface 에 맞추려 하는 것이다.

IT회사에서 일할때 대체로 사람들은 자료정리에 시간을 보내지 않는다. 그렇기에 당연히 slack 이 낫다. 하지만 하나의 단점이라면, 채팅으로 되어 있어 불필요한 대화들도 같이 들어가 있기에 추후에 자료를 정리하고 싶은 순간이 오기는 한다.


References

  1. 블로그 | 2019년 협업 소프트웨어 시장, '춘추전국시대가 온다' - CIO Korea
  2. Collaboration 2019: Teams, Slack and what’s coming | Computerworld

[컴][생각] 프로그래머의 초과근무

초과근무 /

프로그래머의 초과근무


Stack Overflow’s 2018 Developer Survey 에서 프로그래머들이 엄청나게 많은 양의 overtime 일을 하고 있다는 것이 드러났다. 그래서 관련되서 reddit 에 댓글들이 엄청달렸다.

reddit 에서 best 댓글은 아래와 같다.



프로그래머의 초과근무는 여러모로 좋지 않다. reddit 의 댓글에 있는 글들이 수많은 안좋은 이유를 알려준다.

프로그래머가 새로운것을 찾고, 학습하는 시간도 결국 프로그래머의 일하는 시간이지만, 안타깝게도 실제로 그것을 인정받기는 쉽지 않다.

그래서 나는 저 reddit 의 댓글에 찬성한다. 정말 이 한몸 불살라서 내가 돈을 많이 벌겠다는 의지가 아니라면, 정해진 시간만 일하라고 하고 싶다. 어차피 그 이외의 시간에도 풀리지 않았던 문제나 풀어야할 문제가 머리속에서 지워지지 않아서 자신도 모르는 사이에 일하게 될 테니 말이다.

References


  1. Stack Overflow’s 2018 Developer Survey reveals programmers are doing a mountain of overtime : programming

[컴] unit test 작성 범위는 ?

유닛테스트 작성방법 / 유닛테스트 작성 범위


Unit test 의 작성 범위

reddit 에 재밌는 글이 올라왔다.

대략의 내용은 "굳이 하지 않아도 되는 Unit Test 까지 만드느라고 시간을 낭비하고 있다." 정도일 듯 하다. 


우리가 unit test 를 필요로 하는 이유중 하나는 code가 추가되거나 변경될 때, 기존동작에 영향을 미치지 않는 것에 대한 확신을 가지기 위해서 이다.

개인적으로도 이 관점에서 우리가 만약 계속 확장되고, 다듬어져야 하는 project를 진행한다면 unit test 가 꼭 필요하다고 생각된다.

하지만 그렇다고 해서 모든 code 에 대한 검증을 할 필요는 없다. 그것은 시간이 너무 많이 소요되며, 크게 의미가 있지도 않다.

그럼 어떤 unit test 를 하지말아야 할까?


wrapper function 처럼 명확한 code 는 하지 않아도 된다.

위의 link 글에서도 이야기 하지만, 너무나 명확한 code는 굳이 unit test 를 작성할 필요가 없다.

위의 글에서는 아주 명확한 case 를 보여준다. 아무 일도 하지 않고, wrapper function 의 역할을 하는 method 가 예시로 나온다.


public method 에 대한 unit test 만으로 충분

원래 unit test 가 private method 에 대한 test 를 하지 않도록 되어 있지는 않다. 실제로 구글링을 해봐도 unit test 에서 private method 에 대한 test 방법들이 있다.

그래서 필자도 처음에는 특정 logic 에 대한 검증을 하기 위해 private method 라도 unit test 를 시행했다.

하지만 이런 경우 차라리 새롭게 public method 를 사용하도록 새로운 class 로 refactoring 을 하는 것이 맞는 듯 하다. 그리고 되도록 unit test 는 public method 선에서 처리하는 것이 좋은 듯 하다.

왜냐하면 private method 는 결국 public method 안에서 사용되며, private method 가 제대로 동작하지 않는다면 public method 또한 제대로 동작하지 않기 때문에 굳이 중복해서 test 를 행할 피요가 없기 때문이다.


그리고 우리가 public method 수준의 unit test 를 가지고 있어야, class 내부를 refactoring 하는 경우에 많은 private methods 들이 변경될 때 우리는 그것에 대한 unit test 를 없애고, 또 만들어야 하는 일을 하지 않아도 된다.

그러기에 우리는 public method 수준에서 unit test 를 충실하게 작성하면 충분할 것이라 생각한다.


mock up 이 필요한 경우등은 private method 를 test 해야 하는가?

그런데 간혹 외부 라이브러리 등의 문제등으로 mockup 등을 만들 수 없는 경우가 있을 수 있다. 이 경우 public method 를 검증하지 못할 수 있다. 그래서 private method 를 검증해야 할 것 같다. 하지만 만약 그런 경우의 private method 라면 새로운 class 로 만드는 것을 고려해 봐야 할 것이다. 아래 글들이 도움이 될 듯 하다.






[컴][툴] 협업툴

그룹웨어 / 그룹 / 메신저 / 협업 / 트렐로 / trello / github issue /

협업 툴 

  • 메신저를 중심으로 정리: slack, 잔디, 팀업
  • 한화면에서 편집하는 방식으로 정리 : 비캔버스
  • 마인드맵을 이용하는 정리 : 마인드 메스터
  • 카드형식의 정리 : 트렐로
  • 위키를 이용한 정리 : 컨플루언스
  • 다양한 방법제공, 화이트보드, 마인드맵 등: https://miro.com


Demo 영상들



슬랙

  • 슬랙(Slack) 간단히 둘러보기 - YouTube
  • Slack을 3개월간 써본 단상, 2016-03-01 : 한글 검색이 상당히 문제가 있고 아울러 영어 검색도 딱히 좋지는 않다. 과거 대화록 검색에서 결국 원하던것을 찾지 못하여 스크롤로 찾은 적이 제법 있었으니, 검색은 사실상 포기하는게 나을수도 있다. (이건 Confluence나 JIRA 같은 경우에도 해당되는 문제이다)

잔디


  • 무료 :
    • 팀전체 5GB 저장용량
    • 검색 : 최근 메시지 15,000개
    • 팀 관리자 1명
    • 팀 멤버 최대 500명
  • 프리미엄 : 인당 월 5,000원
    • 멤버당 10GB 의 저장공간
    • 검색 제한없음
    • 관리자 무제한
    • 멤버 제한 없음
    • 방문교육
    • 고객지원
  • 엔터프라이즈 : 멤버당 9,000원

팀업 (이스트소프트)

타임라인 방식, 슬랙이나 잔디 같은 방신인듯.

  • 무료 :
    • 개인당 5GB 최대
    • 개별 업로드 용량 100MB 최대
    • 사용인원 최대 50명
    • 백업 (1차 백업)
  • 프리미엄 : 인당 월 5,000원
    • 팀별 1인당 30GB
    • 개별 업로드 최대 2GB
    • 3차 백업


콜라비

아직 신생업체, skip


비캔버스


트렐로


  • 무료
    • 무제한 보드, 리스트, 카드, 멤버, 체크리스트, 첨부파일
    • 보드당 1개의 Power-up
    • 첨부파일 1개의 최대용량 10MB
  • 비지니스 class : 인당 월 $9.99
    • 무제한 Power-up
    • 첨부 파일 최대 250MB
    • 팀의 보드들을 collections 을 이용해서 묶을수 있다.
    • public/private 보드들을 만들수 있는 이용자를 설정할 수 있다.




  • 개인 : 인당 월 $5.99
    • 무제한 마인드 맵
    • 파일/이미지 첨부
    • 이미지 / pdf 내보내기
    • 고급인쇄
    • 우선수위 고객지원
  • 프로: 인당 월 $9.99
    • 개인버전의 모든 기능
    • 여러사용자
    • 관리자 계정
    • 워드와 파워포인트문서로 내보내기
    • 프레젠테이션 내보내기
    • 사용자정의 맵 테마
    • 도메인로그인을 위한 G Suite
    • 사용자정의 서식
    • 통계 & 보고서


컨플루언스


  • 소규모 팀 : 월 $10 - 최대 사용자 10명
  • 성장하는 팀 : 월 $50 - 15 users / $100 - 25 users
  • 자체 서버 호스팅 : $10 결제 - 최대 10명 사용
    • 1년간 무료 유지보수

네이버 카페

  • 개인적으로 ui 가 불편하다.
  • 주제별로 엮기가 힘들다