ソフトウェア設計の際には遺書を書こう

この記事はハワイアンAdvent Calendar 2020 2日目の記事です。ツイートアナリティクスによれば、1日目のブログへのエンゲージメントは32という事だそうです。今確認のためにもう一回開いたので33です。わたしは自分のブログを何回も読み直すので、99%は自分のアクセスでしょう。これまでご愛読頂きありがとうございました。 Advent Calendarの前半では進化的アーキテクチャについて触れてやっていくつもりなので、その為の前提を埋めていきたいと思います。 2020年現在、サービス開発や製品開発の為のソースコードの自動生成が進んでいますが、残念ながら製品開発の根幹となるロジックは人間が書いています。人間がソースコードを書くこの時代において、ソフトウェア設計とはなんの為にあるのでしょうか。リファクタリングはなぜ行うのでしょうか。綺麗なコードを書くのはなんの為でしょうか。綺麗なコード

[baronhorse]

後任に刺される覚悟の話かと思った

[su_zu_ki_1010]

自分も出来るだけ探しやすい場所にログは残すようにしているけど、このログを遺書と表現するという発想は無かった。遺書、使っていきたい。

[a-know]

そうだな

[progrhyme]

設計、採用した技術、実装方法、…そういった1つひとつに賞味期限やその理由を書くってことね

[Nnwww]

アーキテクチャにはそれがどう改修or運用されたら当初の想定を超えた＝設計の寿命なのか文書として残せという話。かなり重要なはずなのに今まで考えたことなかったので真似たい。

[yarumato]

“ソフトウェアの寿命が尽きたとき、該当ソースコードが削除された時、あるいは寿命より前にサービスが終了した時に、今後の寿命の計算に考慮しましょう。取り組むものについて、寿命を計算してみてください。”

[takamii228]

最近は遺書に近いこの辺すぐ傷みそうとかサポート切れたらこっちに移行してね的な予言の書を書いてから退出するようにしている。

[programmablekinoko]

優れたハッカーはドキュメントを書かないと言われていたが、要するに彼らは一から作り直すので保守が不要なだけなんやなと気づいた

[userhiro]

面白い

[a-kuma3]

「寿命」という言う意味では、仕様に則った構造化設計へのアンチテーゼがオブジェクト指向だったはずで、寿命を気にしなきゃいけないクラスは素性が悪い。と、自分に問いかけてはいるけれど。まあ、難しいわな