C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[13]: お仕着せ IDE vs エディタ+コマンドライン [1]


(過去ログ 54 を表示中)

[トピック内 43 記事 (21 - 40 表示)]  << 0 | 1 | 2 >>

■30233 / inTopicNo.21)  Re[4]: お仕着せ IDE vs エディタ+コマンドライン
  
□投稿者/ みきぬ (317回)-(2008/12/19(Fri) 12:33:20)
No30228 (.SHO さん) に返信
> でも、逆に聞きたいのですが、IDEで配置しても、結局最終的にはソースいじって
> 微調整とかはしないのですか?
>
ソースを直接いじることはないですね。
微調整であれば、画面からLocationやSizeなどのプロパティ値を操作すれば事足ります。
操作した結果がすぐ画面で確認できるのは大きいです。
# ウインドウサイズを変えた場合まで考慮すると、たぶんソースだけだと発狂しますw

引用返信 編集キー/
■30234 / inTopicNo.22)  Re[4]: お仕着せ IDE vs エディタ+コマンドライン
□投稿者/ よねKEN (242回)-(2008/12/19(Fri) 12:34:35)
IDE vs エディタって構図に違和感を感じます。
IDEも一種のエディタでしかないからです。

エディタで開発する場合は、ファイルの構成やファイル内の
記述ルールを全部自前のルールで運用できるのに対して、
IDEを利用して開発する場合、IDE利用の前提条件として、
IDEが規定するファイルの構成やファイル内の記述ルールに
厳密に従う必要があるということです。

仕事の場合、選択肢としては、
(1) チームのメンバー全員がIDEを使う
(2) メンバーごとにIDE利用者とエディタ利用者が混在する
あるいは一人の中でもIDE/エディタの両方を併用する
(3) チームのメンバー全員がエディタを使う
というのが挙げられます。

どれが良いか?という判断をするために考えないといけないことは、
最終的なチームとしての生産性が高いかに尽きます。
それを考える上で次点として個人単位でどちらの方が生産性が高いかという話になります。

個々人にとって生産性を高い方を選べばよいわけですが、
(2)のパターンを適用する場合には注意が必要で、エディタ利用者の場合も、
IDEを利用した場合と同じファイル構成/ファイル記述ルールに従う必要があります。
一つのプロジェクト内でルールを合わせることが必須になります。

で、それを踏まえてIDEとエディタのどちらが生産性が高いか?という話に
なるわけですが、前提条件次第ですよね。

例えば、仕事で.NET FrameworkでWindowsアプリを開発する場合、
フォームやコントロールを開発するのにデザイナを使わないという選択肢は
個人的にはありえません。この場合には(2)のパターンも許可したくないです。
(IDEとの連携でいらん問題に嵌るだけだから)

というわけで、私は(1)か(3)の方法を取ります。
.NET Frameworkの開発ならVisual Studio、JavaならEclipse、
Linux上での開発ならEmacsを選択したいところです。
引用返信 編集キー/
■30235 / inTopicNo.23)  Re[5]: お仕着せ IDE vs エディタ+コマンドライン
□投稿者/ たくボン (119回)-(2008/12/19(Fri) 12:35:09)
No30232 (.SHO さん) に返信
> ■No30231 (たくボン さん) に返信
>>しかし、半年もすると桁違いに生産性を上げIDEをはるかに超えます。

そこは読んでますよ:-)
例えば、なんの言語で言われています?
Java?
確かにEclipseは重いので使う気にすらならないから、Eclipseと比較するならエディタの方がマシだと思いますけど。

桁違いにエディタの方が生産性高いって言う根拠を教えてください(完成までのデバックや、仕様変更等あった場合の生産性のことも考えて)

>そして、5年ぐらいしたらIDEを捨てさせます。

俺も5年くらいSHOさんの弟子になろうかな:-)


#まぁ、俺が頭悪いのと動作が遅いだけかもしれないけど。
引用返信 編集キー/
■30236 / inTopicNo.24)  Re[5]: お仕着せ IDE vs エディタ+コマンドライン
□投稿者/ .SHO (485回)-(2008/12/19(Fri) 12:42:56)
No30233 (みきぬ さん) に返信

> ソースを直接いじることはないですね。
> 微調整であれば、画面からLocationやSizeなどのプロパティ値を操作すれば事足ります。

あっ、そうですね。
プロパティをいじれるのか。
まぁ、このレベルになるとソースをいじるのと大差ないですね。

> 操作した結果がすぐ画面で確認できるのは大きいです。

確かに。
GUIに関してはIDEの方が楽ですね。
それほど差はないと思いますが。

> # ウインドウサイズを変えた場合まで考慮すると、たぶんソースだけだと発狂しますw

そこの違いかも知れないですね。
C言語+APIの頃から、普通に発狂しないで WM_SIZE 捕えてコーディングしてますから。
C#勉強始めてDockStyleの便利なこと。。。
引用返信 編集キー/
■30237 / inTopicNo.25)  Re[5]: お仕着せ IDE vs エディタ+コマンドライン
□投稿者/ みきぬ (318回)-(2008/12/19(Fri) 12:43:42)
No30234 (よねKEN さん) に返信
> IDE vs エディタって構図に違和感を感じます。
>
これは同意。

> IDEも一種のエディタでしかないからです。
>
でもこれは違うと思う。

http://ja.wikipedia.org/wiki/%E7%B5%B1%E5%90%88%E9%96%8B%E7%99%BA%E7%92%B0%E5%A2%83
引用返信 編集キー/
■30238 / inTopicNo.26)  Re[5]: お仕着せ IDE vs エディタ+コマンドライン
□投稿者/ よねKEN (243回)-(2008/12/19(Fri) 12:47:01)
> ■No30234 (よねKEN さん) に返信

とか書いている間にいろいろ面白そうな話になっていて、
つらつら書いたことがちょっと空気読めてない感じで恥ずかしい(^^;

主張したいことまとめると、どんな前提条件での話かということを明記して

「●●●(例:C#でWindowsFormのアプリをチームで開発する場合)という前提で
××(例:IDE(Visual Studio))の○○(例:デザイナでのレイアウト)が便利!」

みたいに前提条件を付けてコメントしないと会話がすれ違いそうだなぁという話です。


No30228 (.SHO さん) に返信
> > でも、逆に聞きたいのですが、IDEで配置しても、結局最終的にはソースいじって
> 微調整とかはしないのですか?

デザイナでやる方が早い場合はデザイナでやりますし、
ソースコードを編集する方が早い場合はコードで編集します。
どちらの方法もできます。

引用返信 編集キー/
■30239 / inTopicNo.27)  Re[5]: お仕着せ IDE vs エディタ+コマンドライン
□投稿者/ .SHO (486回)-(2008/12/19(Fri) 12:51:53)
No30234 (よねKEN さん) に返信

> というわけで、私は(1)か(3)の方法を取ります。

デザイナだけIDEを使用して(3)という選択肢はないですか?
実際、うちではそうすることもあるのですが…

引用返信 編集キー/
■30240 / inTopicNo.28)  Re[6]: お仕着せ IDE vs エディタ+コマンドライン
□投稿者/ .SHO (487回)-(2008/12/19(Fri) 12:53:32)
No30238 (よねKEN さん) に返信

> デザイナでやる方が早い場合はデザイナでやりますし、
> ソースコードを編集する方が早い場合はコードで編集します。
> どちらの方法もできます。

ですよね。
同感です!
引用返信 編集キー/
■30241 / inTopicNo.29)  Re[6]: お仕着せ IDE vs エディタ+コマンドライン
□投稿者/ よねKEN (244回)-(2008/12/19(Fri) 12:55:50)
2008/12/19(Fri) 12:59:48 編集(投稿者)

No30237 (みきぬ さん) に返信
>>IDEも一種のエディタでしかないからです。
>>
> でもこれは違うと思う。

これは今回の議論の中心になるであろう部分について「極論として」言ったつもりでした。
でも、これではそうは伝わらないですね。すみません。

私の中でIDEとはVisual StudioやEclipseを指しています。
さらにその中で、開発に最も影響あるところを考えた場合、(他にもあるでしょうが、おおまかに)
(1) エディタとしての側面
(2) ビルドツールとしての側面
(3) デバッガとしての側面
(4) その他
があると思います。

vs エディタ(+コマンドライン)
という話なので、(1)、(2)くらいしか意識していません。

<補足追加>
(1)のエディタとしての側面と言っているのは、
コードの色分け、入力補助だけでなく、コードの自動生成やリファクタリングも
コードを作成するための機能全般を指して言ってます。
</補足追加>

> http://ja.wikipedia.org/wiki/%E7%B5%B1%E5%90%88%E9%96%8B%E7%99%BA%E7%92%B0%E5%A2%83

IDEの意味そのものは一応理解していますが、
最近だとバージョン管理やチーム開発もIDEの機能面として普通に考えられているわけですね。
(Visual Studioにも含まれていますが、実際はあんまり使ってない、
というか、高くてそんな上位バージョン買ってもらえないしw)

IDE派の人もIDEのすべての機能を使っているわけではないと思うので、
これまた人によってIDEの捉え方や便利だと思っているポイントは違いそうですね。

引用返信 編集キー/
■30243 / inTopicNo.30)  Re[6]: お仕着せ IDE vs エディタ+コマンドライン
□投稿者/ .SHO (488回)-(2008/12/19(Fri) 13:06:30)
No30235 (たくボン さん) に返信

> 例えば、なんの言語で言われています?

VB以外です。

> 桁違いにエディタの方が生産性高いって言う根拠を教えてください(完成までのデバックや、仕様変更等あった場合の生産性のことも考えて)

実際に定量化した数値を比べただけなので
根拠というか、どういう計測か?ってことですよね?

当初いろいろ議論はあったのですが、とりあえず単位時間当たりのライン数は意味がない
というのはすぐ決まりました。

動かすのに最低限必要なコードという意味なら、不要なコードやらコメントやらを
やたら自動生成されてしまうので、単純にライン数だけ計測したら、絶対にIDEには
勝てません。

さらに、生産性とは直接関係はしないのですが、同じ機能を実現しているなら
基本的にはライン数が少ない方が品質は高いだろうとしました。
ならFPか?というのも議論ありましたが、結局、ようはお金でしょ。
単位時間当たりに稼ぎだしたお金でいいんじゃない?まさにそれが生産性だし。
ってことで計測しました。
その中には、もちろん完成までのデバックや、仕様変更や、他人のソースをデバッグ
するなど、いろんなファクタが含まれています。

引用返信 編集キー/
■30244 / inTopicNo.31)  Re[6]: お仕着せ IDE vs エディタ+コマンドライン
□投稿者/ い (7回)-(2008/12/19(Fri) 13:52:13)
IDEとはいえ、言語によるんじゃないかな。。。
スクリプト系はリファクタリングが弱いのと、
あれこれ環境やライブラリを用意しなくても、
そこそこに動かすことができるので、エディタで十分って感じがします。

Javaとかでもコード書くだけならエディタで十分なんですが、
APIが多すぎるのでコード保管は絶対必要ですね。他にも、
・ライブラリの動的管理
・リファクタリング
・リアルタイムでの差分ビルド、
・バージョン管理
・Diff
・コードの自動生成
・デバッガ
・スレッドダンプ
・ユニットテスト、
・コーディング規約の動的チェック
・バグパターンの動的チェック、
・Javadocコメントの自動生成
・ソース整形
・カバレッジ計測
等・・・IDE(ここではEclipse)でできることはたくさんあるので、
IDE以外での開発は考えられません。

エディタ代わりにIDEを使うレベルならば、
エディタだけで5年もやってりゃ、そりゃIDEよりも生産性はよくなるでしょうね。
だってIDEとしては使っていないですもん。
IDEとして使った場合との生産性の比較を知りたいですね。

重いという意見も、いいハードを使えばいいだけだし、
お金と時間のバランスじゃないでしょうか。

引用返信 編集キー/
■30247 / inTopicNo.32)  Re[7]: お仕着せ IDE vs エディタ+コマンドライン
□投稿者/ .SHO (489回)-(2008/12/19(Fri) 14:31:05)
No30244 (い さん) に返信

APIが多いとコード保管が必要とか、いまいち意味がわからないところもあるのですが
まぁ、それはいいとして…

う〜ん・・・たぶん業種の違いなんでしょうね。

そこまでやるってことは、そもそも生産性よりも品質に重きを置いているように思えます。
プロジェクトは生産性と品質と納期のバランスで決まりますから。
もしくは、そんなバランスなんて関係ない世界なのかも知れないですね。

うちの場合で言えば、そこまでやるWindowsアプリの場合は、そういうことをやってくれる
下請けに丸投げしちゃいます。

とりあえず言えるのは、IDEで出来る機能を全て並べて便利ですってことなら
誰も反論はないと思います。そのためにMSもIDEを開発したんでしょうから。

引用返信 編集キー/
■30249 / inTopicNo.33)  Re[8]: お仕着せ IDE vs エディタ+コマンドライン
□投稿者/ みきぬ (319回)-(2008/12/19(Fri) 14:57:50)
No30247 (.SHO さん) に返信
> とりあえず言えるのは、IDEで出来る機能を全て並べて便利ですってことなら
> 誰も反論はないと思います。そのためにMSもIDEを開発したんでしょうから。
>
それでは、どういう比較をしようとしてたんですか?

# たぶん ×コード保管 → ○コード補完 だとおもふ
引用返信 編集キー/
■30250 / inTopicNo.34)  Re[9]: お仕着せ IDE vs エディタ+コマンドライン
□投稿者/ .SHO (490回)-(2008/12/19(Fri) 15:05:01)
No30249 (みきぬ さん) に返信

> それでは、どういう比較をしようとしてたんですか?

ですから、IDE vs エディタって構図が不毛なんでしょう。
私の「エディタの方が生産性が高い」という発言が発端なら撤回します。

> # たぶん ×コード保管 → ○コード補完 だとおもふ

なるほど。

引用返信 編集キー/
■30251 / inTopicNo.35)  Re[8]: お仕着せ IDE vs エディタ+コマンドライン
□投稿者/ い (8回)-(2008/12/19(Fri) 15:34:54)
No30247 (.SHO さん) に返信
> そこまでやるってことは、そもそも生産性よりも品質に重きを置いているように思えます。
> プロジェクトは生産性と品質と納期のバランスで決まりますから。
> もしくは、そんなバランスなんて関係ない世界なのかも知れないですね。

どっちかというと、生産性重視でIDEを使うというのが大きいです。
例えばリファクタリング1つにしても、GREP置換では副作用が多すぎて、
そのために生産性が悪くなります。

プログラムの品質は、書き手による部分もありますが、
ツールのサポートによって、暗黙的に一定の品質を保つことも出来ます。
つまり、意識することなく一定の品質を保ったまま、
高い生産性でプログラムを書けるわけです。
(完全に品質はツールに頼りきりという話ではありません)

生産性と品質と納期のバランスという言葉が出ましたが、
バランスもなにも、工夫次第でそれなりに両立できると思います。
というか、いまどき生産性をアップする分、品質が落ちますとか、
品質重視だから納期は遅いです。とか、
そんなこと言えるような殿様商売は通用しないのではないでしょうか。


あと、IDEのメリットとして、クロスリファレンスが挙げられます。
1ファイルが数千行は当たり前、コピペ上等みたいな世界なら問題ないと思いますが、
きちんと設計されたJavaのシステムだと、
コメントも含めて数百行以内というファイルが大量になりますので、
クロスリファレンスできないと困りますね。

引用返信 編集キー/
■30252 / inTopicNo.36)  Re[10]: お仕着せ IDE vs エディタ+コマンドライン
□投稿者/ ごんごん (4回)-(2008/12/19(Fri) 15:37:36)
No30250 (.SHO さん) に返信
> 私の「エディタの方が生産性が高い」という発言が発端なら撤回します。

そもそもこれが発端なので、撤回するということは終了(解決)ということですかね?


つーか、どっちにもメリットデメリットを"感じる部分がある"のだから
場合によって使い分けたり、拘りがあるなら各個人それに従えばいいんじゃない。

# もちろん仕事の場合は現場のルール第一ですが。

エディタ vs IDE の比較は不毛というが総意なのでは?

引用返信 編集キー/
■30253 / inTopicNo.37)  Re[11]: お仕着せ IDE vs エディタ+コマンドライン
□投稿者/ い (9回)-(2008/12/19(Fri) 15:44:52)
>エディタ vs IDE の比較は不毛というが総意なのでは?

ワープロとメモ用紙の比較をしているような気がします。
引用返信 編集キー/
■30254 / inTopicNo.38)  Re[9]: お仕着せ IDE vs エディタ+コマンドライン
□投稿者/ .SHO (491回)-(2008/12/19(Fri) 15:46:01)
No30251 (い さん) に返信

> というか、いまどき生産性をアップする分、品質が落ちますとか、

MSのようにマーケット重視でバグはSPで対応とか

> 品質重視だから納期は遅いです。とか、

人命にかかわるようなシステムではこれもあります。
プロジェクト次第でcase by caseなんです。

> そんなこと言えるような殿様商売は通用しないのではないでしょうか。

ですから、そういう世界にいるのでしょう。

ここに持ちだすようなテーマじゃなかったです。
ごめんなさい。
引用返信 編集キー/
■30256 / inTopicNo.39)  Re[12]: お仕着せ IDE vs エディタ+コマンドライン
□投稿者/ みきぬ (320回)-(2008/12/19(Fri) 15:54:47)
No30253 (い さん) に返信
> >エディタ vs IDE の比較は不毛というが総意なのでは?
>
> ワープロとメモ用紙の比較をしているような気がします。

なるほど、ワープロばかり使っていると漢字がわからなくなるというわけですな。奥が深い。
引用返信 編集キー/
■30257 / inTopicNo.40)  Re[8]: お仕着せ IDE vs エディタ+コマンドライン
 
□投稿者/ 凪瀬 (89回)-(2008/12/19(Fri) 16:05:58)
エディタに戻れない理由

1.自動補完
 標準API+フレームワークのAPIで万単位のクラスが存在するので、暗記は無理。クラスに存在するメソッド名、フィールド名までの暗記はもっと無理。
 よく使う範囲なら暗記しているけどtypoとかするので、typo -> コンパイルエラー -> 探して修正 の手間より、自動保管が断然効率的。
 よくあるコード定型はCtrl+スペースで記載できる。mainと書いてCtrl+スペースでpublic static void main(String[] args)が一発で書けるし、System.out.println();だってsysoと書いてCtrl+スペースで書ける。長ったらしくて面倒とかいうのは補完がない環境の人の愚痴に過ぎない。

2.構文解析を伴うシンタックスハイライト
 予約語のハイライトぐらいなら秀丸ぐらいのエディタでも可能だけども、Java言語の構文を解析した上でのハイライトはエディタでは無理。例えば、ある文字列が、ローカル変数である、インスタンスフィールドである、staticフィールドであるといった区別をした上で、見分けがつくようなハイライトを行ったりすることはエディタではできない。

3.宣言への移動など
 メソッド名を選択してその宣言部分にジャンプしたり、メソッドにカーソルを合わせるだけでメソッドのjavadocを表示したり、クラスのソースにジャンプしたり(jarファイルで参照しているライブラリでもソースがアタッチされていればジャンプ可能)、型階層をツリーで表示したり、あるクラスやメソッドを参照している場所を検索したりする機能がある。このあたりはエディタでもプラグインである程度サポートしているものがある。
 Eclipseでは標準でTODOやFIXMEなどのコメントを一覧管理する機能が付いているし、ソースコード中にブックマークをする機能もついているので、コードを読んで分析するときにも非常に重宝する。

4.コードのフォーマットチェック
 コーディング規約を定めているプロジェクトは多いが、細かいコードのフォーマットなんか人力でチェックなんて労力的に無理で、フォーマットや命名が統一されたコードなんて作りえない。機械によるコードフォーマットチェックならばコーディング規約を実施させることが可能になる。
 また、単純にフォーマットをそろえるだけなら手作業でなくとも機械で一律のフォーマットに変換することができる。

5.危険なプログラミング手法の禁止
 String型をequals()で比較せよ(Javaの場合。C#とは事情が違う)とか例外をcatchして握りつぶすといった潜在的に危険なコードは機械がチェックして警告してくれるため、コードの品質を底上げできる。目視によるソースレビューでは漏らしてしまうものを確実に網羅することができる。
 またFindbugsのようなプラグインを利用することでより高度なバグパターン検出が可能となる。

6.バージョン管理ツールとの連携
 CSVやSubversionなどとの連携機能を持っているので、エディタ上で履歴も見れればdiffもとれる。
またtracやRedmineといったプロジェクト管理ツールと連携してチケットの編集や、そのチケットの作業に伴って変更されたソースの管理などが行える。

7.ブレークポイントによるデバッグ
 いわずもがな。
 プログラムをステップ実行したり、その時点での変数のあたりを参照したり、プロファイラによる解析をしたりできる。

8.自動テストツールのサポート
 JUnitによる自動テストの標準サポート。プラグインなどを用いればテストのカバレッジ計測もできる。

9.リファクタリング機能
 メソッド名などのリネームに伴い利用箇所を網羅して一括変換するような機能性や、長いメソッドから範囲指定してメソッドを抽出する機能、メソッドの引数などの変更機能(利用箇所も網羅して変換)、親クラスへのメソッドの移動、子クラスへにメソッドを展開するなどといったリファクタリングをサポートする各種機能が用意されている。

10.コンパイルエラーに対して解決策を提示
 コンパイルエラーがあった行の警告マークをクリックすると、コンパイルエラーを解決するための解決策を提示してくれる。
 メソッドなどのシンボルがない場合はそのメソッドを作るという選択肢があり、クリックすればメソッドのひな型が作成される。オーバーライドしていない抽象メソッドがあれば、そのメソッドのひな型を書いてくれる。catchしていないチェック例外があればtry-catch文を補完してくれるなどなど。

Eclipseはこうした開発能率をあげ、ストレスなくプログラムを書ける環境を提供してくれるし、そして、この幸せな開発環境を構築するのにただEclipseのサイトからzipをダウンロードしてきて解凍するだけでよいというのが何よりも魅力。

開発環境を作る過程だけで挫折してプログラミングをあきらめるような入門者もいるなか、IDEはとりあえずプログラミングして動かすという喜びまで容易にたどり着かせてくれる。
引用返信 編集キー/

<前の20件 | 次の20件>
トピック内ページ移動 / << 0 | 1 | 2 >>

管理者用

- Child Tree -