Web 開発における 6 つの悪い習慣_html/css_WEB-ITnose

Usersnap では、よく組織された Web サイト開発において (合計) 20 年以上の経験があります。私たちは、これらの過去の経験が、ウェブサイト開発の良い、悪い、醜いものについての良いアイデアを与えてくれると考えています。今はネガティブな点に焦点を当てたくありませんが、一度、過去の悪い点をまとめてみましょう。

1. 20 の重要なポイントを電子メールで送信する

すべてのバグ、機能要件、他の人の拒否された要求をリストした 20 の重要なポイントを他の人に電子メールで送信します。これは製品と同じ問題です。通常、彼らは「なぜ $XY を修正しないのですか? 5 週間前に指摘しましたよね?」といった非難や質問を伴います。開発マネージャーがこれらの会話を実行可能な計画に変換しないと、物事を忘れてしまう危険があります。母親がこれらすべてを教えてくれなかったと文句を言うのではなく、クライアントやマネージャーにバグ トラッカーやプロジェクト管理ツール* の使い方を教えてみてください。そうすれば、長いメールを送信するために膨大な時間を節約できるだけでなく、メールの受信者もあなたが最近何に忙しかったのかをよりよく理解できるようになります。

2. チーム全体に Cc する

問題に関する全員を Cc するということは、誰がこの問題を処理できるかわからないということを意味します。このアプローチには独自の問題があります。そうした場合、おそらく誰も答えなかったり、問題に責任を感じなかったりするでしょう。また、これらのメールを読むことは、関係のない人々の貴重な時間を無駄にします。責任者を特定し、その人にのみメールを送信するようにしてください。

3. テストを他の人に任せる

元々どんなバグがあったのかを知らずに誰かに機能をテストさせることは、チームメンバーの時間を無駄にするもう一つの方法です。例: 顧客から、IE ブラウザの特定のボタンが機能しないとの苦情がありました。最初に問題を引き継いだ開発者の 1 人がそれを解決しましたが、その後、別の QA 担当者が問題を再現する方法もわからないままテストしました。

4. フロントエンドとバックエンドの戦争

開発チームを固定のパートに分割するのは悪い考えであり、非常に非機敏です（心配しないでください、私たちはこの言葉を使う習慣がありません） 。 「フロントエンド」と「バックエンド」を区別すると、「Grabenkämpfe」（または、フロントエンドとバックエンドの間の戦争）が発生しますが、これは間違いなくチームの精神に反するものです。フロントエンド開発者は「バックエンドの変更が遅すぎる」と不満を言うでしょうし、バックエンド開発者は「今年に入って API が変更されるのは 5 回目です」と不満を言うでしょう。

5. 未テストのコードを公開する

誰々の HiPPO (一番給料が高い) のコードだからといって、未テストのコードを公開するのは絶対にダメです。さらに悪いことに、これは金曜日の仕事を終える前に起こりました。もちろん、週末に残業しない限りは別ですが…

6. 最適化が早すぎる

そうですね、ちょっと厳しい言い方ですね。しかし、誰かがあなたのページを見る前に CSS アニメーションの改善を始めても、何の役にも立ちません。バックグラウンド タスクやレポートがある場合は、サービスが読み込まれていない間に 5 ～ 10 秒間実行しても問題ありません。すべてが適切に動作している後で最適化を開始する必要があります。私たちは依然として最適化を強く主張しています。前の記事の第 9 条を参照してください。

元コンピューター科学者であり、米国スタンフォード大学の名誉教授である Donald Ervin Knuth は、厳選された書籍コレクション「The Art of Computer」の著者です。コンピュータプログラミングの「プログラミング」）」。彼の論文「goto ステートメントを使用した構造化プログラミング」の中で、彼は次のように書いています:

要するに、何を最適化したいのかを決める前に最適化を始めると、あらゆる種類の不要なトラブルやエラーが発生することになります。

私たちは、バックアップせずに製品に変更を加えたり、明確なアイデアや指示なしに開発したりすることは推奨しません。しかし幸いなことに、これらのエラーはそれほど頻繁には発生しません。