悪いAPIは伝染していく: 柴田 芳樹 (Yoshiki Shibata)
企業内のソフトウェア開発では、常に新規の開発とは限りません。既存のソフトウェアに新たな機能を追加したり、既存の機能を修正したりすることの方が多かったりします。 既存のソフトウェアに対して新規の公開APIを追加する場合に、既存の公開APIを参考に作ることがあります。その際、既存の公開APIの出来の悪さを、そのまま引きずった新規の公開APIを作成するエンジニアが多くいます。 特に、経験の浅いエンジニアに担当させた場合には、何が良くて何が悪いかも判断できず、「どうして、このようなAPI設計になっているのか？」とか「どうして、このようなJavadocの文章になっているのか？」と聞くと「参考にしたコードがそうなっていました」という返事がほとんどです。つまり、放置しておくと、悪いAPIは駆逐されるどころか、伝染していくことになってしまいます。 上級職人※以上のエンジニアがいない組織では、誰も良いAPI
コピペ開発の終焉 - rabbit2goのブログ
ネットを検索すればあらゆる情報が見つかる。その中にはソースコードの断片も含まれるわけで、そのコードをコピー＆ペーストしてくれば、それなりに動くソフトウェアがたちまち出来上がってしまう。規模が小さいソフトウェア開発ならそれでも通用するのだけど、規模が拡大するにつれてその問題点が露呈してくる。例えばこんなもの。 設計思想の欠如 そもそも、なぜそのような設計にしたのか説明できない。なし崩し的にコードを継ぎ足しているので、根本的なアーキテクチャやデザインパターンが存在せず、場当たり的対応の連続となり、まさに「崩れゆくアーキテクチャ」構成となる。 障害件数の増大 規模の増大に伴うクラス構成の見直しや設計の改善、継続的なリファクタリングが実施されないため、追加されたコード量に比例して複雑度も上がってしまう。その結果として、テスト時に明らかになる障害件数もコード量にそのまま比例する。 技術力の低下 ツギ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
