30章 プログラミングツール
moch5oMaki.icon
ここではコンストラクションに関するツールのみを取り上げる。
とのこと。
プログラマは、非常に価値の高いツールが利用できることに気付かないまま、何年も作業している可能性がある。本性の使命は、利用可能なツールを調べ、便利なツールを見逃していないかどうかを判断する手助けをすることだ。
このあたりって、積極的に情報収集していますか？
ショートカットキーとかも手癖でやってて、あるとき「マジか」ってなることが割と多いmoch5oMaki.icon
30.1設計ツール
UML、アーキテクチャブロック図、ER図などを作成するのを支援するツール
設計ツールはあんまり使ったことないmoch5oMaki.icon
最近見つけたやつ
30.2 ソースコードのツール
プログラマによっては作業時間の約40%をソースコードの編集に費やしている。そうだとしたら最高ランクのIDEに投資する価値がある。
JetBrainsをトミーさんが推してくる流れだ
30.2.1 編集
時代が違うので当たり前だけど知っている機能しか紹介されてないので割愛します
IDEの他にもツールが紹介されているけど、ほとんどIDE上で機能（もしくは拡張機能）で提供されている
インターフェイス文書化ツール
エンタープライズでは割と使っている印象があるけど個人的にはちゃんと使ったことがない
相互参照ツール
変数やルーチン、及びそれらが使用されているすべての場所をWeb上で確認するツールらしい。
クラス階層生成ツール
30.2.2 コード品質の分析
静的解析でコードの品質を査定する
構文とセマンティクスを厳格にチェックするツール
測定結果を報告するツール
ルーチンの複雑さを可視化
ソフトウェアの修正回数とかもカウントするのかmoch5oMaki.icon
修正コードの発生箇所とかそれを書いたプログラマは、バージョン管理ツールで見れるけど、意図としては統計データ的に情報収集に使ってたってことだろうか
30.2.3 ソースコードのリファクタリング
リファクタリングツール
IDEでまかなえる
再構築ツール
go to文の再構築をやってくれる
コード翻訳ツール
ある言語から別の言語に翻訳する
トランスコンパイラ、トランスパイラ
これ、すごいなmoch5oMaki.icon
30.2.4 バージョン管理
割愛
30.2.5 データディクショナリ
データディクショナリは、プロジェクトの重要なデータが全て含まれたデータベースである。
多くの場合、データベーススキーマに主眼が置かれたものになる
データを管理するためのデータベース
数百〜数千ものクラスを管理する、名前の競合などを防ぐなどの目的
30.3 実行可能コードのツール
30.3.1 コードの作成
コンパイラとリンカ
これもツールになるのか
ビルドツール
ビルドツールの違いって気にしたことなかったけど、やっぱりそれなりに違いがあるのだったmoch5oMaki.icon
コードライブラリ
高品質なコードを短時間で書き上げるには、すべてを自分で書くのではなく、オープンソースのコードを探すか、または購入するのがよい。
列挙されているやつは今はオープンソースでだいたい手に入る
コード生成ウィザード
railsのscaffold的な？と思ったけどちょっと違いそう
コード生成ツールの主な欠点は、生成されるコードがほとんど判読不可能なことだ。
現代なら、GUIから操作したらサイトが作れる、Studio的なのに近い感覚？
Studioでどんなコードが生成されるか知らないけどmoch5oMaki.icon
出力できなかった…
プリプロセッサ
複数の環境でのコンパイル、開発版と製品版での差分がある場合のコンパイルなどでマクロ展開をするのが便利とのこと
30.3.2 デバッグツール 23章で詳しく解説
30.3.3 テストツール 22章で詳しく解説
30.3.4 コードチューニング
実行プロファイラ
アセンブラリストと逆アセンブラ
高級言語が生成するアセンブラコードを調べよう、と思う日がやってくるかもしれない。
😆
早そうに見える高級言語のコードがなぜ遅いのかも、アセンブラを見ればわかる。
これはちょっと比較して見てみたい気がする
筆者は実際にコードチューニングの結果が直感的でなかったのでアセンブラリストの確認をやったらしい。なのでこの後の文章も割と力入っている感があるmoch5oMaki.icon
30.4 ツール指向の環境
UNIXは小さなツールの寄せ集め
C/C++はUNIXと同じ概念
UNIXはいいぞー、ということかなmoch5oMaki.icon
30.5 独自のプログラミングツールの作成
100万回に1回の割合で1つ目のオプションを選択し、それ以外は2つ目のオプションを選択するだろう。
30.5.1 プロジェクト固有のツール
4時間45分でツールができて、その後15分で作業が終わるってわかってたらツール作るだろうけど、実業務だとツールを作ったほうがいいかどうかの判断からしないと…
30.5.2 スクリプト
バッチファイルやマクロとも
反復的な作業を自動化する
サーバー内の作業だと割とコマンド履歴からやっちゃうのでスクリプト化しなかったりするなぁmoch5oMaki.icon
30.6 ツールの理想郷
数十年前から、ツールベンダーや業界の評論家たちは、プログラミングが不要になるツールの兆しが見えてきたと断言してきた。
最初はFORTRANだった！？
現実は複雑で、優柔不断なエンドユーザーもいる。そのような現実世界の問題とそれを解決するためのコンピュータのギャップを埋める人間が必要で、その活動はプログラミングと呼ばれるだろう、とのこと。
30.7 参考資料
達人プログラマーは今読んでます
チェックリスト
30.8 まとめ
以下全て引用
プログラマは、非常に効果的なツールがあることに、何年も気付かずにいることがある。
良いツールを利用すれば、作業が大幅に楽になる。
編集、コード品質の分析、リファクタリング、バージョン管理、デバッグ、テスト、コードチューニングのためのツールは簡単に手に入る。
専用のツールが必要になった場合、その多くは作成することができる。
良いツールを利用すれば、ソフトウェア開発の単調な作業を減らすことができる。だからと言ってプログラミングの必要性はなくならないが、「プログラミング」の意味は徐々に変わっていくだろう。
moch5oMaki.icon最近知ったおすすめのツールがあればシェアしてほしい…