コーヒーブレイク #13: プログラミング初心者が知っておくべきこと。デザイン思考を開発プロセスに組み込む 4 つの方法

プログラミング初心者が知っておくべきこと

出典: Stackoverflow 開発者として、コードはどのようなものであるべきかについてさまざまな理論を耳にするでしょう。アプリケーションのコード行が少ないほど読みやすいと考える人もいます。しかし、これは部分的にしか真実ではありません。私は、次の基準を使用してコードの品質を評価することを好みます。

1. コードは一貫性があり、有益で、十分に文書化されている必要があります。
2. コードでは、安定した最新の機能を使用する必要があります。
3. コードは不必要に複雑になったり、壊れたりしてはなりません。

上記の基準のいずれかを犠牲にしてコードの行数を減らすことにした場合、これが問題になります。そんなことしたらダメ。

他人のコードを読むのは難しい

実際、コードの読み取りと書き込みに費やす時間の比率は 10 対 1 を超えています。しかし、他の人のコードを読まないわけにはいきません。他の人のコードを読む必要があります。そして、スキルを向上させるのは早ければ早いほど良いのです。オープンな GitHub リポジトリを使用して、他の人のコードを研究してみてください。いつでも練習できます。自分に合ったプロジェクトを見つけて、すべての行を掘り下げてみましょう。他の人のコードを読む能力を向上させるもう 1 つの方法は、スタイルをコピーし始めることです。他の人のスタイルでコードを書くと、読解力が向上するだけでなく、コードがより親しみやすくなります。試してみる。

「完璧な」コードを書くことは決してありません

チームで働き始めるまで、私は 4 年間ソロ開発者でした。この間のほとんどの期間、私は経験豊富なプログラマーは完璧なコードを書いていると信じていました。私の意見では、完璧なコードを書くことを学ぶのは時間と労力の問題です。しかし、私がチームに参加してみると、「完璧な」コードを書く人はいないことが明らかになりました。確かに、最終的にシステムに組み込まれたコードは、ほとんどの場合「完璧」でした。なぜこのようなことが起こったのでしょうか? すべてはコード分析に関するものです。私は本当に優秀なエンジニアのチームと一緒に働いています。彼らは、お金で雇うことができる最も有能で自信に満ちたプログラマーの一部です。しかし、もし誰かがテストされていないコードをアプリケーションに含めることを提案したら、彼らは (私も含めて) 本当のパニック発作を起こすでしょう。たとえ自分が次のビル・ゲイツだと思っていたとしても、間違いを犯すこともあります。私は論理的な間違いについて話しているのではなく、タイプミスや文字の欠落について話しています。あなたの脳が時々理解できないこと。新鮮な目でしか気づかないもの。細部にまで気を配り、あなたの作品を喜んで批評してくれる人々と仕事をするように努めてください。最初は批判を受け入れるのは難しいかもしれませんが、それがコードの品質を向上させる唯一の信頼できる方法です。コードをレビューするときは防御的にならないように最善を尽くし、批判を個人的に受け取らないようにしてください。あなたはあなたのコードではありません。

1日8時間コードを書いてはいけない

コードの作成に 1 日にどれくらいの時間を費やすかを正確に知ることは誰にもできません。しかし実際には、1 日 4 時間以上コードを書く人はほとんどいません。これに同意しない人は、このルールの例外であるか、従業員の扱いがひどい会社で働いているかのどちらかです。プログラミングは集中力があり、精神的に消耗する作業です。誰かが 1 日 8 時間、週 5 日コードを書くと考えるのは完全に間違いです。締め切りを守る必要がある場合がまれにありますが、めったにないというのは、ほとんどないという意味です。仕事が重荷になって残業を強要しないようにしましょう。1日4時間しか働かないようにと言っているわけではありません。残りの 4 時間は通常、次のようなことに費やすのが最適です。

• 新しいツール、機能、アプリケーションを学ぶ。
• 同僚と作業プロセスについて話し合う。
• 仕事で困難を抱えている同僚を助ける。
• タスクの計画。
• コード分​​析。
• ビジネスミーティング/ミーティング。

また、一日を通して定期的に休憩をとり、（少なくとも少しは）運動することを強くお勧めします。運動のプラスの効果は長い間証明されてきました。

デザイン思考を開発プロセスに組み込む 4 つの方法

Source Tech Beacon 顧客のニーズを満たす製品を作成するには、顧客が何を望んでいるのかを考慮する必要があります。わかりにくいナビゲーションや不必要に長い読み込みインターフェイスを備えたアプリを作成した場合は、将来の失敗に備えてください。プログラマーとして、チームが取り組んでいる製品の設計をさらに深く掘り下げる必要がある場合があります。この種のコラボレーションは、各人が他の人が気づかないかもしれないことに気づくため、非常に役立ちます。開発者とデザイナーがどのように協力できるかについて 4 つのヒントを提供します。

1. 最初から関与する

常にデザインが第一で開発が二の次であるとは考えないでください。これは真実かもしれませんが、開発者が設計プロセスに関与すべきではないという意味ではありません。プログラマーはプロジェクトの実装方法に関する重要な技術情報を提供でき、デザイナーはユーザーの要望をよりよく理解できます。技術的に不可能な機能やユーザーの要求を満たさない機能はできるだけ早く見つけたほうがよいでしょう。設計者と開発者が協力すれば、設計が承認された後ではなく、問題をすぐに発見して解決できます。多くの企業がソフトウェア開発に協力的なアプローチを採用しています。これは、チーム メンバーが自分の段階やコード部分に対してだけ責任を負うのではなく、設計からテストまでのすべてに対して集団的な責任を負うことを意味します。

2.UXプロセスを学ぶ

UX (ユーザー エクスペリエンス) に詳しくない人は、一見些細な点でチームがデザインを何度も変更する理由を理解できないかもしれません。UX プロセスのすべてのステップは、ユーザーに可能な限り最高のエクスペリエンスを提供するという 1 つの理由で行われます。したがって、最初から UX プロセスの作成に注意を払うことが重要です。これには次のものが含まれる場合があります。

• プロジェクトの目的を調査する。
• ワイヤーフレームの作成 - 製品の主な特徴を決定できるシンプルなデザイン。
• ユーザーインターフェイスなど、プロジェクト設計にさらに細かい詳細を追加します。
• デザインのユーザーテスト。これはおそらく UX 開発の最も重要な段階です。これにより、開発に時間を費やす前に、製品に関する貴重な情報が得られます。
• 反復: テスト結果の分析を使用して、設計を反復してユーザー エクスペリエンスを向上させます。

チームは、変更がなくなるまで、または時間が許す限り、設計とテストのステップを数回繰り返します。これは通常、デザインの複数のバージョンが存在することを意味します。

3. 設計開発を追跡する

デザイナーが開発者に相談せずにプロジェクトを作成するのは非常に悪いことです。それは逆効果です。DevOps では、開発者が PNG や PDF などの簡単にアクセスできる形式で設計ブループリントにアクセスできるようにルールを設定することが重要です。アプリケーションの実装を成功させるには、開発者とデザイナーの間の効果的なコラボレーションが不可欠です。完成したデザインをやみくもに引き渡すことは絶対に避けてください。間違いは最後に修正するよりも最初に修正する方が良いです。

4. プロジェクトがどの段階で表示されるかについて合意する

開発者が製品の最小実行バージョン (MVP) を作成するように求められた場合、最初から最終バージョンの要件を知っておく必要があります。これは不当な期待による問題を避けるために必要です。設計者は、MVP と最終バージョンの両方のバージョンの設計を開発者に提示する必要があります。これは、顧客が最終バージョンで何を期待しているかを考慮して、MVP を実装するのに役立ちます。デザイナーと開発者が協力すると、多くのメリットが得られます。彼らはそれぞれ、他の人の経験に適用できる知識を持っています。開発者は、設計に実装できない機能について貴重な洞察を提供できます。一方、プログラマーと協力すると、デザイナーはプロジェクトをやり直す必要がなくなり、結果的にチーム全体の時間を節約できます。