「クリーン・アーキテクチャー」という本を読みました

言わずと知れた有名な本ですよね!

設計とアーキテクトは一緒の意味。

クリーンなアーキテクチャーを作ることが早くソフトウェアを作るために必要、という話が冒頭にあります。

いや、本当にそうなんですよね。

人数がいくらいようと、微妙な設計のソフトウェアは生産性が地に落ちてしまいます。

なので、とにかく設計が大事です。

ただ、私は経営者でもあるので、市場に投入するスピードも必要だということも理解しております…。

ここは本当にジレンマなんですが、要はバランスとしか最終的に言えません。

あまりに設計がずさんなものは、いくら早くてもリリースしないほうがいいですし、かといって設計にこだわりすぎてリリースがずっとできないというのも問題なんですよね。

リリースしてから気づくビジネスニーズというのはよくあることで、そのために設計を直さないといけない、ということもよくあることです。

多くのプログラマが間違ってとらえている話があるそうです。

「システムが動作することと、簡単に変更できることとどちらが大切か?」

多くの人が、動作すること、と答えるでしょう。

しかし、簡単に変更できることの方が重要だと筆者のボブおじさんは言います。

完璧に動作するが、変更できないシステムと、変更できるシステムだったら、後者の方にバリューがあります。

まー、そりゃそうですね。

後者は動作するようにすればいいわけですからね。

 

私も、19年近くプログラミングをしていますが、本当に設計が大事です。

これがおろそかにされていたら、プログラマーは常にバグと戦わねばならず、プログラマーの仕事のほとんどがバグと戦う仕事になってしまいます。

なので、あるプロジェクトが後半になってきたとしても、設計に問題があるとなれば、ウチではリリースを延期することもやむを得ないと私は思います。

 

さて、この本については多くの人が解説を述べていると思うので、ここで詳細を書くのはやめにして、私が特に心にとめておきたいことだけ抜粋しておきます。

①安定した抽象に依存すること

コード本体もそうだけども、画面などの変わりやすいものにテストが依存しないようにする。
テストを直すのが面倒すぎて、画面を直したくないという事態になる。
②フレームワークを選択するのは結婚、不平等な契約である。
③SOLID原則を大切にする。
特に、オブジェクト指向の一番の良いところは、SOLIDのDにあたる、依存性逆転の法則が使える、というところだという視点は目から鱗でした。
④ソフトウェアアーキテクトはプログラムを書き続けないとダメ
そうですか…。でも、これめっちゃわかります。。。
実は、私は2年前ぐらいまで、第一線でコードをあまり書いていない時期がありました。
結果、あんまりよくない事態に終わった気がします。

 

 

ドライバーさんのスキルや担当に合わせて最短の配送ルートを組む機能が誕生!

またまた、ODIN リアルタイム配送システムにすごい機能が爆誕してしまいました…!

ドライバーさんのスキルや担当に合わせて最短の配送ルートを組む機能です。

運送会社、配送会社さんで何人かドライバーさんがいると、よく聞く話が

「このドライバーさんはこのエリア担当」

「このドライバーさんはあそこは出禁になっている」

などという話です。

それを考慮して、配車担当さんがドライバーさんがいつ、どの順番で配送先を回るかという配送計画を作るんですが、これは大変なことなんですよね。

配送先が20とか少なければいいんですが、それが数がもっと多い場合、その最短ルートを計算するのは人間にも難しいし、コンピューターにさえ難しいとされています。

その配車を組むときにミスがあったりすると、配送先やドライバーさんから配車担当さんが怒られてしまう…。

配車担当さんのストレスの原因だったわけです。

でも、もうそのストレスとはおさらばです!!

ODIN 配送計画が解決しますからね!!٩( ‘ω’ )

 

スキル考慮機能 イメージ

スキル考慮機能 イメージ

 

そして、今回さらに新しい機能も生まれたんですが、その名も「搭乗」機能。

俺はガンダムで行く!!

ドライバ―さんと車両の組み合わせを、配送計画にあらかじめ設定してルートを組む機能なんです!

今回、開発は設計を私が担当し、実際の実装は新進気鋭のS君、ちょっと難しいUI部分は若手のホープ、S君が(どっちもイニシャル一緒)担当してくれました!

ありがとう!!

 

ODIN リアルタイム配送システムへのお問い合わせはコチラからどうぞ!

コードの動作を口で説明してもらう

私はうちのプログラマーさんに

「このメソッド(or クラス)が何をしているか、口で説明して」

と言う時があります。

多分、言われた方は

「え、なんで?後藤さんはコード見てもわからないからかな?」

「面倒だな…。」

と思うかと思います。(笑)

 

しかし、これは意図があってやっていることです。

どういう意図かというと、

そのコードがどういう意味なのか、その人がコードと違う形で出力する必要があるから

です。

大体、「口で説明して」と言って、スパッと帰ってこない場合は、そのコードがよくないケースが多いです。

そういうコードは

・やってることが多すぎる

・書いた本人も実行 or デバッグしないと結果がわからない

というコードなんですよ。

当たり前なんですよね、作った人が何をしようかわかってないのであれば、微妙なものができてしまうのは。

 

書く、言う、図にする。

これらは考えを人に伝えるために重要です。

そして、人というのは他人だけではなくて、自分も含まれます。

人に悩みを聞いてもらって、すっきりした経験がある方は多いと思います。

問題が明らかになるからだと言われていますよね。

プログラミングも一緒です。

プログラムを書いたことがない人にはわかりづらいかと思いますが、プログラミングって抽象的なモヤモヤっとしたことばっかりなんですよ!!

抽象的なモヤモヤっとしたことをいかにわかりやすくするか、というのがプログラマーの仕事なので、口で言うのは、自分で問題を整理する、そのプロセスです。

逆に、私もプログラミングの設計などで悩んでいる時に、スタッフの方に聞いてもらって解決することも多いです。

 

特にAI時代において、小難しいコードを書くこと、小難しいコードを読むことはAIを使えば誰でもできるスキルになっています。

しかし、モヤモヤしたこと、抽象的なことを整理することは、今のところ人間の方ができます。

なので、そのスキルを磨いたほうがよさそうです。

書いたり、話したりしていきましょう!

コーヒーでも飲みながら