何故、今なのか
システム開発の仕事についてのブログを書くのなら、真っ先にプログラミングの話が出そうですが、私のブログでは引っ張って引っ張ってこの日がきました、既にプログラミングに関する多少の記述は過去ブログに書いてあります（’A06 ダメダメ技術者からの脱却’を参照してください）あるブロガーの意見を紹介しましょう、それは「同じ内容のブログを書いても同じには感じない、読者には新鮮に見える」らしいのです、では、もう一度、プログラミングについて書いてみましょう、もしかして、同内容のブログを書くって難しいのかもしれない、人間は感情の生き物なのですから、日によって気持ちも変わります
その前にやるべきこと
プログラム仕様書が存在するのなら、とことん理解しましょう、ですが、良くあるケースとして仕様書無し、指導する方の頭にしか仕様書が存在しない場合は、あなたは聞いた内容を文書や図で残しましょう、その後の「言った、言わない」論争を避ける目的とあなたの次に来る担当者への資料として残すことが重要だからです、資料を残さない・・・・悪いことを真似る必要はありません、あなたは資料を残すのです、資料にいつ、誰が了解したかの記述があればなお良しです、時間が無いとか、急ぐとか、私の嫌いな言葉である忙しいとか、文書化しない理由は様々ですが、できる限りで良いので文書化しましょう
俯瞰力
これは難しい理解かもしれませんが、言われたことをそのまま作るなんて、なんとつまらない仕事なのでしょう、自らの仕事への向上心を高めるためにすべきこと、それは俯瞰力です、作成依頼されたプログラムはいつ、どこで、どのような時に、誰から利用されるのか、その目的は何、出来る限りの情報を取得しておきましょう、そして、システム完成後のあなたのプログラムで喜ぶ人は誰でしょう、喜ぶ人がいないなんて、そんな作業は仕事とは言えませんね
機能確認と既存確認とデシジョンテーブル
プログラミングを行う前に機能を羅列してみましょう、後々、機能がそのまま関数やメソッドになるのなら最高の結果です、その機能、どこにあるのでしょう、もしかして、どこかのライブラリーに存在していませんか、言語や他社のライブラリーに存在していませんか、既存に存在している同じロジックのプログラムは絶対に作らない、これ、プログラミングの鉄則です、そこまで探して無ければ、ここで初めて新規作成と判断します、そして、可能ならばデシジョンテーブルを書いてみませんか、失礼ながら、デシジョンテーブルを書けないようでは作成すべきプログラムを100％理解しているとは言えないが私の理論です、デシジョンテーブルがレビューにて承認してもらえたら最高ですね
プログラミング技術不足への対応
作成すべきプログラムの印象がうっすらであっても、あなたの頭に浮かんだ時、もしかして技術的な不安を感じた箇所はありませんか、プログラミングは力作業と言われますが、ダダダダとタイプしてピタッと手が止まる、それは、技術的な問題や不安を感じた瞬間なのです、後でやる・・・でも結構ですが、理想は事前に対処しておくべきです、つまり、問題や不安部分はそれだけでテストプログラムにて確認しておきましょう、このテストプログラム、意外と後日になって役に立つんですよ
コメント