リファクタリング特集よかった。「将来を予測してコードを書いていても上手くいかないから現在の仕様を反映したコードにしよう」みたいなことが序盤に書いてあって心当たりがあって「ウッ」となった。あと7つの凝集度と7つの結合度の紹介と具体的にどういう風にリファクタすると良いか（もしくはしなくてよいか）というのがGoのコードサンプルで説明されていてわかりやすかった。終盤Reactコンポーネントでも論理的凝集を意識したコンポーネントの切り方みたいな話があって、「確かにそこでも使えるのだな」とちょっと新鮮な気持ちになった。コンポーネント内で無理やり分岐で表現しなくて別々の機能を持ったコンポーネントなら別コンポーネントにすればいいだろうとは思っていたものの、これが論理的凝集であるというのは意識していなかった。
「入社した会社にすばやく適応する」特集も興味深くて良かった。以下の記事に大幅加筆したものだそう。
blog.h13i32maru.jp
情報のインプット方法（この会社・チームではどのようにして情報をまとめてるのか）とか、知り方を知るとか、たしかにそういうのは最初のうちはとても大事だなと共感した。
一方で分報で色々と仕事のことを聞くのは、今の弊チームだとそうじゃなくてチームのScrapboxで自分のページを作ってそこにどんどん書いていく方式になるんだろうな（というかそうしている人が多い）と思った。なぜこっちのほうが良さそうと現時点で思ってるのかというと、#times-nantoka みたいなチャンネルは個人にしか紐づいていなくてチームメンバーが入っているとは限らないが、Team Hoge Scrapboxはチームの持ち物なのでみんながいつでも見ることができて情報の凝集度が高い、みたいなイメージ。新参者がScrapboxに困ったことやハマったことを書いていけば、次にまた新参者が入ってきたらその前の人のScrapboxページを見たら同じところではまらずに済んで便利というようなことがあるかもしれないが、分報チャンネルだとSlack全体検索をしないとたどり着けなくて不便そう、みたいな。
事業構造を理解するために、自分の理解を図示する、というのはなるほど良さそうと思った。自分は新卒入社してずっと同じ会社なので事業構造について最近あまり1から学び直しとかはないが、チーム異動とかするときに一旦図に描いてみてこれであってますか？とやるのはいかにも良さそう。
他にもいくつか話題が書いてあったけど、全体的にあると便利なのは知ってるけど言語化されていてありがたいという感じだった、次新メンバーのオンボーディング担当することがあったらこのあたりの話題を意識してサポートしたい。
