投稿元:
レビューを見る
『プログラミングに於いて最も大事なことは何か』というテーマで、世界の著名なプログラマ達が各々の持論を説いている本。
殆どの項目が見開き1ページで完結しており、読みやすいと思う。
内容も、興味深いものが多く丁寧に訳してあるので分かりやすい。
内容で特に印象に残っているのは
・複数の言語を勉強しよう。
・統合開発環境に頼り過ぎないようにしよう。
・名前重要。
投稿元:
レビューを見る
世界の著名なプログラマが1ページ〜2ページで各々が一番伝えたいことを簡潔に述べた本。1つ1つが短く、ちょっとした時間でも読めることが出来て、その1つ1つ非常にためになる話の連続。日本人プログラマによるボーナストラックも良いです。1度は読みたい良書。
投稿元:
レビューを見る
まつもとひろゆきさんの
「名前重要」のエッセーが収穫といったところか。
Rubyは名前がよかったから成功した。
たしかにな。いい名前だ。
自分もシステム構築するときにサーバの名前何にするかで
かなり悩むもんな。
名前重要。
投稿元:
レビューを見る
テーマが多岐にわたる、かつ整理されてないので、頭から順に読むのではなく目次を眺めて「これだっ!」てのを読んでみるといいかも。
内容も初心者にも分かりやすいものから、かなり専門的なものまで多種多様。折りにふれ読み返したい1冊ではある。
投稿元:
レビューを見る
様々な有名プログラマのアドバイスを読むことができる本。1つのコラムが2〜3ページで非常に読みやすい。全員が個別に書いたアドバイスで似たような内容がいくつも登場することから、ソフトウェア開発で大切だと言われることはやはり守るべきであるという事がよく理解できる1冊。
投稿元:
レビューを見る
著名プログラマー達による格言集。一つひとつの内容は他の書籍等で見かけるような内容が多いですが、各プログラマの顔写真と巻末のプロフィール付きということもあり、各格言の背景も透けて見えるのがいいです。
投稿元:
レビューを見る
2年とちょっとぶりの再読。リーダブルコードがコードの書き方に焦点を絞ってよい習慣を語っているとすると、こちらはそれをもう少し広げてプログラマとして技術を磨いたり、チームで上手く仕事をするためのよい習慣を集めたもの、とでも言おうか。すぐにでも取り入れられそうなものから、長い時間をかけて次第に身に付いてくるようなものまで97+10個あるので、たまに読み返してプログラマとしての居住まいを正すために使いたい本。
投稿元:
レビューを見る
「プログラマが知るべき97のこと」からの7つのこと - まほろば技術パーク
http://komeshogun.hatenablog.jp/entry/20141101/1414796516
投稿元:
レビューを見る
耳が痛くなる言葉も、
そうでない言葉もがたくさんありました。
あらためて、当たり前のことを当たり前にやるのは、
本当に難しいことだと感じました。
もっと覚えなくてならないこと、
もっと学ばなくてはならないこと、
もっと経験しなくてはならないことが、
たくさんあると思いました。
できてないと感じたのならやれば良くて、
できてないと感じれたことが、
今の自分の一歩目なのだと思いました。
ざ きのこ本。
(以下抜粋。○:完全抜粋、●:簡略抜粋)
○壊れていないものを直すのは無意味です。(P.13)
○たとえコードが4行ほどのもので、
行っていることが同じだったとしても、
それはたまたま一時的にそうなっていただけのことです。(P.14)
○コードレビューを成功させるためにもっとも有効な方法は、
レビューを楽しいものにすることです。(P.29)
○関数はできる限り短くし、機能は1つに絞り込む。
古くから言われる「24行制限」は今も有効である。(P.31)
○英語には、
たとえば「Make up your room, be quiet and do your homework」ということを
一語で伝えれるような単語はないのです。(P.39)
●デザインパターンの多くは明らかにアプリケーションの中の重複を減らす、
あるいは排除することを目的としています。
オブジェクトの使用する条件がいつも同じであれば、Abstarct Factory、Factory Methodパターンを、
オブジェクトのふるまいに種類があるのであれば、Stategyパターンを使用します。(P.59)
●金融関係のアプリケーションには浮動小数点数を使うべきではないということも書いておくべきでしょう。
(中略)
浮動小数点数は、元々、科学技術計算を効率的に行うことを目的としたものです。
●YANGI(You Ain't Gonna Need It:それはたぶん必要ない)
余計かもしれないがおもしそうだと思えた。
将来必要になるかもしれないと思った。
必要かどうか判断に迷った。
常に考える必要があるのです。いま自分が書いているコードは本当に必要なものなのか。(P.76-77)
●プログラミング言語のパラダイムは大きく、
手続き型、オブジェクト指向型、関数型、論理型、データフロー型などに分類することができます。
(中略)
ある問題を解決するのに、
言語Aではこのイディオムを使用するが、
言語Bで同じイディオムは使えないというような体験が重要なのです。
(中略)
最も顕著な効用は、
1つのパラダイムしか知らなければ思いつかないような表現を
使用することができるということです。(P.86-87)
○find . -name "*.java" | sed 's/.*\/// | sort | uniq -c | grep -v "~ *1 " | sort -r(P.89)
○Shippingクラスのshipメソッドを呼び出す仕事をItemクラスに委譲しています。(P.115)
○ある問題について十分に考えたら、あとは音楽を聴くなり、散歩をするなりして、
脳の創造を司る部分をはたらかせてみてください。
じっとコンピュータの前に座って考え込んでいるより、
その方が良いアイディアを思いつくものです。(P.133)
○プログラミングの技術を本気で磨きたいと思っているのなら、本を読むのもいいですが、
一番いいのは、他人が書いたものでも自分が書いたものでも、
とにかくコードを読むことです。
○スモール・イズ・ビューティフル(P.167)
○いつ、何を、どのように再利用すべきかがわからなければ、良い結果にはなりません。
それをわかるためには、問題領域について、またアルゴリズムとデータ構造について、
十分な知識が必要なのです。(P.169)
○1つの機能の実装が10個存在するのは、WETなシステムであるといえます。
もしDRY原則に従ってシステムが作られていれば、機能XがCPUを30%消費している事実にすぐに発見できる上、
修正するコードも1/10で済むでしょう。
そもそも、10の実装をすべて見つけ出すための時間も手間も必要ありません。(P.172)
○良いテストの条件を簡単にまとめると次のようになるでしょう。(P.180)
・コンテキスト、出発点、満たすべき前提条件がわかる。
・ソフトウェアがどのように起動されるかがわかる。
・期待される結果と、確認すべき事後条件がわかる。
●プログラマが持っておくべきすきるを3つあげるとすれば、
(1)コードを読むスキル
(2)テストをするスキル
(3)デバッグをするスキル
だと考えます。
そして、このスキルはインターネットの情報を読むだけでは身につきません。
野球のルールを知っていたとしても、誰もが上手にヒットを打つことが出来ないのです。
いいバッターになるには、正しいトレーニングをして、試合で経験を積むしかないのです。(P.208)
投稿元:
レビューを見る
色々な意見があるが、今気になったのは以下の3つ。
・エクストリームプログラミング、テスト駆動開発
アジャイル開発向けだが、流用コードの多いプロジェクトでの開発でも使えそう
・複数の言語を学ぶ
手続き型、オブジェクト指向、関数型などを学ぶことにより、その言語が持つ特徴を深く学べる
・名付けの重要性
変数名や関数名などは、その役割をはっきり理解していないと名付けがうまく出来ない
投稿元:
レビューを見る
僕は職業プログラマでもなければ、今のところちゃんと書ける言語もない駆け出しだが全体に語り口がマイルドで読みやすく、内容もなんとなくは把握できた。
しかし、この本で注目すべきは巻末の寄稿者プロフィールと脚注の参考文献だろう。この書籍をきっかけに、興味のある分野へ進んでいくとよさそう。1人前になるための1万時間を有意義にするために、入口としても使える良書。
投稿元:
レビューを見る
リファクタリングのときに、1から作りたい気持ちをぐっと抑える
→そのソースは、レビューを通ってきたソース
→それを捨てるのは、
・コードは生涯自分がサポートするつもりで書く
・面倒でも自動化できることは自動化する
・シンプルさは捨てることによって得られる
→ある程度以下の質のコードは、活かそうとはせず、即座に廃棄してしまった方が得策と言える
・良い部分だけを残して、悪い部分は消す
→それすら困難なコードは、全部消して書き直す
色々な言語を学ぶ
→他者の言葉を知ることは、新たな魂を持つこと(カール大帝)
・常に自分が何をすべきかを明確にすると言うこと
→期限も必ず決める
余分なコードは決して書かない
→常に自分が今書いてるコードは本当に必要なものか考える
・自分の書くコードは、全部、未来の誰かへのメッセージだと思うのよ。その誰かはあなたの弟さんかもしれない。
・文章にしろ、和音にしろ、リズムにしろ、美しく、優雅なもの、優れたものは全て、シンプルである(プラトン)
・コーディング規約を自動化する
→当初ドキュメントにまとめても、まず守られないと思った方が良い
・コードだけが全てを語る
→要件定義書や設計書は、そうなる予定だったもの
投稿元:
レビューを見る
スタープレイヤーたちからの贈り物。結局「限られた時間の中でよりよいものを作るには」ということに集約されそう。
投稿元:
レビューを見る
何度でも読み返したい。
世界中に熱意あるプログラマがいるということ。
超一流のプログラマも、私の周りと同じく十人十色の人柄だということ。細かい・破天荒・溌剌・女性・ナード・上滑り。
誇りある一言一言が、私を勇気付けてくれた。
このままじゃダメだし、このままでいいんだと。
投稿元:
レビューを見る
ソフトフェア開発において、色々な名著があると思いますが、そういった個々の深い本に行く前に読んでおく下準備としても良い本かなと勝手に思いました。
この本を読んでからコーディングの意識は全然変わってきたのでめっちゃいい本だと思います!
この流れで「達人プログラマ」や「リーダブルコード」とかを読み進めたいと思います。