2022年6月23日(木)のツイート履歴

ツイート

• 

  西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
  rgレッドフレーム、とりあえず組めた。あとは水転写デカール貼ってトップコート吹いたら完成の予定。
  00:33
  

• 

  西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
  まとめ: 問題を分割してそれぞれで解決したり、あるいは難しいものをそのまま難しく実装するのはある意味脳死でできる解決法であるんだけど、どちらもコストが高い。それらよりも僕らエンジニアはもうちょい工夫して頭を捻り問題を少コストで解決する手段があるんじゃないかという話。
  00:30
  

• 

  西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
  古典的には、天動説ベースでは星の動きが非常に複雑な計算式だったのを地動説に則れば非常にシンプルな計算になったという話がそれ。 同様に、xy座標で表していたものを極座標で表すことで問題解釈・表現が劇的に簡単になることもありそう。
  00:30
  

• 

  西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
  もちろん、それでも利点はあって、プレゼンテーション層やユースケース層それぞれで考慮するべきことが限定されて考えやすくなる。 ただ、複雑性に対する打ち手はこういった分割統治的な方法だけではなく、モデリング(解釈)によるものもあると思う。
  00:30
  

• 

  西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
  今日考えたいと思ったのはこれ: > 現実が複雑だからソリューションが複雑になってもしょうがない これは一見正論のように思える。例えば、レイヤーアーキテクチャでDB実装に近い部分のコードをインフラ層へ押し込んだところで、結局全体としてみた複雑性は下がっていないような気がする。
  00:30
  

• 

  西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
  また、この辺の話はsimple made easyやworse is betterなどとも関わっていると思う。
  00:30
  

• 

  西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
  ふと、複雑性について考えてみる。 僕らエンジニアのシステム開発は複雑性との戦いと言われたり、複雑な問題を簡単な問題へ分解して解決するのが役割と言われたり、現実が複雑だからソリューションが複雑になってもしょうがないと言われたりで、複雑性とは縁が深い。
  00:30
  

ツイート	お気に入り	フォロー	フォロワー
17745(0)	5339(0)	529(0)	902(0)

delivered by Twieve