코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기

• 쓸데없는 일 줄이는 법

구글의 80 / 20 정책

회사가 개발시간 여유가 있고 실패가 받아들여지고 사장이 백일몽도 근무로 인정해주는 곳이어야 가능

-> 일을 일처럼 느끼지 않게 해주는 , 각자 가진 스스로의 등을 시원하게 긁게 해주는 재미있는 정책

 

자기 자신과 프로젝트를 어떻게 마케팅할건지 소프트웨어 개발자는 고민해라!!(가끔 코딩보다 중요)

->설득이 얼마나 개발자에게 필요한 덕목인지 말한다.... 한국에서 가능할까???

 

the battle for pinball - 실패와 성공보다는 자신을 객관적으로 파악하고 계속 나아가는 것

프로젝트 자체가 성공을 더두더라도 실패하게 되는 경우가 있다.

진정한 실패는 프로젝트에서 아무것도 배우지 못한 사람이다.

 

전문가는 자신을 과신하는 것이 아니라 스스로에게 질문으로 시작된다.

 

 구체적으로 해야할 목록을 정리하지 않으면 90퍼센트만 완료하고 프로젝트가 끝난다.

 

반복의 빠른 속도가 반복의 질보다 우선한다.(빠른 테스트 빠른 피드백)

 

저자는 환상을 가지고 있지 않다. 지메일, 구글, 글쓴이 블로그 모두 인기를 얻기까지 오래 걸렸다.

->하루아침 성공은 없다. 오랜 준비기간이 있는 것이다.

 

*프로그래밍

진정으로 더 나은 프로그래머가 되고 싶다면 프로그래밍 주변에 있는 다른 모든 것들에 열정을 쏟어야 한다. 즉, 사용자, 업계 전반, 그리고 비지니스에 대해서도 관심을 가져야 한다.

 

최고의 프로그래머들은 모두 자신이 하는 일에 대해 평생을 걸 정도의 열정을 품고있다. 일시적으로 사소한 경제적인 문제가 생긴다고 해서 그들이 다른 일을 찾아 다니는 일은 절대 없을 거이다.

 

단순함을 유지한 코딩, 미리 확장될 기능 추측하지 말고 없애기, 진짜 뭔가를 배우기 위해서 스스로 저질러보기, 무어"단순함이라는 것이 단지 수동적으로 지향해야 하는 목표가 아니라 억지로라도 적용돼야 하는 필수적인 원칙"

 

코드가 무엇을 할지가 아니라 무엇을 하지 않을지 선택해라 즉, 반복을 줄이고 클래스를 잘게 쪼개 전부 건드리지 않게 하여라 각각 변수, 코드 한 줄,함수, 클래스, 프로젝트는 오직 하나의 일만 수행해야 한다.

 

중요한 것은 경험 그 자체가 아니라 어떤 사람이 현재 가지고 있는 능력을 약간 뛰어넘는 수준의 도전이 끊임없이 부여되고 그에 대응하는 '노력이 담긴 학습'이라고 주장한다. '노력이 담긴 학습'은 현재 능력의 최첨단 끝에 놓인 문제점을 끊임없이 개선하는 것을 의미한다. 현재 시점에서 제대로 풀어내지 못하는 그런 문제들 말이다.

 

프로그래밍을 진지하게 생각한다면 반드시 다른 동료와 함께 일하는 환경을 고집해야 한다.

 

건강한 소프트웨어 엔지니어링 문화에서는 팀원들이 작품의 품질을 높이고 생산성을 향상시키기 위해 동료를 활용한다. 동료가 코드를 간단하게나마 검토할 수 있게 하라

 

밤에는 이론을 익히고 낮에는 실전을 수행하는 과정을 혼합하는 것은 매력적이다. 대부분 소프트웨어 교육은 학생들이 주로 보고 듣게 하는데 치우치지만, '하고 검토하는'  단계야말로 성장을 촉진하고 기술을 향상시키는 핵심적인 방법이다.

 

*웹 디자인의 원칙

출품작들을 심사하면서 배운 바는 웹사이트의 첫 페이지가 어마어마하게 매력적이어야 한다는 사실이다. 첫 페이지를 훌룡하게 만드는 요소들은 다음과 같다.

빠른 로드, 이목을 끌 문구, 구체적인 스크린샷(생생한 현실의 예를 알 수있게) 절대 동영상을 클릭하거나 슬라이드 쇼를 보게하거나 회원가입을 시키지마라, 장애물이 없는 명확한 동작이 기능하게 하라, 자신의 진짜 타켓층을 고려하면 관심없는 계층은 눈을 돌리겠지만 감수하라

 

경쟁자를 이기기 위해 오히려 더 적게 하라

 

단순함을 추구해라(구글의 시작 페이지)

 

누구나 알기 쉽게 일관성 있는 코딩도 좋지만, UI는 일정한 데이터 수집을 통해 사용하는 사람 편의에 맞게 수정해야 한다.

 

브라우저는 항상 뒤로가기 버튼이 제대로 명시되어 있어야 한다.

 

현재 참여 중인 프로젝트의 사용성에 관심을 두는 사람이 없다면 그 프로젝트의 운명은 이미 다한 것과 마찬가지다.

->사용성은 값싸고 쉬운 일이 아니다. UI 개선을 위해 마우스 이동, 눈궤적쫓기 테스트를 한다.

 

삭제하기 버튼은 작고 멀리 보내기의 버튼은 잘 띄게 크게!

 

낙관적 태도 프로그래머에게 위험한 직업병이다. "아니오"를 외칠 수 있어야 한다.

 

사용자는 코드를 고민하지만, UI의 디자인도 고려해야 한다!

 

============================================================================

 

2/18(화)

 

*테스트

단위 테스트는 프로그램이 올바르게 동작하는 것을 보장해주지 않는다. 하지만 개발자가, 아무리 간단하게라도 앞에 나열한 것 같이 테스트와 관련된 어려운 질문을 스스로 고민하도록 만드는 것은 보장한다.

ex)어떻게 테스트하지? 어떤종료로? 기대결과는? 혹시 예외사항은? 외부의존성은?

 

단위 테스트가 베타테스트의 스케쥴을 방해한다면 아주 심각한 실수를 저지르게 된다. 테스트란 소프트웨어를 베타 테스터들에게 출시한 시점부터 이뤄질 수 있다.(즉, 극단적인 단위테스트는 필요 없으며, 이를 통한 문제가 발생한다면 그건 소수의 확률이고 사용자의 문제일 것이다라는 의미)

 

언제나 소프트웨어를 비난할 수 있는 것은 아니다. 떄로는 하드웨어 자체가 문제인 경우도 있다.

 

애플리케이션의 건강상태에 대해 사용자보다 더 많이 알아야 한다. 내가 작성한 소프트웨어에 있는 진짜 문제점을 사용자들이 와서 알려주면 매우 큰 당혹감을 느낀다. 그전에 내가 먼저 문제를 파악하고 해결해야 한다.

예외목록을 따로 만둘어 두어라. 일종의 할일목록과 같은 역할을 수행한다.

 

어떤 사용자도 경험하지 않을 버그를 수정한다면 실제로 무엇을 수정했다고 말할 수 있는 것일까? TDD는 아무래도 성급한 최적화에 내포된 문제를 공유한다. 이론적인 버그가 아니라 실제적인 버그를 수정해야 한다. 예외 주도 개발이다.

-> 일단 최대한 구동 가능 코드로 소프트웨어를 만들고 피드백을 받아가면서 빠르게 수정하고 보완하자

 

*당신 사용자를 알라

 단순하게 만들자 단순하게!

 

상아탑 개발을 피하자 - 세상에 존재하는 다른 모든 사람이 전부 자신과 같은 개발자가 아니다.

기술적인 소프트웨어의 마법 자체에 목표로 일하지 말자 

 

프로젝트 전체 생명주기에 걸쳐 개발자들이 최종 사용자를 수시로 만나야 한다. 

 

진정한 친구라면 결코 동료 개발자가 직접 디자인한 UI를 출시하도록 내버려 두지 않는다.

 

설문조사에 사용자는 다 거짓말을 한다. 사용자가 소프트웨어를 "실제로 사용하는지", "실제로 어떻게 사용하는지" 보라.

 

출시가 전부가 아니다. 얼마나 많은 사용자가 실제로 당신이 만든 애플리케이션을 사용하는가가 성공의 척도이다.

 

문서화 작업, 인터랙션 이자인, 사용자 커뮤니티 관리, 제품 비전 등 이러한 작업을 제대로 수행하지 못하면 어떤 종류의 코드를 작성하느냐는 별로 상관이 없다.

 

소프트웨어를 맹목적으로 어떤 기능들의 총합, 끝없이 먹을 수 있는 디지털 뷔페라고 판단하는 것을 멈춰야 한다.

 

이미 존재하는 것을 되풀이해서 개발하는 것을 지지한다. 하지만 이미 존재하는 대상의 모든 측면을 철저하게 연구한 다음 그것을 다시 개발해야 하는 이유를 입증하기 전까지는 그렇게 하지 말아야 한다.

 

우리가 스택 오버플로우에 3개 기능이 있다면, 그중에 적어도 2개는 커뮤니티 활동을 관찰하고, 그들이 하고자 하는 일을 더 적은 고생과 노력으로 하도록 돕는 도구를 만드는 과정에서 구현된 거이다.

 

사회적인 소프트웨어를 만드는데 따르는 모든 문제와 답의 출처가 바로 사람들 안에 있다.

 

시람들은 이런 물질적인 보상이 아니라 점수라는 것 자체를 추구한다는 사실을 알 수 있다.(커뮤니티 점수)

 

*우리가 관심을 둬야 할 것들

*읽어볼 만한 내용

추천 도서 목록에서 5위 이내에 드는 프로그래밍 서적들은 모두 프로그래머가 반드시 소유하고 읽어야 하는 책이다.

(코드 컴플리트2, 상식이 통하는 웹사이트가 성공한다, 피플웨어, 실용주의 프로그래머, 소프트웨어 공학의 사실과 오해)

 

당신은 스스로 일해야 한다(자기계발서를 읽는다고 내 일을 대신해 주지 않는다)

 

나만의 일을 할 때마다 전보다 나아지려고 노력하라

 

부모 노롯을 하는 것은 지금껏 해본 모든 일 가운데 가장 어려운 일이다.