Web3時代のつよつよビジネスパーソンを目指すブログ

Web3という大きな波に会社員エンジニアはどう対峙すべきか。クリプト、NFT、DeFi、メタバース…多様な情報に触れ思考したことを発信します。どこにでもいる会社員だからこその、日々の気づき、ビジネスTipsも発信します。

速いプログラムを書くべきか、早くプログラムを書くべきか。

こんにちは。

 

今日の結論としては、

プログラムを書く時は、「リソース」を加味して、

どう書くかを判断する必要があるということです。

 

 

今日は業務で、かなりゴリゴリとpythonでデータ分析の

コードを書いておりました。

書いている中で、ある機能部分を実装するとき、

以下の2択に迫られることがあります。

・ダサくて計算も遅い書き方だが、作業時間少なく書ける

・美しくて計算が速い書き方ができそうなのはなんとなくわかるが、

調べたりするのに作業時間を食いそうだ・・

 

そんな時、仕事としてプログラムを書く身としては

どう判断すべきなのか。

 

美しくて速いプログラムを書くことが正解ではない

まず、ついつい、純粋なプログラマー目線でPCに向かいますと、

どうしても美しくて速いプログラムを書こうと思ってしまうんですね。

 

趣味として、自分が納得のいくコードを書く時なら問題ない。

時間は無尽蔵に使って良いから、最高のプログラムを書いて、

とう仕事のオーダならば、問題ないでしょう。

 

しかし、往々にして、仕事にはリソースという制約条件があります。

時間、工数といった、「どれだけこの作業に時間をかけて良いのか?」

を踏まえて、判断することが必要です。

 

このプログラムによって、何がいつまでにどうなっていたら良いのかを考える

なぜこのプログラムを書くのか、このプログラムを

動かして何をいつまでにするのか?

ここを見失わないことが大事ですね。

 

データサイエンティスト的な業務だと、

お客さんが求めているのは分析結果であったり、そこから次につながる

アクション、仮説です。(大抵は)

 

綺麗で速いプログラムを書いても、ソースはもちろん、

動いているとこをお客さんに見られるという状況は、

なかなかないでしょう。

つまり、こだわるべきポイントは、プログラムの綺麗さでは

ないわけですね。

 

・・・と、今日の私の業務においては、こうでした。

なので、「もっと綺麗なロジックで書きたい・・DataFrameにfor文

使うのはなんかダサい・・」と思いつつも、

分析結果の納期までに間に合わせる!ということをプライオリティにして、

切り替えることができました。

 

まあ、綺麗さにこだわって時間を消費する場面も少なくはないんですけどね。

反省反省。

 

なんにせよ仕事の目的を見失わない、ということは汎用的な考え

プログラミングに限らず、大抵の仕事で共通ですね。

なんのためか?を問うて、行動の判断に落とし込む。

 

最後余談ですが、「リソース」というと、コンピュータの

リソースを考えなければいけない状況もあり得ますね。

性能良いマシンで動かすならば、メモリをガンガン使う

ロジックでも良いか、と考えたり。

 

いろんな制約条件を考えられる人になりたいものです。