【考え方】直感型志向の為にならない実装方法

何考えて実装してるんですか？

現在、別プロジェクトで新人の面倒をチョロっと見ながら実装をしているお陰で、
更新頻度がアホほど下がって企業ランキングも下がりまくり、
ネタを探すのに右往左往しております。
どうも、え～すけさんです。

新人教育って難しい

どこまでの知識を持ってて、どんな考え方をしてるかわからない人に、
実務で使えるレベルのプログラムを教えるって結構難しく、
説明が上手く伝わらずに新人に疲労困憊な日々を送らせてしまっている気がして非常に申し訳ないと反省の日々を過ごしているわけで、
しまいには出だしのタイトルみたいなことを言われてしまう始末となってしまったため、
じゃあ自分って何を考えてプログラムしてるんだろうというのを文章化してみる試みです。

こんなことを考えて仕事してる

あくまで個人的な思考を文章化しただけなので、
この考え方が必ずしも正解とかじゃなく、こんな事考えてるやつが居るんだなぁぐらいの感じで読んでもらえれば幸いです。

とりあえず実装部分（例としてJavaでSpringを使ったWebアプリ想定）をメインにした内容となっているため、設計とかテストとかはちょっと置いといての考えです。

まず実装をする前に

システムの全体像をざっくり把握

実装自体は機能単位でタスクが振られるかと思いますが、
その機能ってどこでどう使われるんだろうというところを簡単にでも理解してないと、
データのつながり（整合性）とかがキチンとしてるかもアレになっちゃうので、
簡単に全体でこんなことやるんだ　とか　DB（テーブル）ってこういう繋がりなんだ的な大まかな全体像を抑えてから作業をしてます。

実装する機能の仕様理解

基本的に以下の順で機能の仕様理解を行います。

• インプットで何が来るのか？
  →画面とか起動パラメータでどんな形式の値が渡されるのかなど
• アウトプットとして何を返すのか？
  →どんな形式（JSON、バイナリ、文字列など）の値を返すのか
• チェック処理はどうする？
  →何を、どうチェックするのか？（パラメータとか処理の途中でのチェック処理周り）
• どんなデータを取ってきて、どう加工するのか？
  →日付だったらフォーマットは？数値はカンマ区切りとかするのか？などなど

上記が理解できれば、大体の処理の中身が検討付くのですが、
ココが新人とかにとってはネックらしい（後述

後はノリと勢いで

仕様が理解できた時点でとりあえず以下の順番で実装を始めます。

1. Form/DTOの作成
   →Input/Outputの情報を元にFormとController←→Serviceへのデータ連携用のInputDto・OutputDtoの作成
   　面倒くさがりなので場合によっては、設計書をコピーすればプロパティを生成するようなExcelとかを作ったりします。
2. Controller・Serviceクラスとメソッドの作成
   →とりあえずガワだけ。
   　Formの中身をDTOに詰め替えてControllerからServiceを呼び出し、
   　Serviceからの戻りをレスポンスに設定する処理を記述
   　→この時点でControllerの実装はほぼ終わり
3. Serviceクラスをゴリゴリに書く
   →入力チェック・データ取得・加工など設計書に合わせて実装
   　基本的にこう書いたらこう動くだろうな的なことを考えながら
   　こう書いたら保守のとき読みにくいだろうから記述レベル落とすか。。。とかを考慮し、
   　極力処理が読みやすいように実装してるはず。。。
4. 微調整的なアレ
   →コードの分割（長い・似たような処理の部分をメソッド化）だったり、
   　JavaDocやコメントちょこちょこ書いたり、
   　コードゴルフしだしたりしてソースをきれいに整形して終わり

ってな具合で

こうやって自分の作業を文章化すると、
如何に「とりあえずやってみるか」の精神で仕事してるかがよく分かるね！
そりゃ新人にとって「コイツ、何考えてるのかわからん？」ってなるわな。。。

新人は何がわからないのか？

仕様が理解できれば、大体の処理の中身が検討付くのですが、
ココが新人とかにとってはネックらしい（後述

プログラムの書き方的な知識がまだまだ乏しいこともそうですが、
まずなにより仕様の理解が結構難しいらしい。

設計書にもよりますが、In/Outとチェック処理しか記載の内容な粗い設計書だった場合、
どんなデータをどういう条件で取ってきて、どんな風に加工してみたいな部分が全くイメージつかないということがわかりまして。。。

自分の場合だと、
とりあえずER図とかでデータの繋がり見て、こんな条件で取ってくればいいのね。
で、こうOutしたいから取ってきたソレをゴニョゴニョ加工すればいいのね。
って言うことが、なんとなくで思いつくわけですが。。。

結局、公式（パターン）なんだよね。。。

プログラムって、人によって書き方は違うかもしれないけど、
やってることって結構パターン化されたものだと自分は思っていて、
如何にそれをいっぱい知ってるかどうかで実装や考え方の幅が決まってくるのかなと感じてます。
仕様的に〇〇したい→ならこう作る　っていうパターンをいくつもこなして身に付けないと、
急に何かが降りてきて覚醒することとかはモブな一般社員には普通ないので、
いっぱいタスクこなして、いっぱい先輩に聞いて教えてもらって、どんどん理解していくしか無いのかなぁって。。。

例えばString型のnull or 空文字チェックの場合

String a;って言う変数があった時のaがnull or 空文字かチェックする場合

教科書通り

if(a == null || a.length == 0)

普通

if(a == null || a.isEmpty())

ライブラリの使い方知ってる

if(StringUtils.isEmpty(a))

と、同じ処理なのに書き方が3つ（もっとあると思うけど）も有るけど、
どの書き方が分かりやすいかとか、スマートかとか、実装方針に沿ってるかとかで、
【書かなきゃいけない書き方】が変わってくるわけで。。。

経験しかないのかな？

こういったパターンってどこでどう覚えるかって言うと、
結局のところQiitaとかStackOverFlowとかの誰かさんが書いたコードを読んで、
なるほどと身につけていくしか無いのかなって。。。
あとはそれを どれだけ自分で噛み砕いてカスタマイズできるか ってところも大事かなと。

強火で一気ではなく、じっくりコトコト

最初は何言ってるかわからないかもしれないけど、
いつか急に色々と繋がって分かる時が来るはずなので、
出来る・分かることをちょっとずつ増やしていこうねって話でした。
なので、これからの新人教育も地道に少しずつ色々と 優しく(大事) 伝授していくしか無いのかなって。。。
※出来ないからって圧をかけない、コッチが先にイライラしちゃいけない（と言い聞かせながら。。。

ね、微塵もためにならないでしょ？