こんにちは
シナジーデザイン プログラマー / マネージャー のAです。
今回は技術的な話です。
マネジメントをする中で
「実装が上手くいかない、、」という部下を接していると
実装中に
考えていることがズレていたり
考えている量が少ないな と感じる事があります。
その状況で当然だと思いますし、
その状況から抜け出そうと、足掻いている最中だと思います。
とはいえ
何を考えるべきか分からないと思うので、
自分が実装しながら考えていることを残します。
前置き）シニアエンジニアは、よく考えるが、手は動かさないらしい。
ジュニア / シニアエンジニアの違いとして
下図の様な挿絵を良く見ます。
引用）アウトプットプロセス（のなと@もちねこはｻﾗﾘｰﾆｬﾝ🐈💨）
ジュニアエンジニアが手を動かし続けているのに対し、
シニアエンジニアは、ぼーっとしています。
で、最終的なコード量は、シニアエンジニアの方が少ない。
という図になります。
このシニアエンジニアが
ぼーっとしてる間、いったい何を考えているのか？
という話を、少し出来ればと思っています。
※
自分がシニアエンジニアだ、、という意図はないんですが
アマチュア時代から含めると歴１０年になるので、
ある程度の信憑性はある話かな、と思います。
なるべく、コードを変えなくて良い方法を考えている
既存のコードを「変える」リスク・コストは
初学者の方が思ってる以上に、高いです。
詳しく説明します。
既存のコードを変えると、、
１，既存のコードを 理解するコスト
２，既存のコードを 変更 / テストするコスト
３，既存のコードが バグるリスク
がそれぞれ高くなります。
既存のコードを変えるには
まず、深く理解する必要がありますし、
テストする必要がありますし、
変えれば変えるほど、バグる可能性が高くなります。
そういった問題を出来るだけ避けるために、
「なるべく、コードを変えない方法はないか？」と考えています。
実は、
その方法の筆頭として
「 “変える” のではなく、”追加する” 」という方法があります。
かみ砕くと
何かの機能を改修するとして、
既存のコードを変更するのではなく、
既存のコードはそのままに、新しいコードを追加して対応する
といった方法になります。
これは「開放閉鎖の原則」と呼ばれていて、
割とポピュラーな原則の１つになります。
他にもう１つ、考えていることがあります。
なるべく、コードを書かなくて良い方法を考えている
書くコードが増えれば増えるほど、、
１，コードを書く / テストするコスト
２，書いたコードを憶えておくコスト
３，バグのあるコードが混入するリスク
がそれぞれ高くなります。
だから、
なるべく、コードを書かずにタスクを終える方が
リスク・コストの面からすれば、安心安全です。
極論、
一切コードを書かなければ、バグるリスクも実装時間も０で済みます。
コードは触らず、ビジネス側の調整で目的達成できるのであれば、
悪い事ではないと個人的には思います。
１点、
この話をすると誤解されるんですが
ショートハンドや、テクニックでコードを短縮する という話ではないです。
例えば
三項演算子を使えば見た目のコード量は減ったように見えるんですが
そういう、付け焼き刃的なことではないので注意してください。
・・・
コードを変えない方が良い。
コードを書かない方が良い。
ネガティブな表現が続きましたが、こんなもんです。
ポジティブ/ネガティブ のバランスは大事ですが、
プログラミングが楽しい、プログラミングが好き、
だけでは、ビジネスとして成立し辛い場面もあると思います。
仕事を上手く進める観点で見れば、
必要な考えだと、この約１０年やってきて、感じています。
