개발자

벌써 블로그를 운영한 지 2년이 넘었다. 매년 회고록을 쓰자고 다짐했지만 2022년은 그냥 넘어간 듯한데... 어쨌든 2년 전 회고록을 작성하던 장소에서 2023년 회고록을 작성하고 있다. 2021년 회고록을 보면서 그때부터 지금까지 무엇을 성장시켰고 배웠는지 알 수 있었다. 이래서 다들 회고록을 써야 한다 하는구나.. 첫 회고록을 작성할 때 누적 방문자 수가 3천 명 정도 되었는데 지금은 30만 명이 다 돼 간다. 누구에겐 누적 방문자 수는 별 의미 없는 숫자일 수 있지만 나에게는 노력했고 성장했다는 증거이기 때문에 뿌듯하다! 전에는 기술적인 생각만 고민했다면 지난 2년 동안은 많은 새로운 사람들을 만났고 여러 가지 경험도 해보고 기술적이 아닌 다른 쪽에서 느낀 것이 참 많았다. 앞으로 나는 어떻게 내..

자료 추상화 변수를 비공개(private)로 정의하는 이유는 코드들이 변수에 의존하지 않게 만들고 싶어서다. 그렇다면 어째서 get, set 함수는 당연하게 외부에 공개(public)하는가? 알다시피 변수를 private로 설정한들 조회(get), 설정(set) 함수를 public으로 제공한다면 의미가 없는 샘이다. 변수 사이에 함수를 넣는다고 구현이 저절로 감춰지지는 않는다. 구현을 감추려면 추상화가 필요하다! 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스이다. 만약 휴대폰 배터리가 15% 이하일 때 절전모드를 작동한다고 해보자. public interface Phone { Double getBatteryPercent(); } if (phone...

작게 만들어라 함수를 만드는 첫째 규칙은 "작게!"다. 함수를 만드는 둘째 규칙은 "더 작게!"다. 함수가 작을수록 더 좋다는 증거나 자료를 제시하기는 어렵지만 함수는 작고 명확하게 구현해야 한다. 그러면 바깥을 감싸는 함수가 작아질 뿐 아니라, 블록 안에서 호출하는 함수의 이름을 적절히 짓는다면 코드를 이해하기 쉬워질 것이다. 이 말은 중첩 구조가 생길만큼 함수가 켜져서는 안 된다는 뜻이다. 당연한 말이지만, 그래야 함수는 읽고 이해하기 쉬워진다. 한 가지만 해라! 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. 지정된 함수 이름 아래에서 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 한다. 단순히 다른 표현이 아니라 의미있는 이름으로 다름 ..

의도를 분명히 밝혀라 의도가 분명하게 들어나있는 이름을 지어라. 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다. 그러므로 이름을 주의 깊게 살펴 더 나은 이름이 떠오르면 개선하기 바란다. 변수나 함수 그리고 클래스 이름은 존재의 이유, 수행기능, 사용 방법을 주석으로 설명하지 않아도 알 수 있어야 한다. public Set getNumbers() { Set numbers = new HashSet(); while (numbers.size() < 7) { Integer number = (int) (Math.random() * 45) + 1; numbers.add(number); } return numbers; } 위 함수는 1부터 45까지 중복이 없는 랜덤한 7개의 숫자를..

코드는 언제나 존재한다. 여러 개발자들은 코드는 더 이상 문제가 아니라고, 새로운 기술이나 비지니스 모델의 요구사항에 집중해야 한다고 생각하는 사람도 있다. 실제로 코드의 종말이 코앞에 닥쳤다고 주장하는 사람이 없지 않다. 코드를 자동으로 생성하는 시대가 다가온다는 말이다. 그때가 되면 프로그래머는 필요가 없다. 하지만 이것은 절대로 불가능한 기대다. 인간 조차도 고객의 막연한 감정만 갖고는 성공적인 시스템을 구현하지 못한다. 궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심한다. 요구사항에 더욱 가까운 언어를 만들 수도 있고, 요구사항에 정형 구조를 뽑아내는 도구를 만들 수도 있다. 하지만 어느 순간에는 정밀한 표현이 필요하다. 그 필요성을 없앨 방법은 없다. 그러므로 코드도 항상 존재하리라...

개발중에 진행되어야 하는 부분을 TODO기능을 사용해 나중에 확인할때가 있다. 하지만 모든 확인사항을 TODO로 사용하기엔 의미상 맞지도 않을 뿐더러 같은 TODO라도 다른 의미라면 구분하기 어렵다. 현재 로그인시 회원 데이터 동기화(레거시 -> 새로 개발한 서비스)하는 코드를 짜고있는데 나중에 동기화가 다 되었을때 동기화 하는 부분에 코드를 모두 지우든 주석처리하든 하려고 한다. 그래서 TODO 기능을 사용해 나중에 동기화가 완료된 후 제거해야할 코드를 구분하려고 한다. 인텔리제이 기준이다. 나는 LEGARCY라는 패턴을 사용해서 사용할 것 이다. 글자 배경, 색도 모두 변경할 수 있다. 요런식으로 사용해서 TODO를 확인하면 한눈에 구분하기 편하다

나는 이제 30살이 된 평범한 개발자이다. 나의 꿈은 열심히 공부하고 일하고 많은 경험으로 좋은 개발자가 되고 내가 살았던 이야기를 책으로 내고 싶다. 물론 내 블로그 글들이 정리가 개판이고 다른 개발자들은 다 아는 내용이겠지만 더 발전할 것이고 회사 사람들과 아직 모르는 개발자들과 공유하고 싶고 최대한 이해하기 쉽도록 정리하도록 정리하고 있다. 그것들을 위해 블로그를 시작했다. 이제 블로그를 한지 3개월 정도밖에 안되었지만 사람들이 어떤 주제에 관심이 많은지 어떤 키워드로 검색을 자주 하는지를 알게 되었다. 어느덧 누적 접속자가 3000명이 넘어간다. 어떤 사람이 볼 땐 적은 수이겠지만 나에게는 처음 공유를 해보는 입장으로써 신기할 따름이다. 나는 2019년 여름부터 다니넌 회사를 2021년에 퇴사하였..

팀 역량 강화 왜 팀의 역량이 중요한가? 예전 소프트웨어는 크기가 작고 간단했지만 현대 소프트웨어는 신경쓸것도 더 많아지고 크기도 커지고 있다. 그것들을 혼자선 처리하긴 무리가 있기에 팀이라는 조직을 꾸리는것이다. 팀 역량이 프로젝트 전체에 역량으로 나타나기 때문에 팀의 역량이 중요하다 무엇이 팀의 역량에 영향을 미치는가? Psychological safety(심리적 안정) 기본적인 여유가 있어야 한다. 누구든 좋은 아이디어나 기술이 있다면 의견을 말할 수 있어야하고 비난받지 않을것이라는 확신이 있어야 한다. 안정되지 않은 팀은 정체될것이다. Impact of work(일에 대한 중요성인지) 내가 만든 사업이 어디에 어느정도 쓰였고 어떤곳에 긍정적 영향을 미쳤는지 본인이 알아야 동기부여와 자부심과 성취감..

"문화가 일을 한다" 공정과 도구보다 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기를 카카오 문화 자기주도성 - 권한과 책임 주도적이고 빠른 의사결정을 위해 필요한 권한을 적임자에게 위임 공개 / 공유 - Shared Context 결론 뿐만 아니라 의견 개진과 토론의 내용까지도 모두 공유 수평커뮤니케이션 - 최선의 의사결정 해당 엄무의 적임자라면 누구나 의사결정 과정에 참여 문화의 바탕 신뢰 내 동료가 하는 이야기는 사용자에게 더 좋은, 그리고 카카오에 더 좋은 얘기일 것이라는 믿음 충돌 불편함을 감수하고 솔직하게 의견을 나누는 행동을 의미하며, 이성적이고 객관적 근거를 갖춘 대립의 과정 헌신 결정된 사항은 '우리의 결정'으로 ..

R&R (Role and Responsibilities) 팀장의 역할 전략 - 옳은 방향에 대한 고민과 목표를 달성하기 위한 자원 계획 리더쉽 - 팀의 역량을 지속적으로 향상시키기 위한 리더의 역할 실행 - 정해진 일정 안에 목표한 성과를 달성하기 위한 자원 관리 정치 - 팀의 성과를 인정받고 높은 보상으로 연결 / 이해관계자들과의 원만한 관계 CTO vs Head of Engineering 회사의 스테이지와 조직 구성에 따라 CTO의 역할이 달라진다. CTO에게 외부의 고객 및 파트너와의 세일즈&커뮤니케이션 비중을 더 크게 요구하고, Head of Engineering에게 기술 분석과 제품 개발의 리딩 비중을 더 요구하는 것으로 R&R(Role and Responsibilities)을 정의하고 발표를 ..