エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

自己分析

f:id:suzaku0914:20170924163046p:plain

分析

Web系
特にJavaは得意。
TypeScriptのおかげで、唯一苦手だった動的型のJavascriptが、TypeScriptをクッションに克服できた気がする。

Gitも最近使えるようになってきたし、開発系のキラキラワードは、ある程度使えると思う。

問題は、概念的な考えが抜けてるような気がする。
機械学習やAI開発経験がないのがキツイ。
Python, Scala知ってるから機械学習するための下地はあるのだが、業務に耐えられる知識がないのが痛いな。。。

開発に至っては、経験則から未経験言語でも習得できる自信がある。
最近習得したTypeScriptは、未経験だったけど、思ったより簡単に覚えられた。
Javaの知識が活かせる言語は、問題なさそう。

VBA使えるから、Excelでドキュメント書いてあるのは、ある程度自動化できる。
個人的には、バージョン管理しやすいMarkdownの方が嬉しいが。

DB関連が全てRDBだけってのは、ちょっとネックな気がする。

Java9リリースと所感

Java SE Development Kit 9 - Downloads

リリース

日本時間9月22日未明にJava9がリリースされた。

たぶん、そのころ「やはり俺の青春ラブコメはまちがっている。」を読み終わって感想ブログ書いてる頃だわ。

難産だった

初めて知ったのは、Java8リリース前くらいかな?
そこから、何回か延期があったので、そうとう難産だったのだろうと思う。

パブリックレビューで否決された時は、どうなるかと思ったが、ちゃんとリリースまでできたね。
早期ビルドのころからいろいろ試して来たので、ここでスルーされるのは、ちょっといただけないな~とは思ってた。

注目

注目している機能は、何と言ってもモジュール化。
いろいろ依存関係で苦戦したことがあるので、なんとしてでも覚えて活用できるようにしておきたい。

あと、気にしなければいけなのは、Stream系のAPIの変更かな?
特にReactive Streamは、覚えておいて損はない気がしている。

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

Jshellも注目だね。
おそらく、開発よりも運用系で使われそうな気がする。
インフラエンジニアも視野に入れたいから、覚えておきたい。

これからすべきこと

  • モジュール化の理解を深める
  • Jshellの活用方法の模索
  • 実験的機能を試してみる

機能100%使いこなせる自信がないので、早めに使えるようにしておきたい。
あと、実験的な機能は、今後に影響ありそうなので、キャッチアップしておいても損はない気がする。

Java9のアップデート

6カ月ごとでアップデートは、まだ提案段階なのね。。。
なんか情報が錯綜してる気がする。
提案が出てきた意図は、セキュリティやバグフィックスだろうか。
JavaOneで何かしら発表ありそうな気がする。
JavaOne報告会を待つとしますか。

関連記事

[速報]Java 9が正式リリース、Javaをモジュール化するProject Jigsawがついに実現。今後のJavaは6カ月ごとタイムベースのアップデートへ - Publickey

2017年9月22日 Java 9が正式リリース,「Project Jigsaw」をようやく実装:Linux Daily Topics|gihyo.jp … 技術評論社

【書評】ソフトウェアアーキテクトが知るべき97のこと

ソフトウェアアーキテクトが知るべき97のこと

ソフトウェアアーキテクトが知るべき97のこと

目次

  1. システムの要件よりも履歴書の見栄えを優先させてはならない
  2. 本質的な複雑さは単純に、 付随的な複雑さは取り除け
  3. 最大の問題は、たぶん技術的なことではない
  4. まずコミュニケーション、そのための明快さとリーダーシップ
  5. パフォーマンスの決め手はアーキテクチャ
  6. 要求仕様の本当の意味を探れ
  7. 立ち上がろう!
  8. すべてのものは、かならずエラーを起こす
  9. それは交渉だということに気付け
  10. 定量化を求めよ
  11. 500行の仕様書より1行のコード
  12. フリーサイズのソリューションを求めるな
  13. パフォーマンスの検討に早過ぎるということはない
  14. アーキテクチャーとはバランスをとること
  15. 犯罪的なコミットエンドランを防ぐには
  16. 選択肢を1つに絞らないための現実的な方法
  17. ビジネスサイドに主導権を渡せ
  18. 一般性より単純性、再利用よりもまず最初に使えること
  19. アーキテクトは手を汚さなければならない
  20. 継続的にインテグレーションを実行せよ
  21. 日程による失敗を避けるために
  22. アーキテクチャーではトレードオフは避けられない
  23. 要塞としてのデータベース
  24. 不確定性が潜むという感覚を磨け
  25. 鏡に映る問題は見かけよりも大きい
  26. 再利用は、アーキテクチャーだけではなく人と教育の問題と心得よ
  27. アーキテクチャーにI(自我)なし
  28. 地上300mからの目
  29. 選ぶ前に試せ
  30. ビジネスドメインを理解せよ
  31. プログラミングは製造ではなく設計だ
  32. デベロッパーに自己裁量を与えよ
  33. 時間がすべてを変える
  34. 「ソフトウェア・アーキテクト」のAは小文字だけ。それで満足せよ。
  35. 大きなスコープは敵
  36. 役者ではなく執事になれ
  37. ソフトウェア・アーキテクチャーが論理的な意味を持つことを考えよ
  38. 摩天楼はスケーラブルではない
  39. 未来はヘテロジニアスとともにある
  40. パフォーマンスがまず大事
  41. ダイアグラムの空白に注意せよ
  42. デザインパターンに習熟せよ
  43. 状況がなによりも大切
  44. ドワーフ、エルフ、ウィザード、キングの4種類の人々
  45. 建物のアーキテクト(建築家)から学ぼう
  46. 繰り返しと戦え
  47. 現実の世界にようこそ
  48. 支配せず、観察せよ
  49. アーキテクトは2つの顔を持つ
  50. アーキテクトは境界とインターフェイスに注意を注げ
  51. デベロッパーに力を
  52. 理由を書き留めよ
  53. 暗黙の仮定、特に自分自身ものを疑え
  54. あなたの知識と経験を共有しよう
  55. パターンの病理学
  56. たとえ話の使いすぎに注意
  57. アプリケーションの保守に力を入れよ
  58. 3つから2つだけを選ぶ覚悟を決めよ
  59. 趣味や個人的な意見ではなく、原理原則に従え
  60. 動くスケルトンから始めよう
  61. データがすべて
  62. 単純なものは単純に
  63. アーキテクトは何よりもまずデベロッパーであれ
  64. ROI変数を意識せよ
  65. 目の前にあるのはレガシーシステムだという前提で設計せよ
  66. 解決策が1つしかない場合には、セカンドオピニオンを求めよ
  67. 変化の影響を把握せよ
  68. ハードウェアの理解も必要
  69. 今の近道、後で大損
  70. 「完璧」は、「十分よい」の敵
  71. 「よいアイデア」を避けよ
  72. 優れたコンテンツは優れたシステムを作る
  73. 怒れるアーキテクトとしてビジネスと対立するな
  74. 主要な指標の耐久性をためしてどこで壊れるかを確かめよ
  75. 設計するならコーディングできなければならない
  76. 他の名前でバラを呼べば、キャベツにしかならない
  77. しっかりとした問題には高品質のソリューションが与えられる
  78. 勤勉さが必要
  79. 自分の判断に責任を持て
  80. クレバーになるな
  81. 武器は慎重に選べ、用意に手放すな
  82. 本当の顧客は目の前の顧客ではない
  83. 設計した通りにはならない
  84. フレームワークは相性で選べ
  85. 強力なビジネスケースを作れ
  86. コードだけではなくデータをコントロールせよ
  87. 技術上の借金は返済せよ
  88. 問題を解こうとするな
  89. システムは用具的に作れ
  90. 問題解決に情熱を注げるデベロッパーを探して手放すな
  91. ソフトウェアは実際には存在しない
  92. 新しい言語を学べ
  93. 未来永劫安泰なソリューションはない
  94. ユーザーの拒否感情の問題
  95. コンソメの重要性
  96. エンドユーザーの立場からはインターフェイスこそがシステム
  97. 優れたソフトウェアは構築されるのではなく、成長する
  98. アーキテクチャは縦と横の基本構造を持つ
  99. ビジネス・アーキテクトを目指せ
  100. 問題にフォーカスせよ
  101. 問題にとらわれるな
  102. 煩雑なことを非属人化し、創造性を高める
  103. 手段的な技術と陳腐化しない本質的な技術
  104. 開発スタイルをデザインする
  105. システムではなく、コミュニケーションをデザインせよ
  106. 移り気な利用者を捉える
  107. 受動的アーキテクトと能動的アーキテクト
  108. 説明責任を果たす

感想

システムの要件よりも履歴書の見栄えを優先させてはならない

最新テクノロジーを知っていることも重要だが、顧客をないがしろにしてはいけない。
プロジェクトでは、新しいテクノロジーより正しいテクノロジーを使うことを心がける。

本質的な複雑さは単純に、 付随的な複雑さは取り除け

本質的な複雑さとは、問題自体の難しさ。
付随的な複雑さとは、問題の難易度を下げるための処理から出て来る問題のこと。

開発者は複雑な問題を解くために集まってくるが、付随的複雑さを量産してしまうこともある。
開発者が本質的な複雑さと向き合えるよう、環境を整えてやるのがアーキテクトの仕事。

最大の問題は、たぶん技術的なことではない

プロジェクトの失敗をテクノロジー的なせいにしがちだが、実際は人間関係が原因なことが多い。
プロジェクトは、人間が構築しているものなので、成功・失敗の鍵は人間になる。

一番重要なのは、意思疎通・話し合うテクノロジー。
知識だけでなく、相手を尊重して会話がしやすい雰囲気を作る。

まずコミュニケーション、そのための明快さとリーダーシップ

アーキテクトは、プロジェクトの目的・目標を伝える必要がある。
そのためには、明快さとリーダーシップが必要になる。

明快さは、長文よりも簡潔な文。
図もシンプルにして、細かい決定よりもアイディアの共有をする。

リーダーシップは、意思決定と理由をセットで伝えることを心がける。
そうすれば、開発者と協力して開発できる。

パフォーマンスの決め手はアーキテクチャ

ミドルウェアの変更だけでは、パフォーマンスは上がらない。
チューニングも同じ。
パフォーマンスを上げたければ、ロジックの整備を行うことが大事。
アーキテクチャがシステムに与える影響はデカい。

要求仕様の本当の意味を探れ

要求したものが問題解決になってないことがある。
ユーザに「なぜ」という質問をしやすいように誘導し、真の問題を探る。
人は、暗黙の前提がある状態で話をしてしまいがちなので、回答内容には注意する。

立ち上がろう!

アーキテクトの仕事は、人に説明することが多い。
説明は、立ってしたほうが効果的。
たってすれば、ボディランゲージしやすいし、声も届きやすい。
だから、立ち上がることから始めよう。

すべてのものは、かならずエラーを起こす

自動化した場合、ヒューマンエラーは減らせるが、手数を省いたエラーは増える。
人よりも汎用的なエラー対処システムはない。

システムは、自動化の塊のようなもの。
だから、エラーがないとは言えない。
エラーが起きない前提は辞めて、受け入れて対処を考えるほうが効率的。

それは交渉だということに気付け

本当に必要か聞かれても、「なんとかなる」ような回答をしてはいけない。
その後の条件は、大抵聞いてない。

この話を聞いて、「2位じゃなダメなんですか?」って言ってた奴を思い出した。
たぶん、このときも「ダメじゃないです」の後に、いろいろ言ってたけど、聞き入れてないんだろうな。
これは、説明ではなく、投資やめる前提の交渉だったんだろう。
それを理解して交渉できなかったから、交渉に負けたのだろう。
というか、やり方卑怯すぎんだろう。。。

定量化を求めよ

アーキテクトの役割は、曖昧なことをシステム化すること。
指標化することを心がける。
指標化できないものは、やるべきではない。
なぜなら、指標化できないものは、あまり重要ではないことが多い。

500行の仕様書より1行のコード

設計は、重要ではあるが、注力しすぎると成果できずに終わる。
目標を達成するための手段であって、成果ではない。

フリーサイズのソリューションを求めるな

パターンは、いつ使うかの見極めが重要。
問題解決には、見極めが必要。

パフォーマンスの検討に早過ぎるということはない

非機能要件は、後回しにしがちだが、早い段階で基準をつくって監視したほうがいい。
あとになってリスク低減、チューニングコストも抑えられる。

アーキテクチャーとはバランスをとること

技術問題のクリアだけでは不十分。
技術要件とビジネス要件のバランスを取る必要がある。

犯罪的なコミットエンドランを防ぐには

コミットエンドランとは、コンパイルしてコミットしたもので、自動テストなしのこと。

コミットエンドランは、プロジェクトにとっては犯罪的な行為で、手戻り工数が大きくなる可能性が高い。
リスクが高いにも関わらず、起こるのは、ビルド・テストに時間がかかりすぎるから。

人に制限を科すより、そうしない環境整備を・やろうと思う理由を無くす必要がある。

選択肢を1つに絞らないための現実的な方法

技術領域は、選択肢を絞ることが可能。
しかし、ビジネス領域は、複数の技術領域にまたがり複雑。

システムを分割可にしておき、ビジネス要件の変更に対応できるようにしておいたほうが、将来的に楽できる。
ビジネスは曖昧なもので移ろいやすいから、対応能力が高いほうがビジネス的には嬉しい。

ビジネスサイドに主導権を渡せ

アーキテクトは、ビジネスとテクノロジーの仲介が役割。
企業の目的と経営の現実化について、技術的な決定を下す必要がある。

ビジネスサイドに主導権を握らせるためには、、開発状況をフィードバックさせる必要がある。

ビジネスサイドが方向性を示さない場合、開発者がビジネス判断しなければいけなくなり、本来の目的から外れる可能性が高い。
アーキテクトは、ビジネス目標・指標をビジネスサイドに決めさせるように動く。
開発者が下す小さな判断が、ビジネス目標を変えないように注意する必要がある。

一般性より単純性、再利用よりもまず最初に使えること

汎用性の追求は、選択肢が多いゆえに誤用の問題がついて回る。

汎用化は、問題の本質を解決するためのもの。
問題を理解しているからこそ、単純でなければいけない。
汎用化することが目的になると、現実が見えなくなり、複雑度が増すだけなので、問題がなんなのかは常に考えて頭に入れておく。

汎用性は、無条件ではない。
ある特定の状況で柔軟に対応できるようにするのが汎用性であることを、十分に理解しておく。

アーキテクトは手を汚さなければならない

アーキテクトは、チームをリードしなければならない。
そのためには、メンバーができることはすべてできる必要がある。
つまり、テクノロジーについては、誰よりも詳しい必要がある。

優れたアーキテクトの条件

  • 問題点の発見
  • 犯人探しより問題の掲示
  • 優れた解決・回避策の掲示
  • 専門分野に関してエキスパート
  • 自らを模範とする

継続的にインテグレーションを実行せよ

CIは、インテグで問題を起こさないためのリスク管理術。
リスク管理だけではなく、開発状況の把握・調整など開発者間の共通認識のための素材としても使える。

開発の安定化、統制を取るためにもCIは必須。

日程による失敗を避けるために

プロジェクトの失敗の大半は、計画なしの日程変更。
日程変更がある場合、作業量について考え、交渉する能力が必要になる。
説得させる能力が日程調整に必要だということを意識しておく。

アーキテクチャーではトレードオフは避けられない

すべての要件を満足させると、システムはバランスが悪いものが出来上がり、結果的に何もできなくなる。
やるなら、適材適所で専門職を上手く使うことが必須。

要塞としてのデータベース

データは、永遠に残る。
データにバグが有ると、致命的になりやすい。
データモデルを安全に作るには、なるべくアプリ層と分断して独立性を保ち、整合性を保つことが重要。

不確定性が潜むという感覚を磨け

選択肢が複数あるのは、システムに不確実性があるから。
意識説に容易なアーキテクトを採用すると、今後の設計に重大なインパクトを残す。

選択肢が単一や選択肢に大差がない場合は、判断条件が足りてない可能性が高い。
判断を先延ばしにしたほうが無難。
その場合は、次の判断タイミングが送れないように注意が必要。

鏡に映る問題は見かけよりも大きい

よく起きがちな問題

  • 小さな問題がいつの間にか重大問題になっている(依存関係とか)
  • 楽観的に物事を考える
  • メンバーの関心事がプロジェクト目標になってない
  • 他人を受け入れない・容認できない

乗り越えるための工夫

  • リスク管理のためのバグトラフィック
  • 多様性に価値観を置く
  • 「いやなにおい」を嗅ぎ分ける(ポケモンの技かな?)
  • 単純なテスト方法の模索
  • 盲点(認識しにくいもの)を無くす

再利用は、アーキテクチャーだけではなく人と教育の問題と心得よ

再利用の条件

再利用できるものがあることを知っている

あると思わないと、利用されない。
利用できるものを見つけたら、それを保持して使えるチャンスを待つ。

使い方を知っている

使い方を覚えるのは、能力と訓練に左右される。
正しく使えば、効果を最大限に得られる。
その努力をしなければいけない。

自作するよりも再利用したほうがいいと思う

問題を自分で解けないことを恥だと思ってはいけない。
コストを賭けるべき場所なのか、よく考えて再利用する/しないの判断を下す。

アーキテクチャーにI(自我)なし

アーキテクチャにありがちなこと

  • 過去の成功から傲慢になる
  • 設計に自己投影(自分の作品への批判を避けるために相手を攻撃する)

対策

  • 要件を正義にする
  • チーム重視して作品の私物化を辞める
  • 仕事にチェックを入れる
  • 自分自身を振り返り、他人への敬意を払っているか反省する

地上300mからの目

ソフトウェアの品質は、内外で別れる。
ソフトウェアの価値を測るには、いろんな視点が必要になる。
プロジェクトにあった測定内容を複数用意して、変化の方向を把握し、柔軟に対処することを心がける。

選ぶ前に試せ

システム開発とは、判断の連続。
何かを決めるには、判断材料が出揃うまで安易に決めてはいけない。
何かを決める前に、その判断が正しいのかを試してから下す。
労力はかかるが、最適解でなかった場合のリスク回避・絶望回避には必要。

ビジネスドメインを理解せよ

ビジネス知識がないと、問題の理解や対策が取れない。

アーキテクトとして成功するには、広い技術知識とビジネスドメインに対する深い知識が必須になる。

プログラミングは製造ではなく設計だ

プログラミングは、建築プロセスではなく、学習・発見のプロセスに近い。

規定してから構築は、変更ができず、開発の邪魔をする。

ソフトウェア開発を最大限活用するには、予測できないものにたして、柔軟に対応できること。
それを阻害するのは、リスクを減らせていない。

デベロッパーに自己裁量を与えよ

アーキテクトがすべてを命令していては、本来やるべき仕事ができなくなる。
開発者の監視に注力するのではなく、各開発者が疑問に思ったことを質問しに来る環境を作ることが大事。

時間がすべてを変える

時間が教えてくれるもの

  • 適切な課題が選択できたか?
  • シンプルに作れたか
  • 古いものに満足せよ

「ソフトウェア・アーキテクト」のAは小文字だけ。それで満足せよ。

小文字である意味が理解できない。。。
文化的な何かがひそんでいるのだろうか?
翻訳する人には、そこら辺の違いを意識した上で、翻訳して欲しいな。。。

大きなスコープは敵

スコープの拡大は、失敗しやすくなる。
なぜなら、見積もりがハズレた場合の影響がデカくなり、チーム開発のやり取りが急増する。

回避するためには、本来のニューズを把握し、優先順位をつけて早くシンプルに対応しておく必要がある。

役者ではなく執事になれ

アーキテクトは、顧客のために行動しなければならない。
エゴで言動を変えてはいけない。

特に、バズワードに踊らされているようでは、アーキテクトとは呼べない。

ソフトウェア・アーキテクチャーが論理的な意味を持つことを考えよ

ソフトウェアの影響は大きい。
ユーザに制約を課す時は、慎重に考える。
決して自分が楽をするために、ユーザに制約を課してはいけない。

摩天楼はスケーラブルではない

ビッグバン的なデプロイは、失敗しやすい。
成功するためには、小さな単位でデプロイする必要がある。
小さくデプロイすることで、失敗の要因を突き止めやすくなる。
また、小さくデプロイするためには、システム分割が明確にできている必要があり、インタフェースの定義が明確化されている必要がある。
そのため、小さくデプロイすることで疎結合なシステムを作りやすくなる。

未来はヘテロジニアスとともにある

ヘテロジニアスとは、別々の領域で別のテクノロジーを使っていること。

今のアーキテクチャは、限界が見えてきたので、対象領域に最適化されているテクノロジーを選択して、生き残りの算段を考えておく必要がある。

パフォーマンスがまず大事

パフォーマンスはシステムに取って重要。
遅すぎては、使い物にならない。

ダイアグラムの空白に注意せよ

ダイアグラムの間には、矢印だけではなくいろんな要素が介在している。
ハード的な要素を省略しているだけで、実際にはあるので、知らなければいけないことが隠されている。
そういうものがあることを認知しておけば、より安全にことを進められる。

デザインパターンに習熟せよ

デザインパターンは、ソフトウェア開発の基本。
アンチパターンは、罠を回避するために必要。

パターンを学んで、実行・適用することがアーキテクトに課せられた課題。

状況がなによりも大切

自分がどのような状況にあるのか、よく把握する。
把握できないと判断ミスにつながり、あとでツケを払うことになる。

ドワーフ、エルフ、ウィザード、キングの4種類の人々

ドワーフ → ハードワーカー
エルフ → 才能特化
ウィザード → 効率高い
キング → 人を協力させて成果を出させる

アーキテクトは、キングのように振る舞う必要がある。

建物のアーキテクト(建築家)から学ぼう

  • アーキテクトの役割は調停
  • エラーは隠さず、破壊を恐れない
  • 完璧なものなどない。不完全を容認する

繰り返しと戦え

コピペは問題に注力してないので、不要なコードがないとは言えない。
重複は、作業の遅延を招く。
何もしなければ重複は取り除かれないので、見つけたらトラフィックする習慣が必要。

現実の世界にようこそ

連続した世界で、あらゆる事象が並列実行される。
だからといって、逃避してはならない。
現実にたいして人間は古くから対応できている。
システムも対応できるハズ。

支配せず、観察せよ

すべてを支配するアーキテクチャは、密結合になりやすい。
完全なコントロールがなくすことが、今後のアーキテクチャの課題になる。

アーキテクトは2つの顔を持つ

プロジェクトは、相反する要件を含むことがある。
両立するように調整するのがアーキテクトのお仕事。
そして、その変化に対応できるように全力を尽くすのが、持つべきマインド。

アーキテクトは境界とインターフェイスに注意を注げ

大きな問題に対応するには、問題を分割する必要がある。
分割統治をして、複雑な問題に取り組む。

分割統治するためには、問題領域の境界を明確化し、名前付けをする。
各問題の関係を洗い出し、それぞれどのように関係しているのか分かるコンテキストマップを作る。
そうすれば、システムを見通せて、問題解決の方法を考えたり、現状を説明する資料として使える。

デベロッパーに力を

ソフトウェア開発は、チームでするもの。
なので、アーキテクトは開発者の力が発揮できるように尽力する必要がある。
そのためにすべきことは、以下。

  • 開発者に力をつけさせる
  • 採用活動に参加してチームを強くする
  • ロードマップの作成
  • 過度な制約の廃止
  • 本質的でない仕事から開発者を守る

理由を書き留めよ

ドキュメントの価値は、人によって違うが、アーキテクト選定の議事録は、開発者に与える影響が大きい。 作ることで得られるメリットは以下の通り

  • 原則について会話する材料になる
  • 反論が正しいか判断する基準になる
  • 引き継ぎ
  • 基礎の確立
  • 設定の見直し

暗黙の仮定、特に自分自身ものを疑え

経験的証拠のない仮定・思い込みは、後戻りできなくなる前に正しいか確認する。
技術は日進月歩で進化しているので、思い込みによる指向の固定化は危険。

あなたの知識と経験を共有しよう

知恵を引き出すには、他人に説明して倫理の穴を見つけてもらうのが一番楽。

失敗から学ぶためにも、共有して議論をする必要がある。
基礎にする前に、それが誤りではないことを確認した方がいい。

パターンの病理学

自分が博識であることを自慢するために、問題領域にパターンを適用するのは危険。
不必要にパターンをもちいるのは、作り過ぎや複雑化に繋がる。
誤用を誘発するので、誘惑に負けず、冷静な判断を下す。

不必要なパターンが適用される例として、自動コード生成されたソースを見ると、心底そう思う。
特に誤用が多いのが、Facadeパターンだと思うね。
まとめる必要性を感じないのに、単純アクセスでもFacade噛ませてあったりして、ムダなコードが増えてる事が多い。
コーディングは、まだ人の領域で、何も考えてないコピペマスターは、淘汰されることを切に願う。

たとえ話の使いすぎに注意

メタファーや比喩は、複雑で曖昧なものを理解するために必要。
プロジェクト創成期には、薬にはなるが、成熟してくると、都合のいい解釈をしたり、ビジネス問題より優先してしまうことがあるので、毒に変わることがある。
メタファーに振り回されすぎない注意が必要。

アプリケーションの保守に力を入れよ

保守に思いつき対応はNG。
システムのライブサイクルの大半は保守なので、注意してないとすぐにモンスター化する。

本番稼働を成功させるためには、早い段階から保守の観点を取り入れ、開発を勧める。
開発者と保守者では、スキルセットが違うので、視点が足りてないことがあることを理解して開発をすすめる。

3つから2つだけを選ぶ覚悟を決めよ

全てを実現するのは、複雑化され、難解バグを生むだけ。
本当に必要なのか、十分に考慮する。

これは、原理原則を適用する場合も同じ。
メリット・デメリットを考え、必要なものだけを選んで欲張ってはいけない。
トレードオフを受け入れる考えを持つことが重要。

趣味や個人的な意見ではなく、原理原則に従え

原理原則に従うと、説明が楽になる。
共通認識として使えるので、会話がスムーズに進む。

見解や趣味でことをすすめると、政治的議論の引き金になる。

動くスケルトンから始めよう

動くスケルトンとは、最小限の実装で動作するもの。

最初に作ることで、フィードバックサイクルが短くなり、修正や要件だしが楽になる。
動く状態を保ちながら、機能拡張したほうが、最後に一気に作り上げる開発よりも成功しやすい。

データがすべて

プログラムは、データを操るためのツール。
リリース後のシステムのバグの大半は、データに起因している。
正しいタイミングで、正しいデータが送られていれば、システムは正常に動く。
システムのコア部分は、データを理解することがから始まる。

単純なものは単純に

単純な問題は、博識であることの証明に複雑に解いてはならない。
その場合、コストが高くなる

将来の予測は、大抵ハズレるもので、設計はなるべくシンプルにして、誰でも対応できるようにしておく。

アーキテクトは何よりもまずデベロッパーであれ

アーキテクトは、デベロッパーとして専門分野を極めた人がなれるもの。

ROI変数を意識せよ

ROIとは、使ったリソースにたいする利益の割合。

ソフトウェア開発は、投資のようなもの。
ROIを意識して、効率的な判断をしないと、あまり価値はない。
アーキテクチャ上の判断は、ROIを意識することから始めよう。

目の前にあるのはレガシーシステムだという前提で設計せよ

システムは、遅かれ早かれレガシーになる。
だから、メンテナンス性には注意する必要がある。
メンテナンスに必要なものは、以下の通り

  • 明確正
  • テスト可能性
  • 正確性
  • トレース容易性

解決策が1つしかない場合には、セカンドオピニオンを求めよ

解決策が一つしかないということは、トレードオフの余地がない。
アーキテクトとして経験が不足していると思わなければいけない。
その場合、なるべく多くの人の意見を聞いて、どするか考えたほうがいい。

変化の影響を把握せよ

変化は、モジュールだけとは限らない。
スケーラビリティや、チームの人員、他システムのIF変更など。。。

変化はコントロールできないので、変化に影響を受ける箇所を局所化しておき、対応が簡単にできるようにする。
そうすることで、リスク計測しやすくなる。
アーキテクトとして、常に変化影響が最小になるように準備をしておく。

ハードウェアの理解も必要

ハードがソフトに与える影響は大きい。
なるべく早い段階から、ハードの専門家と連携できるようにして、ハードの制約を知っておく。
ビジネスニーズに答えるためにも、ソフトウェアだけでなく、ハードウェアも意識しておく。

今の近道、後で大損

初期開発は、近道をなるべく避けて、まずい設計を潰す。
基礎づくりをしていることを忘れてはいけない。

基礎づくりが疎かになっていると、後で大きな代償を支払うことになる。

「完璧」は、「十分よい」の敵

完璧を求めすぎると、メンテナンス難やチームの混乱を招く。
要件達成ができる最低ラインで終えるようにして、余った時間を他に回したほうが、正しく時間を使える。

「よいアイデア」を避けよ

よいアイディアをプロジェクト途中で入れるのは、かなり危険。
よいアイディアと思っても、適用するにはコストがかかることを常に意識する。

よいアイディアで善意からくるものでも、それが必ずしも正しいとは限らない。
悪意のない悪は、やっかいで非常に質が悪い。
受け入れる前に、それをやる必要があるのか、よく考える。

優れたコンテンツは優れたシステムを作る

コンテンツは、システムに価値を与える。
コンテンツが優れていなけければ、システム開発が成功したとはいえない。
システム開発の段階で、なるべくコンテンツへのフィードバックをすることを、忘れてはいけない。

怒れるアーキテクトとしてビジネスと対立するな

ビジネスは、デベロッパーの存在理由。
ビジネスでの意見対立でキレるのは、得策ではない。
意見の不一致を認め、どうやって解決するのか考える。
どうしても許せない場合は、転職するしかない。
自分のエゴを通して、機会損失することは、避けるべき。

主要な指標の耐久性をためしてどこで壊れるかを確かめよ

耐久性を知ることで、問題箇所をしることができる。
性能について、後手の対応ではなく、先手の対応ができるため、メリットは大きい。

設計するならコーディングできなければならない

使ったことがないものを使うのは、リスクが大きい。

覚えるに時間が掛かるが、プロダクトの落とし穴に気づくのが早くなったり、不要なリスク混入を避けられる。

アーキテクトは、デベロッパーでもある。
使えないテクノロジーがある場合は、学習して身につけましょう。

他の名前でバラを呼べば、キャベツにしかならない

名前がコロコロ変わるのは、設計に問題がある。
名前が変わるタイミングで、何が目的だったのか、よく考え直す習慣をつける。
そうすれば、次回の設計はよりよくできるはず。

しっかりとした問題には高品質のソリューションが与えられる

アーキテクトに必要なことは、問題の線引。
問題を正しく分割できることが、耐久性を高め、設計しやすいシステムに繋がる。

勤勉さが必要

勤勉さに欠けるアーキテクトは、原則からハズレることが多く、システムを瓦解させがち。
勤勉でいることは、アーキテクトに必要な要素。

勤勉であるためには、ルールを作り、常に守ることが必要。
これは、どの業界でも当てはまる。

自分の判断に責任を持て

ソフトウェアの失敗は、アーキテクトの判断ミスや詰めの甘さ。
責任を持って開発に挑まないと、失敗は避けられない。

判断を下すためには、下記の条件に気をつける

  • 判断理由が完全に説明できる
  • 決定したものは、検証していること
  • 決定したものが守られていることを確認する手段があること
  • より詳しい人がいたら、その人に判断を委譲できるようにしておく

クレバーになるな

ここでのクレバーは、小手先の騙し技を使う人のこと。

クレバーなことばかりしていると、あとで大きな代償を支払うことになる。

アーキテクトは、単純なものを作ることに注力する。
クレバーな設計は、ほころびが出やすいので避ける。

武器は慎重に選べ、用意に手放すな

使い慣れた武器は、使い慣れているので効率的に開発ができる。
捨てる場合は、デメリットが発生することを忘れてはいけない。
新技術を使う場合のメリット・デメリットは以下の通り

  • 学習コストがかかる
  • だいたいは古い技術で代用できる
  • 新規テクノロジーが成功するとは限らない

将来性を考え、新技術の取捨選択をしましょう。

本当の顧客は目の前の顧客ではない

本当の顧客は、もっと奥にいる。
真の顧客の成功が、自分の成功に繋がる。
目の前の顧客の成功は、自分の成功には繋がらない。

設計した通りにはならない

考え抜いた設計が、現実に通用するとは限らない。
小さな変更が積み重なり、設計がズレることはよくあること。
そこに仕様変更・バグが重なれば、最初に設計したものは、影も形もなくなることがある。

設計したものが絶対と思わず、変わることを受け入れなければならない。

フレームワークは相性で選べ

フレームワークの担当領域が被ると、複雑になりやすい。
使うなら、担当ドメインを明確に分割して任せる。
その他のフレームワークと連携するなら、特に注意しなければならない。

強力なビジネスケースを作れ

人は、認識したものが現実で価値を持つ。
デベロッパーが価値を出すには、ビジネスで成功・使える必要がある。

コードだけではなくデータをコントロールせよ

システムは、ソースだけで構成されていない。
スキーマやデータもバージョン管理する。
トラブルを想定した場合、管理できているほうが万全に対応できる。

技術上の借金は返済せよ

技術的負債は、利子がある。
なるべく早く返さないと、利子で肥大化して、借金地獄に突入する。

問題を解こうとするな

問題をいきなり解いてはいけない。
その問題が正しく定義されているところから確認する必要がある。
あと、解く必要がある問題なのかも十分に考える。

システムは用具的に作れ

仕事には、道具が必要不可欠。
道具はシンプルである方が、簡単で効果的に使える。

システムは、ユーザにとっては道具。
なるべく使いやすくシンプルに作る。

問題解決に情熱を注げるデベロッパーを探して手放すな

強力なチームは、アーキテクト一人では作れない。
優れたデベロッパーが複数必要になるが、見つけるのは至難の業。
見つけたら大切に扱い、意欲を削がないようにして維持する。

ソフトウェアは実際には存在しない

ソフトウェアは、物理的なものではない。
使えたり、変更したりできるけど、現実世界には直接影響を与えない。
使われないと存在しないと同義であることを忘れてはいけない。

新しい言語を学べ

ビジネスの人は、プログラミング用語は知らない。
だから、デベロッパーはビジネス用語を覚えて、直面している問題について会話できるようになると、重宝される。

未来永劫安泰なソリューションはない

未来は、誰にも分からない。
そのため、未来永劫バグを起こさないシステムを作るのは、不可能。
未来にばかり目を向けず、今の問題を直視する。
今の選択を誤れば、未来も誤った結果になることを理解しておく。

ユーザーの拒否感情の問題

ユーザの拒否反応は、プロジェクト失敗に繋がる。
回避するためには、人柱が必要。
ユーザや利害関係者の代表と対話して、両者が納得できる折衷案を出すことは重要。

コンソメの重要性

ソフトウェアのバグや要件漏れは、曖昧さや不明瞭な言葉に起因している。
解決するには、質問を繰り返し、コンセプトを洗練する必要がある。

タイトルにあるコンソメは、濾過して美味いコンソメを作ることは、ソフトウェア開発と似ているよと言いたかった。

エンドユーザーの立場からはインターフェイスこそがシステム

エンドユーザーは内部の構造なんて意識しない。UIこそがすべて。
システムを成功させるには、内部構造を知っている人とUIの専門家が手を組む必要がある。

優れたソフトウェアは構築されるのではなく、成長する

ソフトウェアの失敗は、いきなり大規模で作ったり、想定外の規模に膨れ上がることが多い。

初期は、明確なコンセプトを持った状態から小さく始めて、徐々に大きくしたほうが、成功しやすい。

日本人アーキテクトによる知っておくべき11のこと

アーキテクチャは縦と横の基本構造を持つ

現実の問題は、非線形でいろいろなものが影響し合う。
何に価値を置くか決めることで、モデル化され2次元構造になる。
問題を解く場合、まず何に価値を置くのか決めることから始める。

ビジネス・アーキテクトを目指せ

ソフトウェアの考え方は、ビジネスに繋がることが多い。
また、テクノロジーをビジネスに反映させるのは、アーキテクトの仕事。
ビジネスパーソンとして価値観を養い、目的をもって仕事することは、必ず将来のためになる。

問題にフォーカスせよ

正しく問題を定義してないと、見当違いなシステムが出来上がり、誰にも使われない。
真の問題を見抜く必要がある。
問題を発見して解決する能力が必要。

問題にとらわれるな

問題は、人によって見方が違う。
解決策は、制約とコストが伴うので、まずは何を問題にしているのか理解することから始める。

煩雑なことを非属人化し、創造性を高める

自動化は、煩雑な問題を解決するためのもの。
ソフトウェア開発全体への適用は無理。
なぜなら、自動化前提だと制約がついてまわるため、新たな問題の解決に制約がかかる。

ソフトウェア開発は、煩雑作業と知的創造を含む。

手段的な技術と陳腐化しない本質的な技術

最新テクノロジーに精通していてもできないものがあるのは、手段的知識を得ているだけで、技術体系や理論を理解してないから。

ノウハウを溜め込むのはいいが、陳腐化しやすく新しい考えで上書きされることもある。
ネットにある情報は、大半がノウハウ。
理論や原則は、ネットでは集めにくい。

ノウハウ:ユーザに価値を提供する手段として必要 理論:問題解決に必要

ノウハウだけ、理論だけでは、変化する世の中に対応できない。
両方バランス良く学び、変化に備える。

開発スタイルをデザインする

開発手法は、テクノロジーと同じくらい重要。
要件対応、バグの混入率、チームの雰囲気などに影響を与える。

メンバーの特性に合わせて、どう進めていくかも考える。

システムではなく、コミュニケーションをデザインせよ

新規システムの開発は、組織の風土を理解し、モデル化すること。
モデル化できれば、システム化すべき箇所が見つかるハズ。

システムはのユーザを作るのではなく、やりたいことを実現するためのシステムを作っていることを、忘れてはいけない。

移り気な利用者を捉える

要求分析は、曖昧さや不確実性が残る。
なぜなら、利用者全員の話を聞くことはできないため。

曖昧さを無くすためには、利用者を想定し、目的・振る舞いの仮定・検証を繰り返してシステムを最適化していくしかない。

受動的アーキテクトと能動的アーキテクト

受動的アーキテクトは、ユーザからの要求にあったものを高機能・高品質で作りたがる。
売上増加など、自分の都合のために、不要な機能提案をすることもある。

能動的アーキテクトは、最小の投資で最大の成果が得られることを目指す。
権限が大きいので、検証してない新テクノロジーを試したり、失敗を秘密にしようとすることもある。

どちらもメリット・デメリットがあるが、理想像は似通る。
違ってくるのは、環境要因。
環境が個人に影響を与えることを自覚して、バランスをとって成長しましょう。

説明責任を果たす

要件をクリアしてシンプルに作るのが、アーキテクトの役割。
それを実現するためには、開発者にたいして説明責任を果たす必要がある。

説明は、ドキュメントを多くすればいいわけではない。
必要最小限のドキュメントを作り、サンプルなどを用意して、初期導入の敷居を下げる。

感想

いろんな人の意見を見て言えるのは、問題の定義がアーキテクトの本質な気がする。
問題の切り方がシステムを左右するといろんな人が言っているから、たぶん真実なんでしょうね。

あと、慢心しちゃダメなんだろうなって読んでて思った。
役割・役職が変わっても、自己研磨を怠るやつは、失敗するんだろうな~って感じた。

XP祭り2017 参加報告

http://xpjug.com/wp-content/uploads/2017/07/xp2017-eyecatch.png

公式サイト

XP祭り2017

きっかけ

他の人はどう働いているのか知るためが主な目的。
あとは、倉貫さんの話を聴きに。
「納品」をなくせばうまくいくって本を読んだが、これを考えついた人の思考がどうなっているのか知りたかった衝動に駆られた。

受講セッション

  • A-1 オープニング (Agile仙人) – 10:00~10:30
  • A-2 【基調対談】ワークスタイル改革を実践者する二人が、働き方の本質を語る (青野 慶久さん、倉貫 義人さん)

倉貫さんの話で満足できたので、帰っちゃいました。。。

感想

ちょっと遅れて到着。

XP祭りって、最初タイトル見た時、Windows信者が集まって何かするのかと思ってしまった。。。

A-1 オープニング

ふ~んで終わってしまった。
途中で入ったので、話を掴むのに戸惑った。

【基調対談】ワークスタイル改革を実践者する二人が、働き方の本質を語る

これは、聞いてよかった。
マネジメント・評価不要論にかなり得心が言った。

マネジメントの必要性を歌う輩はいっぱいいるけど、今のマネジメントって、基本束縛することになっていると思うんですよね。
報告したら、「俺に分かるように説明して」は、何度も聞いた。
そもそも、お前管理してるんだから、つうかあで通じるんじゃないの?って思うんだが。。。
あれはするな、これは報告しろ、まるで俺たちを子ども扱いしてると思うんですよ。
話を聞いていてわかったのは、マネジメントしている人や管理職は、管理=支配と勘違いしているんじゃなかろうかということを、聞いていて思いついた。
いいすぎかもしれないけど、ソフトウェア業界の管理職って、リアル蟹工船なのではないかとも思ってしまう。

そういえば、蟹工船って概要はしってるけど読んだことないな。
著作権消失のため青空文庫で無料公開されてるみたいだから、今度読んでみよ!
過去の俺の経験と比較してみたい。

小林多喜二 蟹工船

話が逸れた。。。

セルフマネジメントできれば、今の管理職のやってることは不要になるってのは、たしかにそう。
だから、管理職じゃない人に対して、自己管理できるようにしてあげるのが、必要なんだと思う。
これからの管理職は、支配ではなく導く能力が必要になるって考えはあってると思う。
※ヴィジョンは、ちょっと恥ずかしくて言葉にできない!

評価不要論が一番心に響いたかな。
自分は評価する側になっているので、最初聞いた時は、かなり疑問が沸いたが、かなり納得できた。
今の会社の評価制度には、かなり疑問を持っていて、評価項目ってコレだけでいいの?って感じている。
今の評価形式だと、目標を低く設定して、達成したら大げさにアピるから、会社にとっても本人にとっても成長しにくい状態になっているのは、たしかにその通り。
結局のところ、客観で公平な評価は無理だから、キャリアパスを築かせるためのアドバイス・スキルの棚卸しをしてあげるべきで、評価なんてそこまで重要じゃないと感じた。
つまり、評価よりキャリアの構築を重視しているので、評価が不要ってことなんだね。
なんて言ってたか忘れたけど、KPIみたいなことをして、次のアクションをどう起こすかの部分が自然な流れで成長に繋がるので、いいと思いました。

あとは、副業推しが強かったな。
ここで副業を推している意味は、金儲けって意味ではなく、多種多様な経験をしてこいって感じだった。
関係ないことでも、最終的にはそれが本業に生きるって感じだったかな?
最近になって、俺も副業したいと思っているが、金儲けの意味合いが強かったので、真にやりたいことだけやろうと思いました。

三十路になったエンジニアとこれからの行動と目標

とうとう

とうとう三十路。。。
9/14は、僕の誕生日なんです。上戸彩と同じですな。
小さい頃思っていた将来像とは違っているなと感じる。

性格は捻くれ、独身で、スキルも足りない。。。
子供の頃は、聖人なみの人徳者で、イケメンでハイスペックだったんだが、いつからこうなった?
こりぁ、あれだ、世間が悪い。
優秀な無垢な子どもをダメにした罪は重い!

と、現実逃避しても現実は変わらないので、これからどうしていくか考える。
ちょっとやけ酒してから書いているから、本音が出てるかもしれない。

今思い返すと、若さってやっぱり素晴らしいな。
まだ、いくらでも変化できるっていいことだと思うよ。
俺は、もう死ぬまで内面は変わらない気がする。。。

これから

既婚者になる

結婚しないとマズいと感じ始めた。
なんでそう思うかというと、自分の考えに固執するような雰囲気を感じるから。
誰か近くにいて、意見を交換したい。
他人だと、真の意見なんて言わないからな。
あと、話すのが億劫になる。気心知れた仲のヤツがやっぱり欲しくなった。
一人には慣れているとは言え、一人じゃできないことが分かっているのと、それが欲しくなった。

結婚している人って、何が目的で結婚したんだろう?

とりあえず、目標達成のために、身だしなみと外出するようにしよう。
なるべく週末は飲み屋に行ってみようと思う。
あと、洗顔と髭には気をつけよう。
新社会人の頃は、石鹸泡立てて、それを使って洗顔していたが、途中でめんどくさくなって辞めちゃった。
朝は、洗顔を入念にしときます。。。
あと、たまに髭を剃り忘れるのも避けないとな。。。

技術面

いままで振り返ると、ノウハウは結構溜まってる気がする。
オブジェクト指向の考え方、デザインパターンに対する理解はできていると思う。
あと、意外と俺って嗅覚がいいんじゃなかろうかとも思った。
ちょっと前に書いた「Tabulator概要」のアクセスが高い。
Qiitaでも取り上げてもらえたのは嬉しかった。

suzaku-tec.hatenadiary.jp

今感じているのは、ノウハウばかり溜め込んで、今後使えなくなるときが来たら、無能に戻るのではないかという危機感。
なんとしてもコレは避けたい。
コレを避けるために、いろいろ考えたが、理論・原則を知ることが、キーポイントな気がしている。
短絡的にはノウハウを覚えれば、開発者としては困らない気もするが、使われる側で終わってしまいそうな気がしている。
理論・原則を覚えて、誰にでもできることから、俺にしかできないことをできるようにしないといけないと思う。
理論・原則って、web上にはあんまりないんだよな。
webにあるのは、どちらかと言うとノウハウ。
こう解決できるよが多い。
そいうのが多いのは、理論・原則が教科書チックになってしまうからだと、個人的には思う。
強めの意志を持って、学ばないといけないと、感じている。

他にも、欲しいスキルはある。
説明・プレゼン能力、ビジネスの考え方、英語の読み書き、環境構築、並列処理の概念、抽象化やモデリングなど。
上げてくときりがない。

取り敢えず35歳までの目標

  • 他人しかいないところでプレゼン
  • 高度情報処理技術者を複数持つ(理論・原則を知る)
  • なるべく毎週コードを書く(ノウハウを劣化させない)
  • 英語のドキュメントもなるべくみる
  • 権威を身につける(認知度の高い資格を持つ)
  • コマンドベースを愛する
  • Vimを覚えてみる

取り敢えず、他人にデカイ顔できる準備をしておく。
あと、どんなことになっても対応できる対応力。英語が一番ネックだな。
原理原則は、今持っているデザインパターンオブジェクト指向の考えを昇華させれば、なんとかできそう。

コマンドベースは、最近重要だと感じた。
特にログ解析とかするとき、Linuxのコマンド使ってやれると、いろいろ細工が簡単にできる。
最近は、ログ解析するときは、エディタとか開かないほうがいいと感じている。

その他できればいいな

デザイナーの知人が欲しいな。
もしくは、ネットワークエンジニア。
コーディング能力を伸ばしていたので、他の分野もそろそろ伸ばしたい今日このごろ。

今までやっててよかったこと

反省してばかりだと心が弱る一方な気がするので、個人的に成功したことを書いておく

月1冊ペースで技術系書籍を読破

これは、考え方を広めるのに役立った。
あと、読むべき箇所とやまなくて良い箇所の切り分けをしていかないと時間が足りないと気づいて、集中して読む場所と読まない場所を分けるようになった。
そのおかげで、時間の節約と効率的な情報の収集ができた気がする。
あと、ブログとかに吐き出すおかげで、自分の考えを残しておく習慣が付いたのも良かった

早期出社

早く行っても仕事はしないんですけどね。
周囲の評判が、何もしてないのに高くなったのには、驚いた。
みんな、俺が仕事していると思っているのだろうか?
目的は、早く会社に行って体力回復しているだけなんですけどね。
出社だけで、体力が6割くらい削られる。
東京出てきてからそれが顕著。
新潟に居た頃は、女子高生や専門学生たちと登校時間がかぶり、となりに座ってくれた時は、なんとなく得した気分にもなったが、東京は違う。
おっさん比率が高すぎる。

そのせいか不明だが、体力の減りが早くなった。

早く出て、休みながら技術系書籍読んでたわ。

その他

もっと趣味を増やしたいが、増やそうとするとインドアになっちゃうんだよね。。。
最近気になってるのは、ガンプラ
3Dプリンタが安くなってきているので、オリジナルガンプラを作ってみたい衝動に駆られる。

あとは、物書きしようかとも考えてる。
よく「変わってるね」って言われる。
自分は常識人だと思っているのだが、周囲は違うようだ。。。
真面目に答えたはずなのに、なぜか笑いをとっていることに凄く違和感を感じる。
きっと変わってるからなんでしょう。。。
日々思ったことはメモっとこう。
そして、復習ノートは、書き忘れしないように気をつけよう。
とりあえず、自動ドアは、俺を無視するのを辞めろ。
ずっと立ち止まってると変な人に見えちゃうでしょうが!
もしかして、俺の隠密スキルが高すぎた??
そうか、俺の前世は忍者だったのかもしれない。

最近カメラを買ったので、旅行もいいかなとは思っている。
買った理由は、決してコミケでレイヤーさんを撮りたいからではない。

あとは、IoTでなんか遊べるものないかな~と探している。
ラジコンとか自作プログラミングできれば、ハマりそうな気はしている。
レイスティンガーとか作ってみたい。
ここらへん、電子工作の考え方がないから、全然想像がつかないんだよね。。。
こういう電子工作は、すごい憧れる。

IoT開発で気をつけること

きっかけ

いま、IoTといっていいものか分からない製品を作っている。
※ちょっとバズ狙いでIot入れてみました。

製品上にwebサーバーを立てて、そいつを使ってアプリを開発している。
要は、スマホみたいなものを作っていると思えば、創造がつくだろうか?

そこで得たシステム開発の考え方をまとめる。

気をつけること

不確実性との付き合い方

頭の中で確実だと思っていることでも、別のバグでちょっとしたものが巡り巡って影響することがある。
特に、初期化や起動中、状態遷移中が不確実性と衝突しやすい。
完璧だと思っても、影響範囲をデカく作ってしまったために、他の影響を受けることが考えられる。

対処としては、公開範囲を狭くするしか無い。
つまり、スパゲッティコードを作らないように心がける必要がある。
特に、適切なデザインパターンを適用することが大事。
シンプルかつ、小さく作ることを心がけないと、あとで何が原因でバグったのか分からなくなる。

不確実性と正面からメンチ切る場合、スパゲッティで勝負してては勝てない。
シンプルなこんぼうやナイフで十分。
IoT開発にとどまらないが、不確実性が出やすいので、公開範囲には最新の注意を払う。

あと、依存関係は注視したほうがいい。
依存関係がスッキリしてない=スパゲッティで、いざ問題が起こった時、どこが原因だったのか、わかりづらくなる。
誤用をさけるためにも、依存関係図をかけるなら早いうちにかいたほうがいい。
そのほうが、チームの共通認識を作りやすいし、レビュー指摘の意図が伝わりやすくなるはず。

ログ出力

注意すべきは、どこで何をしたか。
これが出てないと、何も追えない。
また、過度にログを出しすぎるのもNG。
それはそれで追いかけづらくなる。

大事なのは、システム影響がある変更をログに出すこと。
ログは、システムの状態を見るためのものなので、システム影響がある変更は、必ず出力する。

障害対応で得たこと

コメントは適度に書く

適切に命名したからと言って、必ずしも分かりやすいとは限らない。
ソース上に書けない因果関係などは、必ずかかないと、障害に対応しづらくなる。

たまに、適切に命名したから大丈夫みたいなやつがいるが、必ずしも意図が伝わるとは限らない。
書きすぎるのも良くないが、書かなすぎもよくない。
ソース作ってて不安だと思う箇所が必ず出るはず。
そういう時は、周囲の暇そうな人間か、命令を聞く人間を捕まえて、軽く相談することが重要。
他人に伝わらなければ、コメント書くか、そもそも設計を見直した方がいい。

ログには決まった文言を

障害調査でログをgrepすることはよくあるはず。
そう言ったときに、ワードが複数並ぶのは、かなり面倒くさい。
なるべく文言は統一したほうがいい。

ここらへんの考え方は、エリック・エヴァンスドメイン駆動設計が参考になりそう。
※前、読んだけど、分からなすぎて挫折した。。。

今なら読める気がする。
ログ設計にも応用できるかもしれない。

あとがき

結構長いことブログに吐き出してなかったので、コメント程度だが吐き出す。

【資格】Java SE 8 Programmer II受講結果

結果

落ちました。。。

合格ライン65%に対して、正答率60%
あと、2問正解してれば合格だったと思う。

振り返り

StreamAPIと関数型インタフェースで点を落としすぎた。
既存の関数型インタフェースのメソッドなんて、全部おぼえられねぇよ。。。
たぶん、手を動かさないとダメなんだろうな。
問題集は一通りやったけど、Java SE 8 Programmer IIは、それだけではダメなんだろうな。。。

今後

一回、有名な関数型インタフェースは、実装してみるしかない。
あと、StreamAPIの基本的なメソッドも実装してまとめる。

予定

直近は、情報処理技術者試験に注力するため、次の受験は年末だろうか。
このままいくと、情報処理技術者試験も落としそうなんだよな。。。
三十路になるから、そろそろガチで転職に有利なものを持たないとイケない。

そもそも、資格は業務と直結しないけど、他者の説得材料には有効だからな。
なんとしても早いうちにとっておきたい。