開発をする上で最も大切にしなければいけないものはなんでしょうか。私はスピードだと思います。
開発はコストです。早く終わるということは、その分コストを削れます。コストを削ることができればその分が利益になります。ビジネスの目的である利益に貢献しているので、これはとても価値のあることです。
バスより飛行機が高いのも早く目的地に着くからですね。食洗機や洗濯機をお金を出して買うのも、家事の時間が短縮されるからです。
ブラウザは何を使っていますか？世界のブラウザのシェアNo1はGoogle Chromeです。Chromeが1番速いからみんな使っているのです。
速いということはそれだけで価値があるのです。
私はシンプルに実装することをとても大切にしています。最も大切にしていると言っても過言ではありません。
プログラミングの経験が浅い人は、難解なコードを書いたり、短い行数でコードを書けることがかっこいいと考えているかもしれませんが、完全に間違っています。シンプルに実装することは実は難しいのです。プログラムというものは、すぐに複雑になってしまうからです。複雑でかっこいいコードを書こうという考えがそもそもの間違いです。
この記事を読んでいるみなさんは、今後は簡単でシンプルな必要最小限のコードを書くという意識でコードを書いてください。
私はNode.jsのコミッターがトラディショナルなfor文を使ったコードを書いていることを見たことがあります。そのコードは、これ以上ないくらいシンプルなコードでした。
現在のプログラムの多くは、今後も多くの変更が入ります。そうであれば、完璧に動くことよりもメンテナンスがしやすいことが大切です。後々、悪い影響を及ぼすコードは複雑で難解なコードです。シンプルで意図が明快なコードが問題を起こすことはありません。
一般的な技術を有したエンジニアであれば誰でも理解できるコードを書いてください。
テストカバレッジ100%は目指さない
以前、このようなツイートをしました。
マージ条件に作成したコードのテストカバレッジが100%であることというプロジェクトを見たことがあります
— しょーやん (@sinn_shoyan) July 28, 2019
テストカバレッジ100%に違和感を感じない人はもう少し勉強した方がいいですね。
テストカバレッジ100%を目指すとこのようになってしまいます。
テストカバレッジ100%を目指すとどうなるかを説明しましょう。 テストの目的がカバレッジを通すことになってしまい、意味のないテストが乱立します
— しょーやん (@sinn_shoyan) July 28, 2019
さらにテストの問題も発生します。
さらに、コードとテストコードが密結合になり、コードを少し変えるとテストが落ちるという状態になります。 リファクタリングする場合、テストコードも書き直しになります
— しょーやん (@sinn_shoyan) July 28, 2019
テストカバレッジの問題については次の記事に詳しく書いてあります。
全てのコードにコメントを書くのは馬鹿げていると感じる人は多いでしょう。全てのコードにテストを書くということも同じように考えるとどうでしょう。何事も過ぎたるは及ばざるが如しです。
こんにちは、しょーやんです。
私はエンジニアとして12年目で、現在はエンジニアチームのリーダーとしてWebアプリケーションのシステムを開発しています。キャリアとしては、SIerで1年、ベンチャー企業で3年、300人程度の企業で5年、現在は6000人規模の会社でエンジニアとして働いています。
前提として、ここで話すことはアプリケーション設計に関する話しです。データベースの関数自体の使用を否定しているわけではありません。データベース固有の関数を使う前に少し考えてみましょうという話しです。まずは、データベース固有の関数を使うリスクについて説明します。
データベースには固有の関数が用意されています。MySQLだとDATE_FORMATやNOW、SUMといったような関数です。これらを利用するのは便利ですが、安易な利用はおすすめしません。相応の理由がない限りは避けるべきです。理由は、データベース固有の関数を利用すると移植性が失われてしまうからです。
多くの人はデータベースを変更することはほとんどないだろうと考えます。本当にそうでしょうか。
例えば、開発環境ではSQLite、プロダクション環境ではMySQLを使うということは特段珍しいことではありません。
トランザクション境界を分離できないようなインテグレーションテストを実行するときはどうでしょうか。
ユーザーの情報を取得するAPIのインテグレーションテストがあるとします。このテストをクリアするためには、事前にユーザーのデータをデータベースに登録しておくことが必要です。そうでなければユーザーのデータを検証することができません。
テスト用のデータベースを共有で利用していた場合、一時的に作成されたテストデータが他のテストに影響するようになるでしょう。この問題は複数のテストが同時に実行されるようなCI環境になると顕著に現れます。解決策の1つとしてプロダクション環境と同じデータベースが含まれたイメージを作成するという手がありますが、複雑なイメージファイルを作成することは、なるべくなら避けたいところです。
ロバート・C・マーティンは著書「Clean Architecture」で、データベースはあくまで道具の1つであり、アーキテクチャの中心になるものではないと言っています。データベースは家のドアノブのようなものであり、アーキテクチャ的にはどうでもよいのです。ドアノブに家の設計を合わせることはしないでしょう。データベースがドアノブのようなものであれば、データベースに依存しないようにアプリケーションを実装するのは当然のことのように思えます。
RailsやSpringのような現在のフレームワークは、データベースを抽象化して扱えるような仕組みを提供しています。多くの場合、それはORMとして提供されており、利用するドライバーの設定を変更するだけでデータベースを変更することが可能です。
アプリケーション設計の側面から考えると、データベース固有の関数は避けるべきです。データベース固有の関数を利用する必要が場合は、基本的なCRUDで同じことができないかを検討しましょう。さもなければ、たった1つのデータベース固有の関数のせいでアプリケーションの移植性は失われてしまいます。
多くのアプリケーションは基本的なCRUDで構築することが可能です。少しの手間を省くためにデータベース固有の関数（例えばMySQLのREPLACE）を利用することはデメリットの方が大きくなる可能性があります。よく見られるアンチパターンはNOWの多様です。時刻はアプリケーション側で取得できます。アプリケーション側で対応できるものはアプリケーションの機能で対応しましょう。
データベース固有の機能に頼った方がいい場合も存在します。例えば、位置情報を扱うような場合です。位置情報を扱う場合、PostgreSQLの拡張であるPostGISを利用した方が少ない労力で実装することができるでしょう。このように明確なアドバンテージがある場合はデータベース固有の機能を利用しない理由はありません。
こんにちは、しょーやんです。
私はエンジニアとして12年目で、現在はエンジニアチームのリーダーとしてWebアプリケーションのシステムを開発しています。キャリアとしては、SIerで1年、ベンチャー企業で3年、300人程度の企業で5年、現在は6000人規模の会社でエンジニアとして働いています。
度々「相談」という言葉が耳に入ってきます。この「相談」という言葉について耳にするたびに「基準を作ればいいのに」と思います。今回は「相談」と「基準」について考えていきたいと思います。
はじめに私の周りで使われている「相談」について説明します。「相談」とは次のような意味で使われています。
なんらかの判断を行わないといけないとき、その判断の観点を他者に伺う、もしくはその判断が正しいのどうかを他者に伺う行為。
私は「相談」という言葉があまり好きではありません。それは、相談が引き起こすふるまいには次の問題点があるからです。
自分以外の誰かに相談するということは、次のようなタスクが必要になってきます。
これらは本質的な仕事ではなく、仕事のスピードを遅くするだけのタスクにすぎません。
多くの場合、なんらかの権利・権力を持っている他者に対して相談を行うことになると思います（なんらかの権利・権力を持っているので権力者と呼ぶことにします）。例えば、ある権力者はAと言いますが、他の権力者に聞いてみるとBと言います。このように権力者によって回答が異なる場合、現場は混乱します。
自身で意思決定ができない環境でプロフェッショナルとして仕事を行うことは困難です。
このように相談にはいくつかの問題があります。相談の問題が見えてきたところで、「基準」について説明します。
「基準」とは何かの判断を行うときの指標となるものです。例えば、火事が起こったら119番に電話しますし、泥棒に入られた時は110番に電話しますよね。誰も迷うことはないと思います。これは、明確な基準が定められているからですね。
私は相談ではなく明確な基準を決めるのがよいと考えています。それは、次のようなメリットがあるからです。
明確な基準があれば上長であろうが、あなたであろうが、誰が判断しても同じです。基準の前で立場は関係ありません。
誰が判断しても同じ結果になるわけですから、いちいち誰かに相談する必要はありません。忙しい上司を捕まえたり、関係者とMTGの時間を設定したり、説明する資料を作成する必要もありません。今、この場であなたが決めればいいのです。
相談と明確な基準の比較をするために、2つの組織を例として考えてみます。
1つ目の組織では最終的な判断は上長に相談する必要があります。意思決定をするのに上長とのアポイントメントや説明資料が必要です。意思決定を行うためには1日程度かかるかもしれません。
2つ目の組織は明確な基準があり、その基準をもとに問題に直面している当人が判断を行います。明確な基準があるので、その問題に直面している人がその場で決めることができます。
この2つの組織を比較した場合、生産性が高いのは明らかに基準が明確な組織です。このように相談と基準のどちらの戦略をとるかで、生産的な面においての差がみてとれます。