プログラマーがなすべき26ヶ条
1
普段から色んな情報を見て新しい技術はチェックしておく。常に目的意識を持ち、使えそうな技術は取り入れる。
2
要求をよく聞く。会社の場合は上司が望んでいる事をよく聞き、それを忠実に再現できるよう想像する。
3
完成形を細かくイメージする。要求に合致したものを提供できるのが大前提。さらに細部までイメージし、完成形を具体化する。
絵に書いて表したりもする。
4
完成までの工程を見積もり、納品時期を決める。工程表を作成する。
5
完成形までの道筋を明確にする。
ゴールまでのデータの流れ、処理の順番。ネットワークを使うならネットワークの経路。どこにデータがあり、それをどの経路で取得するか？
6
データ取得経路の明確化。
ファイアーウォールがあるか？プロキシは？ネットワーク担当者への申請書提出も必要に応じて行う。
7
開発言語を決める。
実装したい事に対して得意な言語を選定。機能により複数言語を選択。
8
どの処理をどの技術で行うか決める。大きくはフロントエンドとバックエンドがある。フロントエンドで何をやるか、バックエンドで何をやるか役割分担を明確化する。フロントエンドの言語、バックエンドの言語を決める。
実装方法がわからない場合は、ネット検索したりして実装方法を探す。
また普段の情報収集から当てはまるものがあればそれを利用する。
9
フロントエンドとバックエンドの情報交換の仕組みを決める。どうお互いをやりとりさせるか。
Ajaxを使うのかCGIを使うのか。
10
機械に負担をかけない実装方法を考案。値渡しでなく参照渡しにしたりしてメモリを食わないよう考える。
11
コーディングにあたり、変数名、オブジェクト名、関数名は果たしたい機能を表すような名前をつける。
データを読むならRead_(読むデータ名)など。基本は英文法にのっとる。
12
条件分岐やループを使う場合はフローチャートに書いて無限ループにハマったり間違った条件分岐にならないよう注意する。
13
ところどころログを吐いて途中結果を確かめながらコーディングを行う。想定した途中結果がでない場合は、アルゴリズムを見直し、トライアンドエラーを繰り返していく。
14
同じ処理は関数を用いてやるなど無駄のないコーディングを心掛ける。
オブジェクト指向を基本とし、同じ処理だが別名を用いるなど考える。
実体化するにあたっても名前に気をつける。
15
それぞれのクラスの役割を明確にしてある程度分離的思考でコーディングを行う。分離することでバグの箇所が見つけやすくなる。
16
ライブラリの利用。ここは賛否両論あるが、
ライブラリは積極的に活用し、なるべく自分で書くコードは減らす。
それによりコード管理が楽になる。
サーバにすでにライブラリがあるか調べる。ない場合はサーバ管理者に 連絡してルート権限でインストールしてもらうか、自身の領域にインストールして使えるようにする。
17
一通りできても、想定外の動作も想定して一通り動作チェックを行いバグが出た場合は原因を特定し、必要に応じてアルゴリズムを見直す。
18
個人的に動作チェックが終わったら、関係者に試験版を見せて動作チェックを行ってもらう。
19
バージョン管理
GITなどのリポジトリを用いて誰が何をどう改修したのかわかるようにしておく。
20
納品
改修したなら何を改修したのかを過不足なく簡潔に図示したりして説明し、いつ改修作業を実施するかお知らせする。
21
デプロイ作業
予告した改修日に再度お知らせして
ミスがないように注意して本番環境に適用する。インストールの手順書をあらかじめ作っておき、ひとつひとつ確認しながら作業を進める。
想定外の事象が現れたらただちに中断してインストールを見合わせる。
22
インストールが終了した旨再度連絡。
23
開発者ドキュメントを作成。
何をどう改修したか技術的にきちんとドキュメントとして残しておき、将来的な改修に役立つようにする。
後任に引き継ぐつもりで記載する。
24
電磁波を浴びすぎないように健康に気をつける。
脳が資源なため、栄養のある食事、十分な睡眠に気をつけて、常にベストコンディションでプログラミングに臨めるようにしておく。
25
自分の分野だけでなく関係する部分を幅広く知っておく。例えフロントエンドが担当だとしてもサーバやネットワークの知識も身につけておく。
26
場合によっては、今回の改修で知り得た技術的メモを投稿したりして、誰かに役立つようにする。