본문 바로가기

관심사

제럴드 와인버그 <Quality Software Book : How Software Is Built > - 9장 요약 Chapter 9: Why It's Always Hard to Steer9.2.2 The history of software engineeringThe Size/Complexity Dynamic 은 문제의 크기가 커질수록 복잡도가 제곱으로 높아지는 문제 유형을 말한다.소프트웨어 역사를 보면, 성공하는 경험을 할 수록, 조직은 점점 더 어려운 문제를 찾고, 도전해왔다. 그러면서 소프트웨어가 발전해왔다. 위의 그림은 소프트웨어 개발에 대한 effect diagram이다.소프트웨어 조직이 성공을 경험하면 -> 도전적인 과제를 찾아서 -> 문제의 크기가 커져서 -> 솔루션의 복잡도가 높아진다.문제의 난이도가 높아지면, 처음에는 개발자수를 늘리고, 고급인력을 채용하면서 리니어하게 문제를 해결할 수 있다. 그런데 ..
제럴드 와인버그 <Quality Software Book : How Software Is Built > - 4장 요약 How Software Is Built 본문 중에서..4.1 Shooting at Moving TargetsWhen teaching someone to shoot at a moving target, you cannot give instructions about which direction to shoot, because the direction is constantly changing. Instead, you must give general instructions about aiming guns, instructions that can then be applied to a wide variety of moving targets. That's why the study of patterns of softwa..
마틴파울러 <NoSQL 빅데이터 세상으로 떠나는 간결한 안내서> - 15장 데이터베이스 선정 본문 중에서... 15장 데이터베이스 선정NoSQL 기술을 사용하는 데는 두가지 주요 이유가 있다.애플리케이션의 필요에 더 잘 부합하는 데이터베이스를 사용해 프로그래머 생산성을 향상시키기 위해.대용량 데이터 처리, 지연 시간 감소, 처리량 증가를 통해 데이터 접근 성능을 향상시키기 위해NoSQL 기술을 사용하기로 결정하기 전에 프로그래머 생산성과 성능에 대한 기대를 테스트로 확인하는 것이 필수다.서비스를 캡슐화하면 필요에 따라 데이터 저장소 기술을 변경할 수 있다. 애플리케이션 일부를 서비스로 분리하면 기존 애플리케이션에서도 NoSQL을 도입할 수 있다.대부분의 애플리케이션에서, 특히 전략적인 것이 아니라면 관계형 기술을 계속 사용해야 한다. 적어도 NoSQL 생태계가 더 성숙해질 때까지는 그렇다. 관계..
제럴드 와인버그 <Quality Software Book : How Software Is Built > - 3장 요약 How Software Is BuiltChapter 3. What Is Needed To Change Patterns? 3.1.1 Thought and communication in various patternsOblivious. Individualism is the key. Variable. Emotion and mysticism drive everything. People don't use words in consistent way. This works under the most current sources… I've fixed several bugs and made a lot of changes in the application code since this release, so I believe t..
제럴드 와인버그 <Quality Software Book : How Software Is Built > - 2장 요약 How Software Is BuiltChapter 2. Software SubculturesQuality is value to some person(s). Requirements are not an end in themselves, but a means to an end—the end of providing value to some person(s). ... In software work, however, we cannot assume this ideal situation, so much of the development process is concerned with more closely approaching the "true" requirements. Therefore, much of what we..
제럴드 와인버그 <Quality Software Book : How Software Is Built > - 1장 요약 How Software Is Built Preface1. the ability to observe what’s happening and to understand the significance of your observations2. the ability to act congruently in difficult interpersonal situations, even though you may be confused, or angry, or so afraid you want to run away and hide 3. the ability to understand complex situations so you can plan a project and then observe and act so as to keep..
애시 모리아 <린 스타트업> - 9장 요약 본문 중에서..전형적인 제품 개발 주기는 요구사항 / 개발 / 품질보증 / 출시로 이루어져있다. 요구사항 수집 단계에서도 학습을 하지만, 많은 내용을 학습하게 되는건 제품 출시 이후다. 학습 단계에 빨리 도달하기 위해서는 가능한 한 최소 제품을 구축할 수 있게 MVP 범위를 핵심 기능으로 축소하는거다. - 가장 중요한 문제부터 시작해야한다.MVP의 핵심은 기장 중요한 문제를 해결하는 솔루션 데모에 반영되어야한다. - 있으면 좋은 기능과 필요없는 기능들을 제거해야한다. 데모의 모든 요소를 반드시 필요한 기능, 있으면 좋은 기능, 필요없는 기능으로 구분할 수 있어야한다. 필요없는 기능들은 즉시 제거하고, 반드시 필요한 선결 기능이 아니라면 있으면 좋은 기능들은 대기 목록에 추가해야한다. - 최적화가 아니라 ..
<사이트 신뢰성 엔지니어링> - 1부 요약 본문 중에서...서비스 관리를 위해 시스템 관리자를 활용하는 방법시스템 관리자를 두면 몇 가지 장점을 얻을 수 있다. 서비스를 운영하고 지탱하는 방법을 직접 결정하는 회사라면 시스템 관리자를 통해 쉽게 서비스를 운영할 수 있다. 시스템 관리자 역할을 소화할 수 있는 전문 인력도 풍부하다. 그런데 시스템 관리팀과 개발팀을 별개로 나누어 운영하면 단점도 존재한다. 변경이력관리와 이벤트 처리를 모두 수작업에 의존하는 팀을 통해 서비스를 운영하게 되면 서비스와 트래픽이 증가하면 업무량 역시 늘어나서 팀의 규모가 커져서 결국 큰 비용이 들게 된다. 그리고 이러한 직접비용보다 간접비용이 더 큰 비용을 발생시키기도 한다. 두 팀의 배경 지식, 스킬, 동기 유발 조건 등이 각각 다르기 때문이다. 그래서 서로 다른 용어..