"손코딩뇌컴파일눈디버깅" 모임을 소개합니다.
백문이 불여일런, 트라이얼앤에러(Trial and Error) 식의 몹쓸 교육을 받아 온 개발자들이 코딩하기 전에 신중하고 꼼꼼하게 생각해보기란 쉽지 않습니다.
개발 시간 중 디버깅 시간이 절반 이상을 차지하고 있는 실정에 버그를 줄이기 위해 TDD니 유닛테스트니 많은 방법들이 개발되고 있지만 가장 일차적으로 중요한 것은 개발자들이 꼼꼼히 따져보는 것이 아니겠는지요?
미국의 선진 SW회사들은 이미 화이트보드에 PS문제를 푸는 것을 인터뷰 방식으로 채택하고 있습니다. 이는 이와 같은 풀이 방식이 개발자들의 기본 역량을 측정하기에 알맞은 지표라는 것이고, 개발자들이 기본적으로 갖춰야 할 역량이기도 하다는 것 입니다.
또한 자신의 생각을 명확하게 정리하고 다른 사람이 이해할 수 있도록 전달하는 Communication Skill 도 개발자가 갖춰야 할 역량 중 하나 입니다. 알고리즘을 어떻게 구현할 것인가를 팀원들과 소통하면서 자연스럽게 생각을 정리하고 전달하는 연습도 할 수 있습니다.
컴퓨터에 앉아 코딩하기 전 펜과 종이를 들고 눈과 머리와 손을 굴려 보시는 것은 어떠신지요??
"손코딩뇌컴파일눈디버깅" 모임을 소개합니다.
백문이 불여일런, 트라이얼앤에러(Trial and Error) 식의 몹쓸 교육을 받아 온 개발자들이 코딩하기 전에 신중하고 꼼꼼하게 생각해보기란 쉽지 않습니다.
개발 시간 중 디버깅 시간이 절반 이상을 차지하고 있는 실정에 버그를 줄이기 위해 TDD니 유닛테스트니 많은 방법들이 개발되고 있지만 가장 일차적으로 중요한 것은 개발자들이 꼼꼼히 따져보는 것이 아니겠는지요?
미국의 선진 SW회사들은 이미 화이트보드에 PS문제를 푸는 것을 인터뷰 방식으로 채택하고 있습니다. 이는 이와 같은 풀이 방식이 개발자들의 기본 역량을 측정하기에 알맞은 지표라는 것이고, 개발자들이 기본적으로 갖춰야 할 역량이기도 하다는 것 입니다.
또한 자신의 생각을 명확하게 정리하고 다른 사람이 이해할 수 있도록 전달하는 Communication Skill 도 개발자가 갖춰야 할 역량 중 하나 입니다. 알고리즘을 어떻게 구현할 것인가를 팀원들과 소통하면서 자연스럽게 생각을 정리하고 전달하는 연습도 할 수 있습니다.
컴퓨터에 앉아 코딩하기 전 펜과 종이를 들고 눈과 머리와 손을 굴려 보시는 것은 어떠신지요??
<3탄>스프링 부트를 사용한 마이크로 서비스 개발 (로컬 환경) | 페어 프로그래밍 데모 (테스트 작성)
이번 세션에서는 Spring Boot를 사용한 웹 애플리케이션 개발에 대해 소개합니다. 이때 제작되는 애플리케이션은 Pivotal에서 풀타임으로 사용하고 있는 페어프로그래밍을 통해 테스트부터 작성하는 핑퐁 페어등을 소개합니다. 두명이 함께 코드를 작성하는 환경을 통해 빠른 사업환경의 변화를 수용할 수 있는 개발 업무가 Pivotal에서는 어떻게 다른지 살펴봅니다.
한국 표준(?) 자바셋(Java 1.6+Spring 3.x+MyBatis)과 Monolithic 아키텍처를 사용하고 있었던 제 조직 내에서 기술적 변화를 이끌어가는 것에 관련된 내용입니다.
변화를 유도하기 위해서 어떻게 해야 하는지가 핵심이며,
Architecture, Frontend, Backend, 방법론/프로세스의 영역을 각각의 단계로 나누어서 Phase1을 수행한 것과 Phase2를 수행 중인 내용에 대해서도 다룹니다.
Phase1
- Architecture : Frontend / Backend 명시적 분리
- Frontend : Angular.js, Grunt, Bower 도입
- Backend : Java 1.7/Spring4, ORM 도입
- 방법론/프로세스 : Scrum, Git
Phase2
- Architecture : Micro-Service Architecture(MSA)
- Frontend : Content Router, E2E Test
- Backend : Polyglot, Multi-Framework
- 방법론/프로세스 : Scrum+JIRA, Git Branch Policy, Pair Programming, Code Workshop
언제 애자일을 써야 좋을까? The better ways of developing softwareKevin Kim
The better ways of developing software
Software Development Methodology
Agile
Scrum Methodology
eXtreme Programming(XP)
Waterfall
Kanban
When to Use Scrum
When to Use Kanban
- 애자일 선언문의 원칙들
- 애자일의 오해
- 스크럼(Scrum)
- User Story
- Estimation
- XP(eXtreme Programming)
- XP Practice #1 – TDD와 테스트 자동화
- XP Practice #2 – Refactoring, CI
- 애자일 사례 소개
<3탄>스프링 부트를 사용한 마이크로 서비스 개발 (로컬 환경) | 페어 프로그래밍 데모 (테스트 작성)
이번 세션에서는 Spring Boot를 사용한 웹 애플리케이션 개발에 대해 소개합니다. 이때 제작되는 애플리케이션은 Pivotal에서 풀타임으로 사용하고 있는 페어프로그래밍을 통해 테스트부터 작성하는 핑퐁 페어등을 소개합니다. 두명이 함께 코드를 작성하는 환경을 통해 빠른 사업환경의 변화를 수용할 수 있는 개발 업무가 Pivotal에서는 어떻게 다른지 살펴봅니다.
한국 표준(?) 자바셋(Java 1.6+Spring 3.x+MyBatis)과 Monolithic 아키텍처를 사용하고 있었던 제 조직 내에서 기술적 변화를 이끌어가는 것에 관련된 내용입니다.
변화를 유도하기 위해서 어떻게 해야 하는지가 핵심이며,
Architecture, Frontend, Backend, 방법론/프로세스의 영역을 각각의 단계로 나누어서 Phase1을 수행한 것과 Phase2를 수행 중인 내용에 대해서도 다룹니다.
Phase1
- Architecture : Frontend / Backend 명시적 분리
- Frontend : Angular.js, Grunt, Bower 도입
- Backend : Java 1.7/Spring4, ORM 도입
- 방법론/프로세스 : Scrum, Git
Phase2
- Architecture : Micro-Service Architecture(MSA)
- Frontend : Content Router, E2E Test
- Backend : Polyglot, Multi-Framework
- 방법론/프로세스 : Scrum+JIRA, Git Branch Policy, Pair Programming, Code Workshop
언제 애자일을 써야 좋을까? The better ways of developing softwareKevin Kim
The better ways of developing software
Software Development Methodology
Agile
Scrum Methodology
eXtreme Programming(XP)
Waterfall
Kanban
When to Use Scrum
When to Use Kanban
- 애자일 선언문의 원칙들
- 애자일의 오해
- 스크럼(Scrum)
- User Story
- Estimation
- XP(eXtreme Programming)
- XP Practice #1 – TDD와 테스트 자동화
- XP Practice #2 – Refactoring, CI
- 애자일 사례 소개
3. Long long time ago
• 회사에서 JDK7로 개발. 모던 Language에 대한 지적
호기심
• (당시 GAE가 지원안함. 얼마전부터 지원 시작)
• 문제가 터지면 70%는 NPE… (난 null 증오해)
• 사내에 약장수가 존재 했음… ( @kunny )
4.
5. Kotlin
• Null Safety 기능이 아주 훌륭해!
• Codeless!!. 코드량과 버그량은 비례
• lambda 처음 써봤어. 그냥 막 다 좋아!
• (옆에서 스칼라에 다 있는 기능이야..라고 해도 좋았음)
12. 제대로 약장사임
• Paper : https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf
• Code Mesh 2015 : https://www.youtube.com/watch?v=FGQAP0GxlW8
• Erlang Factory SF 2016 : https://www.youtube.com/watch?v=Z35Tt87pIpg
• Functional Conf 2016 : https://www.youtube.com/watch?v=XrNdvWqxBvA
• Lambda Days 2017 : https://www.youtube.com/watch?v=1qBHf8DrWR8
13. 서문
• 1.Functional Programming 이란?
- Main Function -> Functions -> Bottom Level
Function 구조로 만들어가는 프로그래밍 기법. 모든 구
성은 함수.
- Bottom Level Function 만이 Primitives로 구성됨.
14. 서문 cont’
• 2. FP의 특징
- 선언문이 없다. : 변수가 한번 주어지면 변경할 수 없
다.(Immutable)
- Side-Effect가 없다. : 모든 함수는 같은 입력을 받으
면 출력이 동일해야한다.
- Side-Effect가 없기 때문에 함수들의 호출 순서와는 무관하게 동일한 결과를 얻을 수 있다. ->
제어 흐름에 대한 제약이 줄어든다 -> 연산에 대한 호출의 시간적 제약이 없기 때문에 변수와 값의
교체를 자유롭게할 수 있다. -> 참조 투명성 -> 이런 자유도가 정규화된 프로그래밍 방식보다 수학적
으로 더 적합한 프로그래밍을 할 수 있게한다.
15. 서문 cont’
• FP의 장점
- 엄청난 생산성 : 코드량이 확실히 줄어든다.
왜? 선언문이 없어지니까 (코드의 대부분은 선언문)
• 하지만…
- 참조 투명성과 같은 이슈에 둔감하거나 필요성을 못느끼는 개
발자들에게는 딱히 좋은 점이 안느껴진다.
- FP의 철학을 제대로 이해하지 못하고 코드를 작성하면 FP의 장
점을 제대로 얻을 수 없다.
• 서문에 언급한 특징만으로는 FP의 힘을 설명하기 어렵고, FP 개
발자들이 추구해야할 방향에 대해서 설명하기 어렵다.
• 이 논문에서 이 문제들을 짚어볼 것이다.
16. 구조적 프로그래밍을 통한 유추
• 구조적 프로그래밍(Structured Programming, SP)을
통해 FP의 강력함을 유추해본다.
• SP의 장점들은 다음과 같다.
- goto가 없다.
- block에는 entry와 exit가 하나씩만 존재한다.
- SP는 UnSP보다 수학적으로 더 다루기 쉽다.
• SP의 장점들은 FP와 큰 차이가 없다.
17. 구조적 프로그래밍을 통한 유추 (Cont’)
• SP vs UnSP 의 가장 큰 차이점
- SP는 모듈화가 가능하다.
• 모듈화는 엄청난 생산성 향상을 가져온다.
- 모듈의 소형화는 코드를 빠르고 쉽게 작성할 수 있게
함.
- 일반화된 모듈은 재사용이 가능. 재사용이란 관점은
절처형 프로그래밍의 빠른 발전에 기여했다.
- 프로그램의 모듈화는 테스트를 독립적으로 할 수 있게
만들었다. 이것은 디버깅 시간을 줄이는데 도움을 주었
다.
18. 구조적 프로그래밍을 통한 유추 (Cont’)
• SP는 커다란 프로그램을 작은 단위의 프로그램으로 만들어
주는데 큰 도움을 주었다.
• 하지만…
- 모듈화는 하나의 문제를 분할해서 여러개의 문제로 만드
는 단점이 있다. 근본 문제를 해결하기 위해서는 작은 문제
들을 하나하나 모두 해결해야만한다.
• 그래서 모듈화와 마찬가지로 중요한 것은 나눠진 모듈들을
다시 잘 접착하는 것이 중요하다.
- 이 접착 방법에 대한 것이 중요한 이슈이고 이 문제를 해
결하는 것이 FP의 가장 중요한 장점으로 이야기되어야한다.
19. - John Hughes
“FP 개발자들은 잘 접착할 수 있는 더 작고, 더 단순
하고 더 일반화된 모듈들을 추구해야한다.”
아마도 이 모듈이 Function으로 생각됨. - nurinamu
21. Gluing Functions Together (cont’)
• Function을 작은 단위의 함수로 정의하면, 새로운 함수
도 해당 함수로 모두 표현이 가능하다.
• High-order functions (고차함수) 지원은 함수들의 결
합에 필수 지원 기능이다.
22. Gluing Programs Together
• g, f는 각각의 프로그램. 위 상황에서 g는 f가 output을
완전히 반환하기 전까지는 대기 상태.
- f의 output을 완전히 반환한다는 것은 특정 메모리를
그 크기만큼 선점해야한다는 것. 만약 해당 output이
거대하다면 메모리 낭비가 큼.
- 그래서 g가 연산 시작이 가능한 만큼이 만들어지면 그
때 g가 해당 f의 output을 input으로 사용하여 처리.
- 이것이 “Lazy Evaluation”
23. Gluing Programs Together (Cont’)
• Lazy Evaluation은 fp에서 모듈화를 위한 최고의 기능.
• 그럼 왜 non-FP에서는 Lazy Evaluation을 도입하지 않
는 것일까?
- 도입이 가능하다. 하지만 코드의 기대치가 Lazy를 기대하지 않고 만들어진 시스템에 Lazy가 도입
이되면 다른 side effect를 일으킬 수 있어, 디버깅을 더 어렵게 만든다. 그래서 처음부터 해당 기능
에 대한 고려가 없는 시스템에 추가하는 것은 좋은 고려사항이 되지 못한다.
24. Gluing Programs Together (Cont’)
• Newton-Raphson Square Roots
• Numerical Differentiation
• Numerical Integrations
• Lazy Evaluation은 또 다른 주제로 추가 스터디가 필요
함.
- 심화된 Lazy Evaluation 기법을 위해서는 Monads도 공부 필요.
25. An Example from A.I
• 간단한 틱택토 게임을 예제로 이야기.
• Static evaluation의 한계점을 이야기함.
- input 마다 모든 결과를 연산하는 것은 판이 커질 수
록 시간도 오래걸리고, 어느 순간에는 연산 불가 상태가
됨.
- 필요한 만큼만 얻고 반환하는 형태 : Lazy Evaluation
이 필요.
• High-order function을 이용해 모든 것을 함수로 표현
가능
26. Conclusion
• 모듈화(Modularity)는 성공적인 프로그래밍의 Key.
• 생산성 향상을 목표로하는 언어들은 반드시 모듈화 프로그래
밍을 잘 지원해야한다.
• 모듈화 프로그래밍을 지원하기 위해서는 나누는 것 뿐만 아니
라 결합에 대한 고려도 잘 되어있어야한다.
• FP는 High-order function과 Lazy Evaluation이라는 접착제
를 고려한 패러다임이다.
• 그래서 FP 개발자들은 해당 기능에 대한 숙지가 반드시 필요
하다.
27. 그래서 Kotlin은?
• Kotlin에서의 Lazy Evaluation.
https://www.safaribooksonline.com/library/view/
introduction-to-kotlin/9781491964125/
video283045.html
• Global Function 선언이 가능.
28. 팀원들에게는…
• 1. 모듈화된 코드를 짜도록 노력하자.
- OOP로 이미 하고는 있지만 더 작은 단위인 함수로
- 모듈단위 TC도 편해진다.
• 2. Side-Effect 없이 또는 예상 가능한 코드를 짜자.
- FP를 해보자
• 3. JVM 언어중에 FP로 접근할 수 있는 언어인 Kotlin을
해보자.
- Kotlin 좀 써봅시다