子供の寝かしつけで寝てしまうが夜中に起きてしまい眠れないパターン
に今日なってしまった。23時半ごろトイレで目が覚め、その後目がさえてしまい全然眠れず。今日は重たい打ち合わせとそのための資料作成をしなければいけないのに困った。
今日は1時間粘ってしまったが、30分粘ってダメなときは諦めて起きてしまおう。そのほうが時間を有効活用できる気がする。
あー仕事すっかなー。
■
チームリーダーになって約2週間が経過したが、やったことといえばキックオフミーティングを開催したことと、チーム名を決めたことくらいかw 夏休みもあったし会社も全社イベントでバタバタしていたのでやむを得ない部分はある。
ゴールをどこに持っていくか。少なくとも会社の方針として外注を使っていく方向なので、うまく外注を使って開発を回す方法を考えなくてはならない。感覚としてはなんとなくわかってきている。
- 仕様をきちんと書く
今はなんとなくJIRAに書いてるが、それだとソフトウェア全体の仕様が蓄積されないので、AsciiDocにまとめるのがよかろう。
- 設計作業
ここが悩ましい。どこまで自分たちでやり、どこまで外注に任せるか。Web開発の場合、フレームワークがしっかりしてるので楽。Android開発はきつい。MVPで設計しても、それを無視したコードだったり、順守するあまりに流れが複雑になりすぎてしまったり。
- タスクは時間の見積もりができるくらいまでは分割する。半日以内くらいが目安。
- コーディング
ここは外注メイン。
- テスト
ユニットテストを導入してみたい。何のテストをしたのかがコードとして残るのは大きい。
やはりブログ書くといいね。頭がアウトプット指向に切り替わる。この流れを崩さないところまでもっていきたい。
■
あー月曜日だ。今週は打ち合わせいっぱいで忙しい。仕事貯め込んだまま翌週に夏休みに突入してしまいそうだ。
仕事に対する漠然とした不安が悶々としている。みんなはこういう不安にどう向き合っているんだろうか。
Clean Archtecture
なぜこの本を読もうと思ったか
きっかけはQiitaの記事。どの記事だったかは忘れた。
自分のソフトウェア開発の知識は10年前に学んだオブジェクト指向で止まっている。ソフトウェア開発の10年分の進化は、生産性を高めるために知っておくべきだと考えた。
また、現在Kotlinを使った開発もしているが、関数型の考え方を理解していない故に有効活用できていない気もしていた。
感想
全体の感想
まだ読んでる途中だが、読んで正解だった。ソフトウェア設計における指針が新しい考え方を取り入れつつコンパクトにまとまっている。きちんと内容を咀嚼して実行できるようになりたい。できればチームのメンバーにも考え方は浸透させたい。
覚えておきたいこと
- 関数型プログラミングのパラダイム
- ふるまいよりも構造に価値がある
- 境界線を引く → これはもともとやっていた
Clean Architecture 達人に学ぶソフトウェアの構造と設計
- 作者: Robert C.Martin,角征典,高木正弘
- 出版社/メーカー: KADOKAWA
- 発売日: 2018/07/27
- メディア: 単行本
- この商品を含むブログを見る
ファイル共有のためにgitを使うのはアリか?
早速新チームのことについて色々考えている中で、一つの懸念事項がプロジェクトのファイル共有をどうするかという問題。
以下既存のファイル共有のツールの問題点。
- ファイルサーバ
- 一部のメンバーがアクセスできない
- すぐ散らかる
- Wiki
- 使い勝手が悪い
- Google Drive
- 使い勝手が悪い
プロジェクトで共有するファイルは以下のようなもの。
- 議事録
- 提案書
- 要件定義書
- 設計書
- テストドキュメント
というわけでgitを使ったらどうか。
テキスト形式で書けるものは基本AsciiDocにする。
gitを使った場合、以下のようなメリットがある。
- commitのログがそのままプロジェクトのログになる。これにより案件の引継ぎがしやすくなる。
- ファイルのバージョン管理ができる
- テキストの場合は差分もわかる
- WordとかPDFとかExcelとかはバイナリ差分がとれるだけになるが、Commit Messageに修正事項を入れておけばよい。
- プロジェクトのファイルがメンバー間で同期される
- 適当にファイルを配置すると他の人の迷惑になるので、自然と整理される??
というわけでなんか良さそうな気がしてきた。チームのKickoffで提案してみよう。
チームリーダーになった
チームリーダーをやることになった。チームメンバーはアルバイトも入れて7人。ほどよいサイズ。
不安はたくさんある。耳の痛いことを言ったりしなければならないだろうし、自分も言われるようになるだろう。傷つくことを恐れる自分にとってはチャレンジである。そもそもメンバーが自分についてきてくれるのか。今の体制よりも生産性を高めることができるのか。
いろいろ考えなければならない。しかし、自分の癖としてついつい考えすぎて行動が遅れがちなので、考える時間を少なめに見積もり、アクションを早めに起こすようにしたい。
そしていい加減インプット指向からアウトプット指向に転換しなければと思う。自分で考えることと学ぶことのバランスをとらないと。課題を明確にせずに本を読むのはやめよう。少なくとも本を読んだ場合は書評をブログに書こう。
そんなわけで久々にブログのエントリを書いてみた。これからがんばろう。