1.他人のせいにする前に自分のコードをチェック
自分や他の人のプリセット状況を疑ってみてください。異なるベンダーのツールには異なるプリセットが組み込まれているかもしれませんし、同じベンダーが異なるツールを提供しているかもしれません。
誰かが、あなたが繰り返せない問題を報告してほしいと言ったら、彼らが何をしたのか見てきてください。あなたが思いつかなかったことをやってくれるかもしれないし、そのことを別の順序でやってくれるかもしれません。
とにかく、編纂者を責める前に、シャーロック・ホームズの忠告を思い出してください。"すべての不可能性を排除したとき、残ったものは、どんなにあり得ない人物であっても、真実に違いない"。ダーク・ジェントリーも似たようなことを言っています。
--アラン・ケリー
2.継続的な学習
興味深い時代に生きています。グローバル化に伴い、仕事ができる人が大量にいることを意識する必要があります。競争力を保つためには、常に学び続ける必要があります。そうでなければ、自分が必要とされなくなるか、その仕事が他の誰かに安くアウトソーシングされるまで、いつまでも同じ仕事をし続ける、遅れた人間になってしまいます。
ですから、どうしますか？寛大な上司の中には、スキルの幅を広げるためのトレーニングを提供してくれる人もいます。また、トレーニングをする自由な時間もお金も与えてくれない会社もあります。ですから、仕事を安定させるためには、自分の教育に責任を持つ必要があります。
学習を続けるための方法のリストです。これらの多くはオンラインで気軽に見つけることができます：
- 本、雑誌、ブログ、ツイッター、その他のウェブサイトを読みましょう。さらに深く知りたい場合は、メーリングリストやニュースグループを追加することを検討してください！
- 本当に特定の技術に集中したいのであれば、自分の手を汚して、コードを書いてください！
- 業界のトップに立つと、学習の妨げになることがあります。誰からでも学ぶことはできますが、自分より賢い人や経験豊富な人からはより多くを学ぶことができます。メンターが見つからない場合は、次の段階に進んでください。
- 自分が使っているフレームワークやライブラリを知りましょう。どのように動作するかを知ることで、より快適に使うことができます。オープンソースであればラッキーです。デバッガーを使って、内部でどのように動作しているのかをシングルステップで確認しましょう。本当に賢い人たちによって書かれ、レビューされたコードを見ることができます。
- 何か間違ったことをしたり、バグを修正したり、問題にぶつかったりしたときは、何が起こっているのかを深く掘り下げて調べてみてください。誰かが同じ問題を抱えていて、それをウェブに投稿している可能性があります！
- 何かを学ぶのに最適な方法は、教えたり話したりすることです。人々があなたの話を聞きたがったり、質問をしたりすると、学習意欲が高まります。職場のユーザー・グループや地域の協会で、ランチ・アンド・ラーニングの方法を使いましょう！
- 興味のある言語、技術、法律を研究できる研究グループや地域のユーザーグループに参加したり、立ち上げたりしましょう。
- もっとカンファレンスに行きましょう。もし行くことができなくても、多くの会議がその内容をオンラインで無料公開しています。
- 長距離通勤をお探しですか？ブログをお聞きください。
- コードベースで静的解析ツールを実行したり、IDEで警告を見たりしたことはありますか？それらが何を報告しているのか、そしてなぜそうなるのかを把握しましょう！
- 有能なプログラマーのアドバイスに従って、毎年新しい言語を学びましょう。少なくとも1つは新しいテクニックやツールを学びましょう。現在の知識ベースで使えるように、ブランチを出してアイデアを追加しましょう！
- 学ぶべきことのすべてがテクノロジーに関連している必要はありません。自分の仕事の分野で何かを学べば、ニーズをよりよく理解することができ、ビジネス上の問題を解決する助けになります。より生産的になる方法や、より効率的に仕事をする方法を学ぶのも良い選択肢です！
- 学校へ戻る
マトリックス』のネオのように、必要なものを脳に直接ダウンロードできる能力があればいいのですが。でも、そんなことはありません。毎瞬勉強する必要はありません。週に1回など、少しの時間で十分です。仕事以外の生活も必要です。
テクノロジーは急速に進歩しています。
--クリント・シャンク
3.何かを壊すことを恐れないで
業界経験のある人なら誰でも、間違いなく不安定さに悩まされたプロジェクトに携わったことがあるでしょう。システムのリファクタリング非常に難しく、通常、ある場所を変更すると、別の無関係な場所に触れます。モジュールが追加されるたびに、プログラマーの目標はできるだけ変更しないことであり、バージョンごとに慎重になります。これは、積み木で高層ビルを建てるのと同じくらい災難に見舞われやすいことです。システムがすでに病気であるため、適当なものを変更することは非常に有害です。医者が必要なのです。すでに自分のシステムのどこが悪いかわかっているにもかかわらず、「オムレツを作るために卵を割る」ことを恐れているのです。熟練した医師は、手術をするためには切開が必要であることを知っていますし、切開は一時的なものですぐに治ることも知っています。最初の痛みに対しては、手術は非常に価値のあるもので、患者は通常、手術前よりも良い状態になります。
コードのことは気にしないでください。何かに取り組んでいる最中に、一時的に中断されても誰が心配するでしょうか？変化を恐れていると、プロジェクトはそのような状態になってしまいます。プロジェクトのリファクタリングに時間をかければ、多くの時間を節約できます。さらに、壊れたシステムに対処しているチームの経験が、それをうまく機能させるために何をすべきかのアイデアを与えてくれるというおまけもあります。抵抗するのではなく、この知識を使うことを学んでください。誰もが、嫌なことに時間を費やすべきではないのです。内部インターフェイスを再定義し、モジュールを再編成し、リファクタリングし、コードをコピー＆ペーストし、依存関係を減らして設計をシンプルにしましょう。極端なものを排除することで、コードの複雑さを減らすことができます。極端なものは、しばしば過度の結合を生み出します。旧アーキテクチャから新アーキテクチャへの移行は、変更をテストしながらゆっくりと行ってください。大規模なプロジェクトで大規模なリファクタリングを行おうとすると、多くの問題が発生し、プロジェクトの途中ですべての努力を放棄することになりかねません。
医者である以上、治癒のために病巣を取り除くことを恐れてはなりません。態度は伝染するものであり、長引いたプロジェクトに変更を加えるよう、他の人を動機づけるものです。チーム全員が気持ちよく取り組めるプロジェクトをリストアップしましょう。これらのタスクは目に見える結果を生まないかもしれませんが、経営陣を説得すれば、支出を削減し、新しいリリースの開発を加速させるでしょう。コードの全体的な「健全性」を気にすることをやめないでください。
--マイク・ルイス
4.プロのプログラマーであること
プロのプログラマーの最も重要な特徴は、個人の責任です。プロのプログラマーは、自分のキャリア、自分の見積もり、自分のスケジュール、自分のミス、自分の仕事に責任を持ちます。プロのプログラマーは、これらの責任を他人に転嫁しません。
もしあなたがプロなら、自分の仕事に責任があります。本を読み、学ぶ責任があります。業界や技術のトレンドについていく責任があります。そして多くのプログラマーは、それを上司の仕事だと思っています。申し訳ありませんが、それはとても間違っています。医者もそうだと思いますか？弁護士もそうだと思いますか？いいえ、彼らは時間とお金を使って勉強します。休日には雑誌を読み、計画を立てます。彼らは常に自分自身をアップデートしていますし、そうしなければならないのです。あなたと雇用主との関係は、契約を履行することだけが目的です。要するに、雇用主があなたに給料を払うと約束したら、あなたはその仕事をきちんとこなすことを約束しなければならないのです。
プロのプログラマーは、書いたコードに責任を持ちます。もしそのコードが正しく動くかどうか確信が持てなければ、安易にそのコードを公開することはないでしょう。自信のないコードをリリースするつもりだと想像してみてください。プロのプログラマーは、QAにバグを見つけてもらいたくないのです。もちろん、完璧なものなどありませんから、QAはいくつかの問題を見つけるかもしれません。しかし、プロフェッショナルである以上、QAに悪いところを見つけられたくないという姿勢を持つことは重要です。
プロフェッショナルはチームプレーヤーです。チーム全体の未来に責任を持つのです。互いに助け合い、教え合い、学び合います。チームメイトの誰かが倒れたとき、他の全員がそこにいて気遣います。
プロは膨大なバグリストを許容しません。膨大なバグリストは不注意です。課題追跡データベースに何百もの課題があるシステムは、不注意の悲劇です。実際、課題追跡システムに大きく依存するプロジェクトのほとんどは、常に不注意です。自動化が必要なバグがこれほど長いリストになっているのは、非常に大規模なシステムだけでしょう。
プロフェッショナルは自分の仕事に誇りを持ち、散らかしたりしません。コードをきちんと整理し、構造化し、読みやすくします。既定の標準に従い、それをしっかりと実践します。彼らは決して調子に乗りません。医師があなたの心臓の開腹手術をしている間、あなたは体の外に出ることができるとします。この医師には期限があります。余分な血球が失われて心肺循環が機能しなくなる前に終わらせなければなりません。どうすればいいと思いますか？典型的なソフトウェア開発者のように焦らせ、混乱させたいですか？それとも「後で戻って修正します」と言わせたいですか？それとも、時間を作るという規律に注意深く従い、彼自身のアプローチが今できる最善のものだと信じてほしいのでしょうか。カオスを望むのか、プロフェッショナリズムを望むのか。
プロフェッショナルは責任を持たなければなりません。彼らは自分のキャリアに責任を持つでしょう。彼らはコードが正しく機能することに責任を負います。彼らは自分の仕事の質に責任があります。締め切りが迫っていても、彼らは自分の原則を放棄することはありません。実際、プレッシャーがかかると、プロはその原則をより厳しく要求することさえあります。
--ロバート・C・マーティン
5.コード解析ツールの使用
テストの価値は、プログラミングの早い段階で開発者に植え付けられます。今年は、ユニットテスト、テスト駆動開発、そしてアジャイル手法の台頭が、開発サイクルのあらゆるプロセスで多用されています。しかし、テストはコードの品質を向上させる数多くのツールの一つに過ぎません。
遡れば、C言語が新興の技術であった頃、CPUの使用時間とストレージの形態は非常に限られていました。最初のCコンパイラーはこのことに気づき、意味解析によって便利なコードの量を減らしました。そのため、コンパイル段階で検出できるエラーはごく一部に限られていました。これを補うために、スティーブン・ジョンソンはlintというツールを書きました。このツールはコードの冗長性を取り除き、類似のCコンパイラで取り除かれていた静的解析を実装するものです。しかし、この静的解析ツールは、無駄な警告や文体の問題についての不必要な警告をたくさん追加します。
現在、言語、コンパイラ、静的解析ツールの状況は大きく異なっています。メモリとCPU時間も非常に安価になったため、コンパイラはより多くのエラー検出を行えるようになりました。ほとんどすべての言語に、問題のある書式や一般的な問題をチェックするツールが少なくとも1つはありますが、潜在的なヌル・ポインタ参照などの暗黙的なエラーは検出されないことがあります。CのSPlintやPythonのPylintのような、より洗練されたツールでは、設定可能です。つまり、設定ファイルを通して、ツールがコマンドラインやIDeでどのようなエラーや警告を出すかを選択できます。
もし他のすべてがうまくいかず、コンパイラやIDEやlintツールが見つけられなかった単純なバグや違反を探していることに気づいたら、静的解析ツールをすべて片付けなければなりません。これは言うほど難しいことではありません。ほとんどのプログラミング言語、特に動的であると主張する言語には、抽象構文木とコンパイルツールが標準ライブラリの一部として含まれています。あなたが使っている言語の開発チームの標準ライブラリの詳細を調べることは意味があります。例えば、Pythonの標準ライブラリには、コンパイラとターゲットプログラムのバイトコードを生成するディスアセンブラが含まれています。これはコンパイラの作者であるpython-devチームにとっては曖昧なツールのように見えるかもしれませんが、実際には日々の作業に大きな違いをもたらします。このライブラリは最後のスタックトレースから情報を逆アセンブルすることができ、バイトコード命令が最後のキャッチされなかった例外を投げるので、適切なフィードバックを与えてくれます。
ですから、テストをQA作業の最後に置くのではなく、優れた分析ツールを活用し、間違いを示すことを恐れないでください！
--サラ・マウント
6.友人とUbuntu哲学
ですから、多くの場合、コードは独立して書かれ、そのコードには問題に対する個人の理解や非常に個人的な解決策が反映されます。それはチームの一部かもしれませんが、チームである以上、独立したものであることに変わりはありません。独立して書かれたコードが、他の人によって実行され、使用され、拡張され、信頼されることを忘れがちです。これが、見落とされがちなソフトウェア開発の社会的側面です。ソフトウェアの作成は、技術的な活動と社会的な活動のミックスです。開発チームだけでなく、全員が個人的な成功の可能性を高める責任を負っているのです。
禅は個人のためのものです。人々のグループにとって、Ubuntuも一種の禅です。自分のためだけに書かれたコードを見ることは、ほとんど不可能です。
--アスラム・カーン
7.あなたはコードを気にする必要があります
シャーロック・ホームズでなくとも、良いプログラマーは良いコードを書きます。悪いプログラマーは...そうではありません。ゴミを作り出し、それを掃除しなければならないのです。いいものを書きたいんでしょ？それなら、良いプログラマーになろうとするのは当然です。
偉大なコードは無からは生まれません。惑星直列のような運では生まれません。素晴らしいコードを得るためには、そのために努力しなければなりません。ちょっとした努力です。もし本当に素晴らしいコードを書こうと思えば、素晴らしいコードを書くことができるでしょう。
優れたプログラミングは、技術的な能力だけから生まれるものではありません。私は、非常に素晴らしいアルゴリズムを書くことができ、プログラミング言語の標準を暗記している、非常に高いレベルのプログラマーを見てきました。このコードは読むのも、使うのも、修正するのも苦痛です。また、もっとシンプルなコードを書くことにこだわり、非常にエレガントで表現力豊かなプログラムを書く、一緒に仕事をするのが単純に楽しい、もっと謙虚なプログラマーにも会ったことがあります。
ソフトウェア業界での長年の経験から、平均的なプログラマーと優れたプログラマーの本当の違いは「姿勢」であるという結論に達しました。優れたプログラマーは、プロフェッショナルなアプローチを用い、現実世界の制約やソフトウェア業界のプレッシャーの中で、可能な限り最高のソフトウェアを書こうとします。
コードには良い計画が必要です。偉大なプログラマーになるためには、良い計画を立て、コードを本当に大切にしなければなりません。優れたコードは、熟練した職人によって作られるものであり、決して湖のようなプログラマーや自称コーディングの達人によって、何の考えもなしに作られるものではありません。
--ピート・グッドリフ
