常連

最近部署異動して2週間くらい経ち、プロジェクトのキャッチアップを行ってきたのですが、みなさんは新規参画時のキャッチアップってどうやってますか？

自分は大きく分けると以下を実施したのですが、例えばコード読むときとかどういう読み方をするか、ドメイン知識のキャッチアップはどうやってやってるかなどを聞きたいです。

1. 技術的なキャッチアップ（コミュニケーション、開発フロー、コードリーディング、インフラ構成）
2. 業界、ドメイン知識のキャッチアップ

ITコンサル、SEだと割とプロジェクトを転々とすることあると思うんですけど、自社開発のエンジニアは数年に1回くらいの頻度だと思うので、特に前者の方たちの経験値からTipsなど伺えるとなお嬉しいです

新規参画プロジェクトに入ったらどう過ごすか

実用的で無い内容なのでここで聞いて良いのか悩みましたが，一応クラスの設計の参考になるだろうと思って質問しました。
自分の普段使いがPythonなので，説明用のコードはPython風ですが，どの言語にも共通する問題だと思います。

先ほど友人と，「鶏肉を5つに切る」にはどうすれば良いかという例えばなしをしていました。
これを実装する場合，

* chicken.cut(5)  # chickenは (Foodクラスを継承した) Meatクラスのインスタンス
* chef.cut("chicken", 5)  # chefはChefクラスのインスタンス。あらかじめset_foodなどで{"chicken": chicken}を内部に保持した状態にしておく

の2通りが考えられるのではないかと思います。

鶏肉の状態が変化するという意味では，「chickenが5つに分割された状態になる」前者の方が自然であるように思えます。それに説明が短くて済みます。おまけに「オブジェクト指向 料理」で検索するとこっちの例え話しか出てきません。議論のきっかけになった第三者の意見も，「鶏肉.cut(5)できたらいいのに」というものでした。

しかし一方，cutするのは料理人であることを踏まえると，「chefがchickenを5つにcutする」方が自然です。しかも，

* 食材chickenとeggを混ぜる → chef.mix("chicken", "egg")
* 手持ちの食材を見せる → chef.show_foods()
* 親子丼のレシピを覚える → chef.learn_menu("oyakodon", [needed_foods])
* 食材chickenとeggを消費して料理oyakodonを完成させる → chef.cook("oyakodon")
* 熟練度システムを加える → 「if self.level >= 10」などを加える
* 「knife」が無いとcutできないことにする → 「if self.has_knife」などを加える

と，後々の拡張が容易です。なので，僕はこちらの案に一票を入れました (とはいえ，Chefクラスを一体どれほど大規模なクラスにするつもりなのでしょうか?)

他にも，料理は料理で別クラスにすべきだ，とか，オブジェクト指向が本当に必要なのか，とか，初心者なりに様々な意見が出ました。

これらについて，オブジェクト指向に慣れた方の意見を聞きたいです。
よろしくお願いします。

---

補足: 僕が想定していた設計例はこんな感じです

```Python
class Food(object):
    def __init__(self, size, hardness):
        self.size = size
        self.hardness = hardness


class Chef(object):
    def __init__(self, level):
        self.level = level
        self.has_knife = False
        self.foods_ = {}

    def set_food(self, food, obj, n):
        self.foods_[food] = [obj, n]
        print('%sを手に入れた!' % (food))

    def show_foods(self):
        foods = self.foods_
        return {i: (foods[i][0].size, foods[i][1]) for i in foods.keys()}

    def cut(self, food, n):
        if food not in self.foods_.keys():
            print('食材がありません')
        elif not self.has_knife:
            print('ナイフがないと切れません')
        elif self.level < self.foods_[food][0].hardness:
            print('レベルがたりません')
        else:
            self.foods_[food][0].size *= 1 / n
            self.foods_[food][1] *= n
            print('%sを%d個に切断しました' % (food, n))

meat = Food(size=10, hardness=3)
chef = Chef(level=1)
chef.cut('meat', 5)  # 食材がありません
chef.show_foods()  # {}
chef.set_food('meat', meat, 3)  # 'meatを手に入れた!'
chef.show_foods()  # {'meat': (10, 3)}
chef.cut('meat', 5)  # ナイフがないと切れません
chef.has_knife = True
chef.cut('meat', 5)  # レベルがたりません
chef.level += 10
chef.cut('meat', 5)  # meatを5個に切断しました
chef.show_foods()  # {'meat': (2.0, 15)}
```

皆さん多くの有用な回答をありがとうございました。
当初の質問「foodが切るかchefが切るか」について，food派の回答で最も納得のいく理由を説明してくださったLLmanさんをベストアンサーとさせていただきました。
(全員へ返信する時間がなかったのでLLmanさんへの返信欄に全員宛のお礼を書かせていただきました)

今回知ったことを実際のコーディングにも活かせていければと思っております。

オブジェクト指向で料理を例える場合，chicken.cut()かchef.cut()か

## ✒️テーマ
【teratail12周年！】これからの「**teratailでの抱負**」をお聞かせください！

## ✍️詳細
おかげさまでteratailは、2014年7月16日のスタートから今年で12周年を迎えることができました。
これまで質問や回答を投稿し、teratailに貢献くださったすべての皆さんに、改めて感謝申し上げます。

そこで今回は「これから1年のteratailでの抱負」を募集します📮

例えば、
- 回答者として、こんな関わり方をしていきたい（「この分野は任せろ」「初心者にわかりやすく」「週1で回答する!」など）
- 質問者として、こう質問できるようになりたい
- teratailに「こうなってほしい」という願い
- あるいは単純に、この1年でやってみたいこと　などなど

長い決意表明でも、一言でも歓迎です。
長く使ってくださっている方も、最近登録された方も、ぜひみなさんの投稿をお待ちしています！

## 🎉祝・12周年
この1年でご活躍くださったみなさんを表彰する12周年特設ページも公開しています。
ぜひこちらもご覧ください👇
[https://teratail.com/12th-anniversary](https://teratail.com/12th-anniversary)

【teratail12周年！】これからの「teratailでの抱負」をお聞かせください！

## 🖊️テーマ
「同じような処理は共通化して1つにまとめる」のは開発の基本ですが、共通化しすぎたせいで、後から「一部の画面だけ仕様を変えたい」となったときに共通処理が足かせになり、修正が大惨事になった経験はありませんか？

逆に、共通化を恐れて重複コードだらけにすると、仕様変更の際に全箇所を直して回る不毛な作業が発生します。

まだ経験の浅い若手エンジニアから「似たような処理なので共通化しちゃっていいですか？」と聞かれたとき、皆さんは将来の手戻りを防ぐために、どのタイミングまで「あえて共通化せずに残せ」とアドバイスしていますか？現場独自の「折り合いの付け方」をぜひ教えてください！

## 👤運営メンバーの回答
運営メンバーのFさんは、「まったく同じロジックだとしても、3箇所以上で使われるまでは絶対に共通化させない（2箇所まではコピペを許容する）」というルールを徹底しているとのこと！

2回目の段階では、それが本当に同じ目的の処理なのか、たまたま今同じなだけなのかが見極められないため、早すぎる共通化で身動きが取れなくなるリスクを避けるためにそうしているそうです。

## 〜teratailトーク!とは？〜
詳細を公式ブログで公開しています。ぜひお読みください。
[「teratailトーク!」スタート🎉　気軽に意見交換しよう！](https://blog.teratail.com/entry/teratail-talk)

早すぎる共通化 vs 重複コード、現場での判断基準は？

## テーマ、知りたいこと
自分が新しく入った開発チームなどでわからないことがあった時、「人に聞く」タイミングをどのように決めていますか？

## 背景、状況
私は、最近未経験からソフトウェアエンジニアに転職したばかりのものです。
※初投稿のため、文章に至らない点などあるかもしれませんがご容赦いただけると幸いです。

独学で勉強を進めたり、プログラミングスクールに通ったりして知識をつけ転職しました。
しかしながら、いざチーム開発の実務に携わると、知らなかったことばかりで、新たに学習することばかりです。

特に苦戦するのは、アーキテクチャ、設計などの知識です。

なるべく自分でキャッチアップしたい思いから、まずは web、書籍を漁ったり、AIツール（自分は主に CurorやClaudeなど）を使用して仕様や設計を分析したりしています。
ただ、AIが出した情報は100%正確とは限らないため、AIが出した情報をなるべく自分で解釈・精査した上で人に聞く、というアプローチをとっています。

これまでの経験で、結局人に聞いた方が早く理解できたり、そもそもAIの出した内容が不正確だったりと、「最終的には人に聞く方が良かったな」「初めから人に聞けばよかったな」と思うこともしばしばでした。

AI はなんでも聞ける一方、その対話で答えがわかるんじゃないか？と夢中になり、その**対話に時間をかけすぎてしまう**ことがあるように思います。

そこで、「人に聞く」タイミングをどのように見極めているかについて、IT系の業務に携わる皆さんのご意見をお伺いしたいと思いました。

## 私自身の方針
現状自分は、下記のような方針をとっています。
- 1時間一人で調べてわからなければ人に聞く
- わからないなりにも自分の中である程度仮説がたったら聞く

似たような方法をされている方のご意見や、他の方法をとっている方のご意見など、幅広くお伺いし、自分も含め同じような悩みを抱えている方の参考になればなと思います。
