信頼はずっと、挑戦はもっと。

お問い合わせ
TEL:03-3496-3888

BLOG コアテックの社員ブログ (毎週月曜~金曜更新中)

2019

29

11月

新人プログラマーが仕事を振られた時にやった方がいいと思うこと =後(プログラム新規作成編)=

テクログ

こんにちわ。パグと申します。

前編はこちら→https://core-tech.jp/blog/article469/

プログラム改修編はこちら→https://core-tech.jp/blog/article473/


私はWEBサイト制作においては、プログラム改修よりもプログラム新規作成の方が、

作業ハードルが低い様に感じます。

理由としては、既存システムの影響範囲調査があまりないためです(新規だから影響箇所が少ない!)。

既存システムに新規にページを作成する様な作業が、特に楽な作業に感じます。

一方で、全て1から作らなくてはならないので、ルーティン化されていないときついのでは、

と感じます。もしあなたが新卒、新人1〜2年目で、ページの新規作成を命じられた場合に

何からしたら良いのかわからなくなってしまったら、「詳細設計」を順番に行ってみてください。


1.自分の作成予定ページの動線を知る


自分が作成するページはどこから入ってくるのかを理解します。

表示画面がPOSTでくるのか、GETでくるのか、

トップページなのか複数ページなのか、検索結果ページなのか・・・

色々なパターンがあるかと思います。

そして、入力、確認、完了の様な登録系の処理なのか・・・

検索、検索結果の様な表示系の処理なのか・・・を整理し、

自分の画面の遷移図を書いてみます。


遷移図には書き方が色々ありますし、お作法があるチームもありますので、

何も参考になる資料がない場合はもはや手書きでも良いと思います。


例えば、簡単に書くとこの様な形になります。


・遷移元 → 入力(新規、または更新) ←→ 確認 → 完了


・遷移元 → 検索 → 検索結果 → 詳細ページ




2.自分の画面の対象となるデータを知る


登録系画面の場合は、データを登録するTBLの設計を行います

(基本設計が終わってから作業を依頼される場合は、すでに終わっていることも多いフェーズです)

表示系画面の場合は、取得元を調査します。

ここでPGがすることはSQLを先に考えてしまうことです。

Model設計(すでに存在する場合は、メソッドの設計)です。


例えば以下のようなことを考えます。


・新規登録の場合はどんなカラムが必要か

・更新処理ではどのカラムを更新するのか

・取得処理の場合はリレーションや、取得条件などは何か、何をInとして、何をOutしたら良いのか


SQLが苦手という方によく出会います。DBによって一回でとるのか分けてとるのか、

SQLの書き方も様々ですが、取得系処理のSQLが苦手な人は、どんな結果になっていて欲しいのか

完成系のTBLを想像してからSQLを書くと頭が整理されるのではないかと思います。

まずはSELECTで取得するカラムを想像します→次にWHEREやJoinの条件を考えます。


3.機能の設計を行います。


ここに関しては改修編と同様ですが、とにかく細分化すること。

自分が書けると思われる単位までの細分化です。


この様な形で大枠を決めたら、とにかく作業を細かい単位に分割していきます。

詳細設計とか言われたけど、何からしたらいいんだ・・・ってなる人は、イベント単位で

考え始めると、楽かな、と思います。クラサバ型にせよ、スタンドアロン型にせよ、イベントがあって

処理があるので・・・何から書き始めたらいいの?と設計に混乱する人は、

とりあえずその機能のイベントトリガーが何かを考えて、

そのイベントに対する処理を考えるのが良いかと思います。

バッチ処理なら、呼び出された時、画面処理なら、ユーザーの動作や表示されるタイミングです。


・初期表示

 ・Analyticsやメタタグなども確認する

・POSTまたはGETでデータ受け取り

・データがある場合→編集画面

・データがない場合→新規画面

・データのValidation

・加工処理

→エラーの戻し方

・画面の遷移

・画面の表示の仕方

・Xを押下

・・・

・Xを変更

・・・


このようにイベントが大枠で、そこからの細分化を考えるとスムーズかなと思います。

ちなみに、単体テスト仕様書もこの様な形で書くとわかりやすくなります。



4. 詳細の設計ができたらコードを書きはじめます


順番に作っていきましょう。表示させて、HTMLを作って、中身を書きます。


・ルートを作る

→URLを打ち込むと、空のController,Viewが表示される様にする

・ViewにHTMLを書き込む

→この時呼び出すCSS,JSなどを考えます

・Conotllerを書き込む

→機能設計通りにかく→Modelとつなぐ


5.詳細設計を修正し、テスト仕様書を書く


この辺りも改修と同じく、テスト仕様書を書きながら、

想定通りになっていない箇所を修正していきます。自分で、正常、異常系など含めて

テストが一周できるくらいになっていればCD完了です。

この時に、想定外エラーやXSS対策、CSRF対策などできていたらより素晴らしいです。

業務システム系の開発の場合はCD完了って言ったのに、

バグが出てる状態でテストチームに回したりするとめちゃくちゃ怒られます。


最後に


新人の人が初めての新規作成を命じられて、いきなり放置プレイする現場には

なかなか出会ったことがありませんが、何も言われないからといって

「これでいいのかな?」と思いつつ進めるのは、オススメしません。


・遷移図、TBL設計、機能設計ができたら、PM(PL)に確認する

・一つのActionができたところでPM(PL)に確認する


といった感じに、確認しながら進めていくと、完成後大幅に戻されることが少ないのではないかと思います。

プロジェクトリーダーも、プロジェクトマネージャーも作業を振っている以上は

仕様確認を何度もされることに、嫌な顔をしないはずなので、

「これでいいのか」と何度も確認しながら作業していきましょう。

口頭ベースだと確認に応じてくれない、リーダーの時間が取れないことも少なくはありませんが、

質問の方式を変えてみると良いのではないでしょうか。

例えば、表にまとめて、まとめて見てもらうとか、設計書のXXのXXが・・・と

資料を渡すとか、色々方法はあります。


工期に余裕のある現場であれば、先にテスト仕様書(コード)を作成してから、

CDを行うとより精度を高めることができますので、オススメです。


「新人の時にすればよかったこと」は、きっと3年経ってから気付くことが多くの人に

あるかと思いますが、それを初期の段階でできていると、きっと

この先の自分が楽になることでしょう。


以上です。ではまた。

この記事を書いた人

マスオさん

パグ

所 属:
WEBインテグレーション事業部
出身地:
田舎
仕事内容:
システム開発