プログラミング

プログラミング | オリジナル、AI翻訳

Home 2025.01

プログラミング

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

無限のエンジニアになろう

大企業では厳格なデータセキュリティポリシーが適用され、従業員や契約社員は入社初週にラップトップを受け取り、退職時に返却する。
プロジェクトには多くの詳細が含まれるが、従業員は業務中に情報を忘れがちであり、特に1年以上離れるとなおさらだ。
経験から得られる記憶には、プロジェクトの概要、チームとのやり取り、LinkedInのつながりなどがあるが、厳格な情報管理のため、文書化された記録は残らない。
このような企業での最初の契約業務は、フラストレーションを感じやすく、ソフトウェアエンジニアリングをより難しくし、仕事に大きな影響を与える可能性がある。
最近、真に無制限ではないにしても、社内リソースを活用して環境を無限に感じさせる方法を理解した。
複数のソフトウェアオプションが利用可能であり、特にWindows上のコンパイラを使えば、スクリプトや小さなツールを作成できる。
可能な限り多くのライブラリやプログラミング言語を学び、社内で提供されているものを最大限に活用しよう。
Go、Rust、C/C++のビルドツール、npmを使ったJavaScript、C#などの言語がサポートされており、知識が増えれば柔軟性も高まる。
AIの時代には、Pythonスクリプトを使ってPostmanのようなカスタムツールを構築したり、ツールに機能が不足している場合はデータベーススクリプトを書こう。
AIを使ってタスクを自動化しよう。例えば、Seleniumスクリプトを使ったテストやパフォーマンステストのスクリプトなどだ。
大企業での制限感の初期の原因はマインドセットにあった。ポリシーは物事を構築したり効果的に仕事をすることを妨げるものではない。
人生において、感じる制限はしばしば十分に深く考えていないことに由来する。もっと試せば、独自のアイデアが生まれるかもしれない。
大企業で無限のエンジニアになることは、全体として無限の人間になることを意味する。

Back Donate