일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 |
- 함수형 사고
- 2016년회고
- 개발7년차매니저1일차
- Raw-Request-URI
- coursera
- 데이터레이크
- 회고
- 클린코드
- 2017회고
- 데이터유통
- 개발자
- 해커컵
- datalake
- 데이터플랫폼
- 알고스팟
- kafka
- spray
- clean code
- 실전사례
- 데이터야놀자
- 테스트주도개발
- 개발자로살아남기
- 동시성
- 단위테스트
- hackercup2017
- wait region split
- 박종천
- functional thinking
- 코딩인터뷰
- 켄트백
- Today
- Total
목록전체보기 (97)
Software Engineering Note
다양한 코드 냄새에 대한 내용. 수정해야할 부분이 있을때 보통 냄새가 난다는 표현을 한다. 주석 부적절한 정보. 소스코드 관리 시스템, 버그 추적 시스템 등 시스템에 저장할 정보는 주석으로 적절하지 못하다.중복된 주석. 코드만으로 충분한데 굳이 설명을 붙이는것주석으로 처리된 코드를 발견하면 즉각 지워버려라! 소스코드관리 시스템에 어차피 남으니까 환경 빌드는 간단히 한단계로 끝나야 한다. 모든 단위 테스트는 한 명령으로 돌려야 한다. 모든 테스트를 한 번에 실행하는 능력은 아주 근본적이고 아주 중요하다. 함수 너무 많은 인수. 넷 이상은 그 가치가 아주 의심스러우므로 최대한 피한다.플래그 인수. boolean 인수는 함수가 여러 기능을 수행한다는 명백한 증거다. 피할것죽은함수. 아무도 호출하지 않는 함수는..
https://www.coursera.org/learn/progfun1 6월부터 7월 말까지 수강했다.총 5개 과제를 코스가 끝나기전에 과제당 8/10점 이상으로 통과하면 된다. 늦게 제출한 댓가로 페널티도 없다. 과거에 비해 좀 완화된 느낌인데, 시간이 유동적인 사람들에게는 유리한면도 있지만 대책없이 미뤄버리면 나중에 감당이 안되기때문에 조심해야한다. 심지어 지금까지 획득한 스코어를 가지고 다음열리는 코스로 넘어갈 수 있다. 여러모로 수강하는 사람들에게는 유연해졌지만 바짝 쪼여줘야 어떻게든 끝내는 사람들에게는 수강이 언제 끝나게 될지 모르는 코스가 되었다. 최종 점수가 2% 부족한 98%. 딱 어정쩡한 나같다. 또한, scala 스페셜 코스를 준비해두었다. https://www.coursera.org/..
최근에 진행한 프로젝트에서 처음으로 프로젝트 리더를 맡았다. 끝나고 나니 뭐 특별한게 있었을까 싶지만 어쨌든 경험을 공유해보고자 한다. 내 상황은 다음과 같았다. 프로젝트의 성격은 전환성이었다. 기존에 있던 시스템을 새로운 시스템으로 전환하는일직접 프로젝트를 진행한 참여인원은 나 포함 2명. 그런데 관련 시스템이 있어서 협업은 총 4명나만 근무지가 판교였고, 나머지 인원은 모두 제주도였다. 프로젝트 리더의 역할 프로젝트 리더라고 해서 어떤 지위적인 우위를 의미하는건 아니다. (특히 kakao 같은 수평문화를 지향하는 조직에서는 더더욱) 주로 개발외에 다음과 같은 일을 담당했다. 주간회의 시간에 진행상황을 정리하고 공유한다.기술셋을 정하고 전체적인 시스템 구조를 잡는다.계획을 세우고 정리한다. (이번주기에..
페북 타임라인에 회자되길래 구입한 책. 구입한지는 꽤 되었는데 이제서야 다 읽었다. 전체적으로 필체가 강력하다고 해야할까? "~하면 안된다. 그건 프로페셔널이 아니다." 이런 문구가 자주 등장한다.아주 대쪽같은 선비가 훈계를 하는 그런 느낌이랄까? 덕분에 정신이 번쩍나는 기분도 느낄 수 있었다. 저자는 브라질 출신으로 어릴적부터 프로그래밍을 해왔다고 한다.그러다 유럽으로 가서 일을하고싶어 소프트웨어 개발자를 직업으로 선택하게 되었고, 그 이후로 자신이 전문가로 거듭나게 된 이야기를 간간히 섞어서 이야기 해준다. 예를 들면, 그 당시에는 난해한 코드를 짜서 코드를 읽는 사람들을 곤란에 빠뜨리는게 실력이 좋은 것으로 인정 받았었는데, 사수를 만나서 까인(?) 경험이 충격이었다고. 결국, 개발문화가 잘 정착되..
https://www.google.com/about/careers/students/guide-to-technical-development.html 구글에서 제시한 학습(?) 가이드. 요즘 온라인 코스가 많이 생겨서 공부하기 참 좋은 환경이 되어가고 있다. 대학때 제대로 학습을 못한 경우도 있고 (나도 그렇고..) 현업에서는 기초를 다질 시간이 많지않기때문에 시간을 내서 수강해두면 좋을것같다. Take an “Introduction to CS” courseFocus on basic coding instructionsOnline resources:Udacity - Introduction to Computer ScienceCoursera - Computer Science 101Code in (at least)..
2015년 마지막 날에 회고를 한다. 올해도 역시 프로그래밍 대회에 참여했다. 그 성적은 페이스북 해커컵 (1월) => Round1 까지구글 코드잼 (4월) => Round1 까지SKP 코드 스프린트 (7월) => Round2 8위 (http://codesprint.skplanet.com/2015/ranking/round/2)코드 스프린트에서 의미 있는 결과가 있었던듯하다. 추천 문제였는데 재미있었다. 운영상의 문제(?)가 있어서 고득점자들이 평가불가가 되버려서 순위권에 올라간 것. 운이 좋았다고 해야겠다. 프로그래밍 대회에는 매년 참가하지만 준비는 그만큼 못하는 것같다. 바쁘다고 하지만 핑계지 뭐 -_-;; 알고리즘 공부좀 제대로 해서 참여해보고싶다. 클린코드 스터디를 계속해서 꼭! 끝을 보고싶었는데 ..
이 장에서는 명령행 인수(argument) 구문분석기를 구현하고, 점진적으로 개선하는 것을 보여준다. 코드가 대부분이라 여기에 적을수는 없지만 모두 타이핑 해봤다. (진짜다..) 따라하면서 느낀점은, 테스트를 꼼꼼하게 작성하고 개선을 정말 조금씩 한다는거다. 나는 보통 한번에 막 고치는 스타일인데 급한 성격을 가라앉히고 천천히 개선하는 습관을 들여야겠다. 읽다가 옳다구나! 하는 문구정도만 정리해본다. 지난 경험에서 얻은 교훈=> 프로그래밍은 과학보다 공예에 가깝다는 사실. 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다는 의미다. 프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위다. => 돌아올 수 없는 강을 건너지 말고 조금씩 개선. TDD를 ..
개발 하다가 느끼는 좋은 코드를 만드는 간단한 습관 딱 2가지. 1. 메소드로 추출해서 잘개 쪼개기2. 중복 제거 이게 땡이라는게 아니라 시작점이라고 말하고싶다. 메소드로 잘게 쪼개다보면 누가누가 친한지가 보이게되고, 친한 애들은 따로 모아놓고싶어진다. 그러면 클래스로 빼내게 되고 친한 애들은 모여있게 되니 전문용어로 응집도가 높아지게 되겠다. 그리고 이렇게 기능별로 잘 나누어지게 되면 테스트 하기도 수월해진다. 중복제거는 말 그대로 반복되는 코드는 하나로 묶어두고 재사용하자는 것이다. 이걸 잘 하려면 어떤 부분이 공통부분이고, 어떤 부분이 독립적인지 잘 가려내야한다. 그냥 머리로 파악하는게 아니라 실제로 이렇게 해보고 저렇게 해보면서 (일명 삽질) 공통된 부분을 추출해가는 것이다. 실용주의 프로그래머에..
객체지향의 사실과 오해- 역할, 책임, 협력 관점에서 본 객체지향조영호 지음 | 위키북스 | 2015.06.17책소개객체지향에 대한 선입견을 버려라! 『객체지향의 사실과 오해』는 객체지향이란 무엇인가라는 원론적면서도 다소 위험한 질문에 답하기 위해 쓰여진 책이다. 안타깝게도 많은 사람들이 객체지향의... 같은 회사에 다니는분이 추천하셔서 읽어본 책. 제목 그대로 책체지향에 대해 개발자들이 오해하고 있는 부분들을 집어내고, 어떤것이 좋은 설계인가를 다루는 책이다. 코드가 거의 없는 책이기때문에 개념 위주로 비교적 어렵지않게 읽을 수 있는 책이었다. 특히 이상한 나라의 앨리스를 예로 들면서 이야기에 나오는 부분들을 객체지향 설계 부분과 잘 엮어서 설명하고 있는데 이 부분만 봐도 객체지향에 대해서 얼마나 많은..
동시성이 필요한 이유 동시성은 결합을 없애는 전략이다. => "무엇"과 "언제"를 분리한다. 구조적 관점: 무엇과 언제를 분리하면 애플리케이션 구조와 효율이 극적으로 나아진다. 처리량 개선: 응답을 기다리는 웹 정보 수집기, 많은 사용자를 처리해야 하는 시스템 등에서 동시성이 요구됨 동시성에 대한 미신과 오해 동시성은 항상 성능을 높여준다 => 동시성은 "때로" 성능을 높여준다.동시성을 구현해도 설계는 변하지 않는다 => 일반적으로 무엇과 언제를 분리하면 시스템 구조가 크게 달라진다.웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다. => 컨테이너가 어떻게 동작하는지, 어떻게 동시 수정, 데드락 등과 같은 문제를 피할 수 있는지 알아야 한다. 동시성에 대한 타당한 생각동시성은 다소 부하를 ..