業務こなしての問題・気づき
C#
やったことがないのだが、なぜかレビューアにされてしまった。。。
using
用途がいろいろあって、javaのimportと同じ認識でいると、たまに戸惑うことがあった。
使い方としては、下記がある。
- usingディレクティブ
- javaのimportと同義
- usingエイリアスディレクティブ
- javaのimportとほぼ同義。usingディレクティブとの違いが分かりにくいが、別名をつけられるってのがミソ
- typescriptのimport／javascriptのrequireに近い感覚で使える
- using静的ディレクティブ
- usingディレクティブの静的メソッド・静的フィールドと同じ
- なんか、静的（せいてき）ってタイピングしてると、やましい気持ちになる
- javaのstatic importみたいな感じ？
- usingディレクティブの静的メソッド・静的フィールドと同じ
- usingステートメント
- javaのtry-with-resourceと同じ
こうやって書き出してみると、usingステートメントが厄介。
Javaエンジニアからすると、try-with-resourceの感覚があるので、「なんでここでusing使えるんだ？？」ってなる。
イメージとしては、typescriptのimport／javascriptのrequrireに近い。
usingステートメントが、いままでやってきた言語と違う。
実際にコードを書いているor見ているのだが、利用用途としては、usingディレクティブ／usingステートメントが多め。（ほぼusingディレクティブ）
namespace
javaだとpackageの認識。
javaだと、package=ディレクトリ構成で、一致してないとコンパイルエラーになるのであまり気にしてなかったが、C#でファイル移動した際、namespaceとフォルダ構成が一致しなくなってもビルドが問題なかったので、気づかなかった。。。
namespaceを考慮しないで実装すると、無秩序になってファイル重複が頻発しそうなので、ファイル移動する場合は、namespaceを考慮する必要があるなと感じた。
ビルドの定義で、検出できたりしないのだろうか？
レビューアとしての学び
コードレビューをしているのだが、C#ほとんどやったことない人がコードレビューやって大丈夫なんですかね。。。？
初期化場所と利用箇所は近いほうがいい
- 初期化を重複してやってしまう可能性が高い
- すべきではない理由
- メモリを無駄に使う
- 初期化コストが膨れると、ボトルネックになる
- すべきではない理由
- 作っていく過程で、利用しなくなっても変数だけ残るリスクを減らせる
レビューしていて、初期化の場所が離れていると上の現象がよく発生した気がする。
特に、後者は気づきにくいから厄介だった。。。
仕様の認識
たまに、設計書に書いてあることをそのまま実装して出してくる人がいるのだが、明らかに書いてあるまま実装してると、仕様で満たしたいことが実現できていないor矛盾があるのに気づかない状態でくることがある。
そういうのは、後続のテスト工程に流さないようにしたいので、注意してみている。（テストで発覚したときの戻り工数が大きいので、レビューで取れると工数削減効果が大きいから）
上の問題が出てくるのは、仕方ないが、出てくる人は、たいてい、経歴が短い人が多い。
おそらく、仕様がなんであるのか、把握しきれていないのが問題だと思う。
もしくは、実装した結果の想像ができていないとか。
仕様→実装の落とし込みとは別に、実装した結果、どういう仕様になっているかが想像できないと発生する気がする。
これは、実装→テストを反復してやって、経験値を持つことが重要な気がする。
レビューアとして活動しているときは、上記指摘をする場合、あるべき仕様・現在の実装した結果できあがる仕様を明示して、伝えるようにしている。
理由としては、「実装→テストの反復」を、頭の中で反復してやってもらうため。
成果が出てくるかは、まだ分からない。
今のプロジェクト終わるころにどうなっているかで、レビューの効果測定しようと思う。
頭の中で終わらせるのって、化学だと「思考実験」って言うんだっけ？
コードレビューでは、いかにレビューイに思考テストをやってもらうかが重要だと思いました。
if文志向は危険！！（迫真）
結構、if文を使いたがる開発者が多いんだなって、コードレビューしていて感じる。
個人的に、if文を回避するようにしたほうがいいと思ってる。
理由としては、テストのしやすさがに関わってくるから。
if文がいたるところにあると、それをテストする必要性が出てくる。
ケース網羅してくださいって言われると死んじゃうから、なるべくif文を書かない手法を取るようにしている。
条件網羅でもキツイので、なるべくif文は辞めたい。
まだテスターだったころ、if文が大量にあるプログラムのテストをしたことがあるのだが、テストケースと予定に無理があるぜよ。。。
グロッキー状態になったことがあるので、if文を減らせるなら、なるべく減らせる方向でレビューしている。
回避手法としては、定義で紐付けさせておくとか、普遍的なものは何かを見出してデザインパターン適用するようにしている。
適用するデザインパターンは、StateやStorategyなど振る舞いに関するパターンを適用するとif文が減らせるので、多用している。
デザインパターンは設計者でも必要
今のプロジェクトは、レビューアとして活動しているので、設計者と実装者の間に入っていることが多い。
特に仕様の認識を実装者に噛み砕いて説明したり、逆に、設計→実装するにあたって、実装問題があれば、設計者に要点を説明して問題を把握してもらうように動くことが多い。
だいたい前者が大半だけど、後者は、発生するといがいと面倒なんだよね。。。
認識の違いをすり合わせるってのが、むちゃくちゃ時間がかかる。
話がそれたが、デザインパターンの知識は、設計者にも必要だと感じる理由下記の通り
- 実装コストに関わるから。
- 必要な情報が散見されるのが防げると思うから。
デザインパターンの性質上、再利用に重点を置いているので、知っていると、デザインパターンを適用するために必要な情報が集約され、結果的に実装しやすく、意図が伝わりやすい設計書になると思う。
ただ、問題として、過度に適用した結果、ワケワカメ状態になる危険もある。
用法用量を守るってのが大切だと考えている。
実装でも、たまに過度に適用しすぎて、かえって複雑になっているケースがたまにある。
ここらへんの感覚を磨きたいのだが、何かいい方法がないか、模索中
料理
今週の優勝
鶏もも肉の照焼
いままで美味くできなかったが、料理動画を数本見て勉強した結果、パリ皮で噛むと肉汁が溢れ出てくるものが作れた。
包丁で切ったら肉汁が大量に出てきたときは、かなりビビった。
肉の下処理がちゃんとできてなかったから、皮が縮まって、美味く火が通らず、ムラがでてたことが、今までできなかったところだな。
肉系は、下処理がやる／やらないで味がたいぶ変わる。
マジで、店で出せるレベルのものができてしまって、「天才か」って思った。
あまりにできが良かったので、もしかすると、もう、このレベルのものはできないのかも知れない。。。
食べたときの幸福度がダンチだった。
反省点
ホットサンド
キャベツを使う場合、千切りにしたほうがいい。
なぜなら、食べたときにちぎりにくいので、キャベツがベロっと出てきてしまい、口周りを火傷したり、汚す可能性がでてくる。。。
盛り付け
なんか美味くできないんだよね。。。
鶏もも肉の照り焼きは、すごく美味くできたんだけど、盛り付けが映えない感じになってしまって、残念だった。。。
雑記
生活習慣
GWが終わったが、休み明けの作業がものすごくしんどかった。。。
就寝サイクルが壊れかけたのが、まずかったな。。。
次の長期休暇は、就寝サイクルを壊さないように気をつけよう。。。
自宅が精神と時の部屋
最近、部屋にこもりっきりで、時間の感覚が壊れてる。
日の光があんまり入ってこないので、時間感覚がおかしいときがある。
気づいたら実は夕方とか、気づいたらてっぺん過ぎてるとかザラにある。
だから、生活習慣が壊れるわけなのだが。。。
もう、俺の部屋が精神と時の部屋状態。
でも、精神がおかしくなることはない。
料理したり、部屋を掃除してからは、むしろ自粛を楽しんている。
１日中部屋に居てもなんとも感じないのだが、これで苦痛を感じている人がいるってことが信じられない。
むしろ、以前よりメンタル面が安定した気もする。
あらためて、自分は創作活動が好きなんだと感じた。
最近は料理だったが、今度はガンプラに手を出したい状態になってきた。
ボーナスも近いし、作業環境整えたいのが、直近の夢
少なくとも、塗装環境は作りたい
