【新人君物語】第4話 先輩に聞くタイミングって難しい

とある日の朝会。チームみんなで今日の作業確認をします。

先輩さん「ではそういうことで新人君にはこの機能の実装をお願いするよ。多分今日中には終わると思うからよろしくね。」

新人君「わかりました。」

先輩さん「私はこれから2時間ほど会議があるから何かわからないことがあればチームメンバーに聞いてね。一応自分もチャットは見れるから連絡くれてもいいからね。」

朝会が終わり、早速作業に入ります。

新人君「設計書はこのフォルダだな?…あれ?先輩さんが言っていた設計書がないぞ?…いや、似たような名前の設計書がある。これかな?」

チームメンバーに聞いてみようと思いましたがみんな電話をしたり、仕様を話合ったりしていてちょっと忙しそうです。

新人君「まぁこの設計書だろう。早く作業に入らないと先輩さんも帰ってきちゃうし今日中に終わらせなきゃ。」

そういって新人君は作業を始めました。

 

—2時間半後—

 

先輩さん「いやぁごめんごめん、会議が長引いてしまったよ。新人君、進捗はどうだい?」

新人君「はい、いい感じで進んでいます。今日中にも終わりそうです。」

先輩さん「そうかそれはよかったよ。では何かあったら言ってね?」

新人君「わかりました。」

 

—昼休みを挟みさらに2時間後—

 

新人君「うーんここがちょっと上手くいかないなぁ。先輩さんに聞いてみよう。」

先輩さん「どれどれ?…おや?新人君、これは他のチームメンバーが担当する機能だよ?朝こっちを実装してって言わなかったかい?」

そういうと先輩さんは朝新人君に指示をした設計書を開きました。

新人君「あ…。」

先輩さん「この機能は午前中のうちにすでに実装が終わっているんだよ…。どうして聞かなかったんだい…?」

新人君「すみません…。」

 

解説


新人君、やってしまいましたね…。プログラマーというものは案外聞かれないと答えない人が多く、何も言わないということは例え新人でも問題なく作業が進んでいると判断されます。なので不安なことがあったらすぐに聞いたほうがいいでしょう。

新人君は自分の作業担当の設計書がわからず「多分これだろう」という勘で始めてしまいました。結果無駄に時間(工数)を使ってしまったうえ進捗0ということになってしまいました。

作業の始まりは大切です。特に何をするか不安な時は必ず確認しましょう。不安なまま進めて結果違うことをしているほど無駄なことはありません。

一度聞いたあとすぐにまた聞きなおすのは勇気がいることだと思いますが、わからないまま進めるほうが迷惑をかけてしまうことをしっかり覚えておきましょう。


 

定時過ぎ

新人君「先輩さん、なんとか実装終わりました。」

先輩さん「お疲れ様。今日は疲れただろう。」

新人君「はい…。今日はすみませんでした。作業担当が曖昧だった時点で聞くべきでした。」

先輩さん「なんとか今日中に終わったし今回は多めに見るけど、次これで進捗が遅れてしまい、さらに残業が発生して無駄なお金がかかってしまうことになるんだよ?仕事中はお金が発生していることをきちんと意識して次からはきをつけてね?」

新人君「はい、わかりました。」

 

 

 

スポンサーリンク

【新人君物語】第3話 名前をつけるって難しい!編

引き続き先輩さんにソースレビューをしてもらっている新人君。どうやら先輩さんにはまだ気になるところがあるようです。

先輩さん「新人君、ここの変数parameter1とparameter2っていうのは何?」

新人君「parameter1は画面から入力された名前でparameter2は住所です。」

先輩さん「どうしてこの変数名にしたの?」

新人君「画面の最初の項目だったのでparameter1、2つめの項目だからparameter2としました。何かまずいですか?」

先輩「なるほどね…。ちなみにこっちのstartって?ここは終わりの処理だと思うけど?」

新人君「あ!すみません、そこはコピペしてコピー先の名前のままでした。」

先輩さん「…」

 

解説


名前をつけるって難しいですよね。開発をする時はプロジェクト名からクラス名、メソッド名、変数名、返り値のなどなど名前をつけることはたくさんあります。案外ソースを書いているよりよりよい命名を考えて頭をひねる時間のほうが長かったりするのではないでしょうか?

新人君の命名方法ですがかなりまずいですね。名前であれば素直にname、もしくはinputNameとかわかりやすい名前にしたほうがベターでしょう。最初の項目だからparameter1としてしまうと、例えば名前と住所の間に郵便番号の項目が増えてしまったらどうすればいいでしょう?parameter1.5とするのでしょうか?

命名はたいてい英語のため、例えば「入力」って英語でなんだろう?とか「結果」ってなんだろう?と最初は英訳しながら名前をつけることもあるかもしれませんね。

規則に合わせるのが一番大切


プロジェクトやフレームワークにより命名規則が決まっていることも多々あります。インサート文をデータベースに実行するクラスであれば『insert○○クラス』やDTOであれば○○Dto.javaとするみたいな感じです。

たとえこの名前なら一発で何をしているかわかる最高の名前が思いついたとしても命名規則に沿っていなければそれは駄目な名前なのです。


 

新人君「名前をつけるって大切なんですね」

先輩さん「そう。開発は終わってもシステムは動き続ける限りそのコードはずっと残ることになる。いつか見返した時に何をやっているかわからなければあまりいい名前とはいえないよ。もしその辺を勉強したければ『リーダブルコード』という名著があるから読んでみるよいいよ。これは『プログラマーが読むべき本』みたいなランキングで大体上位にいるからオススメだよ」

新人君「わかりました!」

 

続く…

 

スポンサーリンク

【新人君物語】第2話 どうして同じ処理をまとめるの?編

先輩さんが新人君のソースレビューをしている時です。先輩さんがむむっとうめいて話し始めました。

先輩さん「おや?ここのコードだけど違うメソッドで同じ処理がされているよ?なんでかな?」

確かにここは全く同じ処理をしているロジックがある。それは自分でも把握していた。

新人君「確かにここは同じ処理をしていますが、AメソッドではA画面のパラメータを受け取っていて、BメソッドではB画面のパラメータを受け取っています。違う画面の処理なのでそれぞれ分けました。」

先輩さん「なるほどね。ただ全く同じ処理を複数書くということはよくないことなんだ。なんでかわかるかい?」

新人君は動いていればいいんじゃないの?という思を隠しながら、どうして駄目なのか考えてみました。

 

解説


確かに新人君の言うとおり動いているからいいじゃないかという思いもわからなくはありません。ただ、一度作ったプログラムはこの先改修をされる可能性が高いと言う事がポイントになります。そう考えるとなぜ同じ処理を複数個所で書くのがいけないのかわかると思います。

変更に弱いシステム


例えばほぼ同じ機能をもったA画面とB画面にそれぞれ「備考」という項目が増えたとします。その場合「備考」項目を受け取る処理が追加になります。プログラムを見てみると受け取る処理は全く同じなのに別々にプログラムが書かれていました。ということは改修は2箇所になります。

今回は2箇所だからまだいいですが、何箇所も同じ処理が散乱していると修正漏れがあるかもしれません。画面項目なら動かせば修正漏れがあったとわかるからいいですが、あまり気がつかないような処理であればバグの原因がわからずただの修正漏れに時間がかかってしまう可能性もあります。

つまり変更に弱いシステムになってしまうのです。

テスト地獄


また処理が増えるということはこの後実施するであろうテストにも影響が出ます。全く同じ処理(コピペしたソース)だったとしてもそれぞれテストの必要性があります。

例えば「世界のナベアツ」クラスと「日本のナベアツ」クラスがあったとします。どちらの機能も『画面に入力した数字に対し3の倍数であれば画面に表示する』という機能だったとします。

テストでは1~100の数字を1つずつ画面に入力して網羅することになりました。「世界のナベアツ」クラスは問題ありませんでした。ふぅ終わった終わったと思ったのもつかの間、今度は「日本のナベアツ」クラスに対し同じ作業をする必要があるのです。

上の例は極端ですが、同じ処理が複数あるということは同じテストをその個数分必要になる可能性があるということです。

共通化しよう


ということで同じ処理は共通化してしまいましょう。具体的には引数だけ渡して同じ処理を呼ぶとか、そもそも違うクラスで共通クラスを作るのもいいかもしれません。

もしかしたら上手く共通化できないということもあると思います。実際に同じ処理だからといって機能的に共通化できないこともあります。

ただ理由が「自分の技術では難しそう」ということであれば少し頑張って考えてみてほしいです。もしくは先輩に聞いてもいいかもしれません。長い目で見るとそれだけ時間をかける意味はあります(納期以内でね!)

 


新人君「先輩さんの言ったように上手く共通化することができました!」

先輩さん「お疲れ様。コードも短くなってすっきりしたし、よかったよかった」

新人君「先輩さんにレビューをしてもらいよかったです」

先輩さん「そうだね。これからもどんどんレビューしていくからね」

新人君「よろしくお願いします!」

先輩さん「よろしくね。(新人君のコードはレビューしないと危な過ぎるからね…)」

続く…

スポンサーリンク

【新人君物語】第1話 初めての開発編

『新人君』は某情報大学を卒業した新卒の男の子。研修が終わりプロジェクトにアサインされました。優しい『先輩さん』に教わりながら今日からプログラマーとしての人生のスタートです。


先輩さん「環境構築も終わったし、さっそく新人君には開発をやってもらうよ。まずはこの画面を作ってね」

先輩さんから説明を受け早速開発に入ります。任されたのはとあるECサイト(ショッピングサイト)の管理ページです。この画面にテキストボックスとラジオボタンを増やし、登録ボタンを押すと入力値をデータベースに登録するというものでした。

新人君はさっそく画面にテキストボックスとラジオボタンを増やしました。似たような機能がある画面のソースを教えて貰ったので真似をすればすぐに画面は完成しました。問題はその後です。登録ボタンを押したらどのような経路でデータベースに登録されるのかさっぱりわかりません。参考ページを見ても色々なクラスが呼ばれているのはなんとなくわかりますがじゃあどうすればいいのか。

新人君は途方にくれてしまいました…。

 

解説


新人が配属された時、web業界ではわりと任される開発内容ではないでしょうか?管理ページというのは直接お客さんが触れるサイトを「管理」するページなので例えばショッピングサイトのページにバグがある場合より管理ページにバグがあったほうが被害は少なくすみます(運用でカバーできたりもするので)。

今回新人君はデータベースの接続方法がわからず途方に暮れていますね。データベースに接続といっても言語やフレームワークによっても違いますし、そのプロジェクト独自のルールもあるのでまずは聞いてみるのが一番でしょう。

ただし「データベース」に何かするということはどのシステムも必ず「SQL」を使っているというのは変わりません。またヒントとして「MVC」モデルの考え方があると理解しやすいと思います。

SQL


私も新人の頃先輩に「データベースに何かしているということはこのソースのどこかにSQLが書かれている場所があるからそれを探すのだ」と言われなるほどなと思ったものです。

新人の頃は「げ、SQL書かないとだめなのか」と身構えてしまうかもしれませんが、こればかりは避けて通れません。フレームワークによっては直接SQLを書かなくてもフレームワーク独自の機能を使ってデータベースにアクセスしたりもできますが、SQLの基本は変わりません。基本はなるべく早く覚えた方がのちのち楽を出来ると思います。

近道としては使用しているフレームワークのデータベースアクセスの仕方を調べてみることです。場合によっては色々なクラスを経由した上でようやくSQLが現れるということも珍しくありません。なんでこんなあっちこっちクラスを呼ぶんだ?と思ってもそういう思想があると思って納得しましょう(余裕がある時にでも調べましょう)。その過程でゲッターセッターの存在やクエリビルダの存在、DBマッパーの存在を知ると思います。…頑張りましょう。

 

MVC


MVCとはモデル・ビュー・コントローラーの頭文字をとったものです。今回の開発を例にすごく乱暴にいうと

モデル=データベースに接続する流れ

ビュー=画面

コントローラー=ビューとモデルを繋ぐもの

という感じです。まずビューで入力されたものはコントローラーで受け取り、受け取った値をモデルへという流れになります。

MVCを元に作られたシステムであればこの辺の役割がしっかり分かれているので全体像が理解しやすいのではないでしょうか?ちなみにモデルはサービスと呼ばれることもあるのでなんちゃらサービスクラスというものがあったらモデルと思っておいてよいかと思います(フレームワークやシステムによっては違うこともありますが)。そんなこと言われたってDAOとかDTOとかあるって?まぁそういうこともありますよね!コントローラーとモデルが曖昧になってたりすることもあるのでその辺は空気を読みましょう!(白目)

 


先輩さんに教えて貰いながらなんとか実装できました。先輩さんがやれば1日で終わるものに5日もかかってしまいました。

先輩さん「まぁ最初はそんなものだよ。これから覚えていってね」

なんと優しい先輩なのでしょう。残念ながらこんな優しい先輩ばかりではなかったりするのが悲しいところです。ちなみに新人というものはプロジェクト内で工数に入っていなかったり0.5人としてカウントされいたりするのでこれくらいの遅れは織り込み済みだったりします。これで気を落とさず頑張りましょう!

続く…

スポンサーリンク