simpleとeasyの違い
TL;DL
迷った時には、simple(単純)な方を選びたい
小さなsimpleを組み合わせて、問題を解決したい
simple
- 客観的
- 単純
- 1つだけ
- 構造などが簡単、単純な物
easy
- 主観的
- 簡単
- 自分にとって簡単なだけかもしれないけど、誰にとっても簡単は存在しない
- 人が簡単に思う事(感覚)、単純な事
See also
「ゲームプログラマのためのコーディング技術」を読んだ
- 作者: 大圖衛玄
- 出版社/メーカー: 技術評論社
- 発売日: 2015/06/02
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (4件) を見る
ゲームプログラマではないけど...
読んでみた。
ゲームと唄っていますが、またコード例はC++ですが、
例なだけで、より汎用的なコーディング技術をざっと学べる本。(リーダブルコード、リファクタリング本と同様の切り口)
TL;DL
- コードの意図を伝えよう
- 問題を深く理解し、小さく分割
- 対象となるものの本質を掴み、わかりやすい名前を付ける
- 凝集度(1つの事を行う)は高く、結合度(他のクラスとの関連)は低く
- "いかに書くのか"ではなく"いかに書かないか"が重要
- 難しいことをいかに簡単にやれるか
わかりやすいコード
- 可読性が高いコードはわかりやすく、保守性が高い
- 他のプログラマーに明確な意図を伝えるのが、わかりやすいコードを書く目的
- わかりやすいコードを書くコツは、「複雑なコードの問題を小さく分割しながら、わかりやすい名前を付けて整理する」
わかりやすいコードを書くためのテクニック
- 1つの意味を表すコードであれば、たとえ1行でも関数化する
- 条件が連なるなら、早期returnを活用する
- ループの中では一つの事だけを行う
- 不正な状態は、assert(表明)を使って表現する
- 関数を2種類に分類する(計算などを実行し実作業する関数/実作業する関数を複数組み合わて大きな仕事をする関数)
- 小さな関数の必要性(コードの最小単位を関数とする)
*1
- 細かく関数化すると自己説明的なコードになる、テストがしやすい
- 小さい方がコンパイラの最適化の恩恵を受けやすい
- 関数名からクラスの候補を見つける
- 継承よりも委譲
- ユーザ定義形(typedef)を使って適切な名前を与える
シンプルな設計のための原則とパターン
- クラスを利用する側から考えると、どのようなメンバ変数があってなどは知る必要はない > 適切に動作することが保証されているならブラックボックスのまま利用できる方が望ましい
- オブジェクトの内部の状態を保護し、実装の詳細を隠す
- DIP(依存性逆転の原則)を使用し、具象ではなく抽象に依存する
- 呼び出す側は命じるだけ*2
- 複雑なswitch文が出てきたらStrategyパターンで解決できないかを考えること
- アルゴリズムの変化する部分をクラス化し交換できるようにする
- データ構造とアルゴリズムはオブジェクトを動作させるための手段でしかない
- 利用者はクラスがどんな役割を持っていて、どのような責任を果たすのかが重要
- クラス間の結合度を下げる
- 仲介者(Mediator)を使って依存関係を単純にする
- 窓口(Facade)を使って外部とのやり取りを隠蔽、単純化する
- 複雑なオブジェクト生成はFactoryで行う
- 利用者が楽できるように担当クラスに責任を完全に委譲する
- 実装手段からボトムアップで考えるより、クラス利用者視点からトップダウンで考えた方が抽象度が上がる
- 実装手段の交換ができるようにinterfaceを使ってプログラムを組み立てる(Strategy)
- 問題領域は特定の環境に依存しないように設計する/実装領域は動作環境に依存する
- 問題/実装領域を分離しておけば実装領域を交換することで他の環境にも移植可能
- 問題領域を中心に設計すること
See also
送別会
前職の最終出社日は1月末だったが中々タイミングが合わず、 昨日送別会をしてもらった。
土曜日に多くの方が集まってくださり、遠方からわざわざ来てくださった方もいて、
本当に本当にありがとうございます。楽しかったです!
欲しい欲しい言ってた、
を頂きました。
早速ハンドクリームを使ったところ、信じられないくらいシットリして最高ぽい。
これで、まだまだ乾燥するであろう今年の冬も乗り越えられそうだ
FacebookのエンジニアEvan Priestley氏が「どうやってプログラミングを学んだか」
Evan Priestley 氏がどうやってプログラミングを学んだかを教えてください | Knoh (ノウ)
共感する部分、参考になる部分が沢山あったので、
いくつかまとめて抜粋。*1
一番ためになる教訓は、一番苦労して得るものだ
- マスターするには気の遠くなるくらいの時間を費やさなければならない
ソフトウェアの開発に最初から最後まで関わるという経験はとても貴重だったんじゃないだろうか。 なぜなら、プロジェクト開始時のダメなデザインのしっぺ返しを、後で自分でモロに受けるからだ。
一番重要で一番やっかいなスキルはシステムを設計するための判断力
- どうやってシステムをデザインするかは、その後に多大な影響を与える
ぼくのプログラマーとしての成長に一番寄与したのは、「判断力をつける」ということじゃないだろうか
この「判断力」は、プログラマーにとって非常に重要なのだが、そう簡単に教えられるものでもない。 ぼくが知る限り、判断力をつける一番の方法は、自分で設計したシステムを長い間メンテすることだと思う。
「質 v.s. スピード」ではなく「質 = スピード」
- 「質v.s.スピード」という概念は根本的に間違っている
- 素早く開発をしなくては環境、あるいは自分の環境の理解の変化にソフトウェアがついてこれず、ソフトウェアが解決すべき問題が解決できなくなり、必然的に質が落ちてしまう
- 質の高いソフトウェアを書かなくては、なにかある度にインフラが崩壊し、素早く開発をすることができなくなってしまう
片方を犠牲にした場合、知らぬうちにもう一つも犠牲にしているということをお忘れなく。
広く浅く覚えよう/広く浅く全体を見よう
- 複雑なシステムを理解するには、全体のしっかりとしたモデルを頭の中に持つことがカギとなる。おおまかな全体図をまず把握して、そこから部分的につめていくことが大事だ
- 浅く広くシステム全体を理解した方が、知識がお互いに補完しあって、大域的な理解や、新しい分野へのとっかかりにつながる
閑話休題
フェイスブックでは、ぼくは「一番 PHP を嫌っていないエンジニア」と自称していた。 ぼくのことを「PHP バカ」と呼ぶ同僚もいた。
どのプログラミング言語を使うかってのは、多くの人が考えるほど重要ではないと思う。 ぼくの経験上、一番PHPをバカにし、言語の重要性をうそぶく連中は、大体自分たちが提唱する言語でもロクな仕事ができないことが多い。
*1:タイトルと記事内容が逸れている気がしますが...
「ライト、ついていますか」を読んだ
- 作者: ドナルド・C・ゴース,G.M.ワインバーグ,木村泉
- 出版社/メーカー: 共立出版
- 発売日: 1987/10/25
- メディア: 単行本
- 購入: 53人 クリック: 509回
- この商品を含むブログ (190件) を見る
この本には「問題発見の人間学」という副題が付いている通り、
問題解決ではなく、問題発見の心得に着目した書籍。
TL;DL
これは誰の問題なのか?問題はどこから来たかを自問し、
何が問題なのかを見極める事が重要。
心得
以下、本の中のキーワードをメモ
- 問題とは「望まれた事柄と認識された事柄の相違」である
- 問題は見方(欲求・認識)を変えることで解決する可能性がある
- 解決(方法)を問題の定義と取り間違えるな
- 人が問題だと言っていることが本当の問題とは限らない
- 誰の問題か?
- 本当にあなたが解決しなければいけないのか
- 問題はどこから来たのか?
- なぜこの問題が起きたのか
- 結論に飛びついてはいけないが、自分の第一印象は無視するな
- 全ての解答は次の問題の出所
- 新しい視点は必ず新しい不適合を作り出す
- 最も重要なことは問題は解決されることがないと知ること。しかし、考えることを止めなければは大したことではない
- もし人々の頭の中のライトが付いているなら、ちょっと思い出させてやる方がごちゃごちゃ言うより有効
問題は解くより発見する方が難しいし、面白い。
See also
宮古島
これぞ秘境の離島!「宮古島」に行くべき7つの理由 | RETRIP
時間があったので、行ってきた。
airbnbで宿を予約、LCCで格安航空券をと、リーズナブルに行けたし、 思ったより物理的な距離も精神的な距離も近かった。
1月はほぼほぼ雨かくもりぽいけど、気温は東京と比べて10度以上暖かいので最高。
「Team Geek」を読んだ
Team Geek ―Googleのギークたちはいかにしてチームを作るのか
- 作者: Brian W. Fitzpatrick,Ben Collins-Sussman,及川卓也,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/07/20
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (20件) を見る
「良いチームを作るための指南書」、「他人とうまくやるためのHack」
geekに限らず、ソフトウェア開発に限らず参考になると思う。
TL;DL
- 良い・成功するソフトウェアは 「HRT = 謙虚 + 尊敬 + 信頼」の文化が根付いている
- ソフトウェアは人で成り立っている
- チームが目的を達成するためにHRTは必要不可欠なもの
- あらゆる人間関係の衝突はHRTの欠如によるもの
- ソフトウェアを書く理由は、ユーザ生活を豊かにするため
HRT
- Humility
- 世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。
- Respect
- 一緒に働く人のことを心から思いやろう。相手を1人の人間として扱い、その能力や功績や高く評価しよう。
- Trust
- 自分以外の人は有能であり、正しいことをすると信じよう。そうすれば、仕事を任せることができる。