プログラマが知るべき97のこと
ネットでただで見れる…
良い時代になったものですね🐶三🐶
僕が感銘をうけたものを抜粋して
載せておきますmm
１．分別のある行動
技術的負債は、借金です。
短期的には利益になりますが、
完済するまで利息を払い続けなくてはなりません。
早くできるからと手を抜いてコードを書くと、
機能追加やコードのリファクタリングが難しくなります。
新たな不具合を生む温床となり、
テストケースの価値を損なう原因にもなります。
3.ユーザが何をするかを観察する（あなたはユーザではない）
ユーザの身になって考えるということがなかなか出来ないプログラマが多い
ユーザはプログラマのようには物を考えません。
そもそも、プログラマに比べてコンピューターを使う時間が圧倒的に少ないのです。また、コンピューターが中でどう動いてるのかを知らないし、知りたいとも思いません。
プログラマなら日頃から当然のように馴染んでいる
「問題解決のテクニック」 がいろいろありますが、
それに頼ることもできません。
観察していて最初に気づくのは、おそらく「ユーザは基本的にだいたい同じようなことをする」ということでしょう。作業を進める順序も、どこで間違えるかも、ほぼ同じなのです。
つまりソフトウェアは、こういったユーザの基本的な振る舞いを踏まえて設計する必要があるということです。これは、会議室で「ユーザは多分、こうするから・・・」などと想像で話し合うのとは全く違います。単なる想像を基話し合っていても、ユーザが何を求めているか、明確なことは何もわからず、結局複雑で使いづらいものが出来てしまうでしょう。
ユーザを直接観察すれば、
それを防ぐことができるのです。
4.美はシンプルさに宿る
1つのプラトンの言葉を引用します。
ソフトウェア開発に携わる人ならばぜひ知っておくべき言葉、
常に心に留めておくべき言葉だと思います。
「文章にしろ、和音にしろ、リズムにしろ、美しく、優雅なもの優れたものはすべて、シンプルである」
この言葉には、ソフトウェア開発において大事にすべきことが見事に要約されていると思います。
プログラマがコードを書くときに留意すべきことはいくつかありますが、まとめればだいたい次のようになるでしょう。
可読性
保守性
開発効率
(言葉で表現するのが難しい)美しさ
プラトンの言葉が教えてくれるのは
、シンプルであることを心がければ、
上のすべてが達成されるということです。
29.DRY原則
重複は無駄
作業の重複は自動で防ぐ
ロジックの重複は抽象化で防ぐ
36.ハードワークは報われない
神経を集中させる時間、製品を産み出すのに使う時間が
週に30時間を超えるようなら「自分は働き過ぎだ」 と考えるべきでしょう。
自分のかけている労力を減らすことを検討する必要があります。
もっと効率的に働く方法、少ない労力と時間で多くを生み出す方法を探さなくてはならないということです
自分の仕事にどんな無駄があるかを常に観察し、
その結果を後の仕事に反映させていけば、着実な効率化がはかれます。
仕事には長い時間を書けず、
集中して短い時間で終わらせるように心がける。
より効率的な問題解決方法を探す努力を常にする。
プロジェクトに貢献するというのはそういうことです。
技術力を向上させ、自分の行動パターンを振り返り、改善に努めることも、プロジェクトにとってプラスになるでしょう。決しで、ケージの中のハムスターのように、ただその場で車輪を回転させているだけ、というような仕事をすべきではありません。そんなことをすれば、自分自身とプログラマという職業を貶めることになります。プロのプログラマが週60時間、ずっと神経を集中させてひたすらコードを書き続けるというのは、とても賢明なこととは言えないでしょう。プロはただ、がむしゃらに働けばいいというものではありません。
プロの仕事には、
入念な準備と効率化のための努力、
そして日々の反省と絶え間ない変化が必要なのです。
４６．すべきことは常に明確に
大事なのは「いつの間にか手探り状態になっていた」ということを絶対に避けるということ
６４．プロのプログラマとは？
「自分が責任を取る」
１．キャリアに責任を持つというのは、自分の力で自分の価値を高め、成長していくということ
自分の意志で新たな知識と技術を習得し、常に最先端にいられる努力をするもの
２．プロのプログラマは、自分の書いたコードに責任を持ちます。間違いなく正しく動くと確認できるまではリリースをしません。正しく動くかどうか確信のないコードをリリースしてしまう人をプロとは呼べません
３．プロのプログラマはチームプレイヤーです。一人一人が自分の仕事だけでなく、チーム全体のアウトプットに責任を持ちます。互いに助け合い、互いに学び合い、足りないところは補い合います。チームメイトが何か失敗したときには、誰かがカバーします。いつか必ず自分が逆にカバーしてもらうことになると知っているのです。
４．プロのプログラマは、絶対に、間に合わせのいい加減な仕事はしません。自分の誇りにかけて、美しく、完壁な製品を作ろうとします。余分な部分のない「きれいな」コード、構造化されたコード、読みやすいコードを書くよう常にこころがけます。業界標準やベストプラクティスは確実に守ります。決してあわてて仕事に取り組むようなことはありません
プロであるということは、責任を負うということです。
自分のキャリアにも、製品の質にも責任を負います。
製品の質に責任を負うということは、無駄がなく、動作も正しいコードを常に書き続けるということです。たとえ納期に追われて余裕がなくなった時でも、決して手を披くことなく、最善の努力を尽くして良い製品を作るということです。
72.シンプルさは捨てることによって得られる
確かに既存のコードの質が良ければ、作り直しより修正が楽だとは言えますが、質の悪い既存コードは、あっても何の役に立たないことが多いのです。
役に立たないどころか、既存のひどいコードを無理に残そうした結果、かえって余計な手間がかかってしまうということもあります。ある程度以下の質のコードは、活かそうとはせず、即座に破棄してしまった方が得策と言えます。
コードはシンプルなものであるべきです。変数や関数、宣言といった構成要素はできる限り減らすべきです。余分な行、余分な変数…、ともかく余分なものが少しでもあれば、即座に消す
残るべきは、アルゴリズムを完成させ、必要な演算をすべて処理するための、必要最小限の要素だけ
７５．面倒でも自動化できることは自動化する
７９．テストのないソフトウェア開発はあり得ない
テストは、ソフトウェアの品質、再現性を保証するためにどうしても必要なものなのです。それがわかっていれば「テストなんでしていられない」と言うプログラマに対し、「それは無責任だ」と反論することができるでしょう。
テストにもやはり時間がかかります。
しかし、どちらも最終的な成果物の質を一定以上に保つためにすることです。
ソフトウェアを開発する者にとって、テストをするということは、
作るものに責任を持つということなのです。
テストをしさえすればそれで十分ということはないですが、まずテストをしないことには話になりません。
テストは、ソフトウェア開発の中でも特に難しく、そして重要な部分と言っていいでしょう。
８０．1人より2人
プログラマはもはや、技術が優れているだけでは十分でないということです。
他人との連携でより大きな成果が上げられるようでなくてはならないです。
ペアプログラミングは、協力の究極のかたちと言ってもいいでしょう。
ペアプログラミングの利点は、プログラマとしてのスキルが確実に向上するということです。
プログラミングの技術、あるいは問題領域についての知識が自分より上の人と組んだ場合には、間違いなくその人から多くのことを学べます。逆に自分の方が上だった場合も、パートナーに説明しなくてはならないので、すでに知っていたことをさらに詳しく学ぶことになります。その過程で、今まで知らなかったことも多く学ぶはずです。必ず両者がお互いから何かを学ぶことができるのです。
当然、知識や経験が下の人間は、
ペアを組むことで急速に力をつけることになります。
ペアプログラミングのパートナーから、今まで知らなかったキーボードショートカットを教わったとして、それによって得られる長期的な利益はどのくらいでしょうか?
ペアを組むことによって、ソフトウェアの品質は全体としてどのくらい向上するでしょうか。
それを評価する方法はあるでしょうか。
難しい問題に直面した時も、2人であれば行き詰まらずに解決できることが多いですが、その効果が具体的にどのくらいか知ることはできるでしょうか。
ある調査によれば、ペアプログラミングには、生産性、作業速度を40%向上させる効果があるという結果が得られています。ただし、効果を定量的に評価することは難しいようです。
９１良いプログラマになるには
良いコードは何の根拠もなく勝手に生まれたりはしません
良いコードを書きたいと心の底から願い、努力をした人だけが本当に良いコードを書ける
良いプログラマの姿勢は、プロフェッショナルという言葉にふさわしいものです。常に、最大限の力を尽くして良いコードを書こうとします。リソースの制約のある中、早く作業を終わらせろと会社が圧力をかけてくる中、それでもできる限り良いコードを書こうと努力をするのです。
・どんな場合でも、「とりあえず動きそう」というだけのコードは決して書かない。誰が見ても間違いなく正しいとわかる、美しいコードを書くよう常に心がける(コードの正しさを確実に証明できるテストも書く)。
・他のプログラマと協調する。プログラマは孤立した存在ではなし、1人だけで仕事をするプログラマはほとんどいない。大半の仕事はチームで進められる。企業での開発プロジェクトの場合も、オープンソースプロジェクトの場合もあるが、いずれにしてもチームでの仕事であることに変わりはない。常に他のプログラマの存在を意識し、他人が読みやすいコードを書くよう心がける。自分の優秀きを見せつけることでなく、チーム全体の成果を最良にすることを考える
・絶えず積極的に新しい言語、イディオム、テクニックを学ぶ。ただし、学んだことをむやみには使わない。適切と判断した場合にのみ使う。
ここに書いてあることに興味を持ち、最後まで読んだ人はおそらく、プログラミングが好きで、良いプログラマになりたいという熱意を持った人でしょう。
92 顧客の言葉はそのまま受け取らない
自分の希望を伝えるのを嫌がる顧客はまずいない
尋ねれば、詳しく希望を話してくれます。問題は、顧客がいつも本当のことを言うとは限らないということ
顧客には早い段階から、頻繁に疑問を投げかけ、説明を求めるように
→ 「顧客から言われたことを、言葉を換えて言い直す」 ということ
彼らは決して自分の希望を正確に言葉にしているわけではない、というのを常に忘れないように
話し合う際には、図や絵などを利用することも大切でしょう。ホワイトボードに簡単な図を描くだけでもずいぶん違います。
１０１プログラマが持つべき3つのスキル
(1)コードを読むスキル
(2)テストをするスキル
(3)デバッグをするスキル
理想的には、職場に師匠となる人をみつけてその人の弟子になることです。
１０２．快適な環境を追求する
身の回りの環境を改善することで、毎回の作業が効率よくなり、時間を有効に活用できるようになり、快適にコーディングすることが出来るようになります。
快適な環境を追求するにはちょっとした時間の投資が必要になりますが、この投資は決して無駄にはならないでしょう。
プログラムをリファクタリングし、より抽象化され高速な、バグのないコードを生み出すことに集中することも大切なことです。新しい言語やプログラミング手法を取り入れ、プログラマとしてスキルアップすることももちろん大切なことです。
ですが、ちょっと時間を割いて快適な環境づくりを行うことで、コーディングするための時間をより快適に過ごすことができるようになります。
それは一生のうち、
かなりの時間が快適になることを意味するのです。
さあ、あなたも快適な環境を作ることにどん欲になりましょう。
１０６．Noといえることの大事さ
ソフトウェアのデザインにおける究極の美しさはシンプルさにあると言われます。
有名なUNIX哲学では”Write program that do one thing and do it well”(1つのことをうまくやるプログラムを書け)といわれるように、複数の機能をつめ込まず、単一の機能をもったプログラムを組み合わせて使うことが美とされます。
ソフトウェアが人気になり、ユーザが増えるにつれ、「あの機能を追加してくれ」「ここの動作をオプションでOn/Offできるようにしてくれ」という要望が出てきます。実際にそうした機能やオプションが欲しいとおもっているのは、ごく一部であるにもかかわらず、声の大きいユーザからの要望を無視することができず、忠実に応えようとするあまり、あなたはそれをすべて実装してしまいます。ユーザからのフィードパックはうれしいものですからね。
はじめて公開したソフトウェアで特におこりがちなことです。
こうしてあなたのソフトウェアは、ほとんどのユーザが使わないようなニッチな機能と、それを有効にするための複雑怪奇な設定画面または設定ファイルが必要になり、またそれによってメンテナンスがしづらく、バグのでやすいソフトウェアになってしまいました。こうしたソフトウェアはFeature Creep(creep: いつの間にか忍び寄る、からみつく)よばれ、ソフトウェアが破滅に向かう第一歩(あるいはもう手遅れ)の状態になっているといえます。
こうした悲劇を避けるポイントはただひとつ、そうした要望に「No」といえる勇気です。ソフトウェアのコアではないもの、他のソフトウェアと組み合わせて実装できるものに関しては、明確にNoといえることが、結果としてよいデザインやシンプルさを達成する原動力になります。
Discussion