メンテのいらないソフトウェア - 誰かの役に立てばいいブログ

ソフトウェアエンジニアとして働き始めて 20 年以上になります。 元々ソフトウェアでいろいろ作りたくて就いた職業なので、結構な数のプロダクトを開発してきました。 私がメインで開発したもので OSS として出ているものでは、 yrmcds: memcached クローンで、レプリケーション機能などを持つ usocksd: SOCKS4/5 サーバー & ライブラリ transocks: アプリのネットワーク通信を透過的に SOCKS サーバーにプロキシする透過プロキシ coil v2: Kubernetes の CNI ネットワークドライバ moco: MySQL を自動運用する Kubernetes オペレーター accurate: Kubernetes 上で namespace ベースのソフトマルチテナンシーを実現するためのソフトウェア などがあります。これらのソフトウェアの多くは、現役

[sho]

リポジトリを見たらそれなりの頻度でコミットがあるし、これを「メンテいらず」と呼ぶのは大言壮語では。というかこういう作業こそ「メンテ」と呼ぶのでは？

[sonots]

他者のライブラリに依存しないとか、非互換の言語仕様変更が入りにくい言語を使う、とかも重要でしょうか

[k1LoW]

流石すぎる。私の場合は、機能のリストアップというか想像はしているが結局あとで思いもよらない機能が欲しくなる。品質は妥協しないつもりだが詰めが甘すぎる。ムズカシイ...精進します。

[daishi_n]

ソフトウェアは陳腐化との戦いなので、メンテフリーは幻想なんだけどね。最終的には依存部分の非互換で使い捨てになるよね

[tofu-kun]

早めに枯れさせるということをキッチリやっててすごい

[beginnerchang]

そこはこう、djbの話とかになるんじゃないの普通？

[yarumato]

“俺、コード書きたくてソフトウェアエンジニアになったんだけど、メンテナンスに時間を取られたくない。そのために、機能や品質を早めに成熟させる。品質は妥協しない。文書にある挙動はすべて自動テストでカバー”

[juneboku]

さらっと書かれているけれど、技術力がないと体現できないことだよなあ。すばらしい。

[luccafort]

“機能・品質の成熟を早めに済ませることで、メンテナンスにかかる時間を極力ゼロにするのが、私の基本的な戦略です。”腕力でねじ伏せる感があってとってもかっこいい。

[naka-06_18]

最小化が妥当で表現は強いよね

[rryu]

まあ、不具合を直すとか欲しい機能を実装できる構造になっていないのを直すとかの本質的ではない開発のことを言っているのだと思うが、そもそもそれはメンテナンスではないと思う。

[masatotoro]

完成度を最初からあげて運用を楽にする

[honma200]

TeXとかの意味かしら。テストって追加されないのかなぁ

[dot]

メンテ不要にするよりもちょこちょこメンテして、ビッグバン的なメンテをしなくて済むようにする、というのが経験から得られた教訓かなあ。

[seal2501]

ソフトウェアの責務が限定的で、作者の技術力がすごくあって依存が少なくないと難しいので、参考にはなるが模倣はなかなか難しいな

[n314]

自作だと、機能を追加しない限りメンテナンスは要らないよね。自分の使わない機能での更新とか、自分の使わない機能のバグ修正での更新とか、結構不毛だと思っている。

[efcl]

「スコープクリープ」を減らす(メンテを大変にする機能を増やさない/スコープを明確にする) というプロジェクトタスクと捉えることができそう。 Working in Publicでは、これも「メンテナー」のタスクの一種として扱われて

[devorgachem]

わかる。私も実践してる

[koogawa]

“機能・品質の成熟を早めに済ませることで、メンテナンスにかかる時間を極力ゼロにするのが、私の基本的な戦略です”

[karikari1255]

コード書きたい人は趣味でOSS書くのが一番良いのでこれでいいと思う

[aktkro]

圧倒的に強い

[oktnzm]

"私個人はコミュニティとか面倒なので、これでいいやと思ってはいます。" すごい。OSS開発におけるアルパインスタイルみたいな印象。

[naari_3]

つよすぎる

[kamm]

moco気になる

[razokulover]

リストアップ脳力がめちゃくちゃ大事だが自分レベルじゃ後からぼろぼろとあれこれ出てきちゃう…

[buhoho]

考え方は好きだけど、実行する胆力も技術力も普通は無い。すごい。

[ken39arg]

憧れる

[syu-m-5151]

品質と効率を両立させる方法について具体的なアプローチについて。「コードを書くことが仕事ではない」という哲学に基づき、問題解決のためにコードを書くことを避けることも重要である

[Akaza]

Goは特にそれがやりやすい言語だと思う。しっかり作っても言語によってはランタイムの変化に振り回されがち。