Upgrade to Pro — share decks privately, control downloads, hide ads and more …

プロダクトと向き合いながら 目の前のコードと戦うには / Fight the code in ...

soudai sone
November 02, 2022

プロダクトと向き合いながら 目の前のコードと戦うには / Fight the code in front of you

コドモン社でのセミナー内容です

soudai sone

November 02, 2022
Tweet

More Decks by soudai sone

Other Decks in Technology

Transcript

  1. 自己紹介
 曽根 壮大(38歳)
 Have Fun Tech LLC 代表社員
 株式会社リンケージ CTO


    
 そ  ね   たけ とも
 • 日本PostgreSQLユーザ会 勉強会分科会 担当
 • 3人の子供がいます(長女、次女、長男)
 • 技術的にはWeb/LL言語/RDBMSが好きです
 • コミュニティが好き
  2. “「いい質問だ。定義が『売上』となっているのは、必ず『納品』までを考慮しな ければならないためだよ。 仕掛品や完成品の在庫をどれだけ作っても、『納 品できなければマネジメントが成功したとは言えない』からね」
 確かにそうだ。だが、耳慣れない言葉に、私は思わず聞いていた。「在庫と は?この業界に在庫なんてありませんが?」
 私の言葉に、ジョナサンは悲しそうに首を振る。そして言った。
 「いいや、在庫の山はあるのだよ。残念なことに、それこそ山のようにあるだ ろう。ものづくりをしている業界で、納期遅れが起きている職場で、現場に在 庫が無いなどと考えるのは大きな誤りだ」


    「『在庫』とは、将来納品するために存在する、作りかけの未完成品や納品 前の完成品のことだ。 そのままでは納品できないもの、全てが在庫だ。
 例えばIT業界での『在庫』とは、『書きかけのコード』『未テストのコード』『別の コードの完成を待っているテスト済みのコード』 『完成していても顧客に納品 されていないコード』を指す。もちろん、『完成していても顧客に納品されてい ないドキュメント』も在庫だ」”
 https://gist.github.com/voluntas/9c1d9d51e86a853fed6889f743a12145
  3. Make each program do one thing well. 一つのことに集中することで プログラムに不要な部分をなくせる。 不要な部分があると、

    実行速度が遅くなり、 不必要に複雑になり、 融通が効かない。 https://amzn.to/33QPAdv
  4. Build a prototype as soon as possible. ソフトウェアには常に改善の余地はあるの はもちろんだし、時間的な制約などでその ソースコードは必ずしも最高の状態が保た

    れているわけではない。 ほとんどのソフトウェアは妥協の産物だ。 完成することはなく、ただリリースがあるだ けだ。 https://amzn.to/33QPAdv
  5. Build a prototype as soon as possible. UNIXの考え方では、なるべくはやく第三のシス テムを構築するために、すばやく試作 することをおすすめしている。

    直接、第三のシステムをつくることは できないのだ。 1. 短い機能仕様書を書く (3〜4枚程度) 2. ソフトウェアを書く 3. テストして書き直す。 満足できるまで、これを繰り返す。 4. 詳細なドキュメントを (必要なら)書く https://amzn.to/33QPAdv
  6. <?php $view_flag = $_GET[‘v’]; ?> <html> <head> <title>サンプル</title> </head> <body>

    <p>PHPのテストです。</p> <?= $view_flag ? $view : null ?> </body> </html> https://hoge.com?v=true 特定のフラグのときだけ、特定 の表示する 1. ボタン 2. リンク 3. バナー 4. コンポーネント 5. 画面 6. 機能 Viewを見せない
  7. <?php class PlainText { private $textString = null; public function

    getText() { return $this->textString; } public function setText($str) { $this->textString = $str; } } 文字列を扱うクラス。 これに大文字するメソッドを追 加したい場合は? Decoratorパターン
  8. <?php class PlainText { private $textString = null; public function

    getText() { return $this->textString; } public function setText($str) { $this->textString = $str; } // 現場で一番良く見る実装 public function upperCaseGetText($str) { return mb_strtoupper($this->getText()); } } 仕様追加のたびにPlainTextク ラスが大きくなる。 小文字にしたい場合など、どん どんこのクラスが大きくなって いくことが目に見えている。 getText()にifを追加するのは もっとダメ。 Decoratorパターン
  9. <?php /** * テキストを扱うインターフェースクラスです */ interface Text { public function

    getText(); public function setText($str); } Decoratorパターンの場合。 まずはインターフェイスを定義 する。 Decoratorパターン
  10. <?php class PlainText implements Text { private $textString = null;

    public function getText() { return $this->textString; } public function setText($str) { $this->textString = $str; } } 先程のクラスと一緒。 インターフェイスに対する 実装クラスになった。 Decoratorパターン
  11. <?php require_once('Text.class.php'); abstract class TextDecorator implements Text { private $text;

    public function __construct(Text $target) { $this->text = $target; } public function getText() { return $this->text->getText(); } public function setText($str) { $this->text->setText($str); } } Decoratorクラスを作る。 コードの遊び部分になる。 Decoratorパターン
  12. <?php require_once('TextDecorator.class.php'); class UpperCaseText extends TextDecorator { public function __construct(Text

    $target) { parent::__construct($target); } public function getText() { $str = parent::getText(); $str = mb_strtoupper($str); return $str; } } さぁ!Textをdecorateしてみ ましょう!! UpperCaseTextクラスを実装 するとこうなる。 元のPlainTextクラスに全く影 響を与えずに機能を追加する ことができた。 Decoratorパターン
  13. <?php require_once('TextDecorator.class.php'); class DoubleByteText extends TextDecorator { public function __construct(Text

    $target) { parent::__construct($target); } /** * テキストを全角文字に変換して返します * 半角英字、数字、スペース、カタカナを全角に、 * 濁点付きの文字を一文字に変換します */ public function getText() { $str = parent::getText(); $str = mb_convert_kana($str,"RANSKV"); return $str; } } さらに機能追加。 機能追加の単位がクラスに閉 じるので仕様追加の範囲が絞 ることができる。 1クラス、1責務。 シンプルでわかりやすい。 Decoratorパターン
  14. 正規化とSimple is beautiful
  ここまでシンプルな実装を目指しましょうと強調してきましたが、「シンプ ルな実装」とはなんでしょうか。RDBMSを使う上でシンプルな実装のヒン トは正規化です。正規化のコツは次のように表現できます。
 • 事実だけを保存する
 • 重複がない


    • 不整合がない
 • nullがない
 (中略)
  このようにシンプルな設計を目指して考察を繰り返していくことが重要 です。そして同じくらい重要なこととして認識すべきはイージーとシンプル は両立できる、ということです。シンプルを目指し考察を繰り返すことがま さにデータモデリングであり、変化に強い設計につながっていくのです。
 
 https://agilejourney.uzabase.com/entry/2022/07/28/103000
  15. 失敗を許容する
 • ログを元に再実行できる
 ◦ 冪等性
 • ログを元にデータを再現できる
 ◦ 再現性
 •

    ログを元にどこまで・何が・どうなったかわかる
 ◦ 可観測性
 ログとリトライとリラン
  16. 失敗を許容する
 • ログを元に再実行できる
 ◦ 冪等性
 • ログを元にデータを再現できる
 ◦ 再現性
 •

    ログを元にどこまで・何が・どうなったかわかる
 ◦ 可観測性
 ログとリトライとリラン 例えばエラーログが出たときに「次はこのコマンドを叩いてくれ」とメッセージ を出すことができるか?