免罪符としての保守性：地方からの戯言：エンジニアライフ
※今回はいつもよりさらに限定されたところにのみ通じる話で、IT業界一般に通じる話ではありません。 前回、ソースコードの保守性について色々と書いてみました。最後の方で「あまり重要視したくない」と、散々書いておいてそれかよ、的な締め方をしたので、今回はその点について書き進めていきたいと思います。 前回、わたしの個人的な考え方として「保守性はそこに関わる人達の中で考えて適用する」という姿勢について書いてみました。しかし、この「関わる人たちの中で」というのがネックにもなると考えています。特に中小～零細企業に多いと思いますが、新しい技術・手法に対しては消極的なところが多いように見受けられます。そして、その時に意見として出されるものの中に、この「保守性」が挙げられるのです。 保守性を盾にする人たちというのは、新しい技術や手法の導入に対して「メンテナンスが行いにくくなる」だの「できる人が限定されてしまう
保守性が良いとはいうけれど：地方からの戯言：エンジニアライフ
システム開発に携わっている方であれば必ず耳にする「保守性」。これを話題にしようとすると「どうせ結論はまたクラスだオブジェクト指向だとかか、○○信者うぜぇ」とか言われそうなので、今回はちょっと方向を変えた話をしたいと思います。 まず、「保守性ってなんだ」と言われて答えることのできる方はどれくらいいるでしょうか。ちなみに今回のコラムを書くにあたって少し調べてみると、意外にも意識の統一が取れていないことがわかりました。あらかじめ決めておきますが、今回の話題は「ソースコードの保守性」についてです。 昔から「コメントを入れろ」とか「サブルーチン化しろ」とか、少し前からは「クラスを分けろ」というのも増えて、皆さんの勤め先でも保守性を高めるために色々と規定を持つことが多いと思います。理由としては「見通しの悪いソースは直しにくい」「他の人でも直しやすいように」など、基本としては「直しやすい」という点に集約
プログラマの慢心。IT業界の現状。
友人から以下のようなメールが送られてきて、ホントなの？と聞かれた。 1. プログラマがコードを書く。バグはないと信じている。 2. 製品テストが行われて30個のバグが発見される。 3. プログラマは20個のバグを修正し、残り10個はバグではないとテストチームに説明する。 4. 再び製品テストが行われ、バグ修正の結果5つの機能が正しく作動しなくなっていることが発見される。さらに15個の新たなバグが発見される。 5. 上記の工程3、4を数回繰り返す。 6. マーケティング部が楽観的な開発計画に基づいた製品発表を行ったことや、営業部からの圧力により、製品が時期尚早に出荷される。 7. ユーザにより100個のバグが発見される。 8. プログラマが他社に転職する。 9. 緊急で新たに開発チームが組織され、ほぼすべてのバグを修正する。 その過程で新たに500個のバグが生まれる。 10. テストチームの
プログラミングテクニックのまとめ - プログラミング日記
とりあえず思いついたもののまとめ。 まずは、ベーシックなものから。 変数のスコープをなるべく狭くしろ 他はグローバル変数を使うなとか、モジュール化と界面を意識せよなど。とにかくスコープは重要かつ意外と奥が深い。スコープに関係する機能は、モジュール(パッケージ)、クロージャ、ローカル関数、ローカルクラス、変数の種類、アクセス制御など。 同じロジックのコードを2度以上書くな 他はDRY原則、コピペをするななど。自分の場合、2度書く方がシンプルになる場合、2度書くこともある。特に、ifやswitchなどのロジックの中で同じコードが2度現れる場合、ちょっとしたコードでわざわざ別のところで関数やブロックにまとめて、それを参照するのは面倒。但し3度以上現れる場合は関数などにまとめるケースが多いかも。 汎用コード内で条件分岐コードを減らせ 他はifをポリモーフィズムによりなくせなど。条件分岐は汎用性を損
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
