Webプロダクトの失敗する条件

こんにちは。
Hiro_Matsunoです。
雪道でDCT付きのAWDはSPORTモード+VDCカット+パドルシフトを使うことでFFベースだと60:40・FRベースだと45:55のアクティブデフロック状態が可能です。
これ覚えておいてくださいね。
Webプロダクトの成功条件について書きたいと思います。
まずは失敗例から書いていきます。

Webプロダクトの失敗
これですがWebプロダクトの失敗する場合ですが以下の条件が挙げられます。
・組み合わせるフロントエンドのライブラリの調査不足
・バックエンドプログラム言語の調査不足
・データベースの設計ミス
・SQLのチューニング不足
です。

○フロントエンドライブラリの調査不足
フロントエンドライブラリの調査不足ですがどうして起きるのかと言うと安直な調査を行ってしまうケースがあります。
RIOT使いたいとすると普通だとライブラリの使用状態や組み込み方を調査するんですが安直な考え方をするとC#などと同じと考えてしまう人も多く見られます。
ECMAScriptはC#とは似ても似つかない全く別言語なのにも関わらず使用して混乱を招くことになってしまいます。
C#と似ているのはECMAScriptのスーパーセットであるTypeScriptなので注意が必要です。
ECMAScriptはどちらかと言うとPHPのライブラリであるLaravelと同じクラスの書き方をしているので要注意です。
あと言えるのはアロー関数の多用が時にはif文を惑わせる結果になることもあります。
使い勝手が良いからと言って使いまくるのも問題を増やすきっかけになります。
ときには意図的にアロー関数を使わない決断も必要です。
Vue3やReactを使う人はTypeScriptを学ぶ必要があります。
気をつけてください。
ECMAScriptやTypeScriptはトランスパイルと言う作業をしないとブラウザで動かない状況にもなりますので注意が必要です。
トランスパイルとはECMAScriptやTypeScriptのバージョンをECMAScript5に落とすといった作業を行っています。
プログラムのステップ数が多くなるとメモリを大量に使うことになるのでなるべく多いメモリを積んだパソコンが必要になります。

○バックエンドプログラム言語の調査不足
これですがよくあることなんですがRuby・PHP・Pythonは多くのライブラリを持っているので調査をしっかりと行わないとプログラム開発に問題が起こす場合があります。
しっかりと調査する必要があります。
その上使うデータベースによって複数ライブラリを使うこともあります。
MySQL・PostgreSQL・MongoDB等によってはライブラリを変更しないといけないケースがあります。
忘れないでほしいのはNullチェックや半角スペースキーなどのチェックを入れる必要があります。
それはなぜかと言うとSQLインジェクションという問題がついて回ります。
SQLインジェクションとは入力項目から半角スペースを入れてデータベースを触って情報を取得してしまうことを言います。
これを対策するのにはデータベースライブラリから提供されている変換プログラムメソッドを使う必要があります。
必ずこの対策をするようにしましょう。

○データベースの設計ミス
これもよくある問題です。
データベースを組むときなのですが関係性の条件をつけずそのままデータストアにしてしまうことがあります。
その場合はあとから関係性条件をつけることは出来ません。
設計をするときに必ず関係性を見るようにしてください。
データストアにしてしまうとSQLのチューニングが難しい状況になってくるので注意が必要です。
実はこの失敗は私も経験したことがありデータベースからデータを取り出すときに困ったことがあります。
最初からしっかりと設計していればこの問題は防げます。
もう一つ言えることはWebプロダクトの場合はデータ項目内のデータがない項目に関してはNullを使うことは厳禁です。
必ず空文字(””)を使いましょう。
デフォルトで設定できるので必ず設定変更しておいてください。

○SQLのチューニング不足
SQLのチューニング不足はWebサイトのレスポンス不足を起こすきっかけになります。
複雑なSQLを使う場合は必ずテストサーバに接続し実際にSQLを実行しながらチューニングを行うことが必要になります。
慌ててSQL文を作ってしまうとレスポンスが遅くなってしまうこともよくある問題です。
データベースには必ず接続できるソフトが付属していたりしています。
接続ソフトを使いSQLをチューニングし実行スピードを改善することが重要になりますので必ず行いましょう。

今は失敗プロジェクトはよく炎上プロジェクトと言われます。
なぜ炎上と言われるのかと言うと納期に間に合わない状況での言い訳や人員の大量投入による開発レベルの低下や一人プロジェクトでの大量の要件追加など著しく大変な状況になっている事を言います。
私も炎上プロジェクトの火消し役として活躍した経験があります。
火消しって損なことばかりです。
できれば一番やりたくないのが炎上してからの複雑な対応です。
これ一番疲れます。
炎上プロジェクトを作らないようにしましょう。

Hiro_Matsunoでした。

また、明日。

ここから先は

0字

これは私の今までのハッカソン・エンジニアリングワークなどで得た知見等を書いていくものになります。 特に苦労しそうなことを書いていこうと思い…

この記事が気に入ったらサポートをしてみませんか?