こんにちは、Workaholicです。
今回は実務のプログラミングに求められるものについて書いて行きたいと思います。正直いくらでも書けそうなので代表的なものをピックアップしてご紹介いたします。
・実務に求められるもの
プログラミングで一定のアウトプットを作るとなると、実装方法は人それぞれの”色”が出てきます。実際要件通りに沿ったプログラミングが作れていれば良いわけですが、実務で以下の点に関して特に注意をして作成をしなければなりません。
・セキュリティ対応
・イレギュラー対応
・可読性
※これ以外にも大事なポイントはありますが今回はこの３つについて解説します。
・セキュリティ対応
プログラミングのセキュリティ対応とは「脆弱性を盛り込まない」ことです。
例としてはSQLインジェクションやクロスサイト・スクリプティング（XSS）などの対策を行う事です。サイバー攻撃は大企業に限った事ではなく、システムが存在していれば大小にかかわらず等しく攻撃を受ける可能性があります。その為、セキュリティ対策として代表的な攻撃として何があるかをを理解し、対策をコードに盛り込む必要性があるのです。
つまりは「コードが要件通りに動いているからOK」というのは実務においてはNGで、不正な入力値が入れば、問題が生じる恐れがあるというのを考慮する必要性があるのです。当然要件の中に対策を入れる事という話も出てくる事もありますが、近年でも SQLインジェクションやクロスサイト・スクリプティング（XSS） 等の攻撃により、顧客情報流出、改ざんなどの攻撃報告は後を絶ちません。おそらくそのような意識が無かったか、その程度事は言わなくてもやっているものだと思っていたから等の理由が考えられます。どちらにせよお客にも、受注側にもセキュリティ意識があれば良かったはずですが、残念ながら事故は起きている以上は当事者達にこのような意識が無かったと推測されます。
特に顧客情報を扱うプロジェクトではセキュリティについて常に敏感になってほしいです。代表的な事例はIPAのWEBサイトでも公開されていますので初学者は是非学習をしてみてください
・IPA 安全なウェブサイトの作り方 – 1.1 SQLインジェクション
・IPA 安全なウェブサイトの作り方 – 1.5 クロスサイト・スクリプティング
・イレギュラー対応
若干セキュリティ対応にかぶる部分もありますが、ここでは特に「安全確認」と「イレギュラーケース」について説明します。
過去に新人君に実力試しとして新規作成するサーバ（Linux）のログローテションをするShellを作成してもらいました。その中で不要ログ（日次でYYYYMMDDのディレクトリを作成し、その中にログを生成する）を削除する際に彼は以下のような方法で削除をしようとしていました。
※変数LOG_DIRは別作成の定義ファイルより読み込み
※rootにて実行
rm -rf ${LOG_DIR}/*
これはかなり恐ろしいコマンドです。LOG_DIRの変数が読み込みがされなければ変数部分が空になり「rm -rf /*」を実行することになります。ルートディレクトリから全消しのコマンドを発行することになり再起不能となります。しかしながら定義ファイルが消える事なんてないじゃないか？と思うかもしれませんが、その可能性がゼロと言い切れるでしょうか、大事なのはありえなさそうな事が起きても、ダメージが大きい事は事前に対策を行う必要性があるという事です。
対策としては「確実にそこにファイルやディレクトリがあることを確認してから削除をする」ということです。まずは事前に変数を定義しているファイルパスがそこに存在しているか確認します。
if [ -e <定義ファイルパス> ]; then
echo "定義ファイルが存在しません"
exit 2;
fi次に実際に削除をする部分では事前にファイルやディレクトリが存在することを確認したうえで、削除対象を抽出し削除を行います。※del.list内のディレクトリがYYYYMMDDかなどを見ても良いですが最低限以下のようなチェックは入れたいです。
ls -d ${LOG_DIR}/* > ${LIST}/del.list
if [ -s ${LIST}/del.list ]; then
echo "削除対象がありません。"
exit 0;
fi
while read line
do
rm -rf ${LINE}
done << ${LISR}/del.list※今回はYYYYMMDDのディレクトリ事削除する処理
イレギュラー対応としてもう一つ述べたい事があります。それは「想定されるテストケースは条件網羅していればOKではない」という事です。全ての条件見てるからOKじゃないか？と思うかもしれませんが実際起きる事象はたいてい我々の想像の上を行きます。
例えばハイフン付の電話番号を、ハイフンなしにする処理があったとしましょう。「XXX-XXXX-XXXX」通常3-4-4の構成なので4と9番目のハイフンを削除すればOKです。その為プログラムの内容として4と9番目のハイフンを削除する事にしたのは良いのですが・・・この場合はいくつかの問題が発生します。それは「3-4-4」ではないパターンと「データがが取得できず空」のパターン等の、不正なパラメータに対応できていない事です。
普通はそんな事は起きえません。ただ何かしらの原因で発生する可能性を見込んで対策を入れておくのがイレギュラー対応です。ここではそのようなパラメータが来ることを想定して、文字列の中からハイフンを検索をして、事前に「3-4-4」の構成であることと、入力値が空である場合も想定して、正しく異常終了させる処理を追加します。
・可読性
可読性とはそのままで、プログラムコードの読みやすさを指しています。プロジェクトごとのコーディング規約に沿っていれば本来はOKですが、そのコーディング規約が全てを網羅しているわけでもなく、軽視されているパターンが往々にしてあります。
プログラムの可読性は生産性を大きく左右します。コードを見て煩雑すぎて読み解くのに時間がかかる、設計書にもろくなことが書いてないという事はSEあるあるです。可読性の高いプログラムを作成するために以下の点に注意して記載をしましょう。
①コード規約は守る
本当にこの点は軽視されています。プロジェクト全体で軽視されているので作成する側も規約をチェックせずに、なんとなく他人のコードを見て似せる・・・や、レビューする側も動いているから細かい所は気にしない等の事は日常的に発生します。
しかしそうなるとあまりに個々の”色”がコードに反省されてしまい、分かりずらい変数名、必要な処理の抜け、または不要な処理の追加などが行われてしまい、非常に読みずらいものになってしまいます。コードを書く際には規約を守る事と、後々にコードを改修する人の事を考えシンプルに処理を記載することが求められます。
②コメントを書く
コード内の書く処理にコメントを書いてください、書かない派の人もいるらしいですが・・・何度も繰り返しますがコードを読み書きするのは自分だけではありません。後々に改修する人はいる事を忘れてはいけません。全ての処理に詳細なコメントを入れる必要性はありませんが、重要な処理に対して「この処理は何をしているのか」がハッキリと分かるようにコメントを入れましょう。
・最後に
本当はもっと書くべきことが沢山あるのですが今回はここまでとします。このような技術は現場の実務を通して学んでいきます。初心者エンジニアの方は実務だからこそ求められる事について常に意識をするようにしてください、先輩からの指導や、プロジェクト内のドキュメント、コードでしっかりと学習をしましょう。
コメント