タイトルの通り
- 「良いコード/悪いコードで学ぶ設計入門」
- コードレビュー
- 現場に入る
事でめっちゃ学べた。
「良いコード/悪いコードで学ぶ設計入門」
めちゃくちゃ良い本です。 現場に入って、大規模開発 + チーム開発を経験した時に効く本だと思った。
マジで現場では仕様変更を考慮する必要がありますし、チームで開発します。 アプリも多機能で、色んな概念やクラスが入り混じっています。
そういう際に
「特定の役割を持ったクラスが、自身のインスタンス変数を操作するメソッドを持つ設計」はとても有効だと思いました。
それにより、仕様変更が発生した際は例えば「キャンセル理由を表示する条件が変わった。なので、キャンセル理由が格納されているテーブルと密接に関わったモデルクラスで、そのインスタンス変数を使うメソッドを書く」という行為を常に行うと、次回の仕様変更時に、そのモデルのメソッドを修正すると、それがよばれている箇所での影響を最小化できると思った。
ロジック(条件分岐や判定等)は、なるべくそのデータのクラスでメソッドを定義して実装する、という習慣を付けていると、仕様変更の際にめんどくさい思いをしなくて済む、という事が確認できました！
コードレビュー
めちゃくちゃ大事ですね。 現在、現場でたくさんのレビューを頂いて、とても大変(皆さんも、、)という状況なのですが、コードレビューを受けることで「なぜ自分のコードが間違えているのか」という事に気付けて良かったです。 自分のコードは一言で言うと「大規模開発 & チーム開発を考慮していないコード」でした。 それゆえ、大量にレビューが発生してしまいました、、
「大規模開発 & チーム開発」の場合は気をつけないといけない事が多いと思いました、、 また、サービスの改善や仕様変更が多い現場では、「オブジェクト指向設計の基本」みたいなのがとても大事だと思いました。
「特定の目的に特化したクラスで、そのクラスのインスタンス変数を利用したメソッドを定義する」という基本がとても大事だと思いました。 コントローラーでロジック(条件分岐や判定等)を書きそうになったら、なるべくモデルに寄せるべき理由が分かりました。
そうしないと、他のメンバーが保守する時や修正が必要な時に、ロジックの場所に気付けなかったり、同じようなコードを違う場所に書いてしまう恐れがあるからです。
オブジェクト(とあるクラスに属しているデータ)を使った、判定や条件分岐等を行いたくなった際は、そのオブジェクトのクラスの実装を見に行って、なければそこにメソッドを追加して、将来他の箇所で似たような事をやりたくなった時に、修正が一箇所で済む構造にしようと思いました。
現場に入る
プログラミングスクールで時間無制限で学ぶのはやはり効率が悪い気がしました。
- 現場に入って、ついていけないと死ねる + 時間制限がある中で限りある時間を有効活用する
という戦術を取ると効率が良いと思いました。
現場では色んな知識が必要になります。 スクールでは、実際の現場で必要な総合的な知識を全ては教えてくれなかったです。 しかしこれはしょうがないと思っており、スクールも生徒をずっとスクールに置いてしまうと、生徒のお財布状況が大変になるからです。 ですが、スクール側で生徒をさっさと卒業させよう、という取り組みに積極的になれない現状があるので、そういう成長角度が緩くなる状態に気付けず、本質的な学習に取り組めない & お金も無駄に払い続ける(現場に入れば金もらいながら学べるのに)、という悪循環をさっさと断ち切るために、現場に入るために必要な最低限の知識を身に付けたら、現場に入って、まずは「本当に必要な知識」を自覚することが大事だと思いました。
スクールでひたすら時間無制限で、安牌な中で努力しても真の実力は付かない気がしました、、 現場に入って、生存戦略も考えて働くことで、僕は本質的な学習に着手でき始めた気がしています！
次に書きたい記事
- 時間効率の良い学習戦略を追求したい
です。 とにかく現場で私が幸せに働くにはどうすれば良いか？、という所にフォーカスした学習をしたい。
自分自身を守るため + 周りが幸せになるため、です。
「大規模開発 + チーム開発」の会社に入ると、間違いなく
- スクールや個人学習でしてきた以外の学習が必要 + 学習スタイルを変える必要がある
という状況になる気がします。 なので私は現状、初めてそれらに着手しているのですが、喫緊の課題になっています、、
しかし俺は頑張る！
