リファクタリング - 西尾泰和のScrapbox
「このコードは既に十分に綺麗だから、（コメントは追加してもいいけど）リファクタリングする必要はない」" 一生リファクタリングしている自分とは仲良くなってくれなさそう。
プログラミングにおける設計力を高めるには 〜 良いコードを書くために | Social Change!
プログラミングとはコードを書くことだけではありません。どういった構造にするのか、データはどう扱うのか、どのライブラリを使うのか、いくつもの設計を踏まえてコードを書くのです。設計を表現したものがソースコードです。 設計の良し悪しは品質に影響します。では、良い設計を作るスキルは一体どうやって身につけることができるのでしょうか。プログラミング言語の文法は知識なので、独学でも学ぶことができますが、設計に関してはそうはいきません。 本稿では、プログラミングにおける設計力を高めるためにはどうすれば良いのかを考察します。ここで言う設計は、画面や仕様ではなく、ソフトウェア内部の設計ですが、抽象化するとクリエイティブな仕事全般に通じるかもしれません。 本稿の内容は「良い設計」について論じたものではなく、どうすれば身につくのかを考えたものになります。また、私たちソニックガーデンで行っている、良いコードを書ける
コードの可読性、ハッカビリティ、抽象化 | POSTD
def deploy(ip): copy('code/', ip + ':~/code', recursive=True) write_template('conf/config.py', ip + ':~/config.py') write_template('conf/crontab', ip + ':~/.crontab') write_template('conf/crontab', ip + ':/etc/apache2/httpd.conf') run_as_root('service cron restart') run_as_root('service apache restart') post('https://pingdom.com/api/2.0/checks', { 'name':ip, 'host':ip, 'type':'ping' }) タスクを実行するものと
コードを削除したら喜ぶべき。知らない人がみたら意味不明なコードが残っていませんか？
昔はよくわかっていなくて、今は身にしみてよくわかっていることの一つは、追加した行数がマイナスのパッチは素晴らしいということだ。コードは削除できるなら消したいし、自分の書いたコードであれ、誰かが消してくれたらとてもよいことだと思う。 昔はがんばって書いたコードはなるべく「活用」したいと思っていた。活用というのはつまり、捨てるのはなんとなくもったいないから、そのコードをなるべく消さずにすませたいということだ。 しかし無理にコードを生かしておくことの意味など何もない。 コードの履歴などは全部いったん置いておいて、ある時点のソースコードを初めて見たものとしよう。そのソースコードが、そのプログラムが実装するべき機能を実装するために十分かつ最小限のコードであるのと、十分かつ最小限のコードに加えて何かよくわからないコードのどちらかであるとしたら、どちらのほうがいいコードだと思うだろうか？ 前者のほうがい
人のコードを引き継ぐときに一番困るのは「使われていないコード」 | mah365
プログラミングを生業としていると、人のコードを引き継いで開発するなんてこともままある訳ですが、そういうときに一番困るのは「使われていないコード」だなー、としみじみ感じます。 使われていないコードがもたらす弊害 特に動的言語で書かれたコードというのは前触れ無く呼び出される可能性があるため、本当に利用されていないのかどうなのか、きっちりと調べあげるのは困難なケースがあります。例えばrubyであれば、method_missingでキャッチしてsendで動的に処理先を振り分けるなんてことをしていると、単純にgrepして利用状況を見るだけでは不十分な場合があります。 そういう意味では「使われていないコード」というよりは、「使われているのか使われていないのかはっきり分からないコード」という方が適切な表現かも知れません。 そういった「はっきりと判断のつかないコード」がある状態だと何が問題なのかと言うと、
リファクタリング―プログラムの体質改善テクニック読んだ - 銀の人のメモ帳
リファクタリング―プログラムの体質改善テクニック (Object Technology Series) 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史出版社/メーカー: ピアソンエデュケーション発売日: 2000/05メディア: 単行本購入: 94人 クリック: 3,091回この商品を含むブログ (307件) を見る 残念ながらピアソン桐原から出版されていたので、現在は手に入りにくいんだけど、読んだ。 内容的には、リファクタリング手法のカタログみたいな感じだと思う。５章くらいまでは、導入とか、リファクタリングの心構えみたいな事が書いてある。 リファクタリングをするときに「いつすべきか？」というのが問題になると思うんだけど、この本では、機能を実装するときにその周辺をリファクタリングするといいと書いてあった。これは「動いてるものは触るな」っていう考
ナチュラルキーとサロゲートキーについての議論
とあるブログエントリで「ナチュラルキーを主キーにしてはいけない」という主張を見かけたのでこれに反論しておく。これはリレーショナルモデル的には明らかに間違った考えだからだ。 リレーショナルモデルにあるのはナチュラルキーだけリレーショナルモデルには「サロゲートキー（代理キー）」という概念はない。まずこの点に注意して頂きたい。サロゲートキーとは、データベースアプリケーション開発において実用上必要とされる機能であって、本質的には不要のものである。リレーショナルモデルでは、いわゆるナチュラルキーというものがあれば機能的には十分だからだ。 そのためにはまず「キー」という概念が何を指し示すかということについて正しく理解しなければならない。リレーショナルモデルではキーと呼ばれるものは候補キーとスーパーキーという2つの概念だけである。「タプル（≒行）の値を一意に決定することができる属性（≒カラム）の集合」の
書いたコードが一発で動作するとなぜ不安なのか : akiyan.com
書いたコードが一発で動作するとなぜ不安なのか 2013-04-21 プログラミングにおいて少なくないコードを一気に書き上げたとき、そのコードが一発で動作 or テストケースに通るとなんともいえない不安を覚えるのは、プログラマーなら誰でもあるあるネタだと思う。「本当にこれ、一発で動作しちゃっていいの？ 俺、そこまでミスしないプログラマーだっけ？」なんて自分を疑ったりする。 このあいだもそんなことがあったんだけど、ふと気になった。不安になる理由は、自信のなさからくるものだけだろうか？ ちなみに、書いたコードが正しく動作しないとき、コードを修正すると不安になることはない。一体、なぜ？ 一発で動作したブラウザの画面を見ながら、考えてみて、閃いた。「コードの修正は、書いたコードを見直す機会にもなっているから」じゃないだろうか。コードの見直しは「リファクタリング」といっていもいい。 一発で動作してしま
はてなブログ | 無料ブログを作成しよう
来年も作りたい！ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
「工業製品」としてのソフトウェア - 勘と経験と読経
ソフトウェアの品質というと国際基準や規約というものがまずあるのだけれども、そういった観点とは別に「工業製品としての品質」という考え方もあるのではないかと思っている。美しいコードは品質が高いと言われているけれども、それは「芸術品」を目指したものではないか。われわれが作っているものは「芸術品」なのか「工業製品」なのかということを考えるべきではないだろうか。 そのソフトウェアに「品質過剰」は無いか？ 知り合いのプロジェクトで「複数のシステムが使う共通検索機能」があって、スケジュールの関係もありバラバラに(共通化せず)構築してしまった話を最近聞いた。そのプロジェクトでは開発フェーズの終盤で顧客からクレームがあり、該当の機能は苦労して再度共通機能として作りなおしたそうだ。比較的よく聞くたぐいの話だけれども、いくつかの点で少しひっかかった。 内部実装がバラバラだったとしても、外見上の機能性がまったく一
40分濃縮 PHP classの教室
PHPカンファレンス関西2012で使用したスライドです。完全な内容は下北沢で開催した際のスライドと動画を御覧ください。
デバッグする人にやさしいコードの書き方というものがあります - latest log
(ε・◇・)з 分かりやすいコードは、ステップ実行もしやすいのです! (ε・◇・)з ループの先頭に、滅多に通らない大きな塊を配置するのはダメなのです! (ε・◇・)з ポチポチする毎に画面がスクロールするのは、余計なストレスなのです! (ε・﹏・)з ブラウザのデバッガ(IDE) などは、テキストエディタよりも領域が半分程度しかなかったりと、一度にみれる範囲が少ないのです for (i = 0; i < 10; ++i) { if (i === 5) { // 一度しか通らないルート : : : : : : : : : : : : : : : : : : : : : : : : : : : : } else { // 頻繁に通るルート : : // 短い処理 : } } (ε・◇・)з ループの先頭には、頻繁に通る短いコードを配置するのです (ε・◇・)з 滅多に通らない大きな塊は後ろに
コードのリファクタリングのお供に·Clone Digger MOONGIFT
Clone DiggerはPython製のオープンソース・ソフトウェア。プログラミングコードは開発が進むにつれて徐々に汚くなっていく。これは部屋が汚れるようなもので致し方ないだろう。大事なのは定期的に掃除をすることだ。プログラミングコードで言えばリファクタリングがこれにあたる。 レポート リファクタリングを適切に行えば重複するコードが減り、可読性が良くなる。同じような関数があれば統合することもできるだろう。リファクタリングを行う上でアイディアを出してくれるのがClone Diggerだ。 Clone DiggerはPythonとJavaに対応し、似通ったコードを抽出してくれる。プロジェクト全体が多数のファイルに渡っていても、Clone Diggerが全体を洗い出した上でリストアップする。結果はHTMLファイルで出力する。 重複している、または似ている箇所が分かる 改行や空白は無視されるよう
リファクタリングは設計の代わりにはならないよ - masayang's diary
InfoQ: Refactoring Not a Substitute for Design リファクタリングは設計の代わりにはならないよ 2009年2月9日 Chris Sims 「設計ってリファクタリングの一部なの？」という質問を受けた。この質問の背景には、Agileにおける設計の考え方に関する勘違いが見受けられる。よくAgileな人は「テストしろ！ コード書け！ リファクタリングしろ！ 以下繰り返し！」とマントラのように繰り返す。でも、このやり方が設計を置き換える事はない。プロジェクトにおいて一連の作業が延々と繰り返されているだけなんだ。 Phil Hがこんな質問をしてきた： 新しいやり方ってのは、まずとにかくコードを書いて初期イタレーションの目的を達成し、それから必要に応じてリファクタリングを行い、洗練していくっていうことらしい。コードは漸増的に増えていく一方、全体的な設計はしてい
リファクタリング7つ道具 - 千里霧中
リファクタリングで重要なツールについて列挙してみると、ちょうど７つ程度に収まったので、リファクタリング７つ道具としてまとめてみました。 以下に列挙します。 バージョン管理ソフト リファクタリングの作業成果をバージョン管理ソフトで細かく記録しておくと、作業の安全性を高めることができます。そこでは１つの目的を達成する度に、それに関する修正のチェンジセットをリポジトリに記録するようにすると効果的です。 そうすることで、リファクタリングでどこを修正したのか、ある修正に関連する(依存する、影響する)他の修正はあるのか、といった重要な情報を、後から細かく確認できるようになります。 一方で特定のリファクタリングを取り消せるようになる、コードのブランチを取ることができるといったメリットも実現されます。 またバージョン管理ソフトを用いる際は、コミット情報に、誰が修正したのか、何の目的でその修正を行ったのかを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://twitter.com/shibu_jp/status/1777970588667249016
if文の条件式の書き方あれこれ | GuildWorks Blog
Amazon.co.jp: 新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES): Martin Fowler (著), 児玉公信 (翻訳), 友野晶夫 (翻訳), 平澤章 (翻訳), 梅澤真史 (翻訳): 本
Mikadoメソッド - レガシーソフトウェアのリファクタリング手法
リファクタリングは設計の代わりではない
