プログラミング設計手法を語る前に、もっと基本的プログラミングをするべき！！

f:id:hrmch-ioii:20180717230700j:plain

フリーランスでベンチャーに手伝いに行っていたりしていると、設計手法の話や開発手法の話はよく聞くわけです。

ベンチャーの場合、新規プロダクトを作ることが多かったり、人が少ないから設計は実装者に任せられたりすることが多いので、

話題の設計手法の話はよくでます。

ドメインドリブン設計（DDD）とか、RestAPI設計などなど

新しい方法を取り入れて効率的に開発することが目的なら良いことです。

が、しかし、ただ単に取り入れてみたいケースが多いと感じる。

なぜ、そのように感じるかというと…

設計手法とか語る前に、そもそももっと基本的なことを確実にできるようになってから話しましょう。

ってことです。

なんでこんなことになるのかってのは、結局は自分たちのチームの現状を明確に把握できておらず、課題がなになのかをはっきりしてないからにつきると思うのです。

ある程度経験を積んでるエンジニアや知識豊富なエンジニアでも、プログラミングの基本でユーザーに対するメリットが多いとこを置き去りにして開発手法メインで実装してしまっているケースを見かけたりするわけ。目的と手段が逆転して、手段（開発手法を全うすること）が目的化しているパターンです。

開発を効率化するには、開発手法よりもまずは基本的なことをしっかりやりましょう。それだけで相当コスパよくなるはずです。

基本的なプログラムの組み方ってのは

リソースを最小化をする

ということになります。

現代のPCは性能が良すぎて、メモリもガンガン載せれますし、CPUもどんどん性能がよくなってるのであまり気にしないとは思いますが、

ユーザーのこと考えたら、エンジニアとしては最大のメリットを出せる部分だと思う。

サクサク動いて、ある程度古いマシーンでも動くし、同時に他のアプリをガンガン立ち上げても問題なし！

という状態を作るのはユーザーもリソースのこと意識しなくても使えるということは一つの武器になる。

では、具体的にどんなことかというと

１つ目はこれ。当たり前だけどステップ数をとにかくへらす。ステップ数が少ないと実装サイドから見たメリットもあります。

それは、 不具合が発生する確率が減る。 ということ。

動く回数が減るんだから当たり前ですが、普通にスーパーメリットだと僕は思ってる。

無駄にループが何回も動くようなロジックは、速度問題の爆弾にもなります。

開発者は大量データであまりテストしたがらないですが、実際に運用してみると、想定外のデータ量で、ステップ数が増えまくることも。

ちなみにアプリの速度問題は致命的で最も解決するのが厄介な問題なケースが多い。

２つ目がこれ。メモリ問題。

必要なデータ以外は極力保持しない。ということ。

必要なときに、必要な分だけデータをメモリに載せましょう。

ばっかばっかメモリに乗せていつでもすぐにデータにアクセスできる状態作ったりすると、ユーザのメモリが悲鳴あげるよ。

HTMLの量も必要な分だけ必要なときに作ってあげないと画面がもっさりするし、メモリ食うってばよ！

そもそもそのメモリ、ユーザーのメモリだから抑えれるんだったら最小にしてやれよ！

とまぁ、すごい基本中の基本なんだけど、最近は流行りの開発手法やマシンの高性能化で意識されなくなってる部分だけど、

これだけで、速度問題もほとんど起きないし、不具合少なくなるしで他のエンジニアにクオリティ的に勝てるんじゃないか？と感じる今日このごろ。