マイクロサービスってバズワードに釣られてはいけない

きっかけ

下記の記事を見て、自分なりにまとめとメモ。
なんというか、自分も釣られる側な気がして、考えが足りてなかったなと反省の念も込めてる。

マイクロサービスはもう十分 | プロダクト・サービス | POSTD

マイクロサービス

下記サイトから引用

個別に開発された小さなサービスを組み合わせて、一つのサービスを提供するというものです。

マイクロサービスとは何か？ デジタル変革の時代を生き残るための、テクノロジー入門 - Customer Success

マイクロサービスへの準備

マイクロサービスが全知全能の銀の弾丸ではない。
正と負、どちらの効果も持っており、状況次第では負の側面が多く出ることもある。

サイト内で言っていた前提条件

1. ラピッドプロビジョニング
2. ベーシックモニタリング
3. ラピッドデプロイメント

上記条件をすべて満たしていたとしても、本当に負の側面がないか考慮する必要がある。
処理を分散することの問題は、マイクロサービスにも存在しうるので、目をそむけてはいけない。

ラピッドプロビジョニング

スケールアップ・ダウンに耐えられる人材がいるかどうか。
それも一人だけでなく、複数人が各チームに散らばっていること。

ベーシックモニタリング

パフォーマンス計測手法が確立しているか？
確立してない場合、マイクロサービスで分断することによって、どこの何が原因なのか分からなくなるだけ。

ラピッドデプロイメント

迅速なデプロイ方法が確率されているか？
すべて手動の場合、マイクロサービスで分断されたサービスをすべて手作業でした場合、事故る確率は高い。

記事を読んでの感想

存在している問題点から目を背けていたかもしれない。
まだ、本格的にマイクロサービスを適用している現場に言ったことがないから、夢見てたかもしれないな。
結構、バズワードって魅力的に見えるから、飛びつきたくはなるけど、用心しなければいけない。
新手の詐欺かもしれない心持ちで、検討する必要があるなと思う。

Java9 Reactive Streams 試し実装

きっかけ

Java9のリリースが迫っているのと、ITproの記事見て試したくなったから。
あとは、Typescriptで非同期の処理を書くことが非常に多いので、Javaでもやりたくなった。

Reactive Streams

非同期処理を実現するための仕様。
非同期処理を採用しているライブラリとして、RxJava/Akka Streamsが有名。

データの流れに着目したプログラミングスタイルで、Publish-Subscribeモデルの実装ができる。
※Publish/Subscribeは、Observerパターンの発展系みたいなもんだという認識でいる。

非同期にしなければいけないってものでもないが、データを作る側と使う側が疎結合になるので、非同期処理に移行しやすくなる。

java.util.stream.Streamインタフェースとは別ものってことには、要注意。

Publish-Subscribeモデルの処理の流れ

このフローは、RxJavaも同じ。
※Akka Streamsは知らない。。。

そして、定義されているインタフェースは、下記の通り。

• Flow.Publisher
• Flow.Subscriber
• Flow.Subscription
• Flow.Processor

実装

とりあえずITproの奴を真似して作った。

import java.util.concurrent.Flow.Subscriber;
import java.util.concurrent.Flow.Subscription;

public class SampleSubscriber<T> implements Subscriber<T> {

    private Subscription subscription;
    private final String name;

    public SampleSubscriber(String name) {
        this.name = name;
    }

    @Override
    public void onComplete() {
        System.out.println(name + ": " + Thread.currentThread().getName() + ": Complete.");
    }

    @Override
    public void onError(Throwable arg0) {
    }

    @Override
    public void onNext(T item) {
        // 配布されたデータを出力する
        System.out.println(name + ": " + Thread.currentThread().getName() + ": " + item);

        // データの要求
        subscription.request(1);
    }

    @Override
    public void onSubscribe(Subscription subscription) {
        this.subscription = subscription;

        subscription.request(1);
    }

}

import java.util.concurrent.Flow.Subscriber;
import java.util.concurrent.SubmissionPublisher;
import java.util.stream.IntStream;

public class Sample {

    public static void main(String[] args) {
        SubmissionPublisher<Integer> publisher = new SubmissionPublisher<>();

        // Subscriberの生成と登録
        Subscriber<Integer> subscriber1 = new SampleSubscriber<>("Sub1");
        publisher.subscribe(subscriber1);

        Subscriber<Integer> subscriber2 = new SampleSubscriber<>("Sub2");
        publisher.subscribe(subscriber2);

        Subscriber<Integer> subscriber3 = new SampleSubscriber<>("Sub3");
        publisher.subscribe(subscriber3);

        // データの登録
        IntStream.range(0, 5).forEach(publisher::submit);

        // 非同期で処理が終わってしまうので、実行終了するまで一時的に待つ。
        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        publisher.close();
    }

}

実行結果

Sub2: ForkJoinPool.commonPool-worker-1: 0
Sub2: ForkJoinPool.commonPool-worker-1: 1
Sub2: ForkJoinPool.commonPool-worker-1: 2
Sub2: ForkJoinPool.commonPool-worker-1: 3
Sub2: ForkJoinPool.commonPool-worker-1: 4
Sub3: ForkJoinPool.commonPool-worker-2: 0
Sub3: ForkJoinPool.commonPool-worker-2: 1
Sub3: ForkJoinPool.commonPool-worker-2: 2
Sub3: ForkJoinPool.commonPool-worker-2: 3
Sub3: ForkJoinPool.commonPool-worker-2: 4
Sub1: ForkJoinPool.commonPool-worker-3: 0
Sub1: ForkJoinPool.commonPool-worker-3: 1
Sub1: ForkJoinPool.commonPool-worker-3: 2
Sub1: ForkJoinPool.commonPool-worker-3: 3
Sub1: ForkJoinPool.commonPool-worker-3: 4
Sub2: ForkJoinPool.commonPool-worker-2: Complete.
Sub1: ForkJoinPool.commonPool-worker-3: Complete.
Sub3: ForkJoinPool.commonPool-worker-1: Complete.

最初、全部表示されへん！なんでや！って思ったら、非同期処理だから終わってるから表示されないやん！って事に気づいた。
Thread.sleep入れてるのは、そのため。
なんか全部見れる上手い手ってあるものかが気になる。

感想

Filterまで紹介されていたけど、今回は基本的な部分のタッチのみ。
非同期は覚えておいて損はないと思う。
そのうち、ビルドシステムもJavaで書くようになるだろうね。
Gradleは、ピュアJavaじゃないけど、非同期での実装がやりやすくなると、効率的なビルドが実現できるのではなかろうかと、ココロの中で思ってる。
※もしかしたら、知らないだけで、もう出来てる？

ForkJoinPoolって、たしかスレッド管理のやつだったよね。
あんまり使われてるイメージはないんだけど、裏の仕組みで必須なのかな？
どっかでキャッチアップしないとダメだな。

参考サイト

最新Java情報局 - Java SE 9の非同期処理ライブラリ、新概念の「Reactive Streams」を学ぶ：ITpro

タスク

ForkJoinについて理解しておく

【書評】Being Geek

Being Geek ―ギークであり続けるためのキャリア戦略

目次

• 第1部　キャリアの形成
• 第2部　マネージメント
• 第3部　日々の仕事に必要なスキル
• 第4部　変化

読書日

2016.03.22

感想

いつもの内容まとめ。
個人の意見もメモってるので、書いてないことも書いてある。

第1部　キャリアの形成

キャリアのための行動

システム思考

ギークな人とは、世界を明確に区別できる信条を持っている人。
システム思考を絶対と考える。
通用しないときは、もろい物ができあがる。
特に人間は、システム思考に当てはまらない要素を多く含んでいる。

キャリアの青写真

キャリア > 目の前の仕事
今していること、これからすべきことを考えることは重要。
キャリアは、人事・上司の評価で充実するものではない。
ゴールを決めることで、道中にある決断をしやすくする。

大切なことは３つ

なぜか分からないが、「３」には力がある。
経済は、社会・共産・資本。勉強は、やる気・根気・暗記。
キャリアも同じく３つ。
方向性、成長、成果。

成長

成長するには、戦略が必要。
なんでも勉強するのは、時間がかかりすぎる。
また、成長しない人は、死でいるも同然である。

死んでいないかは、下記の内容をチェックする。

• 失敗を経験したか？
• 意義を唱える人がいるか？
• 学びの内容を説明できるか？

失敗から学び、恐れないことが成長することになる。

成果

他人からの評価を高めるには、有言実行しかない。
ただ、有言実行は難しい。
頼まれたことを、相手が認めるまでやりきる必要がある。
または、できないことには「No」を言う。
安易な「Yes」は、信頼を得られないだけでなく、疲弊する。
いわゆるデスマーチが起こる。

Noを言う場合は、Noといったときの評価の低下と、Yesを言ってできなかったときの評価の低下を、天秤にかける。

複雑なことを簡単に

成長は、今日が昨日の繰り返しになってはいけない。
成長の判断基準は、知識。
以下に工夫して新しいものができるかが重要。
知識を使いこなせるかが、大事。
クイズ番組は、知識を使いこなせてない人の集まりな感じ。
なぜそんなに分かるのに、それを使えないのか考えると、大した人ではないのだと感じる。
教授もそういう人が多い印象。
論文述べるのはいいけど、現場適用はあなた達が考えてくださいって姿勢に、ものすごく苛立ちがある。

転職にあたって考えるべきこと

会社が嫌いという理由では、転職するのに十分な理由ではない。
怒りは、まともな物事を考えられなくなる。
冷静なときに、出した答えが転職かどうか、よく考える。

面接での答え方

質問の種類

1. 背景を尋ねるもの
2. 問題解決能力
3. 自由回答

いづれにせよ、質問の意図を正しく理解することが大切。
とりあえずしゃべるは、悪手。
いい加減なことをいうより、「わかりません」の方がいい。

自分という人間を知らせる

質問の意図が分かって、答えが出ているなら、話すだけ。
その場合、簡潔に述べなければいけない。

面接官のボタン

面接とは、相手の情報を引き出す儀式。
面接官の情報も引き出す。

面接を担当するのは誰か

構造化された面接であれば、面接準備済みで、目的に沿って進む。
流れを読んで、質問の兆候を予測し、何を欲しているのか理解する。
構造化されてない面接の場合、面接官が準備不足。
面接が長くなりやすいが、その分、相手の情報を得られるので、攻略方法も発見しやすい。

第2部　マネージメント

企業文化

知るには、人と話すしかない。
文化は、人が作るもので、人を理解できなければ、文化を知ることはできない。
会社の文化は、行動の結果できていることが多い。
会社の核になっている可能性が高いので、常に注意している必要がある。
キャリアの形成にも影響してくる。
転職＝キャリアではない。
転職する理由が、キャリアアップって言っている人は、だいたいおかしい。
形成するキャリアの方向性が合わなかったなら分かる。

第3部　日々の仕事に必要なスキル

ナードハンドブック

ナードとは、日本でいうところのオタクに近い。
何かに熱中して、物事に精通している人間。

マネジメントのシステム

マネージャとは、他人に干渉されながら仕事する人。
扱うものが、ビットから人に変わる。
やるべきことは、戦略的に考えて忘れること。
意図的に忘れても、問題が起きないような仕組みを作ることが仕事。

タスク管理は、大まかに把握しておく。
維持に手間をかけすぎない。

プレゼンテーション

ダメなプレゼン

• スライドが多い。(MSの寺○さんかな？)
• 文字が多い（海外エンジニアに多い。漢字があるって、こういうときに役立つ）
• 1スライドに条法が多い

良いプレゼンをするには

絶え間ない練習と、機転の良さ。
失敗は、よくあること。
複数の目を持った人と話して、可能な限り一般論に近づける。
沈黙を意図的に入れて、内容に区切りを入れる。
沈黙を恐れていると、早口になって何も分からないってことがよくある。

第4部　変化

査定

• 業績の良し悪しより、仕事内容を焦点にする
• 議論であり交渉である
• 予想外なら、一旦冷静に考える

評価よりも中身を重視する。
期待されていることと、それが実際にできているかを見る。

マネージャとコミュニケーション

マネージャになるパターン

• 意志をもってなる
• 小さな選択の結果、なってしまった
• 命令でなった

すべてリスタート

エンジニアとして培ったスキルは、あまり通用しない。
今までと違うスキルが必要になる。
ミーティングの増加、抽象化のフィルタリング、変化球への対応。。。

空白

重要な人の退社

膨大な知識と技術を持っている人の場合、いれば安心だけど、実際はいなくても問題ない。
正答なのか判断しにくくなる。
不測の事態が、発生したときに問題になる。
それを乗り切れれば、後人が育ってくる。

権力・影響力が強い人の場合、文化が変わるだけ。

情報痛が辞めた場合、情報伝達が悪くなる。

全体感想

ギークになりたきゃ、戦略持って物事を学んでいくしかないってのが、読んだ感想。
何も考えずに仕事をこなしているだけでは、ギークにはなれないと感じた。
※この本だけから学んだわけではないが。。。

あと、ギークになろうと思ったら、組織にいると意外と障害があるのではないかとも思った。
それを避けて、楽してやりたいことをやるためにも、組織的な役割と問題の回避方法を知っておいて損はないだろうとも感じた。

eclipse4.7 新機能まとめ

Eclipse 4.7

毎度のことながら、よくお世話になるIDEなので、キャッチアップのために調査。
最近は、TypeScriptやっているせいか、Visual Studio Codeを起動することが多くなってしまったけどね。。。
今回は、地味めなデザインだな。
いつもは、キラキラした派手な画面の印象があるが。

公式サイト

本家

Eclipse Oxygen

Pleiades

日本語化 Eclipse 4.7 Oxygen オキシゲン | MergeDoc Project

変更内容

全部は無理なので、気になった箇所だけ。
もっと知りたい場合は、参考サイトに貼ったリンク先が内容が濃い。

カバレッジ分析

カバレッジ計測のプラグインであるEclEmmaが標準で装備。
EclEmmaにクセがあり意図しない挙動があるようだが、通ってないコードを見分けやすくなった。
以前に調べたことがあったので、そちらを参照してもらえればと。

suzaku-tec.hatenadiary.jp

Git

いろいろ操作性が改善したらしい。
自分は根っからのSourceTree派なので、あんまり興味が沸かなかった。。。
説明は、下記のリンクを参照。

Eclipse 4.7 Oxygen 新機能 30+ / Java 9 を試そう！ - Qiita

修正内容が、かなり多い。
Gitを覚えることの重要性が伺える。

トリガーポイント

ある特定のブレークポイントを通過した場合だけ、トリガーポイントに設定した箇所でとまるようになる機能。
機能の共通化している箇所で、特定のブレークポイントに入ったときにだけ、共通部分のロジックをデバックしたいことはあるはず。
それが、楽にできるようになったってことだろうね。
以前は、共通部分に入る前にブレークポイント貼って、止まったあとに、共通部分にブレークポイント貼ったりして、かなり面倒だった。

二重起動抑止

今までなかったのか。。。
eclipseは重いから、そもそも二重起動しようと思わなかった。
システム的に防止してくれるなら、誤操作で起動は減るかもね。

ウィンドウ > 設定 > 実行/デバッグ > 起動 から、「起動中に終了して再起動する」にチェックを入れる。

エディター切り替えの改善

ワイルドカードの利用が可能になった。
マウス操作しがちだから、あんまり使わないが、覚えると楽なのはたしか。
今は潤沢なメモリもあるし、コマンドによるエディタ切り替えを、覚えて損はないと思う。

参考サイト

qiita.com

大変参考になりました。

【Software Design】2017年7月号 及川卓也のプロダクト開発の道しるべ リーンキャンバス まとめメモ・感想

きっかけ

リーンスタートアップに釣られた。
たぶん、自分がいましている開発もリーンスタートアップに分類されるような気がしたから、まとめメモと感想を書くに至る。

リーンスタートアップ

起業家が一番恐れることは、作ったサービスが顧客に届く前にリソース枯渇すること。
最初に考えたアイディアが当たればいいけど、そんなことは稀。

これを成功に導くために行う考えが、リーンスタートアップ。
やることは単純で、仮設→検証→修正を繰り返すだけ。
もしくは、構築→計算→学習とも表現される。

口で言うのは簡単だが、実際にやるとなったら大変。
やることは誰かに求められているものをリソース枯渇する前に作ること。

リーンキャンバス

事業計画相当のものを１枚のキャンバスで表現したもの。

構成要素として下記の内容が存在する。

• 課題
• 顧客セグメント
• 価値の提案
• ソリューション
• チャネル
• 収益の流れ
• コスト構造
• 主要指標
• 優位性

課題と顧客セグメント

顧客にとって重要なのは、製品ではなく課題が解決されるのかどうか。
課題が明確化してないのに、それを解決できる製品は売れなくて当然。

そして、その課題をどのような顧客が持つのか具体化することで、付加価値を高めるのは何なのかを明確化できる。

価値提案

どのように位置付けられるかを示す。
既に存在している別製品のメタ表現が期待されている。

ソリューション

課題を解決する機能。
ラフでＯＫ

チャネル

顧客へ届ける手段。

収益の流れとコスト構造

ビジネス起こすんだから必須の考え。
事業をどうやって成立させるのか考える。

主要指標

製品の有効性を測るために見るべき指標を決めておく。
複数見ることもある。
段階や見るべきタイミングも考慮しておく。

優位性

強豪が簡単に真似出来ないものを考える。

感想

起業家の視点が足りてないからだろうか？
あんまり頭に入ってこなかった感じ。
なんかのシステム開発に望む時は、ココらへんをもうちょい意識してやってみよう。
たいてい、隠されていて、何考えているのか分からんところが多いけどね。。。
何年もシステム開発できるとも限らないし、起業家の考えは早めに身につけたいな。

【雑記】Typescriptと充実感が得られてないと感じた原因の考察

きっかけ

仕事でTypescript使っているけど、なんか仕事しても充実感？達成感が得られないので、考察した結果をメモる

現状

やっていることは、データの橋渡し。
ハードからあがってきた情報を、クラウドへ打ち上げる前くらいのところを担当している。

クラウド上に展開されているアプリに食わせるために、データを加工しているのが主な仕事かな？
あとは、ハードからあがってくる情報を抽象化するってのもある。

考察

おそらく、グルーコードばかり書いているからだろうと思われる。
なんというか、結果がダイレクトに見えるところじゃないからかも知れない。
ハードは、操作が関係してくるから、作ったら操作して動けば、嬉しいと思う。
しかし、俺が作っているのは、ハードの凄いコードが打ち上げてくるデータの加工。。。
どうしても、ハード側のコーディングの方がすごそうに見えてしまうってのが、心の中である。

前まではJavaばかりやってきたので、ネイティブ系のプログラミングには、憧れがあるのかも知れない。
Javaエンジニアなら、共感してくれる人が多いと信じたい！
無性にWebと関係ない箇所のプログラミングをやってみたいって感覚に、とらわれる事がある。

やっていることは、重要なことだと思うけど、それを実感しにくいんだよね。。。
バグが起きたら、障害切り分けのために真っ先にこっちに問い合わせがくるのも、結構シンドイ。。。
最初は、分かんないことが多すぎて、いろんな人に聞いて回ったりするのが、心理的にくるものがある。
おかげで、全然関与してない部分のログを見れるようになってしまった。

これからどうするか

書いて思ったが、意外と俺凄いんじゃね？って思えてきた。
実感しにくいのが、問題だね。。。
振り返ると、意外と凄いことしてたんだなと思う。
システムの全体像を把握しているわけなんだから。
ただ、自画自賛はちょっとキモいって感じるけどね。。。

仕事で充実感を得られなかったら、たまに振り返って、やってきたっことを見直すのはありかもしれない。
成果が見えにくいならなおさら。
たまに、振り返りの機会をもうけようと思う。

【WEB+DB PRESS】Vol.99 良いコードってなんだろう？まとめメモ・感想

目次

• 良いコードを書く理由
• 変数、定数、メソッド
• クラス
• モジュール
• チーム開発でのテクニック

感想・まとめメモ

良いコードを書く理由

良いコードとは？

• 仕様通りの挙動
• 可読性
• 将来の変更に強い

仕様通りの挙動

バグが無いことの証明はできない。
証明する場合は、悪魔の証明になる。
仕様通りに動いていることを証明するためのテストと、それに向けてのコーディングは、良いコードを書く上の前提だということ。

可読性

名前を適切につけて、読む人に分かりやすくする。
個人的には、理解するまでの時間が最短になるようにするってのが重要だと思う。

変更に強い

これは、簡単なようで実は難しい。
若手の頃はよくわからなかった。
どうやって変更に強くすればいいのかと、毎回疑問に思っていた。
要するに、絶対的な価値をどこに置くかの問題。
ソフトウェア開発なら、ビジネス仕様が絶対。
ビジネス的に変わらない箇所と、変わる可能性が高い箇所を判断して作る。
ビジネスを理解することが、変更に強いソフトウェアを作ることの第一歩だと思う。

絶対良感を育てよう

雑誌で言っていた意味は、良いコードを見たときに、それが何故良いのか説明できる能力のことだそうな。
個人の主観によるのでは？とも思ったが、それを身につける方法は納得。
身につけるには、OSSを見たり、フレームワークのコードを追うなど。
良いコードについて議論するのは、周囲の人の民度によるかもしれないね。。。
たまにマサカリ好きが居たりもするからね。。。
良いコードの議論となる対象は、議論する人が書いてないコードがいいと思う。

あとは、常にコードを書くこともあった。
やろうと思うんだが、なかなか題材が見つけらないんだよね。。。
家に帰ると、どうしてもアニメみたりゲームしたり、ポケモンGoやって帰りが遅くなちゃったりする。
おそらく、常日頃からコーディングする題材を探すようなマインドがないとダメなんだろうな。
なるべくそうするようにはしているが、実践は難しい。

変数、定数、メソッド

変数

悪い変数は、情報量が少なく、理解を妨げる。
良い変数は、スコープが狭く、変数名で意図が伝わる。

スコープを狭くするは、激しく同意！
たまに、クラス変数・メンバ変数を気軽に使うヤツがいるが、かなり危険。
どれくらい危険かと言うと、いろんな洗剤をバケツに入れるくらい。混ぜるな危険だ！
何でかというと、どこでどう制御しているのか、分からなくなる可能性が高い。
今は大丈夫でも、ソフトウェアが進化したら、複雑化してワケワカメになる。
だから、作る時は、なるべくスコープを狭くしてやることが大事。

定数

定数を使うのは、だいたいマジックナンバーを減らすことが目的な事が多い。
ただし、マジックナンバーを減らすためにマジックナンバーの名称そのままでネーミングするのはダメね！
マジックナンバーの定数を切る時は、そのマジックナンバーの意味を定数名にしないと意味ない。

たとえば、Javaで例をあげると下記みたいなのはダメ。

public static final int TWO = 2

これ、なんの数値なのか全然分からへんがな！ってなる。
たまに、こういう変数名をつける輩がいるので、レビュー時は注意しないといけない。

メソッド

メソッド切り分けする理由

• 関心ごとの集約
• 再利用性を高める

つまり、DRY原則に従えってこと。
過度な原則の適用は注意。

メソッド名

• 簡潔
• わかりやすい単語
• やりすぎない

詰め込まず、やりたい関心事に細かく分類して、名称をつけてやれば、基本的に上記は満たせると思う。
メソッド作って満足せず、見返して、詰め込み過ぎてないかチェックする習慣をつけないとダメだね！

テストしやすいメソッド

テストしにくいメソッドは、だいたい関心事の分離ができてないことが多い印象。
作ってテストしにくいと思ったら、そのままテストコード作るんじゃなくて、作ったコードを見直す。

あと、テストしにくいコードは、開発者に負荷がかかりやすいので、必ず見直した方がいい。

名前の付け方

• 英語の辞書を使う
• 著名なライブラリ、フレームワークを参考にする
• GitHub検索
• 類義語辞典
• 意見を求める

自分は、codicってサイトをよく使う。

codic - プログラマーのためのネーミング辞書

ドンピシャなネーミングをつけてくれるので、結構使う。
ネーミング規約とかある場合でも、参考にはなる。

絶対的な価値観を自分に置かないことだと思う。ネーミングは。
結局のところ、読み手がわかりやすくないといけないから、ネーミングに迷ったら、だいたい自分は近くの人に聞いて、意味が通じるかを試す。

クラス

かなり難しいんだよね、クラス分割って。。。

責務の分割

責務分割は、鬼門。
経験が浅いと、余計な分割をしまくって、クラスのメリットが薄くなる。

システム全体を見て、登場人物達がクラスにあたるハズなので、いきなりクラス設計せずに、全体の概要を掴むことを優先する。
全体像がつかめたら、あとは責務について自問自答。
下記の点について確認する。

• 責務が集中してないか？
• 責務がかぶってないか？
• 責務の境界は明確か？

デザインパターン

GoFが考えた設計のパターンのこと。
ココらへんは、ググるかwikipediaの内容を見れば大丈夫だと思う。

デザインパターン (ソフトウェア) - Wikipedia

雑誌で紹介されていたのは、FacadeとStrategyの２つ。

Facade

複雑な手続きを誰かに代行してもらおうというパターン。
個人的な感覚ではあるが、使い方を間違っていることが多い気がする。
なんというか、別のクラスにアクセスするための通り道みたいな感じ。
直接呼べばいいやん！ってことが往々にして感じる事がある。
手順の簡略化が、たぶん主目的だと思う。
手順がないようなクラスのために、Facadeを作るんじゃねぇ！って感じかな？怒りの原因は。
日本語訳で「玄関」みたいな感じになっているから、どこかのアクセスするために通過させる場所みたいになっている気がする。

Strategy

アルゴリズムの付け替えパターン。
Stateパターンもほぼ一緒。取り替えるのが、アルゴリズムか、変数かの違い。
例ではcase文使っていたけど、そうすると値を追加する毎に検索方法変わってないよね？が必要になるから、個人的には反対。
やるならenumでキーとアルゴリズムを持たせて、while文で検索させる。
※Rubyでできるかは知らない。。。

コイツは、マジでよく使うから、覚えた方がいい。
だいたいビジネスは、決まった値のときに挙動を帰ることが多い。
それを安全にするためにも、Strategyの習得は必須。
拡張性も高いしね！

モジュール

モジュールの概念に深く関わってないから、あんまり個人の考えはないんだよね。。。

Java9を見ていると、依存関係の解決が主目的かな？ 時期的に、今見てもふ～んで終わりそうなので、サラッと見て終わり

チーム開発でのテクニック

チームで開発するから、改修しやすいように作ることが重要。

コードレビュー

• 他人に説明できるように作る
• 見通しの良さ
• 属人化防止

相手の理解を助けるコードを書いていくことに重点を置くことが大事。
あとは、メンバーと対話して、チームの価値が何なのかを決めにいく行為も大事。

システム開発

結論としては、ゴールの共有が重要って感じだったかな？
XPについて触れられていた。
あんまりXPって理解してないんだよね。。。
今度、勉強してみよう。

ソフトウェアアーキテクチャ

アーキテクチャは超重要。
なにも考えないで作ると、小手先でなんとかできない問題にぶつかることは必ずある。
最初から考えろは無理だと思うので、問題の都度、どれがいいアーキテクチャなのか、よく考える必要がある。

アーキテクチャでやることは、大きな単位での役割分担を考えること。

関連書籍

この内容読んでたら、やっぱり脳裏には「リーダブルコード」がよぎるわ。。。
あれ、かなり良書だったと、今でも思う。

suzaku-tec.hatenadiary.jp

今後の自身のタスク

• XPを学ぶ
• コーディングを習慣化する
• コーディング題材を探すクセをつける