プログラミングには、低レベルのコーディングからコミュニケーションなどの高レベルのタスクまで、さまざまなスキル セットが必要です。以下のヒントは、私のプログラミングのキャリアを通じて向上するのに役立ちました。
初心者は非効率的なコードを書き、上級プログラマーは最適化されたコードを書きます。しかし、真の専門家は、コードをいつ最適化すべきか、いつ最適化すべきでないかを知っています。
実際には、「最適化されたコード」などというものは実際には存在しません。コードは、速度、メモリ使用量、またはその他のいくつかの要素に関して最適化される場合があります。しかし、時期尚早の最適化について話すときは、通常、速度を最適化する試みについて話しますが、それには通常、別のコストが伴います。
コストとしては、メモリの使用量、プログラムのサイズ、プログラム全体の設計と保守性などが考えられます。最適化には、他の方法よりも理解するのがはるかに難しいテクニックが必要になることが多く、他の人にとってはコードが理解しにくくなる可能性があり、将来的には混乱する可能性さえあります。
ライフサイクルの初期段階でコードを最適化しないようにしてください。少なくともそれを焦点にすることは避けてください。コードをテストし、そのパフォーマンスを測定し、コードのどの部分が最適化によってメリットが得られるかを理解します。
プログラマーとして向上する方法のほとんどには、ある程度のコラボレーションが必要です。完全に一人でコードベースに取り組んでいる場合でも、別のバージョンの自分、つまり疲れている自分、別のプロジェクトから切り替えている自分、または現在の自分より知識がある自分と共同作業する必要があります。
しかし、優れた実践方法は、私利私欲だけを目的としたものではありません。大多数のプログラマーは、ある時点で、最終的には他の人と一緒にコードを作成することになります。
共同作業は複雑なソフトスキルなので、最初は難しく感じても心配しないでください。
ペア プログラミングでも、GitHub 上のプロジェクト メンテナーとの共同作業でも、AI アシスタントの使用でも、練習すれば完璧になります。他の人の提案を受け入れ、自分のアプローチを説明し、異なる意見を尊重する方法を学びます。
それは単なるソフトスキルではありません。 GitHub や Slack などのツールは、特に最大限に活用すると大きな違いを生みます。明確に理解できるコード (または散文) を書くことができれば、どのチームにとっても貴重な人材となることができます。
プログラミングに関しては、学ぶためのツールが不足することはありません。言語やテクノロジースタックなどの基本的なものから、日常をよりスムーズに進めるための小さなユーティリティまで、追加のサポートを常に探しておく必要があります。
このテクニックは、必ずしも最高のツールを使用するというものではなく、それらを最高の方法で使用することを目的としています。 Vim と VSCode のどちらを選択するか悩むのではなく、(よく調べた上で) 1 つを選択し、よく理解してください。本当によくね。
私のキャリアの初期に、Vim マスターである同僚が仕事をしているのを見て、とても勉強になったことを今でも覚えています。彼らはファイルを簡単に飛び回って、私には理解できない方法でナビゲートし、キーを押すだけで根本的な変更を加えました。そしてそれは、Emacs を使用していた同僚に比べれば何でもありませんでした。
より優れたプログラマーになれるツールを見つけるのはスリルがあります。なぜなら、それは多くの場合安価で、即座に永続的にアップグレードできるからです。
Unix の哲学では、ソフトウェアは「1 つのことを実行し、それをうまく実行する」必要があると有名に述べられています。このアプローチは Unix に依存しないため、他のどこにでも適用でき、おそらく何らかの利点が得られるでしょう。
より小さなプログラムを作成するということは、プログラムの保守が容易になることを意味し、より広範囲のタスクを実行するのに役立ちます。パイプやリダイレクトなどの機能を使用して、小さなツールを組み合わせて連携させることができます。これにより、単一のモノリシック アプリケーションへの依存を軽減できます。
プログラムのサイズと密接に関係しているのは、修正しようとしている実際の問題です。場合によっては、タスクを小さな部分に分割し、それぞれを個別のプログラムで解決することで、これに影響を与えることができます。
ただし、多くの場合、明確に定義されたタスクがあっても、その詳細が集中力に影響を与える可能性があります。目標を具体的にしすぎたり、一般的にしすぎたりするのは簡単です。前者のアプローチでは、コードが単一の問題と密接に結びつきすぎて、問題が変化した場合に適応することが困難になる可能性があります。これにより、費用のかかる書き換えが発生する可能性があり、時間と労力がかかるだけでなく、バグが発生するリスクも高まります。
一方、問題を過度に一般化すると、実際に必要なことをはるかに超えたタスクが作成される可能性があります。一般化を続けて、ますます役立つ、または興味深い課題を解決しようとして、最終的には本当の優先事項からは程遠い「すべての問題を解決するプログラム」に取り組むことになりがちです。
同様に、コードの構成要素 (関数) も適切な長さである必要があります。私たちは皆、1 つの巨大な関数で構成されるプログラムを扱わなければならなかったことがありますが、プログラムを追跡したり、推論したり、変更したりするのははるかに困難です。
逆に、これをやりすぎる可能性があります。すべての関数が単なる 1 つのステートメントである場合、その逆の極端な場合と同じくらい、ごちゃ混ぜでわかりにくいコードが作成されることになります。
個人的には、前後にスクロールせずにすべての機能を確認できるように、1 つの画面に収まる機能が好きです。これは、明らかに画面サイズ、フォント サイズ、行の長さなどの要因に依存しますが、一般的に機能を管理しやすくするための有用なガイドラインであると思います。たとえば、一部の言語はより冗長または簡潔なコードに適しているため、必ずご自身の判断で行ってください。
関数について言えば、私がよく書かれたコードを何よりも高く評価するようになったのは、純粋関数の使用です。
純粋関数とは、簡単に言えば、一貫した出力を返すこと以外は何もしない関数です。以下に例を示します。
int max(int a, int b)
{
return a > b ? a : b;
}
この関数は値を返すだけで、max(1, 2) を呼び出すたびに同じ結果が返されます。対照的に、不純な関数の例を次に示します。
function print_random(array) {
const n = array.random();
console.log(n);
return n;
}
このコードにはコンソールに出力されるという副作用があり、同じ入力でも異なる結果が返される可能性があります。
純粋関数は予測しやすいため、組み合わせるのがはるかに簡単です。また、予想される出力を検証できるため、テストがはるかに簡単になります。これは、作成するすべての関数が純粋である必要がある (または純粋であることができる) という意味ではありませんが、コードベースを純化して信頼性を高める機会に注意する必要があります。