며칠 전에 금도금 장미 카타에 대해 알게 됐어요. 아주 희망적인 소개가 있어요. 응, 나한테 희망이 있어요. 몇 년 전에 산디 메츠의 흥미를 끌었어요.
나는 산디 메츠를 사랑한다.나는 단지 그녀를 사랑할 뿐이다.인코딩에 있어서 그녀는 가장 똑똑한 사람 중의 하나이다. 특히 OO가 어떤 모습이어야 하는지를 처리할 때이다.그녀의 책과 강연은 항상 매우 훌륭했다. 나는 단지 언젠가 내가 그녀처럼 프로그래밍을 볼 수 있기를 바랄 뿐이다.
이것은 단지 이것은 흥미로운 문제라는 것을 의미할 뿐이다. 나는 내가 우아한 방식으로 그것을 해결할 수 있는지 알고 싶다.아니면 더 좋고, 어느 정도는 산디가 지지할 것이다.(스포일러: 어떤 사람이 나에게 우리의 해결 방안, 심지어 우리의 사유 과정이 매우 비슷하다는 것을 알려주었다. 이것은 큰 영광이다. 그럼에도 불구하고 나는 그녀의 책을 자주 읽는데 장점이 없다. 원숭이가 봤어, 원숭이가 봤어.)
완전히 성숙한 개발자로서 저는 Le Wagon아기를 가르치고 있습니다. 이것은 루비온 rails를 바탕으로 하는 고품질 제품 훈련 캠프입니다. 저는 개념을 이해해야 의미가 없고 사고 과정이 가치가 있다는 것을 배웠습니다.나는 학생들에게 코드 라이브러리를 어떻게 테스트하는지 가르쳐 줄 수 있다. 나는 학생들이 이해할 수 있는 좋은 테스트를 보여줄 수 있다. 만약에 그들이 우리가 왜 테스트를 하는지, 그리고 우리가 어떤 테스트를 어떻게 작성하는지, 그리고 언제 작성하는지 이해하지 못한다면 많은 수확이 없을 것이다. 사람들은 이론적으로 테스트 세트를 만드는 방법을 알게 될 것이다. 그러나 현실 생활에서는 이 점을 할 수 없다.
이것은 나로 하여금 한 걸음 한 걸음 내가 이 문제를 어떻게 해결했는지 설명하게 했다.나는 똑똑한 사람이 아니다. 나는 많은 사람들이 더 좋은 해결 방안이 있거나, 더 간단한 해결 방안이 있거나, 수중의 문제를 해결할 수 있는 다른 방법이 있다고 믿는다. 그러나 나는 다른 사람의 생각을 살펴볼 때, 어떤 것들을 얻고, 그 중에서 깨우침을 얻을 수 있다고 생각한다.아마도 내 학생 이외에 다른 사람들도 내가 한 일에 대해 흥미를 느낄 것이다.

카타

직접 시도하고 싶으면 그것을 찾을 수 있다here.
앨리슨은 폭풍성'금도금 장미 여인숙'의 자랑스러운 소유자로 거래하고 싶은 모험가들을 많이 만났다.
많은 제품들이 조사를 필요로 하기 때문에 그녀는 지난 몇 달 동안 소프트웨어를 사용하여 그녀의 상품을 추적하여 큰 성공을 거두었다.

아이템당 하루 노화

한 물품은 매일 1개의 품질을 손실한다(단 0보다 낮으면 안 된다)

모든 물품은 사용 날짜가 있고, 이후에 더 빨리 변질될 수 있음

물론 이것은 매우 기본적인 규칙이며 예외도 있다.너는 읽을 수 있다 the full criteria list. 그러나 이것은 치즈와 같은 제품이 분명히 매일 품질을 향상시키거나, 음악회 입장권의 수요가 음악회가 끝날 때까지 점점 높아지고, 그것들의 품질은 존재하지 않는다는 것을 의미한다.
우리의 목표는 마법 아이템과 그들의 새로운 특수 규칙을 추가하는 것이다.봐라, 그것들은 희박한 공기 중의 마법으로 만들어진 것이다. 그것들은 더욱 빨리 파괴된다.

비밀 번호

코드는 다음과 같이 40대의 무서운 조건 코드입니다.

class GildedRose

  def initialize(items)
    @items = items
  end

  def update_quality()
    @items.each do |item|
      if item.name != "Aged Brie" and item.name != "Backstage passes to a TAFKAL80ETC concert"
        if item.quality > 0
          if item.name != "Sulfuras, Hand of Ragnaros"
            item.quality = item.quality - 1
          end
        end
      else
        if item.quality < 50
          item.quality = item.quality + 1
          if item.name == "Backstage passes to a TAFKAL80ETC concert"
            if item.sell_in < 11
              if item.quality < 50
                item.quality = item.quality + 1
              end
            end
            if item.sell_in < 6
              if item.quality < 50
                item.quality = item.quality + 1
              end
            end
          end
        end
      end
      if item.name != "Sulfuras, Hand of Ragnaros"
        item.sell_in = item.sell_in - 1
      end
      if item.sell_in < 0
        if item.name != "Aged Brie"
          if item.name != "Backstage passes to a TAFKAL80ETC concert"
            if item.quality > 0
              if item.name != "Sulfuras, Hand of Ragnaros"
                item.quality = item.quality - 1
              end
            end
          else
            item.quality = item.quality - item.quality
          end
        else
          if item.quality < 50
            item.quality = item.quality + 1
          end
        end
      end
    end
  end
end

class Item
  attr_accessor :name, :sell_in, :quality

  def initialize(name, sell_in, quality)
    @name = name
    @sell_in = sell_in
    @quality = quality
  end

  def to_s()
    "#{@name}, #{@sell_in}, #{@quality}"
  end
end

나는 조건문이 싫다는 것을 인정해야 한다.나는 보호 조항에서 그것들을 사용한다. 만약 내가 사용할 수 없다면, 나는 그것을 사용할 것이다. if. 그러나 내가 볼 때마다 else 나는 그것의 얼굴을 때리고 싶다.나는 내가 할 수 있는 대로 그것을 벗어날 것이다.나는 그들이 싫다.그들은 매우 어리석어 보인다.
...그래서 너는 내가 이 코드 앞에서 느낀 것을 상상할 수 있다.화장실 문을 열고 위가 불편한 요괴를 마주하는 것과 같다.
하지만...그것이 작용했다.그것은 단지 마땅히 해야 할 일을 할 뿐이다.나는 그것을 바꿀 필요가 없다. 심지어는 그것을 볼 필요도 없다. 나는 단지 봉인if을 추가해서 나의 달콤한 마법 아이템else에 싫은 것을 검사하면 일을 할 수 있다.하지만 문제는 더 나빠질 수 있다.나는 내가 더 많이 하도록 촉구받았다고 생각한다. 솔직히 말하자면...더 하고 싶어요.나는 면전에서 그 조건들을 비난하고 싶다.
나는 반드시 이 방법을 재구성해야 한다.상업적인 측면에서 볼 때, 이것은 일리가 있다. 만약 우리가 더 많은 새로운 프로젝트를 추가할 것을 요구한다면, 우리는 끊임없이 조건을 누적할 수 없다.나는 곧 나의 마법 아이템을 혼란 속으로 통합시킬 수 있는지 확인했지만, 나는 그것의 범위를 이해할 수 없었다.
그래서 나는 스카이다이빙을 했다.어쩌면 이것은 방식일지도 모른다. 어쩌면 어떤 패턴이 보일지도 모르지만, 나의 작은 머리는 그것을 파악할 수 없다.방법이 있다면 내 방법에 결함이 있다고 생각한다면 주저하지 마세요.
그렇다고 내가 무사에게 졌다는 건 아니야!아, 아니야. 만약 내가 패턴을 이해할 수 없다면, 나는 그것을 내가 이해할 수 있는 패턴으로 바꿀 거야.하지만 우선 아무것도 깨뜨리지 않을 것을 확신해야 한다.

아무것도 깨뜨리지 마세요.

사람들의 뜻은 왕왕 '그것은 여전히 같은 결과를 되돌려야 한다' 는 것이다.물론'아무것도 파괴하지 않는다'는 데 큰 역할을 했지만 현실에서는 규칙의 범위가 더 넓다.
나는 내가 작성하고 있는 코드에 무엇이 서로 관련되어 있는지 모른다. 그래서 나는 내가 적절하다고 생각하는 모든 것을 마음대로 바꿀 수 없다.나는 인터페이스의 원형을 유지해야 한다. 내가 그것이 관련이 있다고 생각하든지 말든지.필요하면 나중에 수정을 제기할 때가 됐지만, 코드 내부든 외부든 파괴된 것이 없다는 것을 확신해야 한다.

첫 번째 설계 결정: 범위

나는 Item레벨을 바꾸지 않을 것이다.

(GildedRose류는 이러한 Item 대상의 그룹을 계속 받아들여야 하고 #update_quality 메시지에 응답해야 한다.

다른 모든 것을 나는 자유롭게 바꿀 수 있다.문제는 자유가 우리의 격렬한 변혁을 막는 요소가 아니라는 것이다.두려움은일단 재구성이 일어날까 봐 우리는 예상한 결과를 왜곡했다.

시험이 오다

초보자들은 왜 TDD를 사용하느냐, 심지어는 효과가 있느냐고 자주 물어본다.그 중 하나는 재구성을 허용하기 때문에 망칠 염려가 없다는 것이다.그래, 그러니까 네가 테스트를 망치지 않았다면.
기존 코드를 재구성할 때, 코드 라이브러리를 광범위하게 변경해야 한다고 생각하면 더욱 중요하다.내가 테스트로 모든 용례를 덮어썼다는 것을 확인하기 전에, 나는 어떤 줄도 바꾸지 않을 것이다.나는 처음의 잘못이 아니라 복귀가 더 걱정된다.
다행히도, 이 카타는 간단한 스크립트를 제공하여 며칠 동안의 프로젝트의 변화를 보여 주었다.

코드를 수정하기 전에 이 스크립트를 실행하고 결과를 저장한 다음 코드를 변경한 후의 모든 실행과 비교하기만 하면 됩니다.
나는 내가 필요로 하는 것이 있다. 진실의 근원이다.

describe GildedRose do
  before(:all) { `ruby spec/texttest_fixture.rb 100 > test.txt` }
  after(:all)  { `rm test.txt` }

  describe "#update_quality" do
    it "has no regression" do
      expected = "spec/100_updates_expected_results.txt"
      actual = "test.txt"

      expect(IO.read(actual)).to eq IO.read(expected)
    end
  end
end

그럼에도 불구하고, 그것은 내가 읽을 수 있는 오류 메시지로 하나하나 해결할 수 있는 좋은 단원 테스트처럼 편리하지 않기 때문에, 나는 어떻게든 테스트를 만들어야 한다. 이것은 사실의 근원이다. (나는 100일을 마음대로 선택했다. 왜냐하면 왜 그렇지 않기 때문이다.)여기서 다른 테스트만 확인할 거예요.
나는 매우 긴 테스트 파일로 끝났는데, 그 중에는 많은 사례가 있다.

Allison

이 제공한 서면 규칙에 근거하여 추정한 일부

어떤 것은 서로 다른 시도를 통해 제공된 것이고 이런 시도는 진리의 원천이다

그것들은 아름다운 테스트가 아니다. 어떤 의미에서 보면 중복되고 쓸모없는 테스트가 있을 것이다.나는 더욱 심사숙고한 방법을 취해 내 코드가 TDD인지 아닌지를 테스트할 것이다. 그러나 내가 남겨진 얽힌 코드를 처리할 때, 나는 차라리 안전할지언정 후회하지 않을 것이다.
이 글들에서 유일하게 기억해야 할 것은 내가 무언가를 깨뜨리면 테스트가 그것을 잡을 것이다.
이제 우리는 어디서부터 이 혼란을 해결할 수 있는지 찾아볼 수 있다...두 번째 문장에서는 당신의 눈과 주의력을 잘 대하기 위해서입니다.
안녕히 계세요.