티스토리 뷰
http://www.itworld.co.kr/slideshow/85296
1. 이름 붙이기
과제 : 변수, 프로시저, 함수, 클래스, 객체, 데이터베이스 구성 요소 등에 이름 붙이기
어려운 점 : 작은 프로그램 또는 애플리케이션이라 해도 많은 것들에 이름을 붙여야 함. 어떤 것이 무엇이고 무슨 일을 하는지 짐작할 수 있도록, 애플리케이션 전반에 걸쳐 일관적으로, 그리고 간결하게 이름 짓기
“의미 있는 변수 이름 생각해내기” Aditya Muraletharan
“데이터 멤버와 함수의 의미 있는 이름 생각해내기” Lakshman Siripurapu
“컴퓨터 과학에서 어려운 것은 딱 두 가지다. 캐시 무효화, 그리고 이름 짓기” Phil Karlton(Martin Folwer/Jatinder Singh이 전함)
“...중복을 제거하고 잘못된 이름을 수정하는 것을 마스터한다면 그는 바로 객체 지향 디자인의 마스터라고 할 수 있다.” J. B. Rainsberger
Credit: flickr/Jeremy Keith
2. 내가 하는 일(또는 하지 않는 일) 설명하기
과제 : 프로그래머가 아닌 사람들(가족, 친구, 타 부서 사람들)에게 프로그래머라는 직업이 무엇인지, 그리고 무엇이 아닌지 설명하기
어려운 점 : 사랑하는 사람이 내가 어떤 일을 하는지 이해하지 못하는 것. 모든 컴퓨터 관련 문제를 해결해달라는 끊임없는 부탁에 대처하기
“누구에게든 나는 컴퓨터를 고칠 수 없다는 사실을 설명하기” Brandon P-Lost
“가족에게 내가 하는 일이 무엇인지 설명하기” Utsav Singh Rathour
“비전문가에게 내 직업이 밤낮으로 오로지 프로그램만 하는 것이 아니라는 사실을 납득시키기!!” Anand Safi
“나는 부탁만 하면 언제든 해적판 OS와 기타 불법 복제 소프트웨어를 깔아주는 사람이 아니라는 사실을 사람들에게 설명하기” Anbu Jey
Credit: flickr/Bruce Turne
3. 업무 완료 시간 예상
과제 : 프로젝트를 시작하는 시점에 작업에 소요되는 시간을 예측하기
어려운 점 : 해본 적 없는 일을 두고 시간이 얼마나 걸릴지 예상하고, 모호한 요구 사항을 바탕으로 이것저것 추정하고, 예측하지 못한 문제에 대처하기 위한 시간 배정하기.
“하나의 프로그래밍 문제가 얼마나 많은 예상치 못한 상황을 유발하는지, 실제 실행해보기 전에 예측하기란 정말 어렵다...” Jan Christian Meyer
“추정이 가장 어려운 부분이다. 대부분의 사람들이 추정을 확고한 약속으로 여기기 때문이다.” Samnang Chhun
“...프로젝트에 걸릴 시간을 예측하기란 사실상 불가능하다...” Jack Menendez
Credit: flickr/Faith Raider
4. 다른 사람들 상대하기
과제 : 클라이언트에게서 요구 사항을 수집하고 경영진에게 상태 보고서를 제출하고, 테스터와 업무를 조율하고 프로젝트에 대해 다른 엔지니어들과 회의하기
어려운 점 : 기술적 배경이 없는 사람들에게 기술적인 내용 설명하기, 다른 사람들의 간섭 받기, QA 담당자 또는 다른 개발자들과의 의견 불일치
“사람들보다 프로세서를 상대로 내가 하고자 하는 일을 설득하는 편이 훨씬 더 쉽다.” Marko Poutiainen
“엔지니어가 아닌 사람들 상대하기...내게 코드를 쓰는 방법을 설명하려 드는 엔지니어들 상대하기...” Anonymous
“...이 업계에 대한 지식이 없는 사람들과는 의사소통이 어렵다.” lnostdal
“우리 일을 가로막고 있는 다른 팀의 작업이 완료될 때까지 기다리기...” Anonymous
Credit: flickr/Ray Crane
5. 다른 사람의 코드로 작업하기
과제 : 다른 개발자가 작성한 애플리케이션 또는 코드의 일부분을 유지 보수, 디버그, 또는 보강하기
어려운 점 : 레거시 코드의 한 조각이 어떻게 작동하는지 파악하고 최초 개발자의 의도를 알아내는 것. 해당 개발자가 현재 회사에 없고, 코드나 주석 또는 문서가 열악하게 작성되어 있는 경우 더욱 어려워진다.
“문서화가 엉망인 코드를 마이그레이션하기” Omar Diab
“코드를 작성할 실력이 되지 않는 누군가가 작성한 코드를 붙잡고 씨름하기...” Nani Tatiana Isobel
“주석이 없는 수천 라인의 코드를 해독하는 일” Simon Zhu
Credit: flickr/Garrett
6. 동의하지 않는 기능 구현
과제 : 어떤 이유로 포함되지 말아야 한다고 생각하지만, 클라이언트 또는 상급자가 넣으라고 주장하기 때문에 어쩔 수 없이 그 기능을 구현하기
어려운 점 : 개인적인 감정과 의견을 접어두고, 해당 기능을 적절히 구현하고 지원하는 데 시간과 노력 투자하기
“...머리가 돌거나 빨리 은퇴하거나, 선택은 두 가지다.” Sabbir Asgar
Credit: flickr/osaka19
7 문서 작성
과제 : 코드의 기능과 애플리케이션의 작동 원리를 설명하는 문서 작성하기. 독립적인 문서, 코드 주석을 모두 포함한다. 문서의 대상 독자는 최종 사용자부터 다른 개발자들에 이르기까지 광범위하다.
어려운 점 : 많은 시간이 소비될 수 있으며, 아무도 읽지 않는다면 시간 낭비처럼 느껴진다. 프로그래머들은 일반적으로 코드 문서화보다 코드 작성 자체를 더 선호한다.
“단지 ‘프로세스’의 일부라는 이유로 아무도 읽거나 사용하지 않을 쓸모 없는 문서를 작성하는 일” Christian Dechery
“코드를 볼 필요 없이 그 자체로 작동 원리를 충분히 이해할 수 있는 문서 작성하기” Raghu Nandan
“잘 작성되고 설명이 풍부하면서 동시에 간결한 문서 작성하기!” Ayush Goel
Credit: flickr/United States Mission Geneva
8. 테스트 작성
과제 단위 테스트, 즉 작은 소프트웨어 단위의 프로그램 테스트를 작성해서 개발 함수와 루틴이 정해진 기준을 충족하는지 확인하기. 이러한 테스트는 개발 프로세스의 초기에 버그를 찾아 없애는 데 도움이 되며, 나중에 코드가 수정 또는 업데이트될 때 회귀 테스트에도 도움이 된다. 코드를 개발하기 전에 테스트를 작성할 것을 권장하는 개발 방법론도 있지만 사후에 작성하는 경우도 있다.
어려운 점 작성할 테스트를 선택하고 이를 코딩하는 작업은 따분하며, 마치 애플리케이션 구축 외에 주어지는 큰 부가적인 업무처럼 느껴진다.
“테스트 작성이 어렵지는 않다. 단지 좋아하지 않을 뿐이다.” Anonymous
Credit: flickr/Lachlan Hardy
9. 솔루션 디자인
과제: 클라이언트의 요구 사항을 가지고 구현할 기술 솔루션을 디자인하고 설계하기. 데이터 및 코드 구조, 기능 알고리즘, 비즈니스 논리를 캡슐화하고 사용 사례를 충족하는 애플리케이션 흐름을 디자인하는 일이 포함됨
어려운 점 : 클라이언트가 수긍하고 정해진 시간 내에 구축할 수 있으면서 클라이언트의 요구 사항을 충족하는 솔루션을 디자인하는 것
“A에서 시작해 Z에서 끝낼 방법을 생각하는 것이 가장 어려운 부분이다.” misconfiguration
“디자인이 너무 비대하면 그 자체의 무게로 인해 무너지고, 너무 빈약하면 쓸모가 없다.”nvteighen
“실제 작업하기 전에 무엇이 어떻게 돌아갈지 예측하기란 어렵다...”jpkotta
Credit: flickr/spare parts