【朗報】そんなあなたに

コードを書く速度が遅いとお嘆きのあなた！！！

なんか、とにかくコードを書く速度が遅いんだけど、何が一番のボトルネックになってるんだろう ...

— Cside (@Cside_) 2014, 5月 27

あなた！！！ > id:Cside

コードを書くのがなんとなくお嘆きのあなた！！！オブジェクト指向入門第二版を読めば、大半の些細な悩みは解決することでしょう！！！

利用者の声

私も愛用しています！！！最高の本です！！！最高過ぎて前歯が折れました
滋賀県在住マリンスポーツ氏

はこべさんも途中まで読んだそうです
滋賀県在住マリンスポーツ氏

ある昼下がり、しばゆーの机に下巻があるのを目撃したんです
滋賀県在住マリンスポーツ氏

お求めはこちらから

今ならAmazonプライムに加入することで24時間無料で発送いたします(Amazonが)。

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

オブジェクト指向入門 第2版 方法論・実践 (IT Architects’Archive CLASSIC MODER)

速度

ソフトウェアが完成する速さ、コード書く速さは支配的ではないと思っていて、仕様をfixさせるまでに右往左往しないとか、うまくチームが協調して、待ち時間なくリリースまでこぎ着けられるかとか、なんかいろんな政治とか、そういう速さが大事だと思う。コード数時間で書いてその後二週間待つのは寂しい。今いるチームは素早くサイクルを回せていてうまくいってるけど、構造上待たないといけないチームもあると思う。
そういうことはありつつも、まずは自分の速さ上げるのが手っ取り早くて、コードを書く速度を上げるには、ソフトウェア知識を身につけるのが良いと思って、今一番役立ってるのが、上で挙げたオブジェクト指向入門だと思う。オブジェクト指向で書く限りは、責任を適切に配っていくのが大事で、そうすると、縦割りじゃないけど、このオブジェクトはこれは気にするけどこっちはしない、とか述べることができて、一度に気にすべきことが少なくなる。こういった考えは、この本読むまではあまり考えていなかった。責任ベースで考えると、具体的な実装の前に、どのクラスがどういう責任を持つかとか、それらに必然性があるかとか、考えることができて、よい責任や契約が明らかになったら、あとは自然に実装するだけでうまくいく。こういう裏付けをゲットすることで、毎回新しいクラス作るたびに、オブジェクト思考とは、とか言わずに済んで便利。

めでたさ重視

勢い良く開発できてるとき、これはめでたい、とかずっと言ってる。うちのチームがめでたさを大切にしているのかもしれないけど、めでたい人がヘラヘラ仕事してるだけ、と言えなくもない。めでたさを維持するためには、めでたいニュースがどんどん出てこないといけなくて、そのためには、一番ユーザーが喜んでくれそうな順に作って、どんどんリリースしないといけない。その結果、細かいマイルストーンを決めて毎週できたところまでリリースする、という雰囲気になってる。これは良くて、ずっとリリースせずにやってると飽きるけど、小出しにすると、ちょっとずつめでたさを得られる。また、最初のリリースで、こういうフィードバックがあった、とかちょっとずつユーザーの声を得て軌道修正できる。開発チームがめでたいだけでなくて、ユーザーのフィードバックを受けてよりユースケースに沿ったものを作れるので、全世界がめでたい。

なんでもいいから買ってくれ

Csideさんに本売りつけようとしたらよく分からん話になってきた。めでたさが伝わってどうにか本買ってほしい。

読者の声

エンジニアリングはリリースに支配されるのではなく、サービスまたはビジネスの成果に支配されるべき。数字として結果に出てないリリースが高速化されてもあまり意味ない
京都府在住 id:jusei さん

高速に意味ないものを作っても無駄なので、成果が出るのは重要だけど、サービスの成長のためにあれこれ考えるのは全員でやってるはずで、そのことで悩むのはエンジニアに限ったことではないと思います。昔はリーンキャンバス書くのが流行ってました。
サービスやビジネスの成果を出すためにエンジニアとしてできることは、モチベーションを保てる形ですばやく作って、高速にリリースすることだと思います。そのためには、途中でコードが崩壊したらどこにも行けなくなるので、まともな技術を身につけないといけないし、途中でやる気なくなったら何もできなくなるので、良い雰囲気で進められないといけない。