Home

Search results

"category:/BestPractices"

1 2 3 4 Next >>

Title and summary Date/time
1
Twitter는 어떻게 1초에 3,000개의 이미지를 처리하고 있나?
Twitter는 서비스에서 어떻게 이미지를 처리했는지에 대해 잘 정리된 글이 있어서 원 저자의 허락하에 제 블로그에 포스팅합니다. 원 글은 How Twitter Handles 3,000 Images Per Second" 입니다. 이 글을 통해 퍼블릭 서비스를 만들때 사이트내에서 미디어를 어떻게 처리하면 좋을지에 대한 좋은 힌트를 얻을 수 있으면 더더욱 좋을 거 같습니다. 아래부터는 번역 내용입니다. 현재 Twitter는 초당 3,000장의 이미지(약 ...
Oct 12, 2016
5:55:25 PM
2
스타트업에 필요한 코드 품질 관리
코드 품질 관리 부분은 개발자가 소홀히 하기 쉬운 부분이고, 대기업에서는 어느 정도 품질관리 부서가 있어서 프로세스화 되어 있는데, 작은 기업들은 개발자의 성향에 의존하는 환경에 놓여 있어, 개발자가 코드 리뷰하기 전에 남에게 내 놓을 수 있는 최소한의 품질이 보장되는 코드를 양산하도록 도와주는 정적 분석 도구에 대한 사용 가이드를 정리해 보았습니다. 정적 분석 도구를 통해 우리는 기존에 공유된 코딩 스타일을 위반하거나, 잠재적 버그의 가능성이 있는 ...
Nov 5, 2015
4:40:47 PM
3
코드 리뷰의 기본 원칙들
1. 리뷰도 프로젝트의 공식일정과 자원에 포함시킨다. 2. 목표는 사람(사람에 대한 선입견 포함)이 아니라 산출물(프로그램 등)을 검토한다. 3. 문제를 명확하게 할 순 있어도 모두 해결하려고 하지 않는다. 4. 성능과 이해도에 영향을 주지 않는 한 그 사람의 스타일을 문제제기하지 않는다. 5. 리뷰는 2시간을 넘지 않는다. 6. 초기에는 비공식 리뷰나 교육을 자주하고 일정 시간이 지나면 공식 리뷰로 전환한다. 7. 필요하면 체크리스트를 만들어서 리뷰에 ...
Oct 10, 2015
6:29:29 PM
4
Trello, Github, Slack을 활용한 개발 프로세스
개발 흐름 이 프로세스 문서의 현행화는 Github에서 진행되니 추후에는 Github을 방문해 주시면 고맙겠습니다. 개발 프로세스(Trello, Github, Slack) 1. Trello Card 만들기 1.1 기본적인 Trello 흐름 먼저 Trello에서 개발해야 할 기능을 [To Do(Story)]라는 이름의 리스트에 카드로 만들고, 해당 스토리(카드)를 개발자가 구현에 들어가면 [Doing(WIP)] 리스트에 카드를 옮기고, 리뷰에 ...
Jun 8, 2015
5:21:02 PM
5
리팩토링이나 코드 리뷰에 사용할 체크리스트
리팩토링이나 코드 리뷰에 사용할 체크리스트로 사용해도 좋을법한 약어들을 공개합니다. 아직 부족하지만 같이 채워나가요. ^^ DC(Duplicate Code) - 중복된 코드(중복된 코드나 조건들). BPC(Bad Performance Code) - 성능에 좋지 않는 코드. BN(Bad Name) - 변수나 클래스, 함수 등에 너무 길거나 가독성 떨어지고 일관되지 않은 이름. VS(Violates Specifications) - 가이드나 지침을 따르지 ...
Oct 15, 2014
8:10:54 PM
6
그냥 '왜'라고 묻는 것이 항상 최선의 전략은 아니다
좋은 제품을 만드는데 있어서 본질을 파고드는 데 좋은 사례가 바로 '왜?'라는 질문을 자신과 이해당사자들과의 토론에서 끊임없이 하는 것이다. 하지만 건성의 '왜'로 핵심을 파지않고 그저 내용의 이해만을 도울 수 있는 왜는 지양해야 된다는 좋은 아티클 'ASKING WHY IS NOT ALWAYS THE BEST STRATEGY'이 있어 내용을 요약해 봅니다. 제품을 만들 때 ‘왜’라는 질문을 반복하는 것은 본질적인 문제에 도달할 수 있는 좋은 ...
Jun 13, 2014
9:39:30 AM
7
왜 일이 예상대로 끝나지 않는가?
1. 시간을 낭비하고 있는건 아닌지. 시간이 있을 때 그때 그때 스스로 찾아서 완결해 가야 하는데, 마감이 임박하지(빠듯하지) 않으면 동기 부여가 안된다. 초반에 느슨하게 하다가 막판에 불지르다가 일정과 품질에 악영향을 준다. 2. 인터럽트 되는 일을 우선시 한건 아닌지. 일을 하게 되면 항상 생기게 마련이 일의 집중도를 떨어뜨리는 인터럽트이다. 이것 때문에 지금 하는 일이 밀려나고 나중에 다시 시작할 땐 업무 전환 비용이 생긴다. 이럴 땐 장유유서, ...
Apr 25, 2014
9:56:27 AM
8
사이드 프로젝트의 효용성 그리고 중요성
기업에서 개인 자신에 이르기까지 직원들이나 개인 스스로 자신의 잉여 시간을 잘 활용하는 방법에 대해 고민을 많이 하고 있습니다. 그 중에 하나로 사이드 프로젝트를 활용하는 사례가 많이 도출되고 있어 좀 정리를 해 봤습니다. 생각에 그치지 않고 그것을 실현해가는 습관을 길러주는 사이드 프로젝트, 개인에게 사이드 프로젝트 하나쯤은 지속적으로 유지하면 더 커진 나를 발견할 수 있다고 생각합니다. 그리고 먼저 지속적으로 유지해 보세요. 뭔가 달라질 것 같아 ...
Apr 23, 2014
9:23:15 AM
9
4개의 테크 기업을 창업하면서 배운 90가지 유/무형의 자산들
"90 Things I’ve Learned From Founding 4 Technology Companies"라는 포스트는 기업가분들이 기업을 운영함에 있어서 산제되어 있는 많은 문제 해결을 위한 훌륭한 인사이트가 많이서 발번역 수준이지만 번역해 봅니다. 1. 당신 회사의 유일한 비즈니스를 찾아라. 그 비즈니스는 아래 3가지 진리라는 공통점을 가지고 있어야 한다. - 당신과 팀이 큰 열정을 받을 것. - 당신과 팀이 세계에서 제일이 될 수 있는 ...
Mar 13, 2014
6:00:10 PM
10
[번역] 왜 소프트웨어 개발 방법론이 제대로 작동하지 않는가?
이 포스팅은 며칠 전 ycombinator의 트윗(Why don’t software development methodologies work? )을 킵해 놓았다가 좀 더 효율적인 개발에 대한 생각을 정리하고 고민하는 차원에서 번역을 진행해 보았습니다. 방법론이 재대로 작동하는지를 어떻게 알 수 있나? 방법론이 잘 작동하는지 여부는 팀 생산성, 행복, 관계 유지, 예측 가능성, 책임, 의사 소통, 일별 코드량, 맨먼스, 코드 품질, 만들어진 산출물 등 ...
Feb 14, 2014
2:20:58 PM
11
맥도날드 이론
Jon Bell이 팀이나 회사에서 어떻게 하면 창의성을 장려할 수 있는지를 생각하다가 나온 것이 "McDonald’s Theory"인 것이다. 내용인즉, 모든 사람들이 점심시간만 되면 우리는 백지 상태 증후군(blank slate syndrome)이 되죠? ㅋㅋ 점심을 먹기 위해서 어디로 갈까?라는 말을 하면 어느 누구도 말문이 막혀 좋은 곳을 내놓지 않는다. 그럴 때 "맥도날드 어때?" 라고 누가 추천하면 어떤 일이 벌어질까? 모든 사람이 ...
Dec 29, 2013
12:07:51 PM
12
TDD에 관한 비용적인 관점
Ruby on Rails의 창시자 David가 TDD에 대해 비용의식에 대해서 쓴 내용(Testing like the TSA from 37signals)이 있어 정리해 봅니다. TDD에 대한 가치는 분명히 있지만, 무조건적인 옹호보다는 TDD의 비용 인식을 통해 합리적 대안을 찾아서 TDD를 수행하는 것도 괜찮아 보입니다. 먼저, 개발자는 테스트 주도 개발(TDD)의 놀라움을 발견했을 때, 우리들은 스트레스나 불안이 적은, 새롭고 더 좋은 세계의 ...
Dec 26, 2013
2:55:19 PM
13
아이디어를 확산시키는데 필요한 5가지 공통적인 특징
어떻게 하면 아이디어를 확산시킬 수 있는지에 대한 좋은 고민들을 정리한 "The 5 Common Characteristics of Ideas That Spread"이라는 아티클을 메모 차원에서 블로그에 포스팅합니다. 대부분의 창조적인 성공은 뛰어난 아이디어를 생각하고 만드는 것 뿐만 아니라, 그 아이디어를 타겟 고객층에 채택되어질 필요가 있다. 어떤 분야라도(소비자층이나, 미술상, 당신의 직속 관리자나, 당신의 문제를 해결하는 것) 머릿속의 아이디어를 ...
Oct 22, 2013
8:23:24 AM
14
Gang of Four로부터 배우는 10가지 기업가를 위한 레슨
"Gang of Four"는 Amazon, Apple, Facebook과 Google을 말하고, 이들이 현재의 기술을 리드하고 있다고 구글의 Eric Schmidt가 말한데서 유래합니다. Gang of Four를 통해 설득력 있는 비즈니스 모델을 구축하는 방법을 제시한 아티클 "10 Entrepreneurial Lessons From the 'Gang of Four'"를 보면서, 정리를 해 두면 좋을 것 같아 여기에 몇자 적어봅니다. 그리고 제 개인적인 ...
Sep 29, 2013
4:08:29 PM
15
Etsy의 장애(오류, 실수 등 포함된)와 관련된 좋은 문화
버그, 에러, 장애 등에 대해 좋은 인사이트 하나를 챙길 수 있는 "Etsy의 장애(오류, 실수 등 포함된)와 관련된 좋은 문화"라는 아티클이 있어 소개합니다. 개발이나 운영 등 DevOps 문화에 반영하면 좋을 듯 하네요. 대략적으로 요약하면.. 장애의 원인을 일으킨 멤버의 처벌이나 비난을 하지 않는다. 처벌이나 비난으로 인해 자세한 문제의 경위를 보고하지 않는다면, 다른 구성원들에게 동일한 장애가 유발되기 때문에. 그래서 어떤 작업을 ...
Sep 23, 2013
10:48:19 PM
16
예외에 대한 생각들
생각거리들 예외는 코드에서 보이지 않기 때문에 예외가 던져질지, 안던져질지 모르는 상황에서 catch로 습관화해 자신의 좋은 코딩 의무를 회피하는 경향이 있다. 그래서 개발자는 자신의 코드를 깊게, 면밀하게 코드를 탐독해서 예외 상황을 발생 시키지 않도록 잠재적인 버그를 줄일려는 노력을 해야하는데, 이런 두리뭉실한 예외를 catch하는 것으로 자신의 코드와 타협을 하고 있는건 아닌지 고민해야 한다. 예외가 코드에서 오히려 버그를 양산할 수 있다. ...
Sep 4, 2013
1:26:54 PM
17
래리 월이 말한 프로그래머가 가져야할 세가지 덕목
낙타 책의 애칭으로 사랑 받고 있는 "Programming Perl"에서 Larry Wall 은 프로그래머에 필요한 3대 덕목을 재밌게 설명하고 있어, 마음을 되새기기 위해 메모를 해 둡니다. 1. 나태(Laziness) The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that ...
Nov 11, 2012
12:09:35 PM
18
어떻게 하면 프로젝트 관리자는 조직의 민첩성을 올릴수 있을까?
검색을 하다가 우연히 How Can Project Managers Promote Agility in Their Organization?라는 포스트에서 관리자들에게 좋은 인사이트들을 발견할 수 있어 정리를 해봤습니다. 프로젝트 관리자들에게서 조직을 유연하고 민첩하게 만들 수 있는 방법들은 뭐가 있을까요? 아래에 정리한 내용들을 가지고 실천해 보는것도 좋아 보이네요. ^^ 1. 사람들을 물리적으로 가까운 거리에서 함께 일하게 한다. 항상 가능한 것은 ...
Nov 10, 2012
12:53:00 PM
19
코드 리뷰 지침서
개인적으로 코드 리뷰를 했을 때, 이랬으면 좋겠다는 생각을 주섬 주섬 적어본다. 정답은 아니지만 이런 관점을 유지한다면, 앞으로 더 발전적이고 대중화될 수 있는 코드 리뷰가 되지 않을까 생각해 본다. 코드 리뷰는 매우 좋은 일이지만, 잘 일어나지 않을 가능성이 많아서 정말 좋은 인상을 심어줘야 한다. 이건 정말 대의 명제다. 마음을 열고 다른 사람이 자신의 의견을 잘 말할 수 있도록 해주고 경청하는 자세가 아름답다. 말을 안해도 서로가 배울 수 있다. ...
Oct 19, 2012
11:09:42 AM
20
소프트웨어 아키텍트를 위한 팁
우리나라에서 소프트웨어 아키텍처를 만드는 아키텍트에게는 너무나 많은 짐이 부여되어 있고, 또한 아키텍트 본인 스스로도 수많은 사례들을 찾아서 그 방법들을 문제 해결에 적용해 보려 한다. 너무 많은 사례가 타인 합리와에 의해 자기 합리화가 된 것이다. 많은 사례를 적용한다는 것은 그만큼 프로젝트 이해 당사자들에게는 큰 짐이 아닐 수 없다. 어떻게 하면 핵심적인 요소들만 추려서 부담을 최소화하고 아키텍처를 유연하게 할지의 노력이 분명 필요해 보인다. 그리고 ...
Oct 8, 2012
10:48:34 AM

1 2 3 4 Next >>