2021/06/07週 気づきと振り返り タスク管理がない現場は残業を産む

業務こなしての問題・気づき

github

ブランチ管理

ブランチ切ったりマージしたりは、だいたいgithubで完結してる。
むしろ、ローカルでやろうとすると失敗する可能性がある。
特にブランチ作成は。

あと、現場の環境にあわせてGUI使ってるけど、CUIでやったほうがいいケースが使い込んでるとある。
少し前の現場では、コマンドでやっていたけど、管理する側（レビューする側）になると、やっぱり、CUI使ったほうがいい場合が多い。

基本的な操作は、使ってないと忘れるから、なるべくコマンド打つように意識していたい。

退社時間

最近、金曜日は早く退社して休日を満喫できるようにしているのだが、変える人が誰も居ないと、「あれ？帰っちゃ不味いんだっけ？」って思ってしまう。。。
日本人志向の良くないところだとは思う。

特にタスク割り振られてないから、帰ってもいいと思うのだが、残業病が俺の後ろ髪を引っ張るんだよね。。。
やれる作業ないか聞けとかいうやつがいるけど、そもそもタスク降ってないのが悪いのでは？って思う。
だから、日本は管理職やリーダーが育たないのだって感じる。
現場に負荷を強いて、トップは楽するのは違うと思うんだよね。

２，３年前は、やることやって即帰るってのができていたんだが、いつの間にかできなくなってしまったな。。。
たぶん、タスク量が見えない現場に居るせいだろうな。。。
タスクが明白でアレば、状況見て即帰るってのができるのだが、難しいね。。。

思うこと

アラフォー世代

自分がいる現場がそうなだけかも知れないが、やたらと攻撃的な発言が多い 特にＩＴ業界だと、知能労働であるためか、自分の思い通りにならないことに対して癇癪を起こすことが多いような気がする。 地位もそれなりにあるのが面倒なところだと思う。。。

特に癇癪を起こすのは、ＩＴがブラックだと言われる所以だろうな。。。

平時から、穏やかで物腰を柔らかくしておかないと、いざというときに癇癪を起こしてメンバーを潰してしまいそうだから、反面教師として見てる。

もしかして、発破をかければ上手くいくと思っているのだろうか？
なんか、そんな気もする。
そんなことしても、知能労働者にとっては、ただのストレスだから意味ないと思うが。。。

発破をかけるのは、体育会系だろ。。。
知能労働者にそんなことしても無意味だということが分からないのだろうか？
かけたら、逆に萎縮すると思うんだよね。。。
発破かけられる作業を避けると思う。
その結果、前向きに作業してくれる人が減り、作業が特定の人に集中→ミスをする→発破かけられる→消極的になる のループが起きて、チーム環境悪くなるだけだと思うんだ。

似たような年齢層がリーダーの現場で、同じようなことが連発して起きたから、そう思うだけで、実はどの年代にも居るのかも知れない。。。
ここら辺は自分の経験則で語っているが、他の人はどうなんだろう？
４０より上は全部そうかな？

その他

electron

unable to load preload script

preloadで実行できない処理があると出てくる。

可能性として高いのは、mainプロセスでしか実行できないものを利用していることが多い気がする。
自分は、そうだった。。。

mainプロセスでしか利用できないやつと、rendererプロセスでしか利用できないやつの区別ができないんだよね。。。
ドキュメントに書いてあるのは知ってるんだけど、そこら編のサイトを見てやると、知らずに実装してしまい、上記のエラーには見えないエラーが出るから、かなり悩む。
今日は１日潰してしまった。。。
アニメ見ながらやっていたから、丸１日ではないけど、結構悩んだ。

美容

最近、電動シェーバーを新調した。
俺のひげのせいか、前のシェーバーは全然切れなかったんだよね。。。
ひげが柔らかくて太いのが俺の毛の特徴なんだが、前のやつは剃り残しが結構起きてた。
だから、T字カミソリで剃り残しを剃ることをしていた。
コロナ禍だから、ひげ剃らなくてもいっかって思うようになって、剃らなくなってたけど、新品に変えてからは、剃り残しがほとんどないので、毎日使ってる。
心なしか、少し気分もいい。
身だしなみを整えるって、意外とメンタル的に効果があるのでは？って最近は思うようになった。
一時期メンタル不調になってたりもしたので、外出予定がなくても、身だしなみを整えるように心がけたほうがいいなと思いました。

久々の酒

なんか、日本酒が安売りしてたから、久々に買って飲んだ。
地元に近い地域の酒だったが、特に美味いとは思わなかったな。。。
不味いとも思わなかったけど。
冷酒にした方が美味いのだろうか？
日本酒の美味い飲み方がよく分からん。
冷たいほうが飲みやすい気がする。
調査の余地がありそう。

2021/05/31週 気づきと振り返り アンチswitch民に居場所はないのか！

業務こなしての問題・気づき

レビューア

どこまで役割を果たせば・・・

レビューアとして活動しているのだが、どこまでやるべきか迷う。
明らかに可読性最悪なんだけど、レビュー依頼されてきて、時間的にやり直してる時間がない場合、通すか通さないかで悩む。
結局、動き的には問題なかったから通してしまったが、次に読んだときは、やってる内容わからない気がする。。。

なんて言えばいいのだろうか、関心事が数ステップの間にごちゃまぜで入っているせいで、「本当にこのロジックは大丈夫なのか？」って不安になるコードだった。
こういうのって、switch文でよく発生する印象がある。
switch文は、分岐した後に粒度が異なることをやり始めると、ものすごく可読性が落ちると思うんだよね。
説得させるのが面倒くさいから通したけど、思い返すと、通すべきではなかったと思ってしまう。

他のレビューアの人は、どういう価値観でレビューしているのだろうか？
自分は、開放/閉鎖原則に乗っ取らせるのと、可読性を気にしているのだが、他の人の着眼点はどういうところを見ているのか気になる。

仕様と障害内容と実装と改修内容の突き合わせが辛たん。。。

障害が発生して対応したソースのレビュー依頼が来るのだが、ものすごく辛い。。。
設計書と修正内容を比較、修正前のソースと障害内容を照らし合わせて原因を特定し、原因が取り除かれる対処になっているか、修正した内容で新たなバグを生み出さないか見てると、もう、頭がおかしくなりそうだぜ。。。

たまに、問題がきちんと把握できてないケースもあるから、結構、神経質になるくらいマジマジと見ているけど、指摘漏れてそうな予感がビンビンするんだよね。。。

単体で取れればいいやのスタンスで入れば良いのだろうか？
メンタル的に不安定になってそうな気がする。

Git

Gitのコミット単位

gitのコミット単位がバラバラで、複数コミットに対応が跨ってることがザラにあるのだが、それって普通じゃない認識であってる？
レビューするときにシンドすぎて、ギブアップ宣言したからな。
今は、コミット単位をまとまりのある単位でするようにお願いしているが、たまに守ってないのとかあるんだよね。。。

そういうのって、どうやって守らせればいいのだろうか？
一回レビューアにしてみるといいのかな？

その他雑記

rssリーダーができた

個人の趣味で、electronで作っていたRSSリーダーができた。
まだ既読にしたり情報取得するくらいしかできないが、もうちょっと肉付けしたい。
デザインは、Pingendoでやれば、ある程度それなりっぽいのができて満足はしている。

2021/05/24週 気づきと振り返り 「throw e」でなんでトレース情報が消えるねん！！

業務こなしての問題・気づき

c＃

「throw e」と「throw」 違い

トレース情報がリセットされるかされないか。

リセットされるのは、「throw e」
なぜリセットする言語仕様なのかは分からない。。。
基本的に、リセットしたいときってないと思うのだが。。。

このせいで、直さねばならないところが大量にあることに気づいてしまった。。。

ソース管理

問題が起こると、胃が痛い。。。
原因を特定し、

コミット単位がおかしい

プルリクは、自分が回収したもの以外が入っていることを確認して出すのだと思っているが、複数対応が跨ってプルリクされることがある。
レビューする側はかなりきつい。
跨ってプルリクしてくるやつ、公開処刑にしてやろうかとも思ったが、優しい僕は、そこまではできなかった。

そういう文化が根付かないように対応したいのだが、どうやって誘導するべきだろうか？

やっぱり、公開処刑が一番楽だろうか？
迷いどころではある。

一回、関係ない修正を取り込んでしまったせいで、デグレが発生し、火消しで１日が終わってしまったことがある。。。
マジで辛いから、git使ってる人は、マジで辞めて。
これ以上ストレスかけられちゃうと、ハゲちゃうー

プログラミングで思うこと

switch文

case内でifが出てくると、もう無理。
関心事とネストが不一致になることが多く、かなり難読化しやすい。
やっぱり、switch文は好きになれない。

グローバル変数が大チュキ

よく分からんのだが、なぜかグローバル変数を多用する人が結構な割合でいる。

レビューしていて感じたが、なぜグローバル変数を使いたがるのだろうか？
汎用性だけに眼が行っている気がする。
デメリットの方が強いことを認識してないのが原因な気がする。

マジでバグの温床だから、辞めたほうがいいと思うんだよね。
レビューでしつこいくらい指摘してやったから、もう同じミスは侵さないと思いたい。

業務外

趣味で開発したことで学んだことをまとめておく

electron

preload.js

公式ドキュメントに、nodeIntegration: true,は非推奨ですみたいな記述を見つけて、preload.jsで対応するように切り替えた。
理由は、XSS攻撃があるためってあった。
業務で使うことも考えて、preload.jsで実装することを試した。

やり方としては、preloadだとnode.jsの機能が使えるので、利用したいnode.jsの機能を先読みさせて、renderer.jsで使うようにしていた。

例（一部抜粋）

const fs = require('fs');
process.once('loaded', () => {
  global.fs = fs;
});

let fs = window.fs;

面倒くさいのは、renderer.jsで入力補完が聞かないところ。
もしかしたら、何か回避方法があるのかも知れない。
ちなみに、使っているのはvs code。

思ったより、簡単に導入はできた。
入力補完が聞かないのがネック。。。

typescriptなら回避できるのだろうか？
環境準備が面倒くさい&JSでも十分開発できるから、このままでもいいかと思っている。

参考サイト

electron-forgeでpreload.ts - Qiita

その他雑記

スマホを落とした

スマホを落としてしまって、画面にヒビが入ったかと思って絶望したが、強化ガラスフィルムだったので、本体は無傷だった。
強化ガラスフィルムにヒビが入ったけど、そのおかげで本体への衝撃が緩和されて、ひび割れにならなかった。
マジでありがたかったから、新しい強化ガラスフィルムを張り替えた。
3000円くらいするけど、それで本体が守られるんだから、安い買い物だと感じてた。

Java Gold SE11

そろそろ移行を考えて、勉強を始めようと思っているが、時間がとれない。。。

最近、やりたいことがいっぱいあって、勉強に割く時間が後回しになっているんだよね。。。
どうにかして時間を捻出したい。

【参加報告】JJUG CCC 2021 Spring

イベント内容

【オンライン】 JJUG CCC 2021 Spring - 日本Javaユーザーグループ/Japan Java User Group | Doorkeeper

全部見ることはできなかったけど、興味関心あるものは見れた。

参加セッション感想＋メモ

フロントエンド・バックエンド分離の道のり

• 昔ながらのMVC
  • 責務が多い
  • コードがトレースしにくい
  • 並行開発が困難

技術的境界をまたぐ必要が多い＝責務が多い＝やるべきことがおおい＝知識が多い＝辛たん

• 独自FWが醸成されやすい環境

  • 処理が共通化されやすい
  • 時間が経つと
    • コードが読みづらい
    • FWを知っている人間がいなくなると問題対応が難しくなる

• JSP

  • カスタムタグの理解がむずい

• JS

  • javascriptの進化に追いついてイケてない
  • DOM操作の複雑化

JavaエンジニアがJSP/JSを扱うのは辛い

• 問題を解決するには

  • 技術境界をなくす
  • 並列化開発可能にする

• 解決方法を実践する方法

  • サーバーサイドをAPI化
  • フロントはサーバーとは別FWを利用

API化のメリット

• テストしやすい
• 表示の考慮がいらなくなる
• JSP書かなくていい
• 再利用性が高くなった

API化のデメリット

• フロントが完成しないと画面の確認できない（疎通的な意味）
• 画面表示して気づくミスが残る
• フロントとバックが結合部分になり、バグが混在しやすくなった
• 中途半端な棲み分けは、複雑さを残す
• フロント・バックエンドで作業が分かれる
  • 情報連携、重要
  • 連携ミスがあると結合時にバグになって時間がかかるため、情報連携の手順を整備をする必要がある
  • 事前にノウハウがないと教育コストが高い

感想

技術境界は変えられない壁なんだな～と見ていて思った。
分断したときの問題点は、やはり結合部分に集約されるのだと感じた。

あなたの勘と経験は本当に合っていると断言できますか？　プロダクション環境での計測のススメ

• プロファイリングの意味

  • 思い込みの改善をなくすため
  • データに基づかないものは、オカルト

• プロファイリングしないことのデメリット

  • 性能が分からない
  • 対応が後手になる
  • 再現できない
  • 平常時と非常時の差がわからない

カバレッジツールの導入→人への技術的依存を消せる。

感想

jacocoは、知ってた。
一時期、カバレッジの計測のため、ローカル環境で使っていた記憶がある。
使っていたときは、デバック実行でテストしていたときにカバレッジ図るのに使っていた気がする。

メソッドorクラスが死ぬまでのフローは、初めて見た気がする。
カバレッジの利用法として、コードの生死判断にも使っているわけね。

@Deprecatedに行くことはほとんどないかと思ったが、思い返すと、たぶん、ほとんど@Deprecatedに行く気がする。。。
有識者だから確実ってことのほうが少ないと思う。
そもそも、カバレッジで利用箇所が少ないところを見ているのだから、有識者でも知らないのは当然な気がする。

ソフトウェアアーキテクチャの選び方

ソフトウェアアーキテクチャが必要になるとき＝長く運用するとき

将来は予測不可能。ワンタイムではないサービスを作る場合、一定の期間以上のサービスを作る際に、考慮の余地がある。

ソフトウェアの品質と開発効率の損益分岐点＝1ヶ月

• アーキテクチャの目的・達成したいこと
  • 抽象化
    • 抽象度の粒度を合わせる
  • 問題の分割
    • マルチタスクの軽減
  • シンプル化
    • コード間の結合を複雑化しないようにする

アーキテクチャの種類

• レイヤードアーキテクチャ
• ヘキサゴナルアーキテクチャ
• オニオンアーキテクチャ
• クリーンアーキテクチャ

オンラインイベントの感想

アンカンファレンスの様子を見ようと思ったが、操作がイマイチ分からなくて断念した。。。
なんかAmong Usのゲーム画面みたいだな～とは見ていて思った。
キルされそうだから、あんまり長い時間は滞在しなかった。

自宅で見えるから、快適に視聴できた。
デュアルモニタで見ながら検索したりできるのは楽だった。
あと、部屋に人数制限がないから、見れないことがないのも良かった。

今回は、Java16のアップデート内容があんまりないから、事例紹介が多かった印象。
今の現場でJavaは使ってないけど、内容的にはついていけるから問題なし。
ドメイン駆動系のセッションが多かった気がする。
ドメイン駆動は、何回で雰囲気で聞き流しちゃうけど、どっかでちゃんと勉強はしたいとは思うが、座学だけだと理解するのは無理な気がする。。。

2021/05/17週 気づきと振り返り はーやくこいこいボーナス日

業務こなしての問題・気づき

c

テスト用のプログラムを実行したい

C#をほとんどやったことがなかったので、この実装はイケるのか？って思うことがたまにある。
Javaのときは、クラスを適当に作って試してたけど、C#のビルドプロセスが分からなかったので、どうやればいいんだろうと思って調べた。

やることはjavaと同じで、ビルド→実行。
ビルドして出来上がるのがexeってのが、違和感あったけど、とくに問題はなかった。
cscでコンパイルしてできたexeを叩いて、コンソール出力内容とかで試してた。
自分で作ったexeだから問題ないはずだけど、なんかやましい気持ちになる。

拡張メソッド

既存の型やクラスに、元の型の変更や継承をすることなく、新たなメソッドを追加できる仕組み。

頭では理解しているが、どういったデメリットがあるか、考えが及ばなかった。。。

提供されている利用頻度が高いクラスに対して拡張メソッドを追加してしまった。。。
その結果、不本意なところからも呼び出せるようになったりすることを後で知った。
しかも、定義場所がクラスから離れた場所にできるので、可読性を著しく下げるなってのを感じた。

Javaにない機能に触れるときは、その機能がもつ本質部分の見極めをちゃんとしたほうがいいなと感じましたとさ。

エンコード

デフォルト設定は辞めて、なるべく書く。
明示することで設計と実装の差異をなくしたほうがいい。

あと、最初に気をつけようねって話しても、知らぬ間にバグとして入り込んでくるから、恐ろしい存在だなと思った。。。

チーム

情報伝達

やりとりで、意思が伝わってない場合がある。
その場合は中間に入れるように動くと円滑に意思伝達できる

チーム雰囲気大事

中が悪いと、意思疎通ができてないときに誰も合いの手を入れてくれないので時間がかかる。
圧倒的当事者意識をなくす要因になるので、チーム雰囲気ってのは大切だなと思う。

強権を発動したり、相手を罵倒するのは、人間的にもどうかと思ってしまうな。。。

その他雑記

料理

今週は、これといって優勝作品は作れなかったが、牛丼に初めてチャレンジした。
やっぱり、吉野家や松屋は、すごいんだなって思った。
作れるには作れたんだが、肉に味が思ったよりつかなかった。。。
玉ねぎや汁は、無茶苦茶美味いんだけど、肉が思ったほどではなかった。
何かコツがあるのだろうか？

そう言えば、もらったギフト券でミキサーを買った。
ミキサーでバナナスムージーを作ったのだが、そもそもスムージーを飲んだことがないので、成功しているのか失敗しているのかよく分かってないんだよね。。。
とりあえず、飲めるレベルのものはできている。

オンラインイベント

JJUGのオンラインイベント出たのだが、他にもやってるのあるのだろうか？
オンラインイベントの検索サイトって、どこかにあるのかな？

ガンプラ

最近、またガンプラ作るようになったのだが、塗装環境を作ろうか悩み中。
一人暮らしだけど、どうしても塗装ブースが欲しいんだよね。
ムラなく塗れるって、そうとうすごいことだと思うんだよね。
とりあえず、ボーナスの使いみちは気まった。

2021/05/10週 気づきと振り返り 広い作業スペースはサイコー

業務こなしての問題・気づき

dosバッチ

ちょっとしたものを作りたくなって、調査した。
結局、ネットワーク超えが問題になってきたので、バッチファイルの作成は辞めたが、とりあえずメモったのを乗せる。

echoオフ

やり方としては、下記がある。 1. コマンド前に@につける 2. echo off

個人的な感想としては、コマンド単位でやれる@を付けたほうが、誤削除によるソース紛失の可能性が低くなるのではないかと感じた。

ネットワーク越しのコピーは不可

ネットワーク越しにファイルをコピーしてこようとしたら、パスがあってるはずなのに、コピーできなかった。
理由は、許容してないから。
どう対応すればいいかというと、ネットワークドライブでアクセスできるようにすれば、大丈夫らしい。

調査して原因が分かって、さらにそこからネットワークドライブの設定がいることに萎えて、やるのを辞めた。

C

namespaceでクラスが競合

namespaceで同じクラスがあって競合問題が発生していた。

gitでブランチ開発しているのだが、別々のブランチで、同じnamespace・同じクラス名なやつがあって、開発ブランチに両方入れたときにビルドエラーとなった。。。

どっちも自分がレビューしていたけど、気づかねぇよ。。。
ローカルの開発環境でビルドエラーがないから、問題ないと思うじゃん？

クラス構成レベルで、そういうのを考えないといけないな～と個人的に思った。

その他

dellノートPCでファンクションロック

fn+escでファンクション固定化できる。
F2やF5、F7あたりをよく使うので、毎回fn押さずに押下して、毎回イラツイていたが、少しは軽減できそう。

ファンクションロックしてないときのエクセル操作は、かなり苦痛だった。。。

sql

with句

いまいち、使い方が分からん。
サブクエリと一緒な気がするが。。。
サブクエリの使い方を間違わなければ、基本使わなくてもいい気がしている。
何度も使えるってのは理解しているが、いかんせん、慣れてないせいか読みづらい。。。
あんまり使ってこなかったので、アンチパターンをよく分かってないんだよね。。。

どこかのタイミングで、調査して内容まとめた方がいいのかも知れない。

料理

今週も、結構な頻度で料理した。
麻婆豆腐は、もうレギュラー化しつつある。
あとは、卵で閉じるのって、すごく簡単だなって思った。
高校のときに、家庭科で親子丼の作り方を覚えたが、あれの流用が簡単すぎてやばい。
卵で閉じてしまえば、そんなに大崩することはないなって思った。
今週は、豚肉、カキフライを閉じて丼ものにしていた。
あと、カニ玉とかも作った。

今週の優勝

自炊した中で、一番良くできたのは、きゅうりの塩漬け。
簡単だけど、むちゃくちゃ美味かった。
塩で揉み込んで１日置いたんだが、かなり美味しく仕上がった。
米が進むのと、酒のつまみにしたりして食べてた。
普段、酒は飲まないのだが、作ったのを味見して食べたら、無性に飲みたくなった。
久々に酒を飲んだ気がする。
飲んだのは、軽いチューハイだけど、たまに飲むのもいいものだと思った。

今まで、市販の浅漬の素とか買ってたけど、調味料があるなら、自家製の方がうまいなって思った。

自宅の作業環境

かなり変えた。
まず、テーブルを座卓からＬ字テーブルに切り替えた。
以前から、作業スペースの狭さが気になっていたので変えたが、ものすごく快適
リモート勤務なんで、ノートPC配布されているのだが、今までだと自分のPCと一緒にテーブルに置くことができなかった。
しかし、Ｌ時になったので、簡単におけるし、作業を切り替えられるのがとてもいい。
椅子も、それに合わせて変えた。
現場で使うような回転椅子に変えた。肘掛けは、壊しやすいので、強度がありそうなやつを使っている。
前の座椅子は、安物だったせいか、首がやたらと疲れるのだが、今は、そういったことはなく、椅子の上で寝られるくらい快適

安く作業環境を済ませようとしていたが、PCの作業環境は、スペースを確保するのが重要だと思った。
狭い範囲では、かなり苦痛を感じる。

直近の目標

Java SE 11 Goldの試験対策本が出てたので、8月 or 11月目標で 8→11に乗り換えたい

参考サイト

コマンドプロンプト | エコー機能のON/OFFを切り替える(ECHO)

DELLのノートパソコンでファンクションキーが使えない時の対処法 ｜ PC上手

SQLのWITH句の使い方や感想 - Qiita

SQL WITH句で同じSQLを１つのSQLに共通化する

2021/04/26週+5/3週 気づきと振り返り GW明けは休み疲れがひどかった。。。

業務こなしての問題・気づき

C#

やったことがないのだが、なぜかレビューアにされてしまった。。。

using

用途がいろいろあって、javaのimportと同じ認識でいると、たまに戸惑うことがあった。

使い方としては、下記がある。

• usingディレクティブ
  • javaのimportと同義
• usingエイリアスディレクティブ
  • javaのimportとほぼ同義。usingディレクティブとの違いが分かりにくいが、別名をつけられるってのがミソ
  • typescriptのimport／javascriptのrequireに近い感覚で使える
• using静的ディレクティブ
  • usingディレクティブの静的メソッド・静的フィールドと同じ
    • なんか、静的（せいてき）ってタイピングしてると、やましい気持ちになる
  • javaのstatic importみたいな感じ？
• 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が終わったが、休み明けの作業がものすごくしんどかった。。。
就寝サイクルが壊れかけたのが、まずかったな。。。

次の長期休暇は、就寝サイクルを壊さないように気をつけよう。。。

自宅が精神と時の部屋

最近、部屋にこもりっきりで、時間の感覚が壊れてる。
日の光があんまり入ってこないので、時間感覚がおかしいときがある。
気づいたら実は夕方とか、気づいたらてっぺん過ぎてるとかザラにある。
だから、生活習慣が壊れるわけなのだが。。。
もう、俺の部屋が精神と時の部屋状態。

でも、精神がおかしくなることはない。
料理したり、部屋を掃除してからは、むしろ自粛を楽しんている。
１日中部屋に居てもなんとも感じないのだが、これで苦痛を感じている人がいるってことが信じられない。
むしろ、以前よりメンタル面が安定した気もする。

あらためて、自分は創作活動が好きなんだと感じた。
最近は料理だったが、今度はガンプラに手を出したい状態になってきた。
ボーナスも近いし、作業環境整えたいのが、直近の夢
少なくとも、塗装環境は作りたい