コラム

プログラムコードの書き方TOP3。メンテしやすさが肝心!

スポンサーリンク

10年弱PG・SEとして大手メーカーに常駐して
自社開発の部門システムの運用保守・開発・設計・コンサルをしていました。

大手企業に常駐10年以上のSEが10年以上仕事で心掛けていたこと

人材を育てられる企業は強い

経済学部出身で、
「CSVってなんですか?SQLって食べられるの?」
レベルのほぼ新人プログラマーを受け入れて教育し、
将来的には外資企業で、
カスタマーサクセスのアジア太平洋地域のマネージャーになるくらい育て上げたのだから、
しっかり人材を育てられる企業は強いです。

常駐先は2桁兆円売上げる、誰もが知る大企業なのですが、
成長するのもわかります。人を大切にしていました。

そして、単純に働いていて
「一生ここでみんなと働きたい」と思うくらいの居心地さを感じました。

ちなみに、”カスタマーサクセス”はまだ日本では馴染みのない言葉だと思いますが、
どんな組織かを知るには下記の記事が参考になります。

サブスク時代の新業種カスタマーサクセス(クライアントサクセス)部隊とは? - MANEJYUKU
サブスク時代の新業種カスタマーサクセス(クライアントサクセス)部隊とは? - MANEJYUKU

スポンサーリンク カスタマーサービスは聞いたことがあると思うがカスタマーサクセス。もしくはクライアントサクセスという言葉はあまり馴染みがないかもしれない。実は私が米国外資の会社でアジア太平洋地域のマネ

manejyuku.com

だいぶ前置きが長くなりましたが、
「プログラムコード」の書き方について、
PG・SE期間心掛けていたことをTOP3を述べます。

第1位:メンテしやすいコードを意識

これに尽きます。

趣味で書く場合はっきり言ってどうにでも書いて自由ですが、
業務で書くコードは、
未来永劫自分がメンテナンスをするわけではありません。

いくら「いえ、私は会社とともに心中します」という、
一方的な愛社精神を持っている人も、
この激動の時代会社からクビにされるかもしれないし、

今は元気でも急にメンタルをやられ、
休職からの泣く泣く退職ということもありえます。

未来は誰も読めません。

そんな”読めない未来”の中でも、
可能性の高いのは、

「あなたが書いたソースコードを、将来誰かがメンテナンスをする」です。

であれば礼儀として、
他人でもわかりやすいコードの書き方をしておくと、「優しい」です。

「事前準備」→「メイン処理」→「後処理」の型を意識。

型を意識といってもintやcharのことではありません。

正直プログラムでできることは単純です。

引数があって戻り値のあるものであれば、

  • 何かを渡して
  • 加工して
  • 結果を返す 

以上です。
これだけです。

引数も戻り値もないのであれば 

  • 関数起動
  • 決められた処理 

以上です。

先術の例だと「加工して」「決められた処理」のところが、
関数のメインの処理になります。

型を意識しているか否かで大きな差が出ます。

その型とは、
「事前準備」→「メイン処理」→「後処理」です。

「型」は日常生活と同じ

回転寿司でもいきなりデザートのメロンにはかぶりつかないものです。

  • まずお店に入って手の消毒・席に着く・お茶を準備(事前準備)
  • 皿を取り上げる。寿司を口に頬張る。手を拭く(メイン処理 ※ループあり)
  • デザート食べる・お会計をする・店を出る(後処理)

日常的に当たり前の動作ですが、
コードになった瞬間に、
いきなり非日常動作になっているコードを見ることがあります。

第2位:もっと削れないか?短いコードで書けないかを追求

コードが長くなるにつれて、
バグの発生する余地は増えていきます。

同じく、
プログラムの変数を増やすにつれて
変数の管理コストも増加していきます。

ここで意識したいのが、変数の場合は
「これ本当に必要か?」ととことん問い詰めることです。

色々吟味をした結果「無くす」ことができたら最高です。

コードの長さについても「なんか冗長だよな」と感じたら、
いかに短くできるかを検討した方が良い
です。

長ったらしいと感じる処理には無駄があるはずです。
1ブロックでも2ブロックでも簡素化できないかを追求しましょう。

処理を俯瞰フローチャートは強力

そんな時に役立つのがフローチャートです。

処理全体を俯瞰できるので、チャートの中で
重複や、似たような処理を発見することができます。

プログラマーで「あれ〜わかんねーなー」とか
「動かねー」とスタックして小一時間戦っている人に限って、
フローチャートを使ってなかったりします。

確かにフローチャートに落とし込むのは多少時間がかかります。

が、
スタックした時こそ、
一旦冷静になってフローチャートに落とし込んでから
情報を俯瞰して理解してから、
動いた方が結局のところ大幅な時短につながります。

フローチャートについては、別の記事で詳細説明しました。

部品数が少ないものは壊れにくい

Simple is bestと言いますが、その通りです。

身の回りのものでも、
部品数が少ないものほど故障する確率は減ります。
しかも高級感すらでるものです。

思い出して下さい、
高級品こそサッパリしていませんか?

格安ノートパソコンにはやたらシールがぺたぺた貼っていますが、
MacBook Proにはシールは貼っていません。

高級車も然り、高級マンションの部屋も然りです。
サッパリしています。

第3位:テクらない。自己顕示欲誇示は悪

分厚くしかも4千円近い本を買って技術を学ぶのがプログラマーという人種です。

でも、そうやって学ぶと、
人間「使って」みたくなるものです。

学んでインプットしたことを、すかさずアウトプットすることは良いこのなのですが、
頭の片隅に入れないといけないのは、

「これ今業務で書かれているソースコードで”浮かないか?”」と立ち止まることです。

「ん?これどんな処理をしているんだ?」とパッとみて
「うっ!」っとくる難解なものにプロジェクトを回していると出会うことがあります。

初見で他の人がみても、
「うっ!」と嫌気を覚えさせないくらいのコードを書く
のが、
仕事で書くコードとしては「優しい」です。

初見で理解されるコードは業務向き。他人に「優しい」

これはコミュニケーション能力に通じます。

「相手が
後でこのコードを見てすんなり理解できるだろうか?」の気遣いです。

相手を思いやる想像力があれば、
自ずと書くコードは「優しい」ものになります。

「お前らはこんなのわからないだろ!俺すごいだろ!」的な、
テクったコードを書くのは自己満足でしかありません。
業務向きではありません。

もしそういった”テク”った書き方をチームに広めたいのであれば、
コードレビューで一度みんなに集まってもらって説明や意見を得た方が親切です。

横文字・専門用語の連発はコミュニケーション能力欠如の証拠

自己顕示欲誇示
「技術系気質」の人間にありがちなイタい習性です。

具体的にはあなたの周りもいないでしょうか?
「ソフトウェア」でも全然異なる「法律」「会計」でもいいのですが、
専門分野の人に相談した時にやたら専門用語・横文字を並べて、
結果「何言っているか、ワカラン」ってタイプの人です。
しかも早口です。

それでいて本人は説明したら、
満足げにこちらの曇った表情を見ながら
「え、こんなのもわからないんでちゅか?」的な、
ドヤ顔だったりするのでタチが悪いです。

自社の人間ならまだ、
「お前の言ってること、さっぱりわかんねーよ!」と、
悪態をつくチャンスがあるのでマシですが、

他社の人だったら大変です。
気を使わないといけません。

一番最悪なのが、こういった人が
他社の窓口担当に抜擢されているケースです。
技術に明るくとも、絶対に抜擢してはいけない人事です。

なぜなら、
自己顕示欲誇示系なので、人の話を聞きません。

詳しく説明をしても、
そもそも他人からの指摘は、真っ当な意見でも、
彼らにとっては「攻撃を受けた」と同じなので、
守りに入ります。
話が通じません。

こういった相手と仕事をしていると、メンタルを消耗します。

実際に病気になって休職しました。

なので、
窓口担当にはそういった気質の人間を置いてはいけません。
回る仕事も回らなくなります。

まとめ:他人に「優しい」コミュニケーション能力がポイント

業務(プロ)のプログラムコードの書き方のコツを経験則から3点述べました。

それらに共通しベースとなる考え方は他人への「優しさ」であり、
コミュニケーション能力が大切であるという点です。

開発現場では派遣含めひっきりなしで人が入れ替わるのが常です。
「いつかは他の人が見る」ことを念頭において書かれた「優しい」コードは、
引き継いで自分が担当になった時も伝わるものです。

コードには改修履歴にアルファベットで名前が書かれていますが、
「優しい」コードの人の名前を別のプログラムで見かけたら
「あっ、またこの人か!」と見たことも会ったこともない人ですが、
時間を超えてテンションが上がったものです。

逆も然りですw

こちらもCHECK

フローチャート簡単イメージ
フローチャートは難しくない。プロが語る覚えるべき図形はたった3つ!

スポンサーリンク プレゼン資料作成にも役立つ ソフトウェアエンジニアであれば、フローチャートは馴染みがあると思いますが、エンジニア以外でもフローチャートの書き方の作法は、覚えておくとパワポの資料などプ …

続きを見る

スポンサーリンク

関連コンテンツ

ポチッ押して応援してください!

にほんブログ村 IT技術ブログへ

-コラム