Property Change event 를 작성하지 않아도 이 이벤트가 fire될 수 있도록 한다. :)

[Nuget package 설치 전]

public string InitialQty
{
    get
    {
        return _initialQty;
    }
    set
    {
        if (value != _initialQty)
        {
            _initialQty = value;
            base.RaisePropertyChanged(m => m.InitialQty);
        }
    }
}

[Nuget package 설치 후]

public string InitialQty { get; set;}

BaseViewmodel에 AddINotifyPropertyChangedInterface attribute를 추가한다. 

BaseViewmodel를 상속받아 Viewmodel을 작성하면 된다. ^^

/// <summary>
/// A base view model that fires Property Changed events as needed
/// </summary>
[AddINotifyPropertyChangedInterface]
public class BaseViewModel : INotifyPropertyChanged
{
    /// <summary>
    /// The event that is fired when any child property changes its value
    /// </summary>
    public event PropertyChangedEventHandler PropertyChanged = (sender, e) => { };
 
 
    /// <summary>
    /// Call this to fire a <see cref="PropertyChanged"/> event
    /// </summary>
    /// <param name="name"></param>
    public void OnPropertyChanged(string name)
    {
        PropertyChanged(this, new PropertyChangedEventArgs(name));
    }
}

public class MainWindowViewmodel : BaseViewModel
{

책을 읽지 못했지만 Appendix에 좋은 글이 있어 적어논다. :)

A. 엔지니어는 고집쟁이

• 다른 사람의 해결책이 나와 다르다고 해서 틀린 것이 아님을 인정해야합니다.
• 최종 목적지가 틀린 것은 아니고, 오히려 더 빨리 가능 경우도 있겠죠. 
• 어떤 사람이 '똥고집'을 부린다면 ? 본인의 의견을 반영하도록 그 사람을 설득

• 직급은 일을 지시하기 위해 필요한 것이 아니라 업무상의 편의를 위해 사용하는 단어일 뿐입니다.

• 엔지니어가 CEO인 회사는 가지 않겠다. 입니다. 엔지니어의 특징 중에 한 가지는 너무 분석적이라는 것인데요. 그래서 때로는 과감한 투자라는 것을 하지 못하는 경우가 많았습니다.
• 반면에 전문 경영인은 기술적 깊이보다 경영에 대한 센스가 좋고, 얕지만 넓은 시야를 가지고 있는 사람들입니다. 
• 엔지니어의 경우 기술을 습득하는 위조로 살아온 사람들입니다. 그렇기 때문에 자금운용, 영업력, 마케팅 그리고 인력 관리라는 면에서 약할 수밖에 없기 때문입니다.
• 엔지니어가 기술 구현을 잘 하듯이 전문 경영인이 가장 잘하는 것이 회사를 성장시키는 것이기 때문입니다. 

• 부족한 지식을 채우기 위한 경우와 새롭게 프로젝트를 진행해야 하는 경우 . 관련된 자격증을 취득해보는 것이 어떨까 생각합니다. 

• 눈지 보지 말고 쉬십시요, 열심히 일하고 노력한 엔지니어에게 눈치주는 사람은 아무도 없습니다. 

간반(Kanban)은 한국어로 간판이다. 이렇게 쉬운말이었다. 

간판에 일의 진행사항을 기록하고 보여주고 관리한다고 이해하면 편하다. 

저자는 스크럼과 칸반의 좋은 점들의 가져와서 잘 쓰라고 이야기한다. 

절차와 도구에 집중하지 말고 비즈니스에 집중해야한다. 애자일을 따른다. 

• 스크럼 요약
• 조직을 작고, 교차 기능적이며 자기 조직적인 팀으로 쪼개라
• 일을 출시 가능한 작은 단위의 목록으로 나누라
• 목록을 우선순위에 따라 정렬하고 각 항목에 대해 상대적인 노력을 추정하라
• 시간을 짦고 고정된 길이의 이터레이션으로 나누고
• 이터레이션을 마칠 때 잠재적으로 출시 가능한 코드를 시연하라
• 출시 계획을 최적화하고, 매 이터레이션 이후 결과물을 검토하면서 얻어진 지식을 바탕으로 고객과 협업을 통하여 우선순위를 수정하라
• 이터레이션을 마칠 때마다 회고를 실시하여 프로세스를 최적화 하라
• 소규모 팀에서 짦은 기간 동안 작은 것을 만들도록 한다. 
• 전체적인 모습을 볼 수 있게 정기적으로 통합한다. 

• 칸반 요약 
• 작업 흐름을 시간화하라
• 일을 작은 조각으로 나누고, 카드에 각 항목을 기입한 후 벽에 붙인다.
• 이름이 부여된 열을 사용하여 각 망목이 작업 흐름이 어디에 있는지 표시한다.
• WIP 개수를 제한하라. 각 작업 흐름 상태별로 작업 중인 항목을 얼마나 허용할 것인지 확실한 수치를 부여한다.
• 리드 타임을 측정하고 , 리드 타임을 가능한 한 짧고 예측 가능하게 만들 수 있도록 프로세스를 최적화 한다. 

• 스크럼과 칸반 비슷한점
• 둘 다 린하고 애자일 하다.
• 둘 다 당김 스케줄링을 사용한다
• 둘 다 WIP 리밋을 둔다
• 둘 다 투명하게 공정 개선을 이끌어낸다.
• 둘 다 출시 가능한 소프트웨어를 자주, 일찍 출하하는 데 집중한다.
• 둘 다 자기 조직화된 팀을 기반으로 한다.
• 둘 다 일을 작은 단위로 쪼갤 필요가 있다.
• 둘 다 출시 계획은 경험적인자료(속도, 리드 타임)에 기반을 두고 지속적으로 최적화한다. 

• 나머지 책 내용 정리 
• 스스로를 한가지 도구에 제한하지 말라!
• 여러분에게 맞는 것이라면 무엇이는 취하라
• 대신 각 도구의 제약에 관심을 기울이라
  

• 스크럼과 RUP의 가장 큰 차이점 하나는 , RUP를 사용하면 너무 많은 것을 가지고 가서 불필요한 것들은 제거해야 하는 반면 스크럼을 사용하면 너무 조금밖에 없어서 빠진 것들을 추가해야한다. 칸반은 거의 모든 것이 열린 상태다.                     => 프로젝트 맞는 도구를 적절이 사용하는 것이 포인트이다. 

• 스크럼과 칸반은 모두 당김 스케줄링 방식이며 이는 린의 원칙인 JIT(Just In Time) 재고 관리 방식에 해당한다. 이 말은 언제, 얼마나 많은 양의 일을 할지 팀이 정한다는 뜻이며 외부로부터 일을 '넘겨받기'보다는 팀이 준비가 되었을 일을 '당겨온다'는 것이다. 마치 우리 공장에서 SMD라인에서 Component를 다 사용했을 때 내부창고에 자재를 요청해서 당겨오는 것과 같다. 내부창고에서는 Push하지 않는다.

• 스크럼과 간반은 지속적이며 경험주의적 프로세스 최적화에 기반들 두고 있으면 린의 원칙인 '카이젠'에 해당한다. 카이젠은 개선이다. 

• 스크럼과 칸반은 계획을 따르기보다는 변화에 대응할 것을 강조한다. 애자일 선언의 네 가치 가치 중에 하나에 해당한다. 

1. 21세기 소프트웨어 개발
   • 오버엔지니어링 - 코드 작성 전에 대응책을 추상화 하고 , 요소마다 디자인 패턴 적용 / 애자일 방식으로 변경 
   • 커리어 패스를 정할 때 - 내가 열정이 있는 것, 진정 즐겁게 할 수 있는 것을 따라야한다.
   • 고참 개발자, 신참 개발자라는 것은 없다. 
   • 개발자들은 다음과 같은 일을 할 수 있어야 한다. (사진 1)
   • 소프트 웨어를 빠르게 바꾸면서도 품질 유지가 가능하다면 높은 경쟁 우위를 차지할 수 있다. 소프트웨어를 비즈니스의 핵심 자산으로 둔 회사 (아마존, 구글, 트위터, 페이스북 등)가 이러한 경쟁 우위가 있다면 시장에서 메이저 업체로 빨리 성장할 수 있다.
   • 기민하고 정교하게 잘 만들어진 소프트웨엉[ 대한 요구가 그 어느 때보다 높다.
2. 애자일
   • 절차적인 부분 : 팀에 정말로 중요한 것, 비즈니스에 가치가 있는 것에 집중한다. 올바른 목표를 향해 진행 중인지 확인할 수 있다.
     • 회의방식
     • 구성원 각각의 역활
     • 요구사항 파악 방법
     • 작업 진척 속도 파악 방법
     • 점진적/반복적으로 일할 때 취하는 방식
     • 진행 상황을 개발팀 밖의 관계자(고객, 영업 등)에게 전달하는 방식
     • 비즈니스 피드백 방식
   • 기술적인 관점 : 테스트 주도 개발, 페어 프로그ㅐ밍, 지속적인 통합, 단순한 다자인 원칙. 목표한 것을 올바르게 실행하고 있는지 안심할 수 있게 한다.
3. • '애자일을 따른 다'는 것은 새로운 환경에 성공적으로 적응하고 있다는 의미다 - 톰 길브
4. • 민첩(Agile)하다고 해서 애자일을 실행하고 있는 것은 아니다. 애자일 방법론들은 모두 빠르고 짧은 피드백 루프에 대한 것이다.

1. • 미리 세운 계획에 따라 기계적으로 코딩만 하는 것이 아니라, 계획, 일정 및 예산 드의 추산, 요구사항 분석, 팀 구성, 분석, 아키텍처, 제품 리리즈, 우선순위 조정, 시연 그리고 사용자와 프로젝트 이해관계자에게 정긱적으로 피드백을 받는 단계까지 개발자가 수행하기 시작.
2. • 코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져야 할 최소한의 요건이다. 그에 더해 테스트, 분석, 비즈니스에 대한 이해, 커뮤니케이션 능력, 보자 외향적인 성격을 소프트웨어 프로페셔널에게 요구한다.
     
     
   • 애자일 메니페스토(선언문)
     • 우리는 스스로 행하고 다른 이들도 이를 행할 수 있도록 도움을 줌으로써 소프트웨어 개발의 더 나은 방법을 전파한다. 이러한 작업을 통해 우리는 아래와 같은 가치에 도달하게 되었다.
       • 절차와 도구를넘어선 개성과 화합
       • 종합적인 문서화를 넘어선 동작하는 소프트웨어
       • 계약과 협상을 넘어선 고객과의 협력
       • 계획 준수를 넘어서 변화에의 대응
     • 이들의 앞선 가치들을 인정하면서도 뒤에 오는 가치들에 보다 큰 무게를 둔다.

1. • 애자일 12가지 원칙
     • 1. 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
     • 2. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
     • 3. 작동하는 소프트웨어를 자주 전달하라. 2주 ~ 2개월 정도의 간격으로 하되 더 짧은 기간을 선호하라.
     • 4. 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
     • 5. 동기가 부여된 사람들을 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
     • 6. 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
     • 7. 작동하는 소프트웨어가 진척의 주된 척도이다.
     • 8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
     • 9. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
     • 10. 단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다.
     • 11. 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.
     • 12. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

3. • 애자일 스럽지 못한 프로젝트 - 기술적 탁월함보다 절차가 더 중요해졌다. 애자일의 모든 절차들에게는 기술적 탁월함이 전재되어 있다. 
   • 절차에감 집중하고 소프트웨어 개발을 공장 라인처럼 취급하면, 그저 시키는 일만 하고 출퇴근하는 공장 노동자와 다를 바 없는 개발자들만 생긴다. 이렇게 되면 비효율적인 피드백 시스템이 되어 전체 프로젝트에 해를 끼친다.
   • 고참 관리자에게 새로운 절차를 파는 것은 쉽지만 많은 노력과 어려움이 수반되는 기술역량 향상에 투자하도록 설득하기는 꽤 어렵다. 그들은 개발자들이 작성하는 코드 자체의 품질에 관심을 기울여야 한다는 것도 모른다. 그들은 그져 코드가 동작하기만 하면 그냥 만족할 뿐이다.
   • 요약 
   • 기업이 경쟁력을 유지하려면 소프트웨어를 빨리 개발하면서도 더 나은 품질을 유지할 수 있어야한다.
   • 애자일 소프트웨어 개발은 피드백 루프를 짧게하고 변화와 고객의 요구에 빠르게 대응할 수 있는 기회를 준다.
   • 애자일 프로젝트에서 기술적 탁월함의 개선 없이 절차만 개선하는 것은 무의미 한다.
   • 완전한 애자일 전환을 위해서는 프로페셔널 소프트웨어 개발자들이 필요하다.
   • 이들은 기술적 실행 관례, 기술적 전문성 그리고 관련도구들을 마스터하고 있어야한다.
   • 정기적으로 배포되는 소프트웨어에 대해서도 높은 품질을 유지시키며, 완벽하게 테스트되고 쉽게 변경할 수 잇는 소프트웨를 개발할 수 있어야 한다.
   • 완전한 애자일 전화을 위해서는 기업들이 소프트웨어 장신정신을 품어야한다
   
   
4. 
   
5.  소프트웨어 장신 정신
   • 여기저기를 유랑하며 새로운 장인에게 새로운 기술과 도구의 사용법을 익힌다.

3. • 매니페스토 - 프로페셔널 소프트웨어 개발의 수준을 높인다.
     • 동작하는 소프트웨어뿐만 아니라, 정교하고 솜씨있게 만들어진 작품을
       • 코드를 수정할 때 어떤 일이 일어날지 개발자가 알 수 있어야 하고,
       • 수정 자체가 두려운 상황에 처하지 않도록 해야한다. 
       • 변경 사항이 있더라도 그 영향이 해당 기능 모듈에만 국소적으로 제한되며 애플리케이션의 다른 부분에 파급 효과가 없어야 
       • 몇 분 또는 몇 초 만에 전체 애플리케이션에 대한 자동화 테스트가 구동되어 잘못된 부분이 있는지 파악 가능해야한다. 
     • 변화에 애응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을
       • 신규 기능을 추가하거나 버그 수정만을 뜻하지는 않는다. 코드를 깔끔하게 정리하고 구조를 개선하며 확장성을 높이고
       • 테스트를 가능하게 하고, 쉽게 유지보수할 수 있게 하는 것을 포함
       • 캠핑 장소를 처음 발견했을 때보다 더 깨끗하게 남겨두라 - 로버트 마틴
     • 개별젹으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을
       • 멘토링과 공유
     • 고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를
       • 고용자*피고용자 형태의 관계를 믿지 않는다.
       • 파트너쉽과 프로페셔널한 행동을 계약관계보다 상위에 둔다.
       • 장인을 공장 노동자가 아니다. 적극적으로 프로젝트의 성공에 기여해야 한다.
       • 요구사항에 질문하고 , 비즈니스를 이해하고 , 개선사항을 제안하면, 고객 또는 고용주와 생산적인 동반자 관계를 맺어야 한다.

4. 소프트웨어 장인의 태도
   • 오래 전에 작성했던 코드를 지금에 와서도 고칠 부분이 없어 보인다면 , 그것은 그동안 배운 것이 없다는 뜻
   • 독서, 낳은 독서, 블로그 , 기술 웹사이트, 트위터 사용법
   • 카타 
     • codingkata.org
     • codekata.pragprog.com
     • kate.softwarecraftsmanship.org
   • 펫 프로젝트 - 최고의 자가 학습, 자가 훈련 방법 
     • 펫 프로젝트는 비즈니스 프로젝트가 아니다.
     • 비즈니스을 원한다면, 코드를 작성하고 새로운 기술들은 배운는 것은 최우선 순위가 될 수 없다. 애신 코드를 한 줄이라도 작성하기 전에 먼저 린 스타트업 개념에 대한 자료를 찾아보고 익숙해지를 권한다.
     • 팻 프로젝트를 비스니스화 하고 싶다면 비즈니스 자체에 집중하고, 작성된 코드들을 시작이 원하는 방향이 아니라면 얼마든지 버릴 준비가 되어 있어야한다. 즉 코드에 대한 애착을 버리고 비즈니스 요구에 맞는 최소한의 것만 남기고 깨끗이 정리할 수 있어야 한다.
   • 오픈 소스, 페어 프로그래밍
   • 다른 개발자들과 어울리기
   • 나는 아테네에서 가장 똑쪽한 사람임에 틀림없다. 왜냐하면 나는 내가 아무것도 모른다는 사실을 알기 때문이다. - 소크라테스. 
   • 
     
5. 영웅, 선의 그리고 프로페셔널리즘
   • 우리는 프로페셔널하지 못했다. 우리가 왜 그 일을 하는지 스스로 묻지 않았다. 고객이 실제로 무엇을 원하는지 이해하려 하지 않았고 다른 대안을 제시하지도 않았다.
   • 빡빡한 일정을 다루는 가장좋은 밥업은 필요한 모든 것을 분석하여 가능한 위험과 우려사항을 터놓고 관계자들과 소통하는 것이다. 
   • 항상 '아니오'라고만 얘기하는 것은 프로다운 태도가 아니다. 모든 '아니오'에는 반드시 하나 이상의 대안들이 따라와야 한다. 
   • 백로그(해야 할 일 목록) 또한 전체 팀에 공유되고 있었다. 일의 진척도와 해야 할 일을 시작적으로 보여 줌으로써 비즈니스 팀이 우리가 처한 상황을 정확하게 이해할 수 있게 .
   • 
     
6. 동작하는 소프트웨어
   • 동작하는 소프트웨어만으로는 부족하다 / 고품질의 동작하는 소프트웨어 옮겨감
   • 프로그래밍은 집을 짓는다기보다는 정원을 돌보는 것에 가깝다. - 실용중의 프로그래머
   • 자신이 만든 소프트웨에어 인질이 되는 상황 => 기존 코드에 손을 대는 것을 두려워한다면 지체 없이 대응 
   • 장인을 전체 애플리케이션을 몇 분만에 테스트할 수 있는 자동화 테스트를 구축하고 활용할 줄 안다.
   • 왜 단위 테스트 코드를 애당초 작성하지 않고 반복해서 디버깅하고 있는 건지??
   • 자동화된 테스트를 만들고 활용하는 데 능숙한 개발자라면 코드 디버깅을 해야 하는 상황이 매우 드물다. 
   • 태도는 큰 차이를 가져올 수 있는 작은 요소다. - 윈스턴 처칠
   • 무언가 마음에 들지 않는다면 바꾸어라. 그것을 바꿀 수 없다면, 그에 대한 당신의 생각을 바꾸어라 - 마리 엥겔브레이트
   • 요약 - 회사와 개발자들은 정기적으로 도끼날을 가는 시간이 낭비가 아니라는 사실을 이해해야 한다. 바로 그것이 시간을 절약하고 끊임없이 빨리 움직일 수 있는 최선의 방법이다. 
   • 
     
7. 기술적 실행 관례
   • 애자일 방법론은 변화와 싸우는 것이 아니라 변화 자체를 내재화한다. 
   • 테스트 코드를 먼저 작성
     • 아이디어를 생각 해내는 데도 도움 
     • 한 번에 하나에 집중 
     • 모듈 , 클래스 , 함수를 구체적으로 정의하도록 강제하여 점진적으로 진행
     • 코드 작성 완료 후 실제 환경에서 기대한 대로 동작할 것이라고 강하게 확신
     • 
       
   • TDD에 '테스트가 들어있지만 사실 TDD는 설계에 대한 실행 관례다. 
   • 테스트가 코딩 방향을 주도하면 복잡한 코드를 작성하는 것 자체가 어려워진다.
     • 테스트로 규정된 부분만 작성 되기 때문.  오버 엔지니어링을 막는다.
     • 코드가 복잡하고 방대하면 테스트 자체가 어렵기 때문이다.
   • TDD가 주는 비즈니스적 가치
     • TDD에서 주어지는 피드백은 정규적인 설계 리뷰 미팅보다 훨씬 빠르고 객관적
     • 설계 리뷰가 너무 잦으면 무엇이라고 기여하픈 참여자의 욕구로 인해 객관성을 읽고 오버 엔지니어링. 
     • TDD는 코드의 설계, 단순성, 유지보수 용이성에 대해 피드백이 빠르다. 
     • 코드에 대한 살아 움직이는 문서 역활을 한다. 
     • 긍정적인 부가 효과로 회귀 테스트 역할도 한다. 
   • 지속적인 통합 - 피드백 루프를 줄인다. 코드를 올릴 때마다 전체 테스트 슈트가 실행되고 테트스가 실해하면 이메일이 모든 팀에 전달 , '일단 멈추고 버그부터 수정한다.'
   • 리펙토링 - 몇 년동안 바뀐 적이 없는 부분을 리펙토링하는 것은 의미가 없다. 리펙토링은 더 자주 변경되는 부분을 대상으로 시작해야 한다. 
   • 우리는 지속적으로 일하는 더 나은 방법을 찾고 고객을 만족시켜야 한다. 
   • 특정 실행관례가 더 이상 우리에게 가치를 주치 못한다면 그 실행관례를 버려야한다. 우리의 일에 항상 최선의 기술, 도구, 절차, 방법론 그리고 실행관례를 선택할 수 있도록 개방적인 사고 방식을 가져야 한다.
8. 길고 긴 여정
   • 편한다고 익숙한 상태에서 벗어나 나를 발전시키고 배울 수 있는 기회를 지속적으로 찾아야하만 한다. 나의 인생이고 커리어이고, 내가 주인이어야 했다.
   • 원동력 - 동기부여의 원칙 / 돈은 충족되어야 할 기본 조건, 노동자를 움직이는 것은 자율성, 통달, 목적의식.
   • 대규모 조직에서 그 회사를 위해 최선의 것이 무엇인지 집중  <  프로페셔널이 되기 위해 노력하는 대신 주어진 규칙과 질서를 지키는 데 에너지를 는 쏟는다. 사내 정치 게임을 위해서 스스로의 가치는 제처둔다. 자신의 승진에 영향력이 있는 사람들과 다툼를 피하기 위해 정직한 의견을 말하지 않고 회사에 해가 되더라도 승진에 도움이 되는 일이라면 기꺼이 한다.  => 이런 태도로 일하지 말자.
   • 
     
9. 인재 채용
   • 항상 배우기를 우너하고 더 나은 일하는 방법을 찾는 사람은 자신보다 훌륭한 사람과 함께 일하기를 원하고 최소한 자신과 비슷한 역량의 사람이라도 채용되기를 희망한다. 
   • 열정은 기술적인 역량이나 프로그래밍 언어에 대한 이해보다도 더 중요한 조건이었다. 나는 항상 새로운 것을 시도하고, 배우고, 지식을 공유하고 , 커뮤니티 확동에 적극적인 사람을 원했다.
     • Github account
     • blog
     • open source activity
     • technical community activity
     • pet project
     • Twitter 
     • favorite technical books
     • conference to be joined or do presentation
     • 
       
10. 소프트웨어 장인 면접하기
    • 면접을 볼 때, 일자리를 구걸하는 입장이 아니라는 것을 기억해야한다. 
    • 항상 질문을 많이 하는 지원자를 우선시하는 것이 좋다.
    • 면접관의 질문들은 대개 면접관이 중요하게 생각하는 것들을 반영한다.
    • 어떤 도구를 선호하느지? 프로젝트를 금장 시작할 수 있는지? 테스팅/목업 프레임워크를 이미 모두가지고 사용하고 설정? 업무시간 외에도 코딩을 하는 개발자. 
    • 좋은 개발자는 나쁜 개발자를 채용하지 않는다. 
11. 잘못된 면접 방식
    • 금전적 보상 수준보다도 자율성, 배움, 목적, 생산적 파트너쉽, 열정적인 사람들, 좋은 업무 환경과 같은 것을 우선
    • 
      
12. 낮은 사기의 대가
    • 장인은 다른 사람에게 무엇을 하라고 명령하는 대신 다른 개발자들과 함께 앉아
    • 페어 프로그래밍을 하면서 그들의 지식과 경험 열정을 나눈다.
    • 다른 개발자들의 멘토로서 행동하는데 주의를 기울인다.
    • 항상 소프트웨어 대해서 이야기하고 자신의 자기 계발 황동을 다른 사람들과 공유하려한다.
13. 배움의 문화
14. 기술적 변화의 실행
15. 실용주의 장인정신
    • 리펙토링 - 새로운 기능을 추가할 때마다 코드를 분석하고 필요한 경우 리펙토링을 하여 레거시 코드가 새로운 기능을 자연스럽게 반아들일 수 있도록 해야한다.
    • 잘 작성된 코드는 단순하고, 작고, 테스트 가능하며 이해하기 쉽다. 가장 중요한 부분으로 코드가 해야 할 일을 한다. 
    • 코드는 더 적게 작성할수록 좋다.
    • 단순한 설계
      • 모든 테스트의 통과
      • 중복의 최소화
      • 명료성의 최대화
      • 구성요소의 최소화
    • TDD에 능숙한 개발자는 개발 초기부터 디자인 패턴을 적용하는 일이 극히 드물다.
    • 패턴이 먼저가 아니다. 문제에 적합한 리펙토링을 단순한 설계와 SOLID원칙을 따라서 먼저 시도해야 한다. 
16. 소프트웨어 장신으로서의 커리어
    • 열정, 이 단어 하나가 모든 것을 요약한다. 
    • 장인은 소프트웨어 개발과 자신의 직무에 열정적이다. 
17. 소프트웨어 장신정신에 대한 오해와 설명

소스 코드 정리를 파일을 저장시에 자동으로 해주는 Extension.

1. Extension에 가서 설치 후 재시작 

2. Option에 가서 2가지 항목 체크

3. 저장 전에 포맷이 맞지 않고 불필요한 lib가 using 되어 있음

4. 저장 후에 자동으로 정리가 됨. :)

출처 : https://www.youtube.com/watch?v=JhxC-K-Eehg

지금 개발 중인 프로그램과 관련해서 도움이 될만한 글이 있어 실습해보았다.

- UI로 부터 독립적인 클래스라이브러리(Viewmodel) 개발 

- UI없이 독립적으로 UnitTest가 가능 

Sourecode 

https://github.com/paranpiano/CrossPlattformLib.git

MVVM Pattern으로 개발을 다시 하기 전에 개념을 정리하고 싶었다. :)

Winform , Behind code 

- View로 요청을 받음

- View의 control을 Behind code에서 바로 binding    

- Model을 사용해서 business logic을 처리하더라도 View와 강하게 결합 

Model - View(n) - Controller(1) 

- Contoller로 요청을 받음 

- Contoleer는 Model에게 Bisiness logic 처리 요청

- view는 모델을 참조하여 업데이트 함, 

- View와 model과 의존성이 없앨수 없다.

- Model과 view의 의존성을 낮게하는 패턴을 사용하면 좋은 MVC가 된다

Model - view(1) - Presenter(1)

- View로 요청을 받음

- Presenter는 Model에게 Bisiness logic 처리 요청

- 그 결과는 View에게 알려준다. 

- Model와 View과 완벽하게 분리

- View와 Presenter의 의존성이 강하다.(1:1결합)

Model - view(N) - Viewmodel(1)

- View로 요청을 받음

- Command : View의 Behavior를 Command로 View model에게 요청

- View Model은 Model에게 Bisness log을 요청 

- Data binding : View Model의 속성 값이 변경되면 binding된 View control에게 notify가 가면서 자동 업데이트

- Model은 View로 부터 완벽히 분리

- MVP와 달리 Viewmodel은 여러 View에서 재사용이 가능하다.

끊임없이 변하는 세상에서 가장 중요한 기술은 안목이다.

누구에게나 옳은 말은 아닐 것이다. 하지만 새로운 것을 알아보는 능력, 다른 이의 작업을 알아보는 능력 또는 어떤 일을 할 수 있는 여러 방법을 비교하고 당신, 팀, 프로젝트, 조직에 가장 적합한 것을 고를 수 있는 능력은 어마어마하게 소중하다. 내가 아는 이 대부분은 이에 능하지 못했고, 내가 아는 대부분의 리더는 이 부분에선 정말 엉망이었다.

누군가 당신에게 이걸 해야 한다고 말하는 일이나 블로그에서 읽은 것 또는 모두가 하는 걸 그대로 해내는 건 쉽다. 목적과 모든 면을 고려하여 살펴보고 자신에게 가장 잘 맞는 최적의 선택을 하는 게 훨씬 어렵다. 누구나 선택을 해야 하지만, 어떤 이들은 평가 자체를 두려워하여 아무거나 골라버리거나 남들이 하는 대로 따라가는 일도 흔하다.

목적을 달성하는 방법엔 여러 가지가 있지만, 고객 입장에선 뭐든 상관없다.

고객은 개발자가 겪는 문제가 뭔지 관심 없다. 그저 결과물인 소프트웨어가 자신이 원하는 작업을 해결해주길 바랄 뿐이다.

시스템에 문제가 생기고 예외가 발생하든 개발 장비에 문제가 생겼든 다른 개발자가 진상이거나 해커가 침입했든, 사용자에게는 별로 중요한 문제가 아니다. 문제가 생겼을 때 정직해지는 건 좋다. 그게 가끔이라면 말이다. 하지만 고객이 보기 전에 문제가 오래가지 않도록 해두는 편이 더 좋다.

목적을 달성하는 방법엔 여러 가지가 있지만, 고객 입장에선 뭐든 상관없다.

고객은 개발자가 겪는 문제가 뭔지 관심 없다. 그저 결과물인 소프트웨어가 자신이 원하는 작업을 해결해주길 바랄 뿐이다.

시스템에 문제가 생기고 예외가 발생하든 개발 장비에 문제가 생겼든 다른 개발자가 진상이거나 해커가 침입했든, 사용자에게는 별로 중요한 문제가 아니다. 문제가 생겼을 때 정직해지는 건 좋다. 그게 가끔이라면 말이다. 하지만 고객이 보기 전에 문제가 오래가지 않도록 해두는 편이 더 좋다.

로그를 남기지 않아 몰랐던 것이 큰 문제가 될 수 있다.

오늘날에도 소프트웨어가 어떻게 동작하는지 알기 위해 로그나 크래시 리포트, 사용 정보를 충분히 수집하지 않는 걸 보면서 놀라곤 한다. 이러한 정보를 수집하지 않는 사람들은 품질을 과신한다.

측정하고 기록하지 않으면 고객은 당연히 알게 될 문제를 개발자는 알 수 없다. 어떤 문제든 발생하는 즉시 알 수 있도록 나는 늘 세밀하고 유용한 로그, 크래시 추적, 리뷰와 코멘트 등 수집할 수 있는 건 모조리 해야 한다고 주장해왔다. 물론 아직도 이런 것들이 개발자가 되는데 전혀 필요 없다고 생각하는 사람들도 있지만 말이다.

신입 프론트엔드 개발자를 위한 면접 조언

포트폴리오

·         가능하면 GitHub이나 BitBucket 같은 Git 호스팅 서비스에 올려두자. 요즘은 SVN이든 Git이든 VCS를 사용하지 않는 업체를 찾기 어려울 정도다. 혹시 VCS를 전혀 사용하지 않는 개발 업체가 있다면 입사를 다시 한번 고민해보라고 진지하게 말하고 싶다. 입사 지원자에게 GitHub 계정 링크를 알려달라는 곳이 해외는 물론 국내에도 꽤 있다. 가능하면 포트폴리오를 앞서 말한 두 서비스 중 하나를 택해서 올려두는 게 좋다. 개인적으로는 GitHub을 추천하는데, 사용자가 더 많아서 문제가 생겼을 때 도움을 구하기 쉽기 때문이다.

·         .gitignore 파일에 .idea 폴더나 npm-debug.log 같은 불필요한 파일은 포함되지 않게 설정해두자. 코딩 능력과 상관없는 거지만 기본적인 사용법을 모르는 것처럼 보일 수 있다.

·         커밋 메시지는 의외로 많은 것을 말해준다. 신경 써서 좋은 커밋 메시지를 작성하는 게 좋다.

·         혹여 포트폴리오 소개서를 쓴다면 사용한 기술은 나열은 하되 강조하지는 않는 걸 추천한다. 신입에게는 대단한 기술 스택일지 몰라도 (아마) 면접관들에게는 그리 대단하지 않을 공산이 큰데, 그런 걸 강조하면 오히려 더 없어 보이기 때문. 반면 만에 하나라도 면접관의 관심을 끌 만한 기술이라면 굳이 강조하지 않아도 눈에 띌 것이다.

·         개인 프로젝트라 하더라도 테스트 케이스는 성의껏 작성해두자. 코딩 전에 하든 후에 하든, 어쨌든 작성해 두는 게 좋은 인상을 줄 수 있다.

TABLE 14-1. Characteristics of less testable code, and how this leads to problems with design

TABLE 14-2. Characteristics of more testable code, and how this leads to good design

좋은 글이 있어 아래 블로그에서 퍼왔습니다. 문제시 삭제하겠습니다. 

http://rapapa.net/?p=2406