アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
難しい・・・ (スコア:1, 興味深い)
私はそんなに経験豊かではないですが
会社の方の言い分も一理あります
私の場合、リファクタリングする場合は
1 リファクタリングの意味を顧客が理解しており、
且、その作業分の金がでる
2 リファクタリングしてもシステム全体に
影響がないことに確信がもてる
(コードを最適化してバグがでたら、まずいです)
3 リファクタリングした結果何か発生しても
す
リファクタリングに必要な環境への反論 (スコア:0)
> 且、その作業分の金がでる
いいえ。それは正しくありません。リファクタリングが内部的な開発効率を引き上げることをよく知りましょう。
ソースコードを探し回り、やっとのことで見つけた関数の名前が、以前の仕様に基づいた誤ったものだったとき、どれだけの時間が過ぎ去ったでしょうか。
その無駄が消えるのです。
関数名の変更が容易に実現出来る環境は、開発効率の向上に何の効果ももたらさないと思いますか?
>2 リファクタリングしてもシステム全体に
> 影響がないことに確信がもてる
> (コードを最適化してバグがでたら、まずいです)
はい。これは正しいです。そのための自動リファクタリングであり、
そのための単体テストがあります。
>3 リファクタリングした結果何か発生しても
> すべて自分で解決する覚悟・自身がある
はい。これは正しいです。しかし、躊躇ってはなりません。
リファクタリングは事前に深い洞察を必要とします。
安全なリファクタリングを複合した複雑なリファクタリングを行う際には、将来の問題を予測する必要があるでしょう。覚悟が必要になるでしょう。
しかし、覚悟とは何でしょうか。それはプログラミングの腕を上げるために必要な当然の決断です。
もし近い後悔を嫌って、まったく何もしないことを選ぶのなら、将来のコードの腐敗があなたをより深い後悔に導くでしょう。
そこで神に祈っても悪魔に傅いても、もう完全に手遅れなのです。
誰もがコードを呪って作業し、あらゆる変更には最低1週間が必要とされ、必要な機能も追加できず、変更のコストは高騰し、ゆっくりとプロジェクトは破綻していくのです。