読者です 読者をやめる 読者になる 読者になる

PHPと自動化が好きなんだい

アラサー未経験でPHPを覚えて、自動化にハマったWebプログラマー。主にWebネタ、MySQL、Linux、Apacheをやるよ

「プログラマを知るべき97のこと」が長すぎるので要約してみた。

プログラミング、アルゴリズム、サンプルプログラム Webプログラマーの年収、実態、どうやったらなれる?

どうも、yohyamaです。

 

プログラマが知るべき97のこと」が良書らしいということを聞いたので、読んでみました。

なんと、今ならWeb上で無料で公開しています。

元々の文章が長いので、エッセンスだけを要約しました。

 

a0001_014898

 

[01] 分別のある行動

  • 正しくやる方法と素早くやる方法がある。
  • 素早くやる方法は魅力的だが、あとあとで技術的なトラブルの原因になったりするので、スケジュール等を決めて早めに対処しよう。

 

[02] 関数型プログラミングを学ぶことの重要性

 

[03] ユーザが何をするかを観察する(あなたはユーザではない)

  • 「ユーザが何をしたいか」は考えるよりも、観察すれば分かるぜ!

 

[04] コーディング規約を自動化する

  • コーディング規約は自動化しよう!
  • また、プロジェクトに応じて規約は変化させましょう。

 

[05] 美はシンプルさに宿る

  • コードはシンプルが一番。

 

[06] リファクタリングの際に注意すべきこと

  • リファクタリングする際は既存のコードとテストコードを洗いなおそう。
  • ゼロから書くのは辞めて既存のコードを出来るだけ活かそう
  • 大幅な変更ではなく少しずつ変更しよう。
  • 既存のテストが通るか必ず確認しよう
  • 個人の好みでコードを直すことは辞めよう。
  • 古い技術である、という理由だけでリファクタリングするのはやめよう。
  • ミスは付き物。

 

[07] 共有は慎重に

  • システム全体の構造をしっかりと理解したうえで、ライブラリ化しよう。
  • 理解していないのにライブラリ化すると、変な依存関係が出来てしまって、テストが大変になったよ。

 

[08] ボーイスカウト・ルール

  • コードをキレイにすることを心がけよう。

 

[09] 他人よりまず自分を疑う

  • 問題が起きたときは真っ先に自分の書いたコードを疑おう。

 

[10] ツールの選択は慎重に

  • 前提条件、ライフサイクル、設定作業など、色々なことを考慮してツールを選ぼう。

 

[11] ドメインの言葉を使ったコード

  • コードが何を表現しているのかは、できるかぎりひと目で分かるようにしておくべき。

 

[12] コードは設計である

  • 設計は大事。
  • 設計が出来る人間を育てるためには多大な努力が必要。

 

[13] コードレイアウトの重要性

  • プログラマはコードを読んで理解する時間が多い。
  • 読む作業を効率化するためレイアウト工夫したよ。

 

[14] コードレビュー

  • コードレビューの目的はチーム全員の知識、ガイドラインの共有。
  • レビュー中は友好的な態度を取ろう。
  • 曜日を決めて毎週実施しよう。
  • 楽しくするよりも、昼食やお菓子を食べながら砕けた雰囲気でレビューをしよう。

 

[15] コードの論理的検証

  • コードが論理的に妥当かどうか検証しよう。
  • 内容について検証することにして、話し合いをすることでより理解を深めることが出来ます。

 

[16] コメントについてのコメント

  • コードは、次に見る人がすぐに理解できるように書く
  • 必要で十分な量のコメントを、適切な場所に入れること。
  • 「このコードで何がしたいのか」を読む人にわかってもらうが大事。

 

[17] コードに書けないことのみをコメントにする

  • コメントに「書かなくてよいこと」を見極める。
  • メソッドやクラスの名前がわかりにくいなら、名前を変えよう。
  • 関数が長くて分かりにくいなら、分割しよう。
  • コードに「書けないこと」のみをコメントにしよう。

 

[18] 学び続ける姿勢

  • 書籍や雑誌、ブログ、Twitterや各種のWebサイト、メーリングリストニュースグループ、カンファレンス、コミュニティ、ユーザグループ、ポッドキャスティングから情報を得よう。
  • 本当に身につけたい技術は、手を動かして学ぶ。
  • 常に自分よりレベルの高い人と仕事をするようにする。
  • レベルの高い人が周囲にいないなら、転職しよう。
  • 自分の「良き師」になり得る人をネット上で探す
  • 自分の利用しているフレームワークやライブラリに対する知識を深める。デバッガを使ってコードを逐一確認し、中でどういうことが行われているのか見ていこう。
  • 何か問題を発見した場合は、より深いレベルで理解するようにしよう。
  • 自分が学びたいことを人に教えたり、話したりすることは非常に有効である。
  • 自分のコードベースに対して静的分析ツールを実行する。あるいは、IDE使用中に警告が出される場合には、それについてよく調べる。ツールのレポートや、IDEの警告の内容を詳しく分析し、なぜ、このようなレポート、警告になったのか、その理由を追及する。
  • 「達人プログラマ」を読んで実践しよう。
  • コンピュータ関連技術でなくても、業務知識について学ぶことも大事。
  • 自分の生産性を高める方法も学ぼう。

 

[19] 誰にとっての「利便性」か

  • たとえ同じことを何度も繰り返し言っていて、一語にまとめられれば便利だと思っても、それはしないほうが賢明。

 

[20] すばやくデプロイ、こまめにデプロイ

  • くデプロイ作業を早い段階から始めるべきでしょう。その方がコストが少なくて済む。

 

[21] 技術的例外とビジネス例外を明確に区別する

  • 「技術的例外」と「ビジネス例外」を別な例外階層構造で扱うべし。

 

[22] 1万時間の訓練

  • 新しいことを学んで自分を変えよう。
  • 専門的な技術や知識は、ゆっくりと徐々に身につくものなので、ともかく1万時間努力してみよう。

[23] ドメイン特化言語

  • DSLを作るときは、使う人が誰かということを常に考慮にいれておく必要がある。

 

[24] 変更を恐れない

  • コードに変更を加えることを恐れず、積極的にシステムを改良していく姿勢が大事。
  • その姿勢で延び延びになっていた改良プロジェクトが実施に移されるということがあるかもしれないし、またはチームメンバーの意識を高めることに繋がる。
  • 結果的に、システムの質向上につながる。

 

[25] 見られて恥ずかしいデータは使わないこと

  • コード、テストデータに何か入力する時は「これがもし公になったとして問題にならないか」と自問しよう。

 

 

[26] 言語だけでなく文化も学ぶ

  • 言語にはその言語独自の文化というものがあり、真にその言語を知るには、その文化も正しく学ぶ必要がある
  • 複数の言語について学ぶと、デザインパターンについての理解も深まります
  • 新しい言語から新たな発想を得て、同じ問題に対して違った解決策を見つけられるようになることが大事なのです。
  • 従来から使っていた言語でも、より美しいコードが書けるようになることが多いのです。

 

[27] 死ぬはずのプログラムを無理に生かしておいてはいけない

  • 時には例外を潰さないことも重要?

 

[28] 「魔法」に頼りすぎてはいけない

  • 自身が開発を経験していないマネージャは、プログラマの仕事を簡単だと思いがち。
  • 逆にマネージメントの経験のないプログラマは、マネージャの仕事を簡単だと思い込んでしまいがち
  • プロジェクトに関わるすべての人の仕事を詳しく知る必要はないが、たとえその一部でも、知ろうとして損はない
  • 自分の知らない仕事、自分の直接関わっていない仕事をしている人を尊重するということが大事

 

[29] DRY原則

  • DRY原則は、アプリケーションのソースコードだけでなく、開発作業にも適用すべき
  • 可能な限り、テストは自動化すべき
  • ロジックの重複はデザインパターンなどで抽象化して防ぐ
  • ただし、現実にすでに目の前にある問題に対処する以外の目的で、DRY原則を破ってはなりません。
  • 「こういう問題が起きそうだから原則をあらかじめ破っておこう」ということをしてはいけない

 

[30] そのコードに触れてはならない!

  • どんなことがあっても、開発者は本番環境に触れてはならない。
  • 問題が起きた場合でも、それを修正するのは基本的に運用チームの仕事であり、仮に開発者が修正にあたるにしても、それは運用チームからの依頼であるべき

 

[31] 状態だけでなく「ふるまい」もカプセル化する

 

[32] 浮動小数点数は実数ではない

  • 浮動小数点数を使うときは、どういう時に丸めの誤差が出るかをよく知り、その知識を踏まえた上でコーディングをすべき。

 

[33] オープンソースプロジェクトで夢を実現する

  • オーブンソースは、やる気のあるプログラマにとっては、大きなチャンスを与えてくれるもの
  • 他人の作ったソフトウェアについて学ぶのに、テストコードを書くほど効果的な方法は無いのです。

[34] API設計の黄金律

 

[35] 超人の神話

  • どれほど素晴らしいプログラマであっても、はじめから十分な知識と技術を持っていたわけではありません。最初はごく普通の人だったはずです。今は超人に見えるかもしれませんが、それは長い時間をかけて学び、自分を磨いてきたからです。

 

[36] ハードワークは報われない

  • プロはただ、がむしゃらに働けばいいというものではありません。プロの仕事には、入念な準備と効率化のための努力、そして日々の反省と絶え間ない変化が必要なのです。

 

[37] バグレポートの使い方

  • バグレポートは、決して誰かを責めたり、バグが存在するコードを批判したりするためのものではありません。バグについて、より多くの情報を得ること、自分の知らなかったことを知ること

 

[38] 余分なコードは決して書かない

  • そもそもなぜ、不要なはずのコードが書かれたのでしょうか? あとで余分と判断されたとはいえ、プログラマはその時必要だと思ったからそのコードを書いたわけですが、なぜそう思ったのでしょうか。またレビューやペア作業で見過ごされたのはなぜでしょうか?それはおそらく、次のような理由ではないかと考えられます。
  • 余計かもしれないが、面白そうだと思えた(ヒント:「面白い」というのはコードを書く理由にはならない。コードベースに新たな価値を加え得るコードのみを書くこと)
  • 将来必要になるかもしれないと思った。そのためにはいま書くのがベストだと思った(ヒント:これはYAGNIに反していることになる。いま不要なら、いま書くべきではない)
  • 必裂かどうか判断に迷った。顧客に判断を仰ぐべきだったが、それよよりも実装してしまう方が簡単たと思った(ヒント:余計なコードを書くにはその分、手間と時間を要し、また保守にも手間と時間を要することになる。実際には顧客に確認をとった方が簡単なはず。余分なコードを加えてしまえば、保守にかかる手間と時間は「雪だるま式」に増えることになる)
  • 余分な機能を正当化するため、議論を経ておらず、ドキュメントにも書かれていない要件をプログラマがでっちあげた(ヒント:要件を決めるのは顧客であってプログラマが要件を決めてはいけない)
  • 常に考える必要があるのです。いま自分が書いているコードは本当に必要なものなのか、と。

 

[39] 最初が肝心

  • 人が何かをする時には、費用対効果が非常に大切な要素になります。皆自分の中に基準があって、費用対効果がその基準を上回りそうな行動は取りますが、基準以下と判断した行動は普通取りません。どんなに有用なものがあっても、それを使うのに手間がかかりすぎると判断すれば、他のもっと手間のかからないものを探すでしょう。

[40] プロセス間通信とアプリケーションの応答時間の関係

  • アプリケーションの設計にあたっては、入力への応答に必要なIPCの数が多くならないよう配慮すべきでしょう。

[41] 無駄な警告を排除する

  • ノイズが数百にも及ぶようになると、その中から本当にすぐ対応しなくてはならないものを見つけるのは困難ですつまり、警告が本来の役割を果たさなくなってしまうのです。
  • ビルドで余計な警告が出る度、それを即座につぶすということを続けていれば、「これは意味のある警告か否か」ということを逐一判断する必要がなくなります。

[42] コマンドラインツールを使う

  • コマンドラインのビルドツールで仕事をすれば、ビルド時に具体的にどういうことが行われるのかを詳しく知ることができます。
  • DEは開発作業を簡単にし、プログラマの生産性を向上させるために存在するということです。私は何も「IDE を使うな」、と言っているわけではありません。私が言いたいのは、「IDEが裏でしていることをよく見て理解しよう」ということです。そのためには、コマンドラインツールを使ってみるのが最普の方法であるというわけです。

[43] プログラミング言語は複数習得すべき

何年プログラミングを経験しようとも、ずっと同じ言語だけを使い、1つの言語しか知らないプログラマは、その言語の枠の中でしかものを考えられなくなってしまいます。

  • 第二の言語には、是非とも、最初の言語とはパラダイムの違う言語を選ぶべきです。アルゴリズム、イディオム、パターンの実装について嫌でも考えるようになるからですプログラマは少なくとも2つのパラダイムの言語を使いこなせるようになるべき

[44] IDEを知る

IDEは今やプログラマにとってのプロートーチかもしれません。今後は、IDEをどう使えば生産性を上げられるか、時間をかけて学んでいくべきでしょう。

[45] 限界を知る

[46] すべきことは常に明確に

  • 大事なのは、常に自分が何をすべきかを明確にするということです。完了する期限も必ず決めます。もし、期限内に予定の作業が終わらないようであれば、その間に書いたコード、コードに加えた変更はすべて破棄します。再度、小目標を立て直して作業内容を検討し、はじめからやり直すのです。次に何をすればいいかがすぐにわからない時は、やはりあれこれと模索するのですが、大事なのは「いつの間にか手探り状態になっていた」ということを絶対に避けるということです。

[47] 大量のデータはデータベースで

アプリケーションで大量の永続データを扱う必要がある場合やデータが相互に関係し合う場合は、迷うことなくリレーショナルデータベース(RDBMS)にデータを保存すべき

[48] いろいろな言葉を学ぶ

  • ソフトウェア開発に関わるのは、コンピュータとプロジェクトチームのメンバーだけではありません。他にも多くの人が関わります。その中には、同じ社内にいてもプログラムのコードは書かないという人もいれば、社外の人もいます。自分の仕事については知っていても、コンピュータについては知識がない人も大勢いるでしょう。そういう人たちとのコミュニケーションもやはり重要です。
  • 大事なのは自分が話すこと以上に、相手の話に耳を傾けることです。言葉にならない言葉の存在を知ることが大事なのです。

[49] 見積りとは何か

  • まず知らなくてはならないのは「見積りとは何か」そして「見積り結果はどう利用すべきか」というごく基本的なことです。
  • 見積りは、あくまで概算、おおまかな判断なので、ある程度以上の正確さは期待できません。見積りを求められた時には必ず、相手が「見積り」「ターゲット」「コミットメント」という言葉の意味を正しく認識しているかを確認すべきです。

[50] Hello, Worldから始めよう

(読解中)

 

 

[51] プロジェクト自身にしゃべらせる

コードメトリクスの結果は自動で通知されるような仕組みを作ろう。

 

[52] 「その場しのぎ」が長生きしてしまう

いったん暫定ソリューションができてしまうと既成事実化してしまう。早くシステムに統合すべきだが、重要な仕事は他にもたくさんあるので、どうしても後回しになりがち。

この状況を変える最善の方法は、暫定ソリューションに修正を加えるのではなく、不要にしてしまうこと。後から改めて、より優れたソリユーション、より有用性の高いソリューションを作ること。

 

[53] 正しい使い方を簡単に、誤った使い方を困難に

良いインターフェースを作る方法は二つある。1つは、ユーザがしそうな間違いを事前に予測し、それを防止する策を講じること。もう1つは、リリース後の早い時期に実際にインタフェースがどのように誤用されるかを観察し、改良を加えること。

 

[54] 見えないものを見えるように

人間は目に見えるもの、具体的なかたちのあるものについてはよく考えますが、そうでないものについてはあまり考えない傾向にあるのです。

ソフトウェア開発プロジェクトを進める際はいつでも、目に見える証拠がたくさんあるという状態を維持すべきでしょう。目に見える証拠があれば、進捗状況も正確に把握できます。決して頭の中だけの思い込みで判断はしなくなります。

 

[55] 並行処理に有効なメッセージパッシング

共有メモリを使わずメッセージパッシングを使ってプログラミングをすることが、現在のコンピュータハードウェアにはどうしても必要な並行/並列処理にとって最も有効な方法だ

 

[56] 未来へのメッセージ

「自分の書くコードは、全部、未来の誰かへのメッセージだと思うのよ。その誰かは、あなたの弟さんかもしれない。誰か、とても賢い人に、自分が難しい問題をどう解いたのか、丁寧に説明するつもりで書くの」

 

[57] ポリモーフィズムの利用機会を見逃さない

ポリモーフイズムを利用する方が、コードが読みやすく、またバグも少なくなる可能性が高いのです。コードの中に今、if-then-elseブロックになっている箇所があるのなら、そのすべてについてポリモーフイズムが使えないか検討した方が良い

 

[58] テスト担当者はプログラマの友人

テスト担当者たちは、プログラマの敵ではなく「友人」であると私は言いたいです。彼らは、取るに足りないと思えるような問題を逐一指摘してくるかもしれません。それで「恥をかかされた」と思う人もいるでしょう。しかし、些細に思える問題でも解決しておけば、顧客はその問題に煩わされずに済みます。そうすれば、あなたは恥をかくどころか、顧客から高く評価されるでしょう。素晴らしいことではないでしょうかそれはテスト担当者が問題を見つけてくれたからこそ、できたことなのです。

 

 

 ----<続きは随時更新>---