　コンテキストとは、周囲の状況や、背景の事。プログラミング時、コンテキストの概念を、コードの読み書きと思考のツールの2つの側面から利用する。具体的にには、モジュールなどの大きな括りの名前は、何を示しているのか、明確にする。また、物事とは周囲の状況と繋がっていたり、背景があったりする。これらをコンテキストとして考慮すると正確に問題を解く事が出来るようなる。

契約による設計

「呼び出し側」と「呼び出される側」の取り決め
思い違いの早期発見
コメントとアサーションで契約

2019-07-08

「プリンシプルオブプログラミング」- 前提 - 読書メモ

「プリンシプルオブプログラミング」読書メモ

概要　

　今回、コードを綺麗に書けるよう、その概念を学ぶためにプリンシプルオブプログラミングという書籍を読んだ。101個の原則が読みやすくまとめられており、財産になる本だった。この記事では、私自身が大事だと思ったことをメモ・解説を記述していきたいと思う。

プリンシプルオブプログラミング3年目までに身につけたい一生役立つ101の原理原則

作者: 上田勲
出版社/メーカー: 秀和システム
発売日: 2016/03/23
メディア: 単行本
この商品を含むブログ (11件) を見る

概要　
プログラミングに銀の弾丸はない
コードは設計書である
コードは必ず変更される
ロゼッタストーン

プログラミングに銀の弾丸はない

プログラミングに特効薬はない
ソフトウェアは本質的に困難である
歴史を学び「複雑さ」と戦う

　プログラミングには、一瞬で病気を直すような薬はない。コードが複雑だったり、構造が複雑だったりするため、問題が多岐にわたりすべてを解決する特効薬は存在しえない。

コードは設計書である

コードこそが設計書
改善対象がコードである
優秀な設計者(=プログラマ)が必要

　基本設計、詳細設計、プログラミング、テスト、デバッグまでが設計であり、コードが真の設計書であるという考え方。

コードは必ず変更される

コードは修正されるもの
コードとは無常である
変更に強いコードを書く

　コードが変更されるという前提で書くのが良い。変更に強いコードにするためには、読みやすいコードを書くことが重要。コードは、書いている時間より、読んでいる時間の方が時間がかかる。読みやすいコードを書き、読む時間を短縮させることによって、十分にコストのもとは取れる。

ロゼッタストーン

　ソフトウェア開発とアーキテクチャを理解するための情報を記述されたドキュメント。また設計理由を用意しておくと、保守担当者の修正野判断材料となり多くの機会で役に立つ。

2019-07-05

「プリンシプルオブプログラミング」- 思想 - 読書メモ

「プリンシプルオブプログラミング」読書メモ

概要　

プリンシプルオブプログラミング3年目までに身につけたい一生役立つ101の原理原則

作者: 上田勲
出版社/メーカー: 秀和システム
発売日: 2016/03/23
メディア: 単行本
この商品を含むブログ (11件) を見る

概要　
コミュニケーション
シンプル
柔軟性
繰り返しの最小化
対称性
情報隠蔽
ポリシーと実装の分離
参照の一点性
効率性
テスト容易性
再利用性
安全原理
明確性の原則
経済性の原理
最適化の原則
即行プロトタイプ
効率性より移植性

コミュニケーション

コードはコミュニケーションの場
円滑な開発は円滑なコミュニケーションから
コードを読む側の視点に転回

　他の人が読むという事も考えながらコードを書く。開発では、書くことよりも、読むことの方が時間がかかる。読みやすいコードを書くことによって、読む時間が短くなり、コスト削減につながる。

シンプル

コードの複雑性は排除
コードの複雑性は禍根
コードの大事な部分を仕分ける

柔軟性

コードの変更が容易
コードは必ず変更される
コードの拡張性を上げる

繰り返しの最小化

重複を排除
修正の影響を局所化
コードを分割して管理

　コードが重複しているということは、コードを一つにまとめて簡潔に書く

対称性

コードに一貫性をもたせる
他の部分にも類推できる
同じことは同じ表現で行う

　コードに一貫性をもたせる事で、他人がみても理解しやすくなる。という考え方もある

情報隠蔽

必要ないものは見せない
関連を整理してシンプルに
内側を隠蔽する

ログなど、必要の無いものは見せないようにする。たとえばgithubに上げる時など、.gitignoreというファイルに見せたくないファイルを指定することができる。

ポリシーと実装の分離

「ポリシー」と「実装」は混ぜない
「実装」は安定だが「ポリシー」は不安定
「ポリシー」と「実装」は別モジュール

参照の一点性

定義は一度きり
副作用のないプログラミング
「単一代入」とする

効率性

リソースをうまく使う能力
リソースは限られている
リソースを積極的に活用する

テスト容易性

効果的にテストする能力
テストの品質が本体の品質
テストも考慮した品質設計

　テストが無いコードは負債であり、負債を返さないままだと後に負債を返すだけで手一杯になり、新たな開発ができなくなる。

再利用性

再利用「する」「される」能力
できる限り「作らない」で開発効率化
「プラグイン」

　できる限りコードを書かずに、使えるものを使う。それが効率化につながる

安全原理

安全性にこだわる
大事故の発展を防ぐ
安全サイドにコードを書く

明確性の原則

コードを明確にする
コードを読むのはマシンではなく人
明確でなければ改善する

経済性の原理

プログラマの時間を大切に
プログラマの時間は貴重
プログラマに投資をする

　コストがかかるからといって効率化のためのソフトや環境を与えないのは、かえって効率化を阻み、業務の時間的コストが増加する。なのでプログラマには投資をすべきである。

最適化の原則

早いコードより正しいコード
早い段階での「速いコード」は設計を破綻させる
正しくしてから速くする

　正しく無ければ、早くても意味がない。まずは、正しくコードを書く技術をつける事が大事である。

即行プロトタイプ

できるだけ早くプロトタイプ着手
試行錯誤なしで良いものは作れない
プロトタイプで確度を高める

　とりあえず最低限形にすることで、全体像や改善点が見えてくる。クライアントも全体像を想像しやすくなる。

効率性より移植性

効率性より移植性を優先
ソフトウェアの価値を持続
ハードウェアに依存しないコードを書く

2019-06-25

「プリンシプルオブプログラミング」- プログラマのルーティーン - 読書メモ

「プリンシプルオブプログラミング」読書メモ

概要　

　今回、コードを綺麗に書けるよう、その概念を学ぶためにプリンシプルオブプログラミングという書籍を読んだ。101個の原則が読みやすくまとめられており、財産になる本だった。この記事では、私自身が大事だと思ったことをメモ・感想を記述していきたいと思う。

プリンシプルオブプログラミング3年目までに身につけたい一生役立つ101の原理原則

作者: 上田勲
出版社/メーカー: 秀和システム
発売日: 2016/03/23
メディア: 単行本
この商品を含むブログ (11件) を見る

概要　
プログラマの3大美徳
ボーイスカウトの規則
パフォーマンスチューニングの戒め
確認するエゴレスプログラミング
一歩ずつ少しずつ

プログラマの3大美徳

怠慢・短気・傲慢であれ
怠慢・短気・傲慢で作業を仕組み化
自動化・雛形化・モジュール化

怠慢

　みんなが後から楽ができるように、全体の労力を減らすためには労力を惜しまないという意味での怠慢。例で表すと、テストや環境構築の自動化がある。

短気

　起こりうる問題を想定しながらコードを書く。問題があれば、すぐにコードを書き直す。そのような意味での短気である。

放漫

　人に見せても恥ずかしくない、自身を持てるコードを書けるようにする。その意味で高くプライドを持つという意味の放漫。

ボーイスカウトの規則

コードを掃除して帰る
コード腐敗を抑止する
コードは改良してからコミット

　目的として、コードの新鮮さを保つため、悪いコードを直して今後コードをみた人が内容を理解しやすくするため。それがコードの品質向上につながる。ボーイスカウトは「自分が訪れたところは来たときよりも綺麗にする」という規則があり、それをプログラミングに当てはめたもの。

パフォーマンスチューニングの戒め

「速い」コードより「よい」コード
速いコードは「割に合わない」
まずは良いコードを書く

　パフォーマンスチューニングとは、速いコードを書くこと。しかしその前に、正確なコードを書くことが優先である。それができるようになったら、パフォーマンスチューニングを行うべきである。

パフォーマンスチューニングの手順

最適化の必要性を証明する
パフォーマンスを計測し、ボトルネックを特定する
ボトルネックのコードを最適化する
パフォーマンスを計測し、最適化の効果を確認する
最適化したコードの動作に問題がない事を確認する

確認するエゴレスプログラミング

エゴを捨てよ
エゴレスで品質向上
エゴレスプログラミングの10戒を守る

　プライドを捨てて、仲間にコードをみてもらい指摘してもらう事で、かえってそれが品質の向上につながる。しかし、自分を殺しすぎて個性をもなくしてしまうと、逆にチームに貢献できなくなる。エゴのバランスを取ることも重要である。

エゴレスプログラミングの十戒とは

自分自身も間違いを起こすという事を理解し、受け入れる
書いたコードは、自分自身ではありません
どれほど極めたと思っても、上には上がいる
相談なしに、コードを書き直さない
自分よりもスキルが劣る人にも、尊敬と敬意と忍耐を持って接します。
世界で唯一変わらないことは、変わるということだけ
本当の権威は、地位だけでなく、知識から生じる
信じるもののために戦う。ただし、負けは潔く受け入れる
部屋に籠もりきりはいけない
人にやさしく、コードに厳しくして、人ではなくコードを批評する

一歩ずつ少しずつ

ステップ・バイ・ステップ
「手堅い歩み」は効率的
一度に複数やらない

　小さい一歩だが、確実な一歩を歩むことが結果として品質も時間効率も上がる。一歩ずつ進めると一歩ずつ戻っていくこともできる。また、一歩ずつ進めるということは、コードを十分に理解できていることを示す。そのため不安がないまま、作業に進める事ができる。

2019-06-21

「プリンシプルオブプログラミング」- 法則 - 読書メモ

「プリンシプルオブプログラミング」読書メモ

概要　

　今回、コードを綺麗に書けるよう、その概念を学ぶためにプリンシプルオブプログラミングという書籍を読んだ。101個の原則が読みやすくまとめられており、財産になる本だった。この記事では、私自身が大事だと思ったことをメモ/・解説を記述していきたいと思う。

プリンシプルオブプログラミング3年目までに身につけたい一生役立つ101の原理原則

作者: 上田勲
出版社/メーカー: 秀和システム
発売日: 2016/03/23
メディア: 単行本
この商品を含むブログ (11件) を見る

概要　
ブルックスの法則
コンウェイの法則
割れた窓の法則
80-10-10の法則
ジョシュアツリーの法則
セカンドシステム症候群
車輪の再発明
ヤクの毛刈り

ブルックスの法則

要員追加は「火に油」
「人」と「月」は交換不可能
リスケジュール

　要員を追加すると、新規で入ってきた人に説明するためのコストがかかる。そのコストを元々行なっていた人に使うべきである。そのためにはリスケジュールは必要である。

コンウェイの法則

アーキテクチャは組織に従う
アーキテクチャはコミュニケーションに従う
アーキテクチャ設計後に組織編成せよ

割れた窓の法則

悪いコードは「蟻の一穴」
悪いコードは邪心を引き出す
コードは清潔に保つ

　悪いものが一つでもあると、そこの環境はどんどん悪くなっていく。カビが映えるとどんどん広がっていくようになる。そのような事を防ぐために、コードは新鮮に保つ必要がある。

エントロピーの法則

コードは自然に腐っていく
コードは無秩序へ向かう
コード腐敗の兆候をつかむ

　コードは生肉のように時間が経つにつれ腐っていく。腐ったものがコード内に溜まっていき、保守しづらくなっていく。少しの変更でも、多くの労力が必要となり、再設計を余儀なくされる。

80-10-10の法則

プログラミングに万能薬はない
プログラミングの問題領域は広すぎる
ツールの使用は適材適所

　ユーザの求めることの80％は、実現できる可能性が高く、10％は実現可能だが相当な努力が必要になる。最後の10％は実現不可能であるという比率。

ジョシュアツリーの法則

名前がないものは見えない
名前を知ることで存在を知る
ユビキタス言語を使用する

セカンドシステム症候群

二番目のリリースは機能過多
慣れると多機能主義へ
ユーザを考える

　二番目品質にリリースするバージョンは、機能を入れすぎてしまい品質が悪く、機能の使い勝手が悪くなってしまう傾向がある。1つめのバージョンでは、未知の事が多く、リスクが大きい為、慎重に物事を判断することになる。しかし、2番目のバージョンだと知っていることが多く、保留していたものを含めて多くのものを盛り込んでしまう。

車輪の再発明

すでにあるのに作る
車輪を知らない、作りたい
車輪以外に注力する

　すでにあるものを使わずに、新しく作り出すのは時間の無駄である。すでにあるものの存在を知らないのは勉強不足である。同じチームのエンジニアにヒアリングして、あるものの存在が分かることもある。

ヤクの毛刈り

本当の問題にたどり着かない
トラブルは芋づる式
早々に切り上げる

　問題を深堀しすぎて路頭の迷ったときは、まず何が目的だったのか思い出る。道がずれている、時間やコストをと見合わないと感じた場合は作業を止め、別の道を探す。また、同じことでメンバーがはまらないようにドキュメントに残しておくことも重要。

2019-06-18

「プリンシプルオブプログラミング」- エンジニアの視点 - 読書メモ

「プリンシプルオブプログラミング」読書メモ

概要　

プリンシプルオブプログラミング3年目までに身につけたい一生役立つ101の原理原則

作者: 上田勲
出版社/メーカー: 秀和システム
発売日: 2016/03/23
メディア: 単行本
この商品を含むブログ (11件) を見る

概要　
凝集度
結合度
直交性
可逆性
コードの臭い
技術的負債

凝集度

モジュールは「純粋」に
混じりけのあるモジュールは脆い
高強度モジュールを目指す

　凝集度の一番高い機能的強度を持つモジュール作成を目指す。機能的強度を持ったモジュールの変更は、そのモジュールだけで処理できる。また、他のモジュールへの影響度も小さい。凝集度が低いと理解、保守、再利用の面でコードを利用しにくく、脆弱で、変更による影響を植えやすくなってしまう。

結合度

モジュール間は「疎遠」に
相互依存モジュールは脆い
低結合モジュールを目指す

　結合が密なモジュールは互いに依存していまい、互いに影響してしまうので、様々な問題が発生する。例えば、結合しているモジュールに変更が必要になると、動作に影響が出たり、モジュールを利用する場合、結合しているモジュールも必要となるので、再利用しにくくなる。

直交性

コードは独立させよ
直行コードは堅牢
コードのレイヤー化

　直行しているコードは、片方を変更しても、他方に影響がないコード。直交性のあるコードを書けると、生産性の向上とリスクの削減につながる。

可逆性

「UNDO」な選択をせよ
最終決定などない
特定技術に依存しない

コードの臭い

コードの吉兆を見逃すな
味覚はリファクタリングの必要条件
臭いの傾向を知る

　理解しにくい、修正しにくい、拡張しにくいコードを嗅ぎ分けリファクタリングしなければならない。臭いの傾向を知り、把握しておく必要がある。

技術的負債

問題コードは「借金である」
問題コードとうまく付き合う方法
問題コードを管理する

　汚いコードは借金である。もし急務で書いた場合は、後に修正するよう管理が必要である。ドキュメントに残しておくのも一つの手段である。

2019-06-12

会社の会話で？になったエンジニア用語集 Part1

エンジニア用語集

概要

　筆者は19卒で新卒入社した見習いエンジニアです。会社で上司に言われて？になったエンジニア用語を今後忘れないためにもまとめていきたいと思っています。今回はその第一弾です！

概要

フルスクラッチ

フルスクラッチとは、既存のものを一切流用せずにまったく新規に開発すること。もとは模型の分野で使われていた和製英語で、ITの分野では既存のコードを一切使わずにゼロからソフトウェアを開発することを指す。引用 : IT用語辞典

ページネーション

ページネーション（pagination）とは、日本語で丁付け、ページ割りという意味で、Web制作においては、検索結果一覧など、内容の多いページを複数のWebページに分割し、各ページへのリンクを並べてアクセスしやすくするために設置するものです。引用 : プロモにスタ

リファクタリング

リファクタリングとは、ソフトウェア開発において、プログラムの動作や振る舞いを変えることなく、内部の設計や構造を見直し、コードを書き換えたり書き直したりすること。引用 : IT用語辞典

コンフリクト

コンフリクトとは、競合、衝突、対立、葛藤、緊張などの意味を持つ英単語。ITの分野では、複数の同種の何かが同じ資源を同時に利用しようとして競合状態になってしまうことを意味する場合が多い。引用 : IT用語辞典

モジュール

モジュールとは、機能単位、交換可能な構成部分という意味の英単語。システムの一部を構成するひとまとまりの機能を持った部品で、システムや他の部品への接合部（インターフェース）の仕様が規格化・標準化されていて、容易に追加や交換ができるようなもののことを意味する。引用 : IT用語辞典

リスケ(リスケジュール)

予定を組み直すことをリスケジュールという。ほとんどの場合、予定を延期することを指し、当初に立てた予定通りに計画を遂行することが難しくなった際に、実現可能なスケジュールを組み立て直すことを意味する。引用 : IT用語辞典

ペンディング

保留の、未決定の、未解決の、未決着の、審理中の、懸案の、係属中の、宙ぶらりんの、などの意味を持つ英単語。外来語として、今は決定・開始せずに保留にする、先送りする、という意味合いで用いられる。引用 : IT用語辞典