Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ある一定のルールで運行している電車の時刻表を算出する機能 #5

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

h5y1m141
Copy link

@h5y1m141 h5y1m141 commented Jan 10, 2018

このPRについて

こちらの仕様の処理を実装しました

実行結果

cd user/h5y1m141
ruby ./main.rb

上記実行結果は以下のように表示されます

各駅停車の時刻表
["11:10", "11:14", "11:18", "11:23", "11:27", "11:31", "11:35", "11:39", "11:43", "11:47", "11:51", "11:55", "11:59", "12:03", "12:07", "12:11", "12:15", "12:19", "12:23", "12:27", "12:31", "12:34"]
急行の時刻表
["11:15", "11:18", "11:20", "11:22", "11:24", "11:26", "11:28", "11:30", "11:33", "11:35", "11:37", "11:39", "11:42", "11:44", "11:46", "11:48", "11:51", "11:54", "11:57", "12:00", "12:03", "12:05"]

テストについて

MiniTestは使ったことがないのでこんな書き方で良いのかどうか悩みながらも一応

  • 各駅停車
  • 急行停車

の時刻表算出時のベースになりそうなメソッドに対して網羅しました。

参考

コード読む上で参考情報を記載しておきます

それぞれのクラスの役割

各駅停車の処理を例にシーケンス図まとめました。

timetable

実装上の工夫点

仕様理解が難しい(特に各駅停車が急行通過待ちをするあたり)というのが最初の印象だったので、

  def detect_stations_for_waiting_express
    # 後続の急行がある場合
    if [10, 30, 50].include?(@current.min)
      ['SS3']
    else
      ['SS9']
    end
  end

の所でそこをうまく吸収できるようにあらかじめ実装してみました

station_ss3 = stations.select {|target| target[:id] == 'SS3' }.first
station_ss21 = stations.select {|target| target[:id] == 'SS21' }.first
assert_equal('SS1', station_ss1[:id])
assert_equal(true, station_ss3.nil?)
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RSpecのcontext っぽい感じで Minitestでの正常系・異常系のかき分けがイマイチわからなかったのですが

class ExpressTrainTest < MiniTest::Unit::TestCase
  def setup
  end
  test '急行停車する駅を抽出する場合' do
    def test_stop_stations
      # 省略
    end
  end

  test '急行通過する駅を抽出する場合' do
    def test_stop_stations
      # 省略
    end
  end
end

みたいに書くのが良いのですかね?

@chooyan-eng
Copy link
Owner

プルリクありがとうございます!見てみます。

僕以外の方からの意見も集まるよう、現在このリポジトリを宣伝中ですので、気長にお待ちいただければと思います。

@h5y1m141
Copy link
Author

現在このリポジトリを宣伝中ですので、気長にお待ちいただければと思います。

全然大丈夫ですよ~

私も身の回りで、ちょっとづつこのリポジトリ宣伝してるので、ちょっとづつ興味ある人が増えていけば良いですね 😄

def initialize(args)
@base_times = args[:base_times]
@start_time = args[:start_time]
end

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

この args には Hash を渡しているようなので、キーワード引数でいいんじゃないかなと思いました。

def initialize(base_times:, start_time:)

11行目で @start_time をパースしているようなので、 start_time は文字列でしょうか。 start_time という変数名から Time クラスのインスタンスが渡ってきそうな気がしました。 参考

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

start_time は文字列でしょうか

BaseStartTime の単体テストがあればこの辺の仕様が明確になりそうです

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

あ、確かに今みたら、BaseStartTime の単体テスト存在して無かったですね 😓
だから、この処理について期待される振る舞いがどうしても他の人には伝わりづらくなってましたね・・

仕事だったら、「早速修正します!」という流れになりそうですが、ちょっと今、色々あって余裕ないのでそっちの対応は保留します

hour = Time.parse(@start_time).hour
hour = target.empty? ? hour + 1 : hour
Time.new(2018, 1, 1, hour, minute)
end

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

また名前の話になってしまうのですが、 prepare だと何をしてくれるメソッドなのか分からなかったです。戻り値は Time クラスのインスタンスのようなので、何かの時刻を取得するためのメソッドでしょうか。

format_datetime(target)
end
result
end
Copy link

@ttanimichi ttanimichi Mar 1, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

この result という変数は他で特に使っていないようなので、

   def timetable_list
     timetable.prepare(station_list).map do |r|
       target = r[:station][:id] == 'SS21' ? r[:arrive_at] : r[:start_at]
       format_datetime(target)
     end
   end

で良さそうです


def stop_stations
express_stop_names
end

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

これ処理を別のメソッドに抽出する必要ありますかね。もし別名を付けたいだけなのであれば alias_method とかで良いんじゃないかなと思いました

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ここの意図は電車は

  • 各駅停車が停車される駅
  • 急行電車が停車される駅

によって異なるために、

express_train =  ExpressTrain.new
express_train.stop_stations
# => 急行停車駅の一覧が返ってくる

local_train =  LocalTrain.new
local_train.stop_stations
# => 各駅停車駅の一覧が返ってくる

という形にしたかったのが理由としてあります


def start_time_minute
super
end

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

28-30行目不要そうです。書かなくても親クラスの start_time_minute が呼ばれます

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

なるほど~


def start_time_minute
super
end

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

同上

@ttanimichi
Copy link

cc: @chooyan-eng

試しにレビューしてみましたけど、いまいちピンと来なかったです。
これがもし職場の OJT だったらデータモデリングから見直して
解答例というか見本となるようなコードを示したりするんですけど
そこまでするのも正直しんどいよなぁという感じです。

例えば「このメソッド名はこういう理由で良くないですよ」ってコメントしても、
その背景となる DSL の考え方だったりとか、
責務についての考え方なりの諸々の解説をしないと結局伝わらないと思うんですけど
GitHub のコードレビューでそこまでするのもしんどいですしねえ

@h5y1m141
Copy link
Author

h5y1m141 commented Mar 1, 2018

@ttanimichi
レビューありがとうございます!

試しにレビューしてみましたけど、いまいちピンと来なかったです。

について、お伺いしたいのですが、ピンと来ない理由として

  1. このリポジトリにおいて、レビューする時にどのスタンスで取り組むべきかピンと来ない
  2. このPRの実装&設計意図がよくわからない点が多くピンと来ない
  3. 上記の1.と2.の両方の意味
  4. その他

のどれになりそうなのでしょうか?

PR出してから、2ヶ月ほど何もフィードバックなかったので、レビュアーとして関わろうとした時にどういうスタンスで望めばよいのか各自考え方異なりそうで結果

責務についての考え方なりの諸々の解説をしないと結局伝わらないと思うんですけど
GitHub のコードレビューでそこまでするのもしんどいですしねえ

というのが出てきて、結局コードレビューするのがツラいから今までの状況につながるのかなとふと感じたので。

@ttanimichi
Copy link

ttanimichi commented Mar 2, 2018

ピンと来ない理由

1 に近いですかね。どこまで深くレビューすべきなのかなっていうのがふわっとしてて。あまり表面的なレビューだけしても価値が薄いでしょうし

結局コードレビューするのがツラいから今までの状況につながるのかな

FizzBuzz の PR をしてる人が多いですが、FizzBuzz のコードなんかを見ても「ふーん」とか「へえ」くらいの感想しか出てこなくてレビューできる気がしなかったので、この PR のレビューをすることにしました。

@chooyan-eng
Copy link
Owner

@ttanimichi @hoyamada
どのレベルでレビューするかがふわっとしている点、詳しくじっくりレビューするほど労力かけられない、且つGitHub上のやりとりでは限界がある点、、課題ですね。。。ご意見ありがとうございます!

このプルリク上でやりとりが続くとコードに対するコメントと混ざってしまうため、issue #10 を作りました。もしよろしければこちらで議論させていただければと思います。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants