애자일 선언서 이해하기

today 2017-08-20 face Posted by appkr turned_in Learn & Think forum 0

그림출처: http://forintus.com/tag/agile-manifesto/

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

 

INDIVIDUALS AND INTERACTIONS over PROCESSES AND TOOLS

WORKING SOFTWARE over COMPREHENSIVE DOCUMENTATION

CUSTOMER COLLABORATION over CONTRACT NEGOTIATION

RESPONDING TO CHANGE over FOLLOWING A PLAN

 

That is, while there is value in the items on the right, we value items on the left more.

 

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

 

©2001, the above authors

this declaration may be freely copied in any form, but only in its entirely through this notice.

코드 비용에 대한 2016년의 메모

today 2017-08-12 face Posted by appkr turned_in Learn & Think forum 0

책상을 정리하다가 “라라벨 빨간책”이라 알려진 책을 집필하며 2016년 초에 쓴 메모 중 일부를 찾았다.

실무 개발자로 일하지 않던 시절 피상적으로만 생각하던 내용들이 지금은 피부에 와 닿는다. 이 포스트의 본문은 최근 나 또는 내가 속한 팀이 처한 상황에 거의 흡사하게 오버랩핑되는 2016년 메모의 일부분이다. 내 기억이 맞다면, 누군가의 영상 강의를 보고 메모한 것이다.

이 시대의 스승(엉클 밥, 파울러 옹 등)들이 언급한 소프트웨어 개발자로서 코드를 대하는 자세, 즉 소프트웨어의 제 2가치와 제 1가치에 대해 다시 한번 되새겨본다.

개발해서 남에게 납품하는 소프트웨어는 굳이 이럴 필요까진 없다고 생각한다. 그러나, 자신의 서비스를 위해 소프트웨어를 개발한다면, 개발자가 코드를 완전히 소유할 수 있는 시간과 비용을 인정해 줘야 한다.

아키텍처와 의존성

today 2017-07-09 face Posted by appkr turned_in Learn & Think forum 0

이 글은 그간 내가 짠 코드에 대한 반성이며, 앞으로 더 잘 만들겠다는 약속이며, 이런 실수를 하지 말라는 계몽이기도합니다.

割鷄焉用牛刀(할계언용우도) 닭 잡는 데 어찌 소 잡는 칼을 쓰겠는가?

논어(論語) "양화(陽貨)"편

오해를 하실까봐 미리 쉴드를 칩니다. 제가 좋아하고 자주 인용하는 말입니다.

그런데 바꾸어 생각해보면, 소잡는데 닭 잡는 칼을 쓰는 것도 바보 같은 짓입니다. 일회성으로 사용할 소프트웨어을 개발할 때는 모든 설계 원칙을 지킬 필요 없습니다만, 계속 유지 보수해야 하는 대형 서비스를 개발할 때는 소 잡는 칼을 써야지요.

지난 몇 개월간 저의 포커스는 읽기 쉬운 코드였습니다. “팀에 처음 합류한 신입이 코드를 이해하고 바로 프로젝트에 투입할 수 있는가?” 라는 관점이죠.

컴퓨터가 인식 가능한 코드는 바보라도 작성할 수 있지만, 인간이 이해할 수 있는 코드는 실력 있는 프로그래머만 작성할 수 있다.

- 마틴파울러 "리팩토링"

저는 2016년 12월 부터 라라벨 5.2로 개발한 메쉬프라임이라는 서비스 개발에 참여하고 있습니다. 이 서비스는 오픈한 지 대략 1년 됐고 현재는 매일 2만 트랜잭션 정도가 발생하고, 이 트랜잭션에는 네다섯 개 정도의 테이블이 연결되어 있어서, 대략 10만 레코드가 생성됩니다. 오늘 기준으로 master 브랜치에 총 3,495 커밋이 있고, 추가된 코드는 대략 42만 라인입니다. 결코 작은 서비스가 아니죠?

팀 합류 초기에 폭풍같이 몰아치던 기능 추가 프로젝트가 어느 정도 마무리되어, 한 숨 돌리면서, 몇 주전에 라라벨 프레임워크 버전 업을 시도한 적이 있습니다. 운영 서버에 적용할 의도는 아니었지만, 곧 5.5 LTS가 나오니 5.3 -> 5.4까지 마이그레이션 해보자는 취지였지요. 공식 매뉴얼에서 말하는 마이그레이션 가이드를 따라 5.3 마이그레이션을 수행했습니다. 랜딩 페이지가 나오고 로그인도 잘 됐습니다만, API 엔드포인트를 하나씩 호출해 보고 문제점들을 하나씩 잡아가는 과정에서 마이그레이션이 불가하다는 점을 깨닫고 뒤로 물러섰습니다.

왜 그랬을까요? 바로 이 글에서 쓰고자 하는 1) 커플링된 코드2) 아키텍처 때문이었습니다. 본문에 나오는 코드는 메쉬프라임과 무관함을 밝힙니다.

이제 나는 읽기 쉬울 뿐만 아니라 유지 보수가 편리한 코드를 개발할 것을 약속합니다.

프로그램이 지닌 가치는 두 종류다. 하나는 1) 현재의 기능이라는 가치이고, 또 하나는 2) 미래의 기능이라는 가치다. 프로그래밍할 때 개발자는 주로 그 프로그램에 현재 무슨 기능을 넣을지에 전념한다. 버그를 수정하든 새 기능을 추가하든, 그것은 프로그램의 성능을 높임으로써 현재 기능의 가치를 높이는 일이다.

프로그램의 현재 기능은 그저 일부에 불과하다는 사실을 깨우치지 않으면 개발자로서 오래 가지 못한다. 오늘 일을 오늘 할 수 있어도 내일 일을 내일 할 능력이 없다면 개발자로서 싪패하게 된다. 오늘 해야 할 일은 알아도 내일 일은 알 수 없는 것이 당연하다. 이런 일, 저런 일, 또는 어쩌면 생각지도 못한 일을 하게 될 수도 있다.

- 켄트 벡
keyboard_arrow_up