2020-06-12
プログラマが絶対守るべきこと（連載第1回目）
この記事で紹介していること
プログラマが絶対守るべきこと（はじめに）
エンジニアとして、プログラムに携わると、大半は人さまが作ったプログラムを修正したり、読み解いたりすることになります。
そんなときに、いつも思います。
- 「ちゃんと考えて作ってないな」
- 「改修する人に理解させようとしていないな」
- 「場当たり的に作ってるな」
そんなプログラムを改修するのは、骨が折れます。
時間も金もかかるし、バグも起きやすい。
そんなプログラムを一言でいうとこれ。
「自分以外のプログラマに理解させようとしていない」
今回から「プログラマが絶対守るべきこと」と題して、私が常々思うこと、私が守っていることを書いていこうと思います。
読んでほしい対象は、主に初学者ですが、実はそれよりも会社の運営にかかわる人に読んでほしいです。
これは、将来的なプログラム資産の運用にかかわる時間、金、人のコストに直結するお話です。
記事一覧
本項にかかる連載記事は、こちらにリンク追加していきます。
改修しにくいプログラムは何が悪いか
「早く安くプログラムを作る」ことは、初学者にとって意外と簡単です。
設計書も仕様書も作成せず、じゃんじゃん機能を作ることは、教科書の延長だからです。
作ったものを繰り返し動作確認すれば、品質も担保できるでしょう。
ここ、特にステークホルダ（会社運営者などの非エンジニアで利害に直接携わる人）に知ってもらいたい。
安く作ったプログラムを改修するのは、時間と金がかかります。
※きっかわさん、いつもありがとうございます。
機能的な品質は担保できても、将来性という品質を担保できるのはエンジニアだけなんですよ。
長く使い、改修を繰り返すつもりがあるなら、絶対に最初に時間をかけるべきです。
こういうシステムを改修するときに、ステークホルダがエンジニアに、決まって投げかける言葉があります。
「なんでそんなに時間がかかるの？」
はい。そろそろこの辺を理解していきましょう。
改修しにくいプログラムとは
- リテラルが多い
- 変数名が何を意味しているのか謎、または使いまわして意味変わってる
- すでに廃止した機能なのに、デッドコードとして残っている
- 同じ意味を持つ情報が冗長に記述されている
言ってみれば「場当たり的」なプログラムは改修しにくいです。
「このソースは、他人が見て理解できるかな？」を常に考えてほしいです。
ステークホルダの方々は「レビューする工数」を取ってほしいです。
技術力が高くなくてもいいんです。それこそ、作成者本人でもいいんです。
作成者本人が1か月後見て理解できないプログラムは、絶対改修に時間がかかります。
逆にしっかりと規則性やルールを持たせたプログラムは改修しやすいです。
将来的にコスト減につながります。
プログラマが絶対守るべきこと
次回から、改修しにくいプログラムにならないように、プログラムが絶対守るべき具体的方策を書いていきます。
これを守れば他人が見てわかりやすく修正しやすい、結果修正コストが下がり、考案からリリースまでの時間が短縮され、早期に利益につながります。
方針転換に即座に対応できることは、機会損失が少ないということ。
会社運営に携わる方。ここ重要じゃないですか？
