記事一覧

プログラマが絶対守るべきこと(連載第1回目)

プログラマが絶対守るべきこと(はじめに)

エンジニアとして、プログラムに携わると、大半は人さまが作ったプログラムを修正したり、読み解いたりすることになります。
そんなときに、いつも思います。


  • 「ちゃんと考えて作ってないな」
  • 「改修する人に理解させようとしていないな」
  • 「場当たり的に作ってるな」


そんなプログラムを改修するのは、骨が折れます。
時間も金もかかるし、バグも起きやすい。


そんなプログラムを一言でいうとこれ。
「自分以外のプログラマに理解させようとしていない」


今回から「プログラマが絶対守るべきこと」と題して、私が常々思うこと、私が守っていることを書いていこうと思います。


読んでほしい対象は、主に初学者ですが、実はそれよりも会社の運営にかかわる人に読んでほしいです。
これは、将来的なプログラム資産の運用にかかわる時間、金、人のコストに直結するお話です。


記事一覧

本項にかかる連載記事は、こちらにリンク追加していきます。


改修しにくいプログラムは何が悪いか


「早く安くプログラムを作る」ことは、初学者にとって意外と簡単です。
設計書も仕様書も作成せず、じゃんじゃん機能を作ることは、教科書の延長だからです。
作ったものを繰り返し動作確認すれば、品質も担保できるでしょう。


ここ、特にステークホルダ(会社運営者などの非エンジニアで利害に直接携わる人)に知ってもらいたい。


 安く作ったプログラムを改修するのは、時間と金がかかります。
※きっかわさん、いつもありがとうございます。


機能的な品質は担保できても、将来性という品質を担保できるのはエンジニアだけなんですよ。
長く使い、改修を繰り返すつもりがあるなら、絶対に最初に時間をかけるべきです。


こういうシステムを改修するときに、ステークホルダがエンジニアに、決まって投げかける言葉があります。
 「なんでそんなに時間がかかるの?」
はい。そろそろこの辺を理解していきましょう。



改修しにくいプログラムとは


  • リテラルが多い
  • 変数名が何を意味しているのか謎、または使いまわして意味変わってる
  • すでに廃止した機能なのに、デッドコードとして残っている
  • 同じ意味を持つ情報が冗長に記述されている


言ってみれば「場当たり的」なプログラムは改修しにくいです。
「このソースは、他人が見て理解できるかな?」を常に考えてほしいです。
ステークホルダの方々は「レビューする工数」を取ってほしいです。
技術力が高くなくてもいいんです。それこそ、作成者本人でもいいんです。
作成者本人が1か月後見て理解できないプログラムは、絶対改修に時間がかかります。



逆にしっかりと規則性やルールを持たせたプログラムは改修しやすいです。
将来的にコスト減につながります。


プログラマが絶対守るべきこと


次回から、改修しにくいプログラムにならないように、プログラムが絶対守るべき具体的方策を書いていきます。


これを守れば他人が見てわかりやすく修正しやすい、結果修正コストが下がり、考案からリリースまでの時間が短縮され、早期に利益につながります。
方針転換に即座に対応できることは、機会損失が少ないということ。
会社運営に携わる方。ここ重要じゃないですか?





スポンサーサイト



コメント

コメントの投稿

非公開コメント