プログラミング | オリジナル、AI翻訳
-
競技プログラミングは、あなたのモチベーションを高める限り、やっても構わない。
-
プログラミングは文章を書くことに似ている。創造的な活動だ。
-
自分自身のプロジェクトに取り組もう。技術ブログを書こう。10年続けるブログのように、何年もメンテナンスするプロジェクトのためにプログラミングしよう。
-
通常、今流行っている技術を追いかける必要はない。多くのトレンドは数年で消えていくからだ。
-
自分の好奇心を追求し、自分のためにプログラミングしよう。
-
自分のためにプログラムを作ってみよう。それらは仕事の課題ではない。
-
プログラミング中に頻繁に不幸せを感じるなら、それは間違ったやり方でやっている証拠だ。
-
iOS、Android、バックエンド、フロントエンド、AIはどれも良い。少なくともそれらを使って小さなプロジェクトを作ったり、数ヶ月学んだりしてみよう。
-
デバッグとは疑うことだ。コードの一行一行を信用せず、もっと良い方法を考えられる。
-
プログラミングでは、一文字でも一行のログでも重要だ。それらは何かを伝えている。
-
プログラミングを使って他人が使う製品を作る。ユーザーがいるのは面白いことだ。
-
厳しくある必要はない。数百人のユーザーが心からあなたの製品を愛してくれる方が、数万人のユーザーがただ優しく好意的であるよりも良い。
-
プログラミングを始めた理由を忘れずに。
-
プログラミングの知識を人生のあらゆる側面に応用しよう。それらは同じだ。物事をバッチで処理するか一つずつやるか。仕事をどう単位に分けるか。全てのアプリの背後にある技術。ネットワークリクエストの背後にある微妙な詳細。
-
抽象化と論理的思考。細部にこだわる思考。あらゆる解決策を考える思考。
-
真実は真実だ。通常、コンピュータは間違わない。電気回路は間違わない。コンパイラは間違わない。バグがあっても落ち込む必要はない。
-
エレガントでシンプルな解決策を追求しよう。シンプルさは究極の洗練だ。本質的なものを残し、余分なものを削除するためには深く考えなければならない。
-
プログラミング言語については、仕事を成し遂げられる言語ならどれでも構わない。個人的にはJavaとPythonをお勧めする。
-
https://www.yinwang.orgのYin Wangをフォローしよう。彼はプログラミングにおける数少ない天才の一人だが、本人は天才など存在しないと言っている。
-
プログラミングの知識と原則は、言語学習、ハードウェア修理、ライフハック、科学研究にも簡単に応用できる。
-
ほとんどのプログラミング作業では、高校数学以上の高度な数学は必要ない。
-
数年後に自分の古いコードを振り返ったり、長期間コードプロジェクトをメンテナンスしたりしよう。そこから多くのことを学べる。
-
プログラミングへの情熱を失ったら、しばらく他のことをすればいい。
-
テストのタイミングは重要だ。自然にやればいい。プロジェクトのためにテストを書く必要はあまりない。テストを書かない、ユニットテストを書く、統合テストを書く、APIテストを書く。賢く比較しよう。
-
AIコードエディタを試してみよう。ChatGPTや他のチャットボットを頻繁に使おう。AIツールは今や簡単に使えるので、より創造的で重要な部分に集中できる。
-
デバッグ時には、ライブラリの最新バージョンを使っているか確認しよう。ライブラリがメンテナンスされていない場合は、活発にメンテナンスされているクローンやフォークを探そう。
-
ネットワーク速度やプログラムの実行時間を改善する際には、定量的な指標が必要だ。そうでなければ、些細な改善か劣化か正確にわからない。
-
個人プロジェクトでは、テストコードを書かなくても構わないが、大量のコードを変更した後はローカルテストをした方が良い。影響を受けるコード、クラウドパイプラインでの実行時間、エラーが発生する頻度を考慮し、それに応じてテストコードを書こう。ユーザー体験に悪影響を与えずに簡単にテストできる方法を使おう。
-
シンプルでエレガントなコードを書こう。重複を最小限に抑えよう。ただし、時には重複がよりシンプルな解決策につながることもある。特殊なケースを最小限に抑えよう。テストしやすくしよう。共通の関数やプロセスを使うようにリファクタリングし、再帰やループを使い、パターンを見つけよう。
-
エラーを適切に処理しよう。根本原因、責任、変更可能かどうか、外部エラーかどうかを考えよう。救済方法、影響範囲、どこで処理するか、エラーを分類すべきか、発生する可能性、最悪のシナリオを考慮しよう。
-
replaceを使うか、startWithの後にsliceを使うかの違いは、前者が文字列の位置を無視することだ。プログラミングのあらゆる細部に同様の思考を適用しよう。
-
一つの項目の取り得る値を最小限に抑えよう。一つのケースには一つの値だけを使おう。falseがある場合はnullを使わない。翻訳済みのtrueまたはfalseフラグがある場合、翻訳済みフラグがあるたびに、翻訳済みフラグが存在しないことをfalseとして扱わないようにする必要がある。
-
GitHubやSourcetreeを使って変更されたコードブロックを頻繁にレビューしよう。コードを読むのに便利だ。
-
プログラミングでは、些細なことはほとんどない。一文字、リスト項目の順序、全ての文字列、全ての数字、全ての変数名が重要だ。全ての実行順序、全てのログが重要だ。
-
最もワクワクすることをしよう。主流に従わなくても心配する必要はない。
-
コマンドを頻繁に使おう。タスクの自動化やLLMの支援に役立つ。UI操作は自動化が難しい。
-
プログラムのログ（ローカル、UAT、マイクロサービス、パイプラインのログ）をディレクトリに保存しよう。プログラミングでは、これらのログには無数の関連性が含まれている。それらを検索して関係性を特定し、関連データやコンテキストを収集しよう。
-
収集したログがあれば、問題に遭遇した時、以前に遭遇したかどうかが判断しやすくなる。過去のログから修正方法がわかるかもしれない。ログは、全てがどのように機能し、コンピュータがどのようにプログラムを実行するかをより良く理解するのに役立つ。コードとは異なり、ログは時間に関連しており、実行状態に関するより多くの情報を提供する。デバッグにもより軽量だ。
-
デバッグでは、周辺変数の値、スレッド名、関数スタックなど、多くの情報が表示される。
-
全てを自動化しよう。プロキシの更新や最適なプロキシサーバーの選択など。Pythonを使ってスクリプトを大量に書こう。