見出し画像

【開発哲学3_7】〜『CODE COMPLETE第２版(上巻)　第７章』の感想〜高品質なルーチン

M_Kaku堂

感想

ルーチン名ってホント大事✨

ルーチンて作ろうとしているツールを
使う現場の業務を理解した上で、
よくやる定型的な手順を細分化できないと、
ルーチン毎にメソッドなり処理を小分けにできないし、
そこまでできてない＝良いルーチン名を付けることもできない。

ツールだけ作ってほしくて、現場の業務未経験のプログラマを連れてきても、そもそも、
普段必ずやるルーチンワークを（現場業務の流れや禁則事項など）
最低限、定型作業だけでもマニュアル化して見える化
してないと、
連れてこられたプログラマが業務を理解するまでに時間がかかる
か、
トラブルや障害の原因になるツールしかできない
から、
コストが増えるだけ

詳細

見出しとしては、

  1. ルーチンを作成する理由

  2. ルーチンレベルでの設計

  3. 良いルーチン名

  4. ルーチンの長さ

  5. ルーチンの引数の使用

  6. 関数の使用に関する注意点

  7. マクロルーチンとインラインルーチン

  8. まとめ

てな感じ。

なぜか、

ルーチン名（classやFunction、Subなど）を英語で書く人が多い。
しかも、その綴りを間違っている人がさらに多い。
（9-pathの指示を出したかった上司から9-patchて指示された時には苦笑した、、、全然意味が違うやん。）

そういう人に限って、
「いずれは世界的なシステムになります。」
「多国籍な企業になった時に備えて」
↓
「だからプログラムのコードは全て英語で書く」
と声高に語るけど、掘り下げて聞くと、読みやすさ云々ではなく単に

学校や本で習った書き方がそうだったから

が殆ど。
数年前にいた職場で、有名な国立大学を出ている前任者（入社時に既にいない）が残したコードを引き継いだので、蓋を開けて見たら、ルーチン名も引数名も

A-STS1、A-STS2、A-STS3、…
B-STS1、B-STS2、B-STS3、…
C-STS1、C-STS2、C-STS3、…

みたいな略語と数字の割り振りだらけ。
コードを読み解かないと何をしているか把握できず、
いざ読み解いてみると同じ数字や略語の処理なのに、どこかに書き込んだり、編集したり、閉じたりで、
読み解いても結局、

数字にも（略語の）ルーチン名にも意味も規則性もないじゃん！！

とわかり、怒りを通り越して笑った💦（時間を返しておくれ〜〜〜）

（＊メソッドとか中身のコードも、相当読みにくい、可変性も低く、本当にある意味優秀（＝マニアック）だったんだろうなと思いました。
他の資料もみて、他の人にも聞いたけど、STSが何の略だったのかは、未だに分からないまま。。。）

どこの現場にも、

必ずこんな人が1人はいて、「コードを読めばわかる」、「（作った自分にはわかるから）わかるべき」と思いたいんだろうけど、
システムやツールは一度作って職場内とかでリリースされれば、その人の在籍期間よりも長く使われる（＝システムの平均寿命）から、

他の人や後任者が読みやすい引数やクラス、ルーチン名にしておく

は、基本中の基本。

  • 改修や保守のパフォーマンスの向上

  • エラーの発生の軽減

  • バグの発生の軽減

  • コストの軽減

等からも重要なのに、品質品質と言いながら結局は、

とりあえず、目先で動けばそれでいい

と、目先しか見えず、今日も世界中の何処かの会社で、読みにくいコードの解析や障害が頻発した事後対応に時間が割かれる。

そもそもVBAやGASであれば、

関数名や引数名などは日本語で書ける（定義できる）

を知らずに作業している人も多い。
日本人しかいない職場ならば、日本語で関数名やルーチン名を書いていた方がそのコードが何をしているか圧倒的に把握しやすいし、いざ英語対応が必要な時に書き直せば良いだけの話。

例えば、

function SaveBFileToAFolder_(){
   …
}
//AフォルダにBファイルを保存する
function SaveBFileToAFolder_(){
   …
}
function AフォルダにBファイルを保存する_(){
   …
}

のどれがコメント行すら減らせて、コードを自体を初めて見た人が、

そのルーチンで何をしているかわかりやすいか

（もちろん、コメント以外が日本語だとうまく実行できないプログラミング言語では使わないし、引数や定数まで日本語にすると、コードの編集が大変なので、さすがにクラス名やルーチン名でしかしないけど。）

コードの書き方も、

スネーク記法で

function save_Bfile_to_Afolder_()

みたいにオブジェクト指向言語でも書く人もいるし、

キャメル記法（引数名や定数名はlower、クラス名や関数名はupper）で、

function SaveBFileToAFolder_(){
   …
}

と書く人もいるから、規約もなく、それぞれがそれぞれ好き勝手にひとつのツールの別のルーチンを改修すると、書き方もバラバラで読みにくくなる。

事前に、コーディング規約やルーチンの分割単位や行数などを決めておく

参考

VBAでよければ、

現場のコードがどんな感じか見たい人は、（有料だけど）

も出しているので参考にしてみてください。

経営学の本だけど、

のたしか第16章あたり「進化するルーチン（ルーティンだったか）」は、プログラミングに限らず、組織全体のマネジメントも含め、MUJIGRAMなどを通じて、なぜマニュアルが経営を改善させるのかが非常にわかりやすい。

マニュアルと言うと、
「マニュアル人間になるな」
「（自分達の仕事は、マニュアル化できるほど簡単な仕事ではない」
で、嫌悪感や拒否反応を示して否定する人も見かけるけど、それで事故や信用低下で会社がコスト体質になっては意味がないし、
本当にマニュアル化できない作業　＝（自動化含め）パソコンに向かない作業
なんだけど、、、。
逆に、一度作ったら作りっぱなしで、何年もアップデートされないままのマニュアルも、それはそれで現在の実務にとって有害でしかないけどね。

まとめ

「プログラマは全てのコードを読むべき」とよく聞くけど、

でも言われているとおり、何かの作業で、

全てのコードを読んでから作業する人なんてまずいない

から、

読みやすいルーチン名にして、機能もルーチン毎に小分けにしておく。
全てのコードを読んだところで、常に最適解を導けるわけでもない。
↓
（だから、最初から全てのコードを読まなくていいと言いたいのではなく）
💃（自分以外の全ての）他人を意識したわかりやすいコーディングが大事🕺
↓
文芸的プログラミング
3日後のコードは他人

やっぱり日本人には日本語やな〜

この記事が気に入ったらサポートをしてみませんか？