【書評】リーダブルコード

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

きっかけ

そもそも読んだのは、2014年の終わり。
ものすごい売れているので、パラパラめくったら、かなり共感できることが書かれていたので、買った。
すでに買っているのに、読了してないがために２冊買ってしまった思い出の品。
それをきっかけに、クラウドで買った本を管理するようになった。

感想・内容

読んだ感想とまとめ。
主観が入っているので、興味を持った方は購入したほうがいい。
()は、いつも通り、本にはない心の声。

コードの大原則

コードは理解しやすくしなければならない！

なぜなら、読みやすいコードは、他人が最短で理解できるコードの事だから。
他人が理解しやすいようにコーディングすることが、凡人と達人の分かれ目。

コードは短いほうがいいが、他人が理解するまで時間を短くするコードを書くことが優先。
(Javaだと三項演算子がそう。確かに使うとコードが短くなるけど、使い時を間違えると意味が分からなくなる。)

理解しやすい設計が、優れた設計。
(難しいロジックを難しいまま設計するのは、よい設計者とは言えない。)
(エンジニアの腕の見せ所は、分かり難い事をいかに分かりやすく設計するか。その一点に尽きる。)
(難しいものを難しく設計してドヤ顔するのは、恥をしらない愚か者。)

命名

名前に情報を詰め込む

明確な名前を付けることは、多くの情報を詰め込めること。
いい名前は目的や実態を表す。
名前は、短いコメントととらえるべき。

名前の長さ

スコープの範囲で決める。
スコープが狭ければ、処理が見えるため、変数名は短くていい。
(for分のインデックスに "i" を使っていいのは、スコープが狭い時だけって意味だね)

長い名前が問題ではない。意味不明な名前が問題なのだ！
(意味不明な名前とは、ようするにマジックナンバーを使ったりするやつ。)
(日本は、なぜコード値のようなものを命名したがるのだろうか？もの凄く疑問)
(大手SIは、よくすることに思える。)

誤解

誤解されにくい命名を心がける。
命名する際は、誤解を生む要因がないか、積極的に探すクセをつける。
(誤解を生むような命名にするとバグの温床になる。昼ドラで誤解を生むような会話をすると、泥沼に落ちるのと一緒)

コードの美しさ

コードの美しさは、読みやすさ。
シンプルさこそを絶対の基準にする。
美しい　＝　いい設計ではないので、注意。

美しさの原則

• 統一されたレイアウト
• 似ているところは似せる
• 関係するコードをブロック化

コードの段落表記

• 考えをグループ化できる
• 他との考えの違いを区別しやすくする
• 視覚的な踏み石
  (枕詞って言った方が日本人にはしっくりくるかな？)
  (例を出すと、熱湯風呂に入るのをためらっている奴が、「押すなよ」って言ってたら、押してあげることだ)

一貫性あるスタイル　＞　正しいスタイル
正しさよりも一貫性が重要。
見た目をそろえることが、バグの早期発見につながる。

コメント

コメントすべきこと

書き手の意図を読み手に伝える。
コメントが名前の説明になる場合、それは名前がおかしいので、考え直す。

コメントは、修正を促したり、なぜそうなったのか背景を載せるように心がける。

一般的なコメント例

TODO：あとでやるタスクを書く
FIXME：既知のバグや不具合
HACK：許容しにくい解決策
XXX：危険、問題あり

定数のコメント

なぜその値なのかを考える必要がなくすコメントにする。

コメントを書く基準

読み手が、プロジェクトを熟知していない人と考える。
つまり、コメントに書かなければいけないこととは、質問されそうなことに対する答えだ。

コメントを書く作業フロー

1. 頭にあるコメントをすべて書き出す
2. 不要な個所を探す
3. 改善、添削

コメントすべきではないこと

コードからすぐに抽出できること。
コードを補うコメント→コメントを書くのではなく、コードを修正すべき。

コメントに書くべきこと(推奨すべきこと)

• なぜこの作りになっているか
• コードの結果レベル(TODO, FIXMEなど)
• 定数の背景

読み手が欲しているもの

• 疑問に思うことを先回りして書いておく
• ファイル・クラスの全体像
• 一般的ではない動作

コメントの簡素化

コメント領域は少なくすべき。
多いコメント→それだけコードに問題がある。

歯切れのいい文書、短いけど的確な文章が、読みやすさにつながる。
特に、あいまいな代名詞は除去する。
「それ」「これ」は、読み手が何を指しているのか紐解く必要があり、手間と誤解を招く。
使ってもいいが、何を指しているのか明確にしてあげる。

ロジック

if文

条件は、否定形よりも肯定系を使う。
否定形は、分かり難さにつながる。
条件の優劣も見やすさにつながるので、注意。

三甲演算子

基本的には使うべきではないが、よりコードが簡潔になる場合は使うべき。
(これをどう使うかで、コーディング能力がわかる。)

ネスト

• 深い＝精神的苦痛を当たる
• 浅い＝理解しやすい

ネストを浅くするには、処理を途中で終わらせるようにロジックを組む必要がある。

難しいロジック

最善手ではない可能性が高い。
逆転の発想が必要になる。
巨大で難解なロジックはなるべく分割する。

変数

一度だけ初期化するもの。
変数の変更が多くなるということは、処理を追う必要があり、面倒。

テスト

テストコード

テストコードが読みやすい＝テスト以外も読みやすい。

テストコードが読みにくいと起こること

• 本物のコードの修正を恐れる
• 新しいコードを書いてもテストケース書かない

テストの原則

大切ではない詳細　→　隠す 大切な詳細　→　目立たせる

(つまり、本質ではないことは、処理を隠蔽してやる必要がある。)

テストデータ

なるべく単純化させる。
複雑なテストデータは、隠すか単純化しないと、テスト恐怖症を引き起こす。

テストやりすぎ問題

90%のテストは楽だが、残りの10%は難しいもの。
実際に100%のカバレッジを達成しても、バグがゼロになることはない。
コストとバグの消化が割りに合わなくなるので、許容店を考える。

最後に

コードの質を高める

簡単なのは、外部の視点を得ること。
外部には、６ヶ月後の自分も含まれる。
(ぼっちにやさしい！)
(自分は、触らなくなって３日立つと忘れるので、うまく利用する)

エンジニアで大切なこと

実践すること

気づく機会は、手を動かしたもののみに与えられる。
気づきがなければ、成長はできない。

他人に頼る

外部の視点は、自分に気づけないことに対する気づきを与えてくれる。
なので、指摘してくれる人は大切にすべき。

(GitHubにコードを晒す連中は、コレが主要な目的だと思う。)

感想

いろいろ考えが変わった一冊。
自分ではなく、読む人にたいしてコーディングするという考えが、一番印象にのこった＆ためになった。
意外にも、それが出来てない奴が、日本には多い。
言われたことをそのまま実装するだけでは、ダメだということを痛感できた一冊。
新人教育で読ませるだけでも価値があると思うんだが、ウチの会社は理解せんだろうな。。。

これを読書会を社内で開くことを検討中。
やって結果が出たら、ブログに書きたい。

2016年上半期で気に入った文房具

文房具は勉強に重要

2016年に入って、いろいろ試しにノート買ったり、文房具を買うことが多かった気がする。
そのなかで気に入ったものとその理由を書いて、今後に生かす。
※発売自体は結構前のもある。

「マツコの知らない世界」に出ていた文房具の人にちょっと触発された。

気に入ったもの

コクヨノートキャンパス ドット入り罫線

コクヨ キャンパスノート ドット入り罫線 5冊パック B5 B罫 30枚 ノ-3CBTX5

思ったこと

ただ、ドットが入っただけなんだけど、あるとないとでは、雲梯の差が出る。
ちょっと前までは、ドットがないノートを使っていたけど、これを使うようになってノートが凄くきれいになった。
文頭がそろえやすいのが、非常にいい。
単純なことだが、パッと見でわかりやすくて見やすくなる。
自分は、本を読んで得た知識をノートに書くようにしている。
その作業をした際に、後で見やすいのは、とても助かる。

ただでさえ字が汚いので、配置を意識せずにそろえることができるのが、ものすごい楽だった。
方眼ノートでいいのでは？と思ったけど、方眼ノートだと、お絵かき主体になるのよね。。。
方眼ノートは方眼ノートで、別利用シーンがあるので、別に使っている。
それは、後続で紹介。

なにか文章をまとめたいときや、見返すことが前提の場合は、使ってみるといいかもしれない。
自分は結構しっくり来た。

パイロット フリクションボールノック0.5mm

パイロット フリクションボール ノック 0.5mm ブルー LFBK-23EF-L

思ったこと

自分は、青が好きなので、青をよく使う。
だって、黒だと味気ないし、赤だと目が痛い。
ノートをとることにも楽しみを見出したいので、青を使う。

３色にしないのは、ペンの色を変えるのが面倒なのと、どうしても太くなるので、手が痛くなるから。
筆圧が結構強い＆力強く握るほうなので、太いと結構力を入れてしまう。
かといって細すぎると持ちにくいので、0.5mmが自分には一番合っていた。

また、芯の詰め替えも簡単にできるので、非常に使い勝手が良かった。
ただし、詰め替えで置いてあるのは黒が多い。
同士が少なくて残念だわ。。。

ロジカル・シンクノート

高橋政史×ナカバヤシ ロジカル・シンクノート A4 ブラックブルー RP-A402DB

思ったこと

これの用途は、アイディアの書き留め＆説明
図を主体に書くことが多いシーンで使う。
文字が多い場合でも、補足線で矢印入れることが多い場合に使うことが多いかな？
よく使うのが、なにかの勉強会に行ったときに、図と文字、補助線使って考えをメモするときに使う。

最後に

文房具は、学習と因果関係が思ったより強いと感じるようになった。
ケチらずにいろいろ試していきたい。

文具ソムリエール「菅 未里」って人が可愛らしいと思って見ていた。
既婚者だと知ったときは、衝撃が大きかった。
それでも応援したい人ではある。
心の闇とか、興味を引くワードを持っている。遊戯王好きにはたまらないね！

調べたら、ブログ書いているのだな。
これからは、要チェックしておこう。

STATIONERY RESTAURANT | 毎日が楽しくなる文房具いかがですか？

【書評】アジャイル開発とスクラム

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

きっかけ

アジャイルサムライを呼んだが、後続の本で知識を深めたいと思っていたので、読了。
本当は、実際にやってみてフィードバックを得ながら開発するのがいいのだろうけど、プロジェクトの主流はウォーターフォールが一般的で難しい。
あと、私生活に適用しようと思っても、いきなり適用が難しいのがある。
本質をより良く理解したかった。

近くに、メンターになれる人がいれば良かったけど、内向的性格が災いして、なかなかできない。
なんか、アジャイルをテーマにしたカンファレンスがあれば、行きたいと思う。

内容・感想

読んだ感想とまとめ。
主観が入っているので、興味を持った方は購入したほうがいい。
()は、いつも通り、本にはない心の声。

アジャイル開発とは何か、スクラムとは何か

ウォーターフォール

開発工程に従って順次開発する方式。
工程間をドキュメント使って意思疎通する。
下記問題点がある。

• 動くものが最後まで見えない
• 文章での意思疎通による誤解発生のしやすさ
• 完成時に古くなる可能性

アジャイル

開発工程を短い期間で繰り返す。
ユーザの意見を取り入れて開発を行う。

アジャイル開発

手順・プロセスによる開発ではない。
価値観や考え方を元にした開発。
そのため、やり方には複数ある。
決まったやり方を指すのではなく、考え方を指す。

(おそらく多くの人は、決まったやり方を求めている気がする。)
(そのために、誤解が生まれている気がしてならない。)

なぜ、アジャイル開発なのか

従来のシステム開発

1. 市場調査
2. ビジネスモデル確立
3. システム発注
4. ソフトウェア開発
5. 納品
6. リリース

ビジネスのゴールと、ソフトウェア開発のゴールが分断されている。
ビジネスのゴール：システムで利益を得る(リリース以降)
ソフトウェアのゴール：仕様通りに作る(納品まで。リリースも含む場合がある。)

ゴールが違うから別々の利益を求める。
↓
最初の内に多くの機能を求める。
↓
リリースする頃には、いらない機能になってお金がかさむ。

章まとめ

アジャイルが出現した背景
ビジネス変化の高速化

アジャイルの目的
ゴールを共有して、無駄を省く事。
柔軟な対応と費用対効果の向上に主眼を置く。

スクラムとは何か

アジャイルの一種。
経験を元にしたスプリント*1を実行する。
スプリントで得た経験を、次のスプリントに活かす。

スクラムの３つの役割

• プロダクトオーナー
  何を作るか決める人
• 開発チーム
  開発する人々
• スクラムマスター
  マネジメントする人。働きやすい環境構築を行う人。

スクラムの成果物

• インクリメント
  スプリントの成果物。リリースする媒体。
• プロダクトバックログ
  機能リスト
• スプリントバックログ
  今回のスプリントで実装する機能リスト

スクラム５つのイベント

• スプリント
• スプリント計画
• デイリースクラム
• スプリントレビュー
• レトロスペクティブ

スプリント

繰り返す反復の作業。

スプリント計画

スプリント開始時のミーティング(キックオフ)
プロダクトバックログからスプリントバックログを抜き出す。
対応内容を決めて、タスクに落としこむ。

(アジャイルは計画が内容に思われがちだが、実際は、やることを決めて計画は立てる。
アジャイルサムライでも知っていたので、それほど驚きはしないが、知らない人は驚愕するらしい。
※個人の推測

ここでWBSに落とすのだろうか？)

デイリースクラム

朝会・夕会の実施。
活動状況を共有する。
開発チームで対応できないこと→スクラムマスターに依頼する。
共有して見えた状況→プロダクトオーナーに報告

(ウォーターフォールでもやると思う。
ただ、役割を決めてないと宙ぶらりんになるが。
やることは、スクラムの肝な気がする)

スプリントレビュー

スプリントが終わった後のデモ

レトロスペクティブ

スプリントレビューでの振り返り

アジャイル開発の活動

アジャイルの実践には、プラクティスと呼ばれるいくつかの活動が必要になる。

ユーザストーリー

ユーザの言葉で書かれた機能説明　→　これが要求仕様書になる。
アナログ重視して、カードに書かれたことをきっかけとして話す。
会話ベース。
仕様書に落としこむと、ドキュメント肥大化と分析麻痺が起こるから。

(方式が異様に多いのは、何度か経験がある。
ドキュメントが多いと圧倒されるし、仕事をした気になるから注意が必要だと思う。
ドキュメントが多い＝優れたシステムではないハズ！)

プランニング・ポーカー

チーム全体で開発規模を見積もる。
各々の見積もりを比較して決める。
※人は、見積もるより比較が楽なため。

ポーカーのように日数合わせをして進めるので、この名称だと思われる。

朝会（デイリースクラム）

やることを見える化して、チームで共有する。
長くなる議論は、一旦区切る必要がある。

振り返り

チーム活動を通して、今後の改善を話し合う。
PDCAのCAに相当。
気づきを共有して次に活かすのが目的。

(よく考えるとPDCAのCAって、一緒にやることが多い気がする。)

タスクかんばん

現在していることを全てカード化して可視化する。
誰でも見ればプロジェクト状況が分かるようになる。
そうすることでボトルネックを見つけやすくして、スループットをあげる手法。
あと、分散開発がしやすくなる。

(たぶん、これはトヨタの流れだよね。。。)

バーンダウンチャート

スプリントの残作業を認識して、現在の進捗を知るのが目的。
進捗に対してどのような行動をとる／取らせるかが重要。
一番の目的は、行動喚起すること。

ペアプログラミング

ペアでプログラミングさせる。
そうすることで、リアルタイムレビューと知識の共有が行われる。
会話しながら開発するので、集中力が必要になる。

テスト駆動開発

テストの定義→失敗→再設計を繰り返して設計を成長させる。

リファクタリング

外部からのうときを変えずに、内部構造を変える再設計活動。

継続的インテグレーション

動くソフトウェアを常時展開させる

アジャイルを支えるもの

アナログと会話

動くものによって品質を作って密度の濃い場を作る。
開発速度と効率が上がる。

(今までは品質を高めながら作るのが主流だったけど、これからは作りながら品質を高めていくことが主流になる。
そうしないと、速度でないことは、明白なハズ！)

オブジェクト指向

変更・テストの容易性をあげる技術として必須。

(今は、関数型が目立つが、オブジェクト指向と反目はしないと思っている。適用する場所が違うだけ。
アジャイルを突き詰めていくと、マイクロサービスになる気がする。)

スピード時代に独自のアジャイル手法。ワンチームマインドで挑むリクルート

新しい開発標準「SWAT」

メディアの変化

紙　→　Web
旧来の勝ちパターンが遅すぎる。
やってみないとわからないが多数を占めるので、実際にやってみることを優先しなければいけない。
競合他社がいるなかで遅いことは、負けに繋がる。
(ブルーオーシャン戦略の基本ですな)

SWAT

Speedy Willing Alliance Teamの略。
一致団結して、意志をもって開発スピードを追求する。
(言われたことを早くやるではないのが、ポイント)

スクラムと実践知リーダー

スクラムオーナーとプロダクトオーナーに求められるものは、実践知のリーダーシップ。

アリストテレスのフロネシスと実践知

知　→　３つの形態がある。(ドラゴンボールのセルかな？？)

• エピスメーテー
  科学・哲学が該当。
  普遍的で、文脈に依存せず、再現可能で言語表現できるもの
• テクネー
  技術・スキル。文脈依存で実践のノウハウ
• フロネシス
  実践からの知恵。目に見える事象と背後にある関係から適切な判断をして実行する。

(フロネシスを理解してない奴が多いこと。
だから、「Why ~」って言うのに騙される。
やり方を学んでも、それができる場面と背景を理解してないとダメってことだな。
魚の目利きのやり方を覚えても、いい魚が絶対手に入るわけではない。
売っている人との利害関係や関係の構築を考えることも必要なのだ。
それを体系的に伝えることが困難なので、修行という考え方があるのだと、儂は思う。)

実践知に必要なリーダーシップ

• 良い目的を作る　→　良い判断のため
• 場をタイムリーにする　→　知の流通を良くする
• 現実の直視　→　現実を見て、本質を見抜く
• 直感の本質を概念化　→　本質を見つけたら、それを伝える能力
• 概念の実行　→　見つけた法則を実行に移す行動力。政治力も伴う。
• 知の組織化　→　知の伝授・継承・分散

(リーダーシップを発揮するとは、未知の事象を解析して分析、実践して検証を含めること？
何もしない奴は、確かにリーダーシップがあるとは言えんな。
あと、考えを持たない奴も、リーダーとしてどうだろうかと思う。)

感想

アジャイルサムライを読んでいたからか、違和感なく読めた。
リーダーシップの考え方は、概ね同意。
行動を起こして、率先するのがリーダーシップだと思うね。

やっぱり一番難しいのが、問題の共有と解決だろうか。
人の考えは、統一することができないから、アジャイルが失敗しやすい由縁だと感じる。
それをどうやって解消するかが、アジャイル開発の課題な気がする。

アジャイルの基礎はアジャイルサムライで固められた。
汎用概念や、他の取り組み方、実践方法について迷ったら、読むといいかもしれない。
たぶん、アジャイルサムライを読み直すと、見えなかった本質の説明が分かりそうな気がする。
多読がいいとされるのは、理解のきっかけが、いろんなところにあるからかもしれないと思いました（小並感）

アジャイルサムライ−達人開発者への道−

*1:反復プロセス

eclipse4.6 新機能まとめ

Eclipse 4.6

IDEのトレンドを知っているのは、開発者として当然だと思い調査。

ネーミング

いつもなら、天体系の名前のはずだが、今回は、元素名。
なんでだろー(テツトモ風)

マジで気になる。
eclipseって名前自体も天体系の用語だと思うのに。
ネタ切れかな？
テラナイトでも天体の名前が使われているから、個人的には結構覚えやすかったのに。。。

天体の名前は、中二病全開だからだろうか？
プロダクトにおいて、イメージは大切だからな。

そして、スプラッシュ画面の画像は、いつもながらカッコいい。。。

変更内容

バグフィックスは除く。
結構いっぱいある。

• JavaScript ES6 対応他
• メモリ消費量の低減
• Git ステージング・ビュー
• 部分一致でのコンテンツ・アシスト
• エディターで行折り返し
• 最大化などの操作性向上
• JSON エディター
• 起動高速化、UI 性能改善、アップデート高速化
• Eclipse 実行環境は Java 8 が必須に
• WTP の Tomcat 9 対応
• Java 保管アクションにダイヤモンド演算子への変換追加
• "if" のコンテンツ・アシストで == null と != null 候補を表示
• Ctrl+、Ctrl- でエディターのフォント拡大縮小
• ワークスペース選択ダイアログに最近使ったワークスペースの一覧を表示して選択・削除
• ファイルの関連付け設定で「関連付けられていないファイルのオープン」の挙動を設定
• null アノテーションの型を複数指定可能
• ダイアログのダークテーマ対応
• 名前変更ポップアップにオプションを開くためのリンクを表示
• ファイル検索でバイナリーファイルを対象にするオプションを追加
• クイック・アクセスで Ctrl+3 で表示切り替え
• アノテーション新規作成時に Target アノテーションなどのメタアノテーションの追加オプション追加
• リファクタリング：パラメータを新規フィールドに割り当て
• Java > コード・スタイル > フォーマッター > 編集 > 小括弧 に関する設定追加
• 履歴からのアプリケーション終了→再起動
• 編集中エディタの自動セーブ
• 最近使ったワークスーペースを直接選んで起動

...etc

気になった機能と確認結果

eclipse.iniの変更

使用するGCの設定が、G1GCになっている。
G1GCは、以前記事に取り上げたことがあるので、そちらを参照してもらえればと。

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

簡単に言うと、大きなメモリを効率よく管理するためのGC。
あまり大きなメモリを使ってないなら、設定を変えてみるといいかも。
Java9からは、デフォルトになるため、そこらへんは意識しておきたい。

仕組みは、以下の記事がわかりやすかった。

3.1.4 G1GCのメモリー構造とGCの流れについて

JSON エディター

地味にアウトラインが便利。
たまに、設定ファイルとしてJSON使ったりすることがあるので、アウトラインで構造が見やすくなった。

エディターで行折り返し

自分は、常に行折り返しさせないのが使いやすいが、そっちが使いにくい人もいるのだな。
ハード的な要因だろうか？
行折り返しが必要なほど、横いっぱいになるようなコーディングはしないように心がけているので、あまり気にしたことがなかった。

Alt + Shift + Y で切り替える。(デフォルト設定では)

ダークテーマ

闇ですね。
正しき闇の力を使えてこそeclipseって、勝手に思っている。

残念なことに、一部スクロールバーがダークテーマにならない問題が残っている模様。。。
次期バージョンで解決するようです。

この部分は、InteliJ IDEAが一番しっくりくるな。

Ctrl+、Ctrl- でエディターのフォント拡大縮小

これは、ライブコーディングする人にとっては便利ですね。
毎回フォント設定変えるのは、時間かかるうえに、なんか慌てちゃってパニくるときがある。(精神が弱い俺固有の問題かもしれんが。。。)

編集中エディタの自動セーブ

必要なのだろうか？って思ってしまった。
癖でCtrl+Sで勝手に保存してしまうので、個人的にはいらない。
たまにExcelを保存し忘れてクラッシュしてなくなりましたって人を見るけど、「それはリスク背負って作業した結果でしょ？」って思う僕は、傲慢すぎるのだろうか？
デフォルトでは、当然のように無効化されているので、保存癖をつけるのが普通だと思う。

履歴からのアプリケーション終了→再起動

これは、嬉しい。
たまにeclipseがクラッシュして、強制終了することがある。
その際に、Tomcat起動したまんまとかいうと、厄介なことになる。
過去記事にも書いたが、それが結構あって、対処方法を調べて残したほどだ。

suzaku-tec.hatenadiary.jp

多分、ハードが貧弱なせいでしょうね。。。。

最近使ったワークスーペースを直接選んで起動

あんまり起動時にワークスペース選ぶことがないので、実感はわかないのが正直なところ。

クイック・アクセス

なるべくショートカットを使うようになってから使うようになった。
フィルタリング機能が提供された。
これによって、大きな分類を覚えておけば、ある程度アクセスしやすくなる。
覚えてないときとかは、大分類で探すことができるようになるわけですな。

リンク

参考にした記事

Eclipse 4.6 Neon 新機能 TOP10！と Spring Boot STS - Qiita

Eclipse4.6 "Neon"の新機能一覧 - R42日記

感想

takahashikzn さんのブログがすごく詳しかった。
これくらいのことができるエンジニアになりたいものだと思いました。

全体的に、コーディング補助の能力が向上した印象を受ける。
コードの解析技術がもっと進んでくれればいいなと思う。
特にNull解析は！

遊び心ある機能があると面白いかもな～と心の中で思う。

Linuxコマンドの基礎の基礎

基本のコマンド

man

manコマンド。
manualの意味。
わからないことは、とりあえず、調べる。
調べ方がわからないと、学習できないからな。
思春期の子には、ちょっと刺激の強い言葉。

使い方

man コマンド

manの利用方法自体もman manで調べられる。
なんとも不思議な感じ。

less

画面表示制御のコマンドです。
ファイルの中身を確認するのに利用できる。

ls

listの略。
ディレクトリのファイル・フォルダのリストを表示する。

大抵、オプションの-lを組み合わせた、llを作っているところがある。
あとは、ジョークとして、slコマンドがあったりする。
タイピングミスした時にslが走るだけのコマンドだが、気休め程度にはいいかもしれない。

cd

change directoryの略。
ディレクトリを移動する際に利用する。

mkdir

make directoriesの略。
複数のディレクトリを作成できる。

cp

copyの略。
ディレクトリやファイルをコピーする。
ファイル日付を変更したい場合は、touchを使う。

mv

moveの略。
ディレクトリやファイルを移動する際に使う。

mv 移動前のパス 移動後のパス

rm

はremoveの略。
ディレクトリやファイルを削除する。
一度消すと復元できないので、十分に注意する。
windowsは、ごみ箱に行く習慣があるが、あれは悪習慣だと思うね。
消したつもりでも、実際消えてないのは、どうかと思う。

cat

concatenateの略
ファイルの内容を閲覧するコマンド。
lessと違って、すべての内容を出力する。

とりあえず

知らないわけではないが、とりあえず、基本的なコマンドだけ列挙。
lessよりもcat派。
たまにless使うけど、便利なので使うように心がけたいところ。

【SE稼業は忘己利他（もうこりた）】第11回 ヘタレのモチベーション 感想

gihyo.jp

きっかけ

よく見るようになって、共感することが多かった。
思ったことを書き留めておきたいがために、メモする。

内容と感想

はじめにのメモ

やる気やモチベーションは，自分が出すものであって誰かに出してもらうものではないでしょう。

同意。外的要因で下がることがあるかもしれないが、上がるのは内的要因に依存すると思う。
それに、何がきっかけでやる気が上がるか、本人ですらわかっていないことが多い。
それを理解せずに振り回される管理職は、結構いると思う。

インセンティブ（褒美）で人は動くか

他人に言われたり，迫られたりしただけで本気が出ることはまずない。
...
自分自身に火の粉が降りかかってきて初めて人は動く。

子どもを見ればわかる。
強制しても、進んでやることはない。
身の危険を覚えなければ、進んでやることがない。
海馬瀬人が海馬剛三郎の元で生きるために、過酷な教育を受け続けたのと一緒。

水を飲みたくない馬
馬を水飲み場まで連れて行くことはできるが，飲みたくない馬に水を飲ませることはできない。
イギリスの諺

無理やり言うことを聞かせるために、そういう環境に追いやっても、意図したとおり動くことはない。
イギリスにもいい諺がある。

木を見て森を見ず

要するに、目の前の作業に従事するばかり、最終的な目標を見失う。
よくあることだよね。
目的を見失わないように行動しても、いつの間にか五里霧中の状態にあるのは、ざらにある。

グランドデザインって書いてあると、某都知事を思い出してしまうが、書いてあることは、的を射ている。
何ができて目標達成か、そこまでの道のりとチェックポイントをしっかり立てることが重要だと思う。

個人戦が好きなあなたへ～個人戦と組織戦

昔にあった、別会社に委託した開発者の話を思い出した。

【海外：アメリカ】ソフトウエア開発者、仕事を中国企業に丸ごと業務委託したのがバレてクビに！仕事中はネットで時間つぶし | 日刊テラフォー

つまり、内部に知見やノウハウをためなかったためにそうなった。
解雇するのはいいが、組織も体制を考え直す必要があるということだ。
学習を怠った組織は、個人の裁量に任されるので、組織戦ではなく個人戦になる。
本当に組織戦をしたいなら、ノウハウをためることを組織側で考える必要がある。

信頼関係の修復

信頼関係は、簡単にできるものではない。
不条理と思える態度や行動を指摘しても、火に油を注ぐのは、容易に分かるはずだけど、意外と人はできない。
やるなら、必ず自省が先。

「なぜ？」の問いかけの先に本質が見えてくる

「なぜ？」と思うのは大切。
なぜがなければ、本質は見えずに場当たり的対処になる。
それには、同意だが、付け加えると、方向性の問題もある気がする。
頓珍漢な方向に「なぜ？」を進ませることがたまにあるから。

「なぜ？」の回数が少なくなったら、自分の想像力・開発力が衰退し始めたと感じるという考えが、自分にはなく、面白い考えだと思った。

もの柔らかな返答は怒りをそらす

「仁義礼智信」の5つの徳性が、大切であることを説いている。
これを実現したのは、歴史上だと三国志の劉備な気がする。
現に、今でも劉備は、信仰を集めている。
いかに大切かがよくわかると思う。
最近、D.カーネギーの本を読むようになって、劉備の評価がとてつもなく上がっている。
ちなみに、読んでるのは、以下の本

人を動かす 文庫版

失敗に学ぶ効用

野球はミスをするスポーツです。ミスをなくそうとムダな努力をするよりも，ミスから学ぶことのできる選手のほうが，成長が早い。それなのに，ミスをした選手を怒鳴りつけたり，罰練習をさせたりするのは野球というスポーツがわかっていない証拠です。ミスをすると，どうして失敗したのか考えるチャンスになります。次にミスを減らすための練習に熱が入ります。
桑田真澄

桑田真澄の文言が、非常に心に沁みる。
これは、野球選手に限らず、開発者としても持つべきマインドな気がする。
ソフトウェア開発もミスするもの。
ミスから学ぶ体制を作ることが大切やね。

感想

最後の一文にあった言葉が、大切だと思った。

「一緒に考えよう」の一言が言える人間でありたいものです。

一緒に取り込める開発者が欲しいのは、だれしも同じだと思う。
独りぼっちは寂しいもんな
佐倉杏子は、これを意図して言ったのだろうか？
一人にさせず、親身になって問題に取り込んでやることが大切だと思った。
子育てにおいても、開発においても。

子育ては、したことないんですけどね！
そう考えると、親は偉大だと思う。

設計書からコードを自動生成して起こることメモ

問題

分業できない

自動生成にロックインしてしまい、自動生成の仕組みを理解してないとレビューができない。
設計書にどう書くかが問題になり、なかなか話が前に進まない。
大機能単位で、別々の会社に分割すると、設計がやりづらくなるだけで終わる。

問題が先送りされる

設計ばかりに注目され、問題がなかなか現出しない。
単体レベルの問題が出せない。
さらに、自動生成するツールができていない場合、製造に落とす作業ができず、暗中模索してしまう。
いざ、製造になって、根本的問題が発症する可能性が高い。

開発者が軽視される

製造の問題点を指摘しても、自動生成でどうにかなるからで終わる。
こうあるべき論を述べても、どうにもできない。
コードが成長しても、ずっと同じ構成を続ける。
リファクタリングが受け入れられず、設計の改良ができても、コードへの改善が行えない。

設計書が人のためではない

読む人のために作るような設計ができない。
すべてなんらかのフォーマットで書かないといけない。
柔軟な表現にかけるため、理解がしづらくなる。
表現の幅が減ると言ったほうが正しいかも？

どうあるべきだったか

定型的データ構造

適用するなら、定型的なデータ構造のコード生成だけだと思いました。
変更がすくない箇所への自動生成は有効。

仕様書は、変更が入ること前提なことがおおいので、自動生成の対象にすべきではない。
区分値とか、コード定義とかが有効なのかもしれない。

それ以外は

やったらダメだと思う。
知的創造の分野と、単純な繰り返し項目(自動化できる場所)は、きっちり分けるべきだと思います。
知的創造の分野を自動化した結果、人が分からなくなるでは意味がない。 知的創造の分野を自動生成するのは、早すぎる分野かとおもう。