コードについて話しているコーダー
トムはここで執筆しており、ウェブとネイティブのすべてに情熱を注ぐ開発者です。私が最初に数行のコードを書き始めてから、多くの衛星が過ぎ去りました。輝かしい「HelloWorld」の瞬間がありました。それ以来、リアルタイムのアラートシステム、日常業務で医師をサポートする医療アプリケーションからマルチプラットフォームの会議に至るまで、はるかに多くのコードをさらに多くの行で作成してきました-＆-スケジューリング管理ソフトウェア。私もその過程でいくつかのことを学びました。今日は、特にプロジェクトの途中の重い時期に、必ずしもそれほど焦点が当てられるとは限らないコーディングの1つの側面を共有したいと思います。コーダーの責任、正確には、コーダーのコードレガシーについて話しましょう。
Javascriptのピラミッド
建築家の仕事は、新しい建物の基本的なレイアウト、壁、窓、ドアの形状、または正午の太陽に比例する家の配置を定義することだけではありません。とりわけ、建築家は、建物が今後何年にもわたって耐えなければならず、強風、大雨、寒い冬、暑い夏の残酷な性質に耐えなければならないことを知っています。建築家の仕事の最終的な目標は、建物に住む人々が安全な家を持っていることを確認することです。それはすべて彼または彼女の仕事の寿命についてです。それはすべてその遺産についてです。
ソフトウェア開発では、特にスタートアップで働くとき、物事は非常に速いペースで動く傾向があります。新しい機能を迅速に出荷し、市場で注目を集め、ユーザーの関心を維持することが重要です。開発中の焦点は、現在のスプリントまたはその1つの優先度の高い機能をできるだけ早く実装することに限定される傾向があります。
しかし、私がコーディングしているときは、すべて緑色に点灯するテストや、期限に達するだけに制限されるべきではありません。アプリケーションは、実際に使用されると、日常の作業をアプリケーションに依存する可能性のある人間によって使用されます。私が今日構築しているプログラムは、明日残していく遺産です。
例としてウェブを取り上げましょう。NPMを通じて今探している機能を提供するコンポーネントを見つけるのがこれまでになく簡単になりました。それらはすぐにインストールされ、コードベースの残りの部分に接続されます。しかし、私のアプリケーションの寿命に関しては、サードパーティの依存関係が更新プロセス全体を停止する可能性があります。b/ cを更新すると、ある依存関係が別の依存関係の動作を停止します。これは、自分で何を実装するか、フォークするか、パッケージマネージャーから直接インストールするかを決定するバランスを取る行為です。
ただし、サードパーティプロバイダーからのコードは問題ない場合があります。ライブラリまたはフレームワークを使用する前に、いくつかの要因を確認することが重要です。過去のメンテナンスの良さ、現在のアクティブな貢献の数、将来の変更または改善の概要を示すロードマップ、完全にコミュニティで管理または支援されているパッケージその開発を支援するスポンサー？
外部コードから自分のコードベースに移行するとき、私が常に思い出さなければならないことの1つは、開発中に目標をより早く達成するために手抜きをしないことです。短期的には魅力的かもしれませんが、計画が不適切なコードは復讐を果たし、反撃します。コードを書くよりもコードについて考えることは、多くの問題を軽減するのに役立ちます。ここで確かに重要な要素は経験ですが、ジュニア開発者も最初から保守可能なコードの重要性を理解する必要があります。プロジェクトのタイムラインが原因でバグの原因が修正されることはなく、回避策によってのみ解決される可能性があり、コードが乱雑になるか、ユーザーエクスペリエンスが低下するか、またはその両方になります。
機械工の考え方
私が書きたい思慮深いコーディングのもう1つの側面は、アプリケーションのターゲットオーディエンスであるユーザーです。私は電気計算尺の画面の前に9時から5時まで座って、コードの行を調べ、割り当てられた問題に焦点を合わせているので、私のすべての作業が最終的には日常業務で部分的または完全に使用する人が使用します。また、技術者以外の人向けのアプリを作成するのか、他の開発者向けのAPIを作成するのかは、実際には問題ではありません。作成するものは、人間工学に基づいて使用する必要があります。
私は、ユーザーが奇妙でほとんど説明のつかない方法でアプリを操作する可能性があることを直接の経験から知っています。作成者である私は、サービスの「意図しない」動作を拒否する傾向があります。すでに多くの時間とエネルギーをサービスに投資している場合はなおさらです。それでも、フィードバックを受け取るときは落ち着いて、必要に応じて自分自身にそれを聞かせることが、聴衆の実際の実際の使用行動を理解する上で重要な役割を果たします。
私たち開発者は、コーディング時に秩序と均一性のある世界に住んでいます。そこでは、特別な種類の物理学と重力が適用され、すべてのルールを知っています。私たちはその創造者であり住民であるため、それを受け入れ、完全に没頭する世界です。しかし、フィードバック、つまりこの世界の外からの批判に直面すると、通常、開発者による拒否につながります。ユーザーレポートとオプションの処理は、開発に関連する入力として学習し、評価する必要があります。これは私が学んだ教訓であり、プロジェクトのすべての段階で変更やフィードバックを受け入れるのに大いに役立ちます。
process.exit（）;
要約すると、現在作成しているコードだけでなく、今後数年間で人々が使用するコードについても考えてみてください。ターゲットオーディエンスの実際の需要を反映して、最終製品を人間工学的かつ効率的に使用できるように、外部コードパッケージの使用法、プロジェクトの構造と実装について慎重に決定します。フィードバックを理解することは重要であり、誇りに思うことができる高品質の製品を提供するのに大いに役立ちます。
- Tom
