読んだもの
なぜ読んだのか（読む目的）
- ずいぶん前にまつもとゆきひろ氏の講演会に行ったときに紹介されていて興味を持った
- ソフトウェア開発者として生きていくためのヒントが書かれているような気がした
思ったこと達
この本にはソフトウェア開発者のキャリアに関する、概ねすべてのことが書かれている。ボリュームが多く考えさせられる内容でもあったので、読むのにはかなり時間が掛かった。一部内容が単調な章もあり、読むのをやめてしまおうかと思った時もあったが、すべて読み切ることでソフトウェア開発者のキャリアの全体感が掴めたような気がする。
気になった文章とその所感を書いておく。
私は、実際に動いているアプリケーションのソースコードを見て、何が起きているのかをできる限り解明しようと努力するところから始めるのがベストだと思う。
初心者がソフトウェア開発の技術を学習する際に「自分でなにか小さなアプリケーションを作ってみる」というのをファーストステップにするケースが多そう(要出典)。
でも実は、技術の習得や経験を得るという観点では、すでに動いている(運用されている)アプリケーションをいじる方が良いのかも？と感じていた。最近も良く感じる。
- 小さなアプリケーションをゼロから作るよりも、運用されているアプリケーションを修正する仕事の方が多い(と思う)
- 自分で作っているものは(良くも悪くも)雑に「えいや」とできてしまう
- ゼロから作るのと、運用されているアプリケーションの修正では、思考プロセスが違う(と思う)
Webアプリケーション(それなりに利用者のいる)の運用を経験する場、を作ることができたら良さそう。
ルールはない。あるのはガイドラインだけだ。
良い言葉。この筆者は割りと常識に捉われないアクションをしてきている。が、それは破天荒なものかというとそうではなく、論理的な判断に基づいている。大抵は周囲の反応や自身の思い込みによって"ルール"と認識しているだけで、実際はそんなルールなどなく「こうした方がいいかもね」という程度のガイドラインだ、と言ってる。
つまり絶対に守らなければならないルールなどないから、そんなもの気にせずに自分の求めるゴールに突き進むためのアクションをしようぜ、という話。
テストとは、問題を起こす、あるいは起こす可能性のあるすべてのものを見つけることではなく、仕様に照らしてソフトウェアをチェックすること（ソフトウェアのテストを好んでこのように定義する人もいるが）でさえない。
(...中略...)
ソフトウェアを使っていて顧客が大きなマイナスの影響を受けるリスクを軽減することだ。
テストで必要以上に細かいことを気にしてしまうケースはあるかもなぁ、という反省。
ソフトウェア開発には、YAGNI（YouAin'tGoingtoNeedIt、それが必要になることはない）をなくすという原則がある。
初めて知った単語。不要なコードは書かないでおくれ、ということだな。
あなたはコードのデバッグのためにかなりの時間を費やすことになるということだ。人生には、絶対に避けられない定めがある。死ぬこと、税金を取られること、そしてバグを作るプログラマーだ。あなたの時間のかなりの部分がコードのデバッグのために費やされることを考えるなら、デバッグは得意分野にしておくべきではないだろうか？
他人が書いたコードのデバッグ、自分が過去に書いたコードのデバッグ、自分が今書いたコードのデバッグ。確かにデバッグに費やす時間って多いよなぁ。
世の中では新しいソフトウェアが次々に作られているが、新しいソフトウェアはどれでも一定の寿命が想定されており、それはおそらく開発にかかった時間よりも長いだろう。ということは、いつでも新しいソフトウェアよりも古いソフトウェアの方が多いはずだということになる
(寿命が開発に掛かった時間よりも短いケースもそれなりにありそうだけど)一般的にはそうだろうなぁ。「新しい」「古い」の定義は曖昧だけど、少なくともメンテナンスの重要度が相対的に高いソフトウェア、の方が世の中には多い、ということは言えそう。
コードのメンテナンスが得意になる秘訣のひとつは、ボーイスカウトのルールだ。このルールはアメリカのボーイスカウトに由来するもので、「来たときよりもキャンプ場をきれいにして立ち去る」という単純なルールを強調する。
いじったらいじる前よりも綺麗にするということか。
「今回のプルリクではスコープ外とします(=綺麗さは変わらず)」としてしまうこともあるなぁ。
最近では手をつけたプルリクに関連して綺麗にできそうなところがあったら、綺麗にする用のプルリクを別途作って、それを先にマージしてから元のプルリクに戻る、という風にやることが多いかも。
コードは書かれる回数よりも読まれる回数の方が多い
確かに。だから読みやすいコードを書くようにしないとチーム全体の生産性を下げることにつながるんだよな。この言葉、意識しよう。
コメントを読み通さなければ意味が理解できないような暗号的なコードを書くよりもコメントなしで意味が自然にわかる明瞭で表現力の高いコードを書く方がいい
わかる。けど結構コメント書いちゃう派かもなぁ。コメント自体のメンテナンスも必要になってしまうから、コメント書きすぎると良くない、みたいなところはあるよなぁ。
自分の生活を完全にコントロールするためには、まず自分のために時間を使うようにするとよい。
この思考はすごく大事だなぁ。自分のための人生。自分のために時間を使おう。
過去に生きることができないように、未来に生きることもできない。考え方を変え、人生を先延ばしにするのをやめて今本当に生きることを始めなければ、目標としていた日がやってきても、次のいつかを待望するようになってしまうだろう。
自分のためにやろうと思っていたことをいまやる。今度やろう、じゃなく、いまやる。
いいチームは共通の目標を持っている。
(...中略...)
チームに属するソフトウェア開発者の場合、たとえば、ほかのメンバーがすでに進めている仕事に力を貸せるときに、新しい仕事に手を付けたりしないようにすれば、共通目標を大切にするという態度を発信できる。
『ほかのメンバーがすでに進めている仕事に力を貸せるときに、新しい仕事に手を付けたりしない』これめっちゃ良さそう...！
手元の仕事が片付いたら、次の仕事を始める前に他のメンバーに声をかけてみる、というのすごく実践しやすそう。
本にも書いてあったけど「手伝いましょうか？」よりも「その機能興味あるんで一緒にやらせてもらえないですか？」みたいな感じで話せるともっとよさそう。
アジャイル開発環境では、新しいバックログを選んでひとりで仕事をするよりも、すでにバックログに取り組んでいるチームメイトのところに行って、そのバックログを完成させるのを手伝ってから、次のバックログに手を付けよということを原則としている。
え、そうなんだ。知らなかった。アジャイル侍とかに書いてあるかな？全然そういうのちゃんと読んでないや...
優れたソフトウェア開発者とは、まわりのすべての人々の力を上げ、チーム全体の力を向上させる人物
かっこいい。なりたい。なろう。
昇進、昇格していくのは、影響力のあるソフトウェア開発者だ。それはただ単にいいアイデアを持っている人ではなく、自分のアイデアの賛成者を集めることができ、実際にアイデアを実現できる人のことだ。
文書だ！優れたアウトプット。影響力。こういう視点を常に忘れずにいよう。
リーダーシップとは、あなたの未来に対するビジョンに向かって人々があなたについていくようにすることだ。あなたが行く方向に向かわせ、あなたが切り開いた道を歩かせることだ。
そのため、あなたはその道を最初に歩かなければならない。リーダーシップとは、先頭に立つことであり、後ろから押していくことではない。
同じ方向に向かって歩いていく。先頭を歩く。後ろから押していくことではない。
ただ単に一所懸命働くことよりも、一貫性とこだわり、そして何をすべきかを知っていることの方がずっと大切だ。
「一貫性とこだわり」かぁ。正直なところ、そういう確固たる何かを持っていないんだよなぁ。
コントロールできないものをコントロールしようとせず、自分の道に入ってくるあらゆるものを受け入れるつもりになるだけで、人生はずっと楽しいものになる。ずっとワクワクするものになる。
(...中略...)
不確実性を楽しめ
自分自身をしっかりとコントロールできるようになった上で、コントロールできないものはコントロールしようとせず、受け入れる。ということか。
すべてのソフトウェア開発者はいつも何らかのサイドプロジェクトを手がけるようにすべきだと思う。小さく始め、時間と労力を注ぎ込み、完成させることを忘れないようにしよう。
やろうやろうと思っても最近できてないことの1つ。後でやろうじゃなく、いまやる。かな。
何をすべきかがわかっていることと、それがどういう結果をもたらすかがわかっていることには大きな違いがある。結果がどうなるかがわかる人はいない。だから、私たちは持てる知識を活用してできる限りのことを行い、ちょっとした失敗はつきものだと割り切りながら、プロセスを信頼するしかない。失敗しても立ち直って再び挑戦し、決して諦めない限り、最終的にはかならず成功する。
『プロセスを信頼する』って良い言葉だ。プロセスを信頼し、結果が出るまでやりきる。結果が高く評価されたらそれを「成功」と呼ぶ。
今日、たった今、決意を固めて行動を起こそう。
よっしゃ。やってこう。
