転職した

転職した

思ったことをつらつらとメモってゆく。

 転職活動における成功を定義する 

転職を成功させる秘訣は目的を明確に定義すること、これに尽きると思う。

仕事の軸は、

• 内容
• 給料
• 人間関係

だと考えている。

これをどう変えるかを明確に定義する。

自分の場合は内容を第一に考え、目標通りの会社に転職できた。

ほかは、給料をX万まで上げる。〇〇さんや〇〇な人たちと一緒に働くなど。

転職の目的やゴールを決めず、なんとなく転職したり、嫌なことから逃げることだけにとらわれて転職しても、次の転職先でも結局同じことで失敗するだろう。

また、設定目標のすべてを満たすことは難しいという心構えを持つ。目的に優先順位をつけ、それを満たすような会社に転職する。

使った転職サイト

• リクルートエージェント
• レバテックキャリア
• Green
• FindJob
• Paiza

エンジニア向けの転職サイト・エージェントがあるのでそれを使ったほうが良いと感じた。営業色が強く「とりあえず応募しましょう！」みたいなノリや、技術のことをあまり理解していない業者がいるのも事実。

あとは噂に聞いていた全く転職者のプロフィールを見ていない、一方通行のスカウトメールもあった。会社の評判を下げるだけなのでやめたほうが良いと思う。

市場価値

VisualBasic.NETの市場価値ェ。。。

転職エージェントからは「Web業界だとJava、PHPですよ！」（サーバサイド志望した時の反応）と散々言われた。
市場感(市場で求められるスキル、出ている求人数)に関してはエージェントが言うことは間違いないだろう。

ネット上で盛り上がっている、流行りの技術を使うのは一部ということであり、現実として2017年現在では上記に価値があるということか。

面談のむずかしさ

自分が思った以上に面接官に自分のことが伝わらない。

書類で説明したつもりでも、うまく伝わっていなかったり(忙しくて職務経歴書を読み込む暇もないのかも)、 自分がアピールしたい部分と違う部分を拾われたりして、なかなか言いたいことが伝えきれなかったように思う。

あとはSkype面談なるものを初めて経験した。面談前に音声やカメラのチェックは必須。自分の場合、普段Skypeを使わないので事前に友人と練習した。

じつりき

実力をつけるしかない。技術力、思考力、筋力を身つけてタフに生き残ってゆくしかない。やらなければやられる。これからもやっていく。

以上です。

TDDBC Toyama #1 ２日目

いってきた

tddbc.connpass.com

メモ

リファクタリング

• 課題として出されたライフゲームをリファクタリングしていく

レガシーコードのジレンマ コードを変更するためには、テストを整備する必要がある。多くの場合、テストを整備するためには、コードを変更する必要がある。

レガシーコード改善ガイド読書メモ - Anger Driven Development

まさにこれが出た。

方法としては２つあって

1. テストが無いままで安全に変更できる状況を考える
2. 振る舞いを変えること無くテストできるか検討する

バグを直すということ

バグを直す===振る舞いが変わる
また自分がバグと思っているものは実は仕様かもしれない(途中からプロジェクトに参画して、ドキュメントなどが無い状況など)
動いているコードがすべての事実。コードの振る舞いを保つことを考える。変わりそうだったら上長に相談。

KPT

Keep

• テストに保護されるの最高。これで変更のたびに「どうか壊れていませんように」と祈らなくてすむ。
• リファクタリングの実践的な手法を学べた
  　動いているコードをリファクタする時はまず振る舞いを保つように保護する。その時も、
  • 手で行わずIDEのリファクタ機能を使う
  • Lintをかける
  • 静的解析ツールを使って複雑度などを調べる
    などなるべく機械的に変更できる手段から実践していく。
• ペアプロの楽しさを体験できた
  他人のコーディングを間近で見れる(IDEやエディタのホットキーなどのこだわりが垣間見れる、優秀なプログラマのコードの書き方、思考ステップなどの知見が得られる)

Problem

• ペアプロの難しさを体験できた
  • 役割分担(ドライバー、ナビゲーターがなかなか交代できない)
  • 意識合わせ(今回だと、どういう思考でリファクタしていくかというのを逐一確認し、二人がその思考に合わせて行くのが難しかった。一人だと思考を柔軟に変更できる。)
• コードを壊したくなる
  • 破壊衝動に駆られる。
    すぐにコードの振る舞いを変えるような変更を加えたくなったが、ナビゲータの方が制止してくれた。まだTDDが体に染み付いていない。
    対策：既存のコードの振る舞いを保証することを念頭に置く。焦らずTODOリストに落とし込む。現在動いているコードが絶対。２年前の先輩*1に敬意を表する。
• TODOの粒度
  要件定義===テスト設計だと思うのだけど、その落とし込みが難しく感じた。どの程度の粒度で考えるか。粒度が細かすぎるとテストがやりづらいという話も上がった。

Try

• 写経(TDDはセンスではなくスキルなので高めることができる)
• TDDBCの途中になっている課題を終わらせる
• テストファーストで作ってみる

雑感

１日目の深夜まで語り合ったり遊んでたりしたみたいで、早く寝ずに参加すればよかったと少し後悔。。。
朝１からクソコードレビューしたり、夜にこだわりのホットキーの話したり、エンジニアが集まってワイワイ話すのはほんとに楽しい。
是非また行きたいと感じた。

*1:動くクソコードを残して去った先輩のこと、合宿の会話中に何度も出てきた

TDDBC Toyama #1 １日目

いってきた

tddbc.connpass.com

メモ

「動作するきれいなコード」はあらゆる理由で価値がある

これに近づけるのが良いソフトウェア開発

「動作するコード」＋「きれいなコード」に分解して考えると、

• 「きれいなコード」

動かすまで問題がわからない。ソフトウェア開発は予測可能性が低い。

• 「動作するコード」

これをきれいなコードに変更しようとすると

「動くから良いじゃないか」「変更して動かなくなったらどうする？」

という堕落、恐怖がある。

これに打ち勝つためにテストで保護する。

まずはテストで保護された動作するコードを書いて、それを編集してきれいなコードにしていく。
（テストファースト:テストを書いてgreenになるように実装していく。）

TDDのサイクル

1. 次の目標を考える （紙などに書き出すと良い）
2. その目標を示すテストを書く
3. そのテストを実行して失敗させる
4. 目的のコードを書く
5. ２で書いたテストを成功させる
6. テストが通るまでリファクタリングを行う
7. １〜６を繰り返す

日々の作業に落とし込む

• リファクタリングというタスクには呪いがある（終わらない）
• リファクタリングは大事にしない,日々の作業に組み込む
• よいソフトウェア開発はよいフィードバックサイクルから

テストとメンテナンス

• テストのメンテナンスコスト
• テストの理想はMESE
• テストごとの重なり、漏れがあるとメンテナンスコスト高い
• テストもメンテナンスしていく必要がある

実践

• 仮実装（テストコードのテスト）
  例:真偽を返す関数でreturn trueなどして必ずテストを通るようにする。
  こうすることで、テストコードは間違っていないことを確認する。

• TDDアンチパターン：アサーションルーレット
  アサーションを羅列すると、どのテストで落ちたかわからなくなるので避ける。

• 落ちるべきところで落ちることが理想（自分の予想と一致している）。

• テストの対称性
  テスト件数にばらつきがあると、後任者から見ると段差がバラバラのはしごが残っているようにみえる。 テストを減らすことには判断コストがかかる。 テストケースを減らせるのはテスト担当者のみ。最後にテストの数を揃える。

TDDに必要なスキル

• 問題を小さく分割する
• 歩幅を調整する
• テスト＞仮実装＞三角測量＞実装
• テスト＞仮実装＞実装
• テスト＞明白な実装
• テストの構造化とリファクタリング

TDDはスキル

• 一人から始められる
• 才能ではなく習得可能
• 量は質に添加する
• 写経

「TDDの黄金の回転」はジョジョ７部ネタ。

レガシーコード改善ガイド読書メモ

電子書籍で買えばよかった・・・

1章　ソフトウェアの変更

ソフトウェア変更の4つの理由

1. 要件追加
2. バグ修正
3. 設計の改善
4. リソース利用の最適化(メモリ最適化)

4つの変更を加えると変化するもの

	要件追加	バグ修正	リファクタリング	最適化
構造	変化	変化	変化	-
新機能	変化	-	-	-
機能	変化	変化	-	-
リソース利用	-	-	-	変化

プログラムの振る舞いを保ったまま変更するときに考慮すべきこと

1. どんな変更を行わなければならないか
2. 変更が正しく行われたことをどうすれば確認できるか
3. 何も壊していないことをどうすれば確認できるか

2章　フィードバックを得ながらの作業

システム変更の方法

• 編集して祈る
• 保護して変更する

後者がベストだがほとんど前者になっているのが現状

大規模テストによる問題点

• エラー箇所の特定が困難
• 実行時間が長くなる
• カバレッジの把握が困難、新規コード追加時に高いレベルのテストを書く必要があるので作業量が増える

優れた単体テストの条件

• 実行が速い
• 問題箇所の特定がし易い

実行に0.1秒もかかる単体テストは、遅い単体テストである。

• 10テスト/クラス×0.1秒×3000クラス=3000秒＝50分
• 10テスト/クラス×0.01秒×3000クラス=300秒＝5分

2~3時間ごとにすべてのテストを動かす場合を想定すると0.1秒だときつい。

単体テストと分けて考えるべきもの

1. データベースとやり取りする
2. ネットワークを介した通信をする
3. ファイルシステムにアクセスする
4. 実行するために特別な環境設定を必要とする（環境設定ファイルの編集など）

上記テストは価値があるが、単体テストとは分けて考える

レガシーコードのジレンマ

コードを変更するためには、テストを整備する必要がある。多くの場合、テストを整備するためには、コードを変更する必要がある。

レガシーコードの変更手順

1. 変更点を洗い出す
2. テストを書く場所を見つける
3. 依存関係を排除する
4. テストを書く
5. 変更とリファクタリングをおこなう

レガシーコード改善ガイド (Object Oriented SELECTION)

kanazawa.rb meetup #53

行ってきた

kanazawa.rb meetup #53 - kanazawa.rb | Doorkeeper

やったこと

TDDBCの予習

背景

　最近、仕事で作った社内常駐ツール(WPFアプリ)のリファクタリングをしている。ツールは運用3年目に入っていて、今まで仕様変更や追加を重ねてかなり運用が苦しくなっている。業務上の手続きの概念を扱っており、よく仕様変更される感じだ 。

　当時はリーダブルコードも読んでなかったし、オブジェクト指向も今より理解してなかったし、初めてちゃんとアプリ作ったしで、ひどいコードになっている。一つ機能を加えるとあっちこっちでエラーが起こる、ようなことは無いが、自分で作ったから、影響範囲を覚えていてたまたまうまくいっているだけで、自分以外の人間がこの作業をやると大変なことになると思う。

　この現状をどうにか改善したい。 ということで以下の2つに申し込んだ
toyama-eng.connpass.com

tddbc.connpass.com

で、WPFの結合テストについてはBuriKaigiで学んでくるとして、TDDBCでは選択言語JavaScriptで申し込んだ。そこでJavaScriptの単体テストについて予習した。

学んだこと

大体以下のような雰囲気なのかと。

参考サイト：フロントエンドにテストを導入 - Qiita

サーバ側だけならkarmaはいらないって感じか。

以前試してみたことのあるサイトで、他のサイトの情報を見てみてもだいたいこんな構成がいいみたいだ。

疑問

　ネット上のチュートリアルまではできるんだけど、具体的な開発段階での落とし込みかたがわからない。具体的には、

・テストを書くフェーズ

　TDDだからテスト書いてから開発？それとも最初はスピード重視で、ある程度規模が大きくなってからテスト書き始める？

・リファクタリングとテスト

　テストの書かれてないコードをリファクタリングしていくのつらい。こういうときはまずはテストから書けばいいの？

・テストのコスト

　テストを書く人のスキルも必要だけど、保守するのもコストかかりそうだけどどうなんだろ。実際運用してる人の話を聞いてみたい。

メモ

・ブログをtextlintで書く

・オレオレUML
・sysML
・safeML

・仕様を決めるための図の仕様

・テストしやすいコード/しにくいコード

　テストしやすいコードとは関数のように入出力が決まっているもの。

 ・Rubyはminitestが良いらしい

その他

・HoloLens触らせてもらった。近未来感がよい。

参考文献： 

レガシーコード改善ガイド (Object Oriented SELECTION)

リファクタリング:Rubyエディション

VisualStudio2015でよく使うショートカットキーまとめ

VisualStudio2015でよく使うショートカットキーをまとめておく

• 定義に移動 F12
• すべての参照を検索 Shift+F12
• 名前の変更 Ctrl+R,Ctrl+R
• コメント Ctrl+K,Ctrl+C
• コメント解除 Ctrl+K,Ctrl+U
• タブの移動 Ctrl+Alt+PgDn/PgUp
• タブを閉じる Ctrl+F4
• プロジェクトウィンドウに移動 Ctrl+Alt+L
• ビルド Ctrl+Shift+B
• 実行 F5
• ブレークポイント F9
• アウトラインの開閉 Ctrl+M,Ctrl+M
• クイックヒントの表示 Ctrl+K,Ctrl+L
• 行にジャンプ Ctrl+G

参考:https://msdn.microsoft.com/ja-jp/library/da5kh0wa.aspx

ショートカットキー一覧を眺めてるとVisualStudioで普段使っていない機能に気づけてよい
リファクタリングの機能とか使っていきたい所存

2016年コミュニティ活動の振り返り

今年参加したコミュニティ

2月 NodeSchoolFukui
4月 NodeSchoolFukui
5月 Kanazawa.rb
6月 NodeSchoolFukui
7月 Kanazawa.rb
8月 Kanazawa.rb
9月 Kanazawa.rb
10月 NodeSchoolFukui
11月 Kanazawa.rb
12月 Kanazawa.rb

NodeSchoolFukui

もくもく会 NodeSchoolをモクモクやる。メンターは2人程度。 以下今年NodeScoolでやったやつ

• javascripting
• learnyounode
• how to npm
• stream adventure
• Functional JavaScript
• Planet Proto
• Tower of Babel
• Browserify Adventure
• ExpressWorks

NodeSchool自体はほんとに軽めのチュートリアルって感じで短いものは15分程度で終わるイメージ。 この会は事前にNodeSchoolやっておいて疑問点を聞くとか、自分でNode.jsとかElectronアプリ作ってわからないところをメンターに聞くっていう形式がオススメ。
自分にとって初めての勉強会で、緊張しながら自己紹介のときに「今こんなの読んでます」って技術書を見せたら、他の方が「なになに？どんなの？」って集まってきたのを今でも覚えてる。
これ！こういう雰囲気を求めてたんですよ！笑
自分にとっては初体験としては良いものになった。
普段会社で話さないので、「◯◯流行ってるけどどう？」「◯◯かなりアツいよね！」とか技術のことについて他の人と話せるっていうのはほんとに楽しい。

Kanazawa.rb

もくもく会or定期的にイベント
+
懇親会
誕生してから4年目になるコミュニティ。
以下各回の一言感想

• ５月　「はじめてのC☆I」
  CircleCIのハンズオン しかしその後...テスト書くまでには至らず。。。mochaとかのテストフレームワーク使ってテスト環境作ったりしたけど、実際にテストガッツリ書いたりとかは出来てない。。。(そもそもガッツリアプリ作ってない)
  でもテスト駆動開発が実際にどういう風にやるのか体験できた。少なくともテスト駆動開発という概念とCircleCIの使い方は覚えた。テストは来年の課題。

• ８月　「〜 祝4周年 LT大会 〜」
  人生初LT。技術書の感想。中学生の感想文みたいなLTをぴったり3分で収めた。著者から空リプ来るも日和ってリアクションせず。。。LT、ええな！

• ９月　「Elastic勉強会 in Kanazawa」
  参加前は名前知ってる程度。事前に情報収集してみるも新しい概念多そうで動かすには至らず。最近社内でデータ分析の機運があるので、Dockerで動かしてみた。社内の動向を見て提案してみる予定。

• 12月　「年末 LT 大会 ＆ ビアバッシュ！」
  ビアバッシュ楽しい！参加者が多かったのでいろいろな話が聞けた。特にチームや社内の改善の話が自分にとって良かった。自分のネタはAtomのパッケージについて浅い感じで話した。

総評

• 10/12勉強会に参加した
• 意外といったやん？
• そのわりにはアウトプットすくないやん？
• 強い人が多いけどめげない
• 過去の自分との絶対評価だいじにしよう
• 来年はアウトプット意識しよう
• いろいろあるけど、辛くなったら手を動かそう