率直なコミュニケーションとレジリエンス
ある人が話していたのを聞いて、色々考えて自省したので書く。 詳細は書かないが、心象ではなく事実で率直なコミュニケーションをしようという話と、楽しいは最初からあるわけではなく、やってるうちに楽しくなる、楽しい部分を見つけようという話。
事実で率直なコミュニケーション
仕事の上で相手を思うことは必要だがそれでオブラートに包んで無駄なやり取りがあるなら率直にコミュニケーションを取ろうという話で、この話はプログラミングに限定される話ではないが、その話を聞いて思ったのが以下のエントリだった。
クソコード批判とクソコード批判批判はなぜ燃えるのか - osa_k’s diary
身近なところで自分でもレビュー苦手だなという自覚があり、特になんどもレビューしてもらうようなことになると罪悪感を感じるし、逆にレビューする場合はどう伝えたらいいか考えすぎて回りくどい言い方になってしまったりする。ただ、気遣うあまりコミュニケーションに時間がかかったりしてしまうと、限られた時間で物事を成し遂げないといけない仕事だと失敗してしまう可能性が高くなる。 そうしたらどうしていったらいいんだろうということで以下のエントリで
成果と人格を分けることの大切さとその訓練について|emahiro|note
全く気遣いがないのは論外だが、ちゃんとコミュニケーション取れる関係性を持った上で、分けて考えられるようにしていかないといけないというのが正しいと思う。これは前提として関係性がそもそも重要であって、それらがあった上で率直なコミュニケーションを取れるようにしていかないといけなかった。
楽しい部分を見つけよう
もう一つは楽しいは最初からあるわけではなく、やってるうちに楽しくなる、楽しい部分を見つけようという話で、例えば新しいことを始めないといけない時に、最初楽しそうに見えなくても、やってるうちに楽しくなるし、楽しい部分を見つけようということ。
これは、今までと違うことをしないといけなくなってしまった時に、新しいことを拒否してしまったことがあり、楽しくなさそうと思ったわけではないが、今までやっていたこととの違いから、前のを引きずって拒否してしまった。いわゆるレジリエンスが低かったのだと思う。わがままだったし、一時の感情に流されていたなとも思っている。
これに関しては以下の引用が全てで、こういうことは生きてれば割とあることで、ましてや新規事業なんかをやってると結構な確率で発生することなので腐って死なないようにしないといけない。
WoWの世界でそうであったように、現実世界においてもダメージやショックを受けることはある程度避けられないことであり、大事なのはそれを致命打として受け止めずに、次の良い状況につなげるための道を残すことなのだから。
ただ、楽しいは人によって違うかもしれないので方向性があってると良いなとは思う。
まとめ
書いてない思いも要素もたくさんあるが、いまだにこういうことで失敗するので、ちゃんと向き合っていかないといけないと思ってる。
Clean Go Codeを翻訳した
Pungyeon さんに許可をいただいて自習のため翻訳してみました。
原文 github.com
訳出に難しいところがあって、意味を変えないように注意して訳したつもりですが、間違ってたら教えてください。 あとGoogle翻訳がほんと自然な訳をしてくれるのですごい。
この辺が難しかった。
Comments
I say this because there are other ways to explain code and ensure that it's being written comprehensibly and expressively.
なぜ差し替えられることが良いのか
前回で差し替えられることが良いと書いたが、なぜ差し替えられると良いと思っているのか書く。
なぜ冗長すぎたり、実装量が増えるのに差し替えられるようにしておくかというと、その時選択したインフラなり、ライブラリなり、より良いものが結構なスピードで出てくるから。
GAFAMを中心に、今までより良いものが作られることが増えていると思う(しかも公開される)。今までより速かったり、コストが下がったり、顧客への直接的なメリットだけじゃなくて、DXとか運用の負荷が減るとかサービス側にもメリットがある場合も多い。どちらかというと、最近はインフラの進化がすごいのでDB差し替えたり(やりやすいといっても大変だが)、インターフェースとしてgRPC足したり、GraphQL用意したり。
そういう新しいものに割と気軽に乗り換えられるようにしておけるなら多少のデメリットがあるとはいえ、メリットがとてもあると思う。 ただし、アーキテクチャでは吸収しきれないくらいの変更が必要な場合があって、その場合はそれらを選択したメリットがほぼなくなってしまうので難しい。
あとは、新しいほうが面白いと思っている部分も個人的には結構あるんだよね。
ソフトウェアの設計とアーキテクチャ
概要
ソフトウェア設計の言語化スキルを磨くこと|qsona|note
ソフトウェアのアーキテクチャ(特にそのアーキテクチャを選択するとなぜ良いのか)をちゃんと言語化して説明できてないなということで、一旦まとめたほうが良さそうと思ったのでまとめてみる。個人的な考えなのでこれが正しいとは思っていないし、悩んでる部分もたくさんある。 アーキテクチャはサービスが成長して、5年、10年してから良し悪しがわかる場合もあるので難しいなと思う。
前提
採用したアーキテクチャ
レイヤー
他にもDocker用のcontainerディレクトリやらがあったがレイヤーは以下のような感じだった
- domain
- 基本的なデータ構造
- ドメイン固有の処理
- interfaces
- usecases
- 主にinterfacesから呼び出される
- 入力は素直にこれが呼び出される
- 出力はDIPに従って、usecasesに定義されたインタフェースを経由する
- infrastructure
- 独立したコンポーネント
- 具体性が増す
- 例えばDBでもPostgresqlとか
- キャッシュでもRedisとか
- 外部サービスのクライアントもここに実装してた
- 例えばPostgresqlに書き込む場合は、直接ここのモジュールを呼び出すのではなくinterfacesを経由していた
仮にHTTPリクエストがあって、DBに書き込む場合以下のような流れを取っていた。
interface(入力) -> usecases -> interfaces(出力) -> infrastructure -> DB
良さ
- レイヤーごとに差し替えやすい
- 変更が限定的
- 現時点での最良を選択しているつもりだが将来はわからない
- 最良ではないが現時点で良さそうなものを選ばざるおえない場合もある
- 再利用がしやすい
- usecases、domainは基本的に無理だがその他は別のプロジェクトでも利用できる可能性が高い
- プロジェクト内の再利用もDIによってしやすい
- テストが書きやすい(mockingしやすい)
- 差し替えやすいということはmockにも差し替えやすい
- レイヤーによっては独立性が高いのでテストも書きやすい
悪さ(悩んでいること)
- 実装量が増えやすい
- レイヤー間でのデータのやりとりにそれぞれデータ構造が必要になる場合がある
- インターフェースを用意する必要がある
- 冗長すぎる感じがする
- 差し替える可能性がほとんどなくても差し替えられるようにしている
- レイヤーのためにただ他のレイヤーを呼び出すコードがたまにある
- 変更しやすいとはいえ、場合によってはそれなりのコストがかかる
- 根本的な処理の修正は結局、他レイヤーにまたがった修正になることがある
- usecasesのテストなどはmockingだらけになりがちで意味が薄い感じがする
- ほぼmockingされた処理になってしまう
- 呼び出す順番しかテストしてない
まとめ
総じて良さのほうが上回っていると思うが、悩んでいる部分は無視できない
sql migration
あんまり情報が見つからなかったので書いた。 難しいとこないからかもしれないが。 dbのcreateができないのが難点かも。
普通にgo getしてもcliが入らないのでmanualに書いてある通りインストール
go get -tags 'postgres' -u github.com/golang-migrate/migrate/cmd/migrate
migrationファイルの作成。便利
migrate create -ext sql -dir sql/migrate initialize
こんな感じのファイルができる
20190610174331_initilize.down.sql 20190610174331_initilize.up.sql
migration
migrate -database 'postgres://[user]@[host]:5432/[database]?sslmode=disable' -path ./sql/migrate -verbose up
不整合が起きるとschema_migrationsというテーブルの不整合だったバージョンにフラグがたつ。
解消するには失敗したバージョンを直してforce実行。
migrate -database 'postgres://[user]@[host]:5432/[database]?sslmode=disable' -path ./sql/migrate -verbose force [version]
現状の go modules を使って vscode でコードを書く場合
- gocode-gomod を入れる
- Format tool を gofmtにする(vscode のデフォルトのgoreturnsは現状 go modulesに対応していない)
が良さそう。
vscodeでgoのlanguage serverがうまく動かない
前回 go modules に移行したが vscode で go の language server が実用にまだ達していなかった。 gocode は大元が開発を諦めて、forkされたものが対応しようとしているがそれもlanguage serverよりかはいいが、移行する前ほどの快適さはない。
sourcegraphが開発していたlang serverはすでに開発優先度は高くなく今後更新されなくなっていく。
代わりに bingo というのが現在開発されていて候補としては一番に上がって来る。 ただしこちらも使ってみた限りでは実用にはまだ耐えられない感じ。
もう一つはgoogleが開発しているgopls(golpsから最近改名された)。こちらもbingoとまだ大差ない感じだった。ただgoogleが開発しているので期待している。
なので現状はlanguage serverを使っておらず、gocodeのforkされたものを使っている。