残業が多いことのデメリット

有能で自分で勝手に学習する人間に制約を書けて、新しいことに挑戦することができない組織となる。

 

有能な人間は極論。働かせない方がいいい。

 

しかし、ビジネスに最適化させるとノーワークはできないので残業位はさせない方が良いというのが最低限のできることであるといえる。

社会の文化

雑感

今を生きる現代社会において

否定の有効性

疑うことの有効性を上手く活用できていないのかなと思う。

非社会的な行為として排除され続けた結果なのかと思う。

 

疑い続けることと回らない社会になっているのかもしれない。

全てを疑う必要はないがそれらの道具をうまく活用する方法を提案できる社会でないと、今の変化が激しい社会を反映させることや良い政治を選ぶ力は減るのではと思う

 

ここをトップダウンにするとより極化するし

ここをボトムアップする教育が反映されるのは50年後とかになりそう

 

ひろゆきがうまく疑うことの良い文化圏を作り出してほしいけどはてさて

自分には何ができるだろうか

DDD

DDDを

課題

前回採用面談

MVCコントローラとしていた。

レイヤードアーキテクチャを採用レイヤーわけができていなかった。

大量に同じコードがもたせった。

 

最大の問題

チーム内にDDDに詳しい人がいない

 

最大の問題

規律自体はできていない。

業務フローの切り出し

モデル

 

プロダクトオーナーの認識が整理

開発の安心感

工数がかかる。

 

テスタビリティが下がる行為

テスタビリティが下がる場合と上がる場合をメモする

 

テスタビリティが下がるのは、依存関係が多い時にテスタビリティが下がる。

不要な依存は増やさないようにすること

不要な依存とはfatな機能から発生する。

 

テスタビリティが下がる行為２

高結合なオブジェクトを使用してファクトリメソッドを作る。

テストする際に無駄な値を設定してテストする必要があり、テスト容易性が下がる

 

テスタビリティが下がる行為3

データベースをCI/CDでテストする際に様々なデータが入ったDBのテストを各機能開発者が同時期に開発を行い、DBの初期化などのタイミングの問題でテストが失敗する状態。テスト容易性が下がる。

マイクロサービスアーキテクチャの要素の一つDBの分割や、dockerを使った試験を行う環境作りが大切になる。

 

テスタビリティが下がる行為4

画面の入力項目数が多い時はテストがしにくい

 

テスタビリティが下がる行為5

企画検索画面色々なテーブルから情報を引っ張るところがある

ここのテストをすることが難しい。

解決策:DBを分割->各サービスで取得して各テーブルのテストを指せない。

解決策:DBユニット->DbUnitを使う

 

番外編-人間編1

DBUnit学習が必要

テスト仕様書を丁寧に書いたり、

このシステムを知らない人でもできるようにすること。

 

そもそもランニングコストが高い？

 

戻り値があるとテストしやすい