[WebDev] Developer philosophy

 

Developer philosophy @ Things Of Interest

---

 

믿기 어려울 수도 있지만, 오랜 시간이 지난 지금도 여전히 주니어 개발자는 존재한다.

몇 주 전 회사에서 나를 포함한 시니어 개발자들이 모여 각자의 소프트웨어 개발 철학에 대해 약 5분동안 이야기하는 시간을 가졌다. 우리의 다년간의 경험을 주니어 개발자들과 공유하기 위함이었다.

세션 후에, 나의 생각을 정리하고, 약간의 디테일을 덧붙이면 좀 더 가치있을 것이란 생각에 이 글을 작성한다.

내용은 다소 잡다할 수 있으며, 만약 이미 시니어 개발자라면 내용이 익숙할 수도 있고 동의하지 않을 수도 있다! 소프트웨어 개발은 극도록 주관적인 분야니까. 

Avoid, at all costs, arriving at a scenario where the ground-up rewrite starts to look attractive

(* ground-up rewrite: 처음부터 재개발하는 것 )

'재개발'이 매력적이면서도 극도로 위험한 선택이라는 것은 일반적으로 잘 알려져 있다. 재개발에 대한 보통의 조언이라하면 "절대 안돼". 그러나 한걸음 물러나서 보자.

재개발이 좋은 생각인 것 처럼 보이기 시작했다면, '피할 수 있었던 실수'가 이미 만들어지고 난 후이다. 이런 상황은 갑자기 발생한 것은 아닐것이며, 충분히 피할 수 있고 피해야만 한다.

 

아래와 같은 경고 신호가 보이면 조심해라.

- 기술 부채의 증가

- 단순한 코드 변경이 점점 어려워짐

- 문서화, 주석 작성의 어려움

- 신입 개발자 온보딩의 어려움

- 동작하는 코드의 특정 부분을 아는 사람이 줄어듦

- 아무도 이해할 수 없는 버그 발생

 

복잡성이 점점 커지는 것과 항상 맞서라. 신규 기능 추가와 기존 시스템 정리를 번갈아가면서 수행해라.

물론, 재개발이 실제로 작동은 할 수 있다. 또, 기존 기술 부채로 가득한 늪을 유지하는 것보다 더 좋은 선택일 수도 있다. 반면, 어떤 선택도 동작하지 않을 수 있다 - 그 프로젝트는 망할 운명이었고, 어떻게 마지막을 맞이할지만 결정하는 것일 수 있다. 중요한 것은 이 상황은 본질적으로 위험이 따른다는 것이다. 그러나 이 상황은 피할 수 있고, 그렇다는 것은 이 위험도 피할 수 있다는 것이다.

Aim to be 90% done in 50% of the available time

소프트웨어 개발에 유명한 명언이 하나 있다. - 사실 이건 소프트웨어 개발 외의 분야에서 유래했을 수 있다-

"업무의 첫 90%는 90%의 시간이 걸린다. 마지막 10%는 나머지 시간의 90%의 시간이 걸린다"

이 말은 약간 웃기지만, 명백히 사실이다. 이것을 이해하고 있다면, 충분히 고칠 수 있다.

코드를 작성하고, 이것을 동작하게 만드는데는 시간이 필요하다. 이것을 했다는 것은 약 반정도를 했다는 것을 이해해야한다.

코드를 적절한 수준으로 다듬고, 유지보수성을 높이며, 엣지 케이스와 실패 케이스를 적절히 처리하고, 단위 테스트, 통합 테스트, 사용성 테스트, '막판' 기능 변경, 성능, 서비스 가능성, 문서화 등등... 이 모든 것들 또한 엄청난 양의 추가 시간이 필요한 업무의 일부이다.

이 많은 것들은 이론적으로는 스킵 가능하다. 그러나 실무에서 이것들을 진행하지 않는다면, 결국 허술하고 완벽하지 않은 기능이 된다. 그리고 아무도 나중에 이 일을 "제대로" 끝내지 않을 것이다. 언제나 할일은 있다. 세, 네번 반복하면, 결국 조잡한 제품이 된다.

또한 코드를 작성하는 과정에서 예상치 못한 장애물이 발생할 것이다. 이 장애물은 가능한 빨리 발견하는 것이 좋다. 

그리고 만약 계획한 추가 시간이 필요하지 않다는 것이 마법처럼 밝혀진다면? 좋다, 프로세스 개선 할 시간이다! 또는 기술 부채를 해결해라!

 

Automate good practice

보통 프로젝트에는 개발자들이 해야할 것과 하지 말아야 할 특정한 것들이 있다. 새로운 최고의 practice가 생긴다. 일관되게, 모든 곳에서 사용해야 하는 새로운 툴, 필수 헤더, 실행 전 체크해야할 것, 사용하지 않기로 했던 메소드 등이 있다. 이런 것들이 생길 때, 개발자들이 전부 행동을 바꾸도록 하는 두가지 방법이 있다.

 

1. 사회화 하라. 모두에게 직접, 한 명씩 또는 스크럼이나 팀 회의에서 알려라. 이메일을 보내라. 새로운 지침을 위키나 레포지토리의 README, 또는 풀 리퀘스트 템플릿에 추가하라. 사람들이 문서를 읽도록 계속해서 상기시켜라. 누군가의 변경 사항을 영원히 수동으로 검토하며 실수를 찾아라. 절대 잊지 않도록 하라! 체크리스트를 추가하고, 모든 사람이 그 체크리스트를 올바르게 지킬 수 있도록 훈련시켜라. 의무적인 동료 리뷰 수준을 높여라. 모두에게 다시, 또 다시 상기시켜라...

2. 자동화 하라

 

가이드라인을 준수하지 않으면 실패하는 자동화된 테스트를 추가해라. 혹은, 만약 여기저기 있는 모든 것을 한번에 고칠 수 없다면 'ratchet'을 추가해라. 올바른 작동을 하지 않는다면, 예의있는 경고 문구와 함께 빠르게 실패하거나, 더 나아가 문제를 자동으로 수정하라. 보통의 경우에는 best practice를 기계적으로 강제하라.

자동화는 완벽한 해결책이 아니며, 보편적인 해결책 또한 아니고, 이런 상황에서 항상 적절한 해결책이 아닐 수 있다. 자동화 할 수 없는 수많은 요구사항이나 추상적인 기술 요구사항이 굉장히 많다. 그리고 너무 많은 규칙을 도입하면 매우 귀찮아질 수 있으며, 동기 부여된 개발자들은 다양한 방식으로 이런 자동화된 상황을 우회할 수 있다.

만약 "x를 잊지 않았니? x를 항상 기억해!"라고 지속적으로 말하고 있는 자신을 발견한다면, 지금이 자동화할 시간이다. 

Think about pathological data

누구도 황금길은 신경쓰지 않는다. 엣지 케이스는 우리의 평생의 업무이다. 기능이 실패할 수 있는 상황을 항상 생각해라. 기능을 망가뜨리는 방법을 생각해라. 코드는 모든 가능성을 다루어야 한다.

요청이 실패하거나, 영원히 멈추거나, 한시간동안 일초마다 하나의 바이트만 보내면 어떻게 될까? 백만 개의 행을 보여줘야한다면? 이름에 슬래쉬(/)가 있거나, 공백이 있거나, 메가바이트 단위로 길다면? 그 문자열이 비어있을 수 없다고 증명할 수는 것은 믿을 수 없다!

There is usually a simpler way to write it

만약 너가 시간을 제대로 계획했다면, 다시 돌아가 더 좋은 방법을 찾을 시간이 있었을 것이다. 옛날 체스 명언에 "좋은 수를 보았다면, 더 좋은 수를 찾아라"라는 말이 있다. 다른 인용구도 있다. "편지를 너무 길게 써서 미안, 시간이 있었다면 더 짧게 쓸 수 있었을 텐데.."

Write code to be testable

이것은 잘 정의된 인터페이스와 적은 사이드 이펙트를 의미한다. 테스트하기 어렵다는 것이 증명된 코드는 아마 캡슐화가 적절하게 되어있지 않을 가능성이 크다.

It is insufficient for code to be provably correct; it should be obviously, visibly, trivially correct

어떤 코드는 우연히 올바르게 동작하는 것 처럼 보일 수 있다. 왜냐하면 잘못된 입력을 받을 수 있는 상황이 이 코드를 둘러싼 다른 코드들의 구조에 의해 규제되고 있기 때문이다. 나는 이것을 좋아하지 않는다. 기술적으로는 버그가 없을 수 있지만, 이제 다른 코드를 재구성하는 것이 더 어렵고 위험해진다.

특히 보안문제, 또는 이론적인 보안 문제 부재에 해당된다. 현재 이 특정 내부 함수의 호출자들이 모두 신뢰할 수 있다고 해서, 그것이 중요한 문제가 아니라고 생각하지 않는다.