ソフトウェア開発について質問です。

開発スピードが速くてコードが汚いプログラマと、開発スピードは遅いけどコードがきれいなプログラマは、どちらが優秀でしょうか?
ここで「コードがきれい」というのは、「重複が少ない、変数名や関数・メソッド名がわかりやすい、複数の役割を詰め込んだ巨大なクラスやメソッドがない」などを意味します。

回答の条件
  • 1人3回まで
  • 13歳以上
  • 登録:2011/06/04 17:34:20
  • 終了:2011/06/11 02:56:47

ベストアンサー

id:windofjuly No.3

うぃんど回答回数2625ベストアンサー獲得回数11492011/06/04 18:24:27

ポイント22pt

状況によりけりです

 

多少の時間をかけてでもコードを綺麗にしていったほうが、将来的に必要とされる時間(増改築やトラブル対応など)の軽減に繋がりますので長い目で見れば優秀ですが、単独で完結する短いコードや他への転用もあまり出来ないようなシステム、場当たり的に作らなければならなくなった場合などに即応できる人材もこれまた優秀です

 

「結局のところ、どちらが優秀なのでしょうか?」と問われれば「クライアントや上司の求めに応じて、どちらもできる人が優秀」

「では、どちらを目指せば良いでしょうか?」と問われれば「新卒で会社に入ったばかりであれば前者をまずは目指しましょう。中途採用であるなら両方の資質が求められるでしょう」

id:DQNEO

* 長く使うシステムなら、きれいな方がよい

* 急ぎで転用がない場合は速い方がよい

* 要求に応じてどちらのスタイルでもできる人が優秀

私の経験上、両方できる人は稀ですね。

生まれ持った性格によるところが大きいと思います。

2011/06/05 04:32:24

その他の回答(8件)

id:deflation No.1

deflation回答回数1036ベストアンサー獲得回数1262011/06/04 17:41:26

ポイント24pt

プロジェクト計画が立てられているならば、プログラマの優劣という判断は働かず、プログラムの品質を確保する観点から、「開発標準」に即したコードをかけるプログラマが求められます。


経験から言えば、「開発スピードが速くてコードが汚いプログラマ」は開発標準を無視する傾向があるので、「開発スピードは遅いけどコードがきれいなプログラマ」を募る結果になります。ただし、自己流で「コードがきれいなプログラマ」は必要ありません。

id:DQNEO

「コードが汚い=プログラムの品質が悪い」という考えですね。

ここでいう品質は、「メンテナンス性」のことを指していると解釈しました。

「コードが汚い=メンテナンス性が悪い」ということなら、納得できます。

2011/06/05 04:41:02
id:code_tk No.2

code_tk回答回数77ベストアンサー獲得回数112011/06/04 18:08:27

ポイント22pt

チームで働いているなら遅くてもきれいなコードのが引継ぎや修正が楽でいいですね

ただ程度の問題で数千行で完結するプログラムを数週間かけてきれいに作成されても結構迷惑かもですね。Aさんに頼んだら1日でBさんに頼んだら一ヶ月とか

正直この規模だと引継ぎで修正するにしても再作成したほうが早いとかコード読んでもあっという間に終わるので

id:DQNEO

* チームでやるなら、遅くてもきれいな方がよい

* 程度の問題

工数が1日vs1ヵ月ぐらい差があると話が変わってきますね。

2011/06/04 18:55:49
id:windofjuly No.3

うぃんど回答回数2625ベストアンサー獲得回数11492011/06/04 18:24:27ここでベストアンサー

ポイント22pt

状況によりけりです

 

多少の時間をかけてでもコードを綺麗にしていったほうが、将来的に必要とされる時間(増改築やトラブル対応など)の軽減に繋がりますので長い目で見れば優秀ですが、単独で完結する短いコードや他への転用もあまり出来ないようなシステム、場当たり的に作らなければならなくなった場合などに即応できる人材もこれまた優秀です

 

「結局のところ、どちらが優秀なのでしょうか?」と問われれば「クライアントや上司の求めに応じて、どちらもできる人が優秀」

「では、どちらを目指せば良いでしょうか?」と問われれば「新卒で会社に入ったばかりであれば前者をまずは目指しましょう。中途採用であるなら両方の資質が求められるでしょう」

id:DQNEO

* 長く使うシステムなら、きれいな方がよい

* 急ぎで転用がない場合は速い方がよい

* 要求に応じてどちらのスタイルでもできる人が優秀

私の経験上、両方できる人は稀ですね。

生まれ持った性格によるところが大きいと思います。

2011/06/05 04:32:24
id:a-kuma3 No.4

a-kuma3回答回数4439ベストアンサー獲得回数18232011/06/04 19:40:20

ポイント22pt

先の回答の繰り返しになっちゃいますが、「開発スピードが速くてコードが汚いプログラマ」で、品質が高いプログラムは見たことがありません。

その場限りで動いてくれれば良い使い捨てのプログラムであれば、そういう人を使う可能性もあるかもしれません。


結局、コードがきれいかどうか、というのは、設計ができているかどうか、という結果でしか無くて、

  • 開発スピードが速いが、設計がきちんとできないプログラマ
  • 開発スピードは遅いが、きちんと設計するプログラマ

の、どちらが優秀か、と考えれば、答えは自明かと。


ちなみに、コーディング規約をきっちり守るが、設計できないプログラマ、というのも存在するので、

見た目が整然としているかどうかだけで、「コードがきれい」とは言えないでしょうね。

id:DQNEO

ソーシャルアプリみたいな開発スピードが勝負の世界では、速くて汚いプログラマが活躍する余地はあるかもしれませんね。

設計がきれいでも、競争に負けたら終わりでしょうから。

「コーディング規約遵守」と「設計ができる」は別次元というのには同意です。

コーディング規約は守るのが当たり前なので(機械的チェックもできる)、守らないケースは質問時に想定していませんでした。

2011/06/05 04:22:07
id:taknt No.5

きゃづみぃ回答回数13537ベストアンサー獲得回数11982011/06/04 20:18:47

ポイント22pt

仕事の面からすると たとえば 一ヵ月に 早く終わらせて 2つ するプログラマと

1つしかできない プログラマがいたら 上司は その早いほうが 優秀だと判断するでしょう。

つまり お金を稼ぐのが 優秀と言えるのです。

しかし 今後、そのカスタマイズが 入った場合、どれだけ時間がかかるのかで

そのソースコードに対しての優劣がつくことでしょう。

つまり、優劣は その時点ではなく その後に決まるのかと思います。

ま、現状では 開発スピードが速い技術者が 求められている傾向が高いかとは思いますが。

でも、質問の答えとしては ソースコードのできがよいほうが 優秀といえるかなと思います。

id:DQNEO

「優劣は その時点ではなく その後に決まるのかと思います。」

確かにおっしゃる通りですね。

激しく同意します。

ところで、開発完了時にソースコードの良しあしでプログラマを評価する職場というのは実在するのでしょうか?

現実では、実装スピードで評価されるケースが大半だと思います。

2011/06/05 04:26:48
id:j4mika No.6

j4mika回答回数156ベストアンサー獲得回数222011/06/04 20:33:04

ポイント22pt

小規模委託が多い立場からですが、コーディング規約などに縛られず素早く書いて欲しいですので、消費者側から見ると、速い方の方が優秀に見えます。

もっと言えば、資源を無駄使いするような効率の悪いプログラムであったとしても、兎に角、動いてくれる事が必要なこともありますが、それを理解して貰えないことも多々あります。

id:DQNEO

* 発注者側から見ると、開発スピードが速い方がよい。

作って終わりならそうですね。

ただ設計が汚いと、完成した後に

発注者:「ここが不便だから、ちょっと直して」

受託者:「うーん、それをやるには2か月かかります」

発注者:「なんで?」

てなことになりがちです。

ちなみに資源とか実行効率については私の質問の範疇外です。

2011/06/05 04:31:14
id:monyot No.7

monyo回答回数146ベストアンサー獲得回数182011/06/05 10:19:47

ポイント22pt

日本的な一般論でいえば、「開発スピードは遅いけどコードがきれいなプログラマ」が優秀という総意になるのではないかと思いますので、敢えて逆を考えてみたいと思います。


いわゆる研究的な領域で、新しい概念をプログラム化して検証する、といった場合、コーディング規約に則ってしか書けないようなプログラマでは役に立ちません。また小さい会社で自分で書いて自分でメンテするのが大前提であれば、開発スピードが速いほうがもてはやされると思います。


また、今回はバグの数という直接的な品質はどちらも一緒ということですので、その前提に立てば、単体テストはきれいにクリアしてくれて、フレームワークの規約も守り、外部モジュールとのインタフェースもきちんと設計書どおりに作ってくれる前提であれば、内部のコードが汚くても問題とされないかもしれません(アメリカの開発スタイルは、これに近いですよね)。


どちらがより「優秀」かは、求められる外部要件によっても変わってくるので、一概にはいえないと思いますが、社会人プログラマとしての優秀さではなく、プログラマ個人としての優秀さで言えば、前者の方が優秀な場合が多いような気がします。

id:DQNEO

・研究領域・小さな会社では速い方がよい。

・インターフェースが設計どおりなら内部は汚くてもよい

なるほど。

2011/06/06 00:48:51
id:isogava No.8

isogava回答回数50ベストアンサー獲得回数12011/06/05 18:14:36

ポイント22pt

コードは後で整形・修正すれば済むものでもあるので、エラーがなく処理速度も仕様内であれば、汚くても早いプログラマの方が優秀でしょう。

綺麗にするのは後から誰にでもできることですから。

もしもコードの文字数で作業量と金額を算定するのであれば、遅くて綺麗なコードを書くプログラマの方が手取りが多くなるでしょう。

必要に応じて、いや、必要以上にコメントも書いておけばお金になります。

どの世界でもそうですが、結果を早く出してしまうと儲かりませんから(笑)

id:DQNEO

・コードは後で整形・修正すれば済む

なるほど、一理ありますね。

ただ、リファクタリングは誰にでもできるものではないと思います。

いったんリリースしたものを後で直すのは、現場によっては難しいと思います。

それによるバグ混入のリスクがありますし、リファクタしても売上増えないということもあります。

2011/06/06 00:57:54
id:hanako393 No.9

hanako393回答回数1142ベストアンサー獲得回数872011/06/05 22:39:44

ポイント22pt

プログラマーの間では、

>ここで「コードがきれい」というのは、「重複が少ない、変数名や関数・

>メソッド名がわかりやすい、複数の役割を詰め込んだ巨大なクラスやメソッド

>がない」

コードがきれいなほうが優秀だと評価されるでしょう。

ただ会社やプロジェクトで優秀と評価されるかどうかは別問題で

コードがきれいでない人のほうが評価されることも多々ありますし、優秀だと言われてる場合も多いです。

コードがきれいなことにこだわる人は、プロジェクトの進行の邪魔になったり、ビジネスとしてみた場合に利益を生み出さない存在だったりするため、優秀だと言ってもらえないことも多いです。

質問に挙がってることはプログラマーとしてできて普通です。

できないプログラマーよりは優秀なのは事実ですが、小学校時代にテストで満点を取ったことがあるというぐらいの値打ちしかないでしょう。

id:DQNEO

* 「プログラマーの間ではコードがきれいなほうが優秀だと評価される」

それはありそうですね。

私もコードがきれいな人を尊敬してしまいがちです。

* 「会社やプロジェクトでは速い人の方が評価される」

これも真実ですね。

「コードがきれいなことにこだわる人は、プロジェクトの進行の邪魔になったり、ビジネスとしてみた場合に利益を生み出さない存在だったりするため、優秀だと言ってもらえない」

はい。耳が痛いです・・。

2011/06/06 01:02:23
  • id:h311m9
    僕でしたら、開発スピードは遅くてもコードがきれいなプログラマのほうが優秀だと僕は思います。コードが汚いとなんか動作が変になったり、動作がしなくなったりするんなら、開発スピードは遅くてもコードがきれいなコードのほうがいいと思います。
    ↑参考程度に!!(僕はそう思ったんだけでこれは人それぞれだと思います)
  • id:taknt
    >コードが汚いとなんか動作が変になったり、動作がしなくなったりするんなら、

    それは 問題外です。

    コードが汚くても 不具合なく動作するのが前提ですよね。


  • id:DQNEO
    > コードが汚くても 不具合なく動作するのが前提ですよね。

    その通りです。
    コードが汚いからといって、
    不具合が多いとか実行速度が遅いとかは一言も言っていません。

    ただ設計がきれいか汚いかの違いを問うています。
  • id:DQNEO
    誤解が多いので補足します。

    前提条件として、「速くて汚いプログラマ」と「遅くてきれいなプログラマ」でバグや実行速度、コンピュータ資源消費の差はないものとします。

    品質=バグの数と定義するならば、品質の差はないということになります。

  • id:deflation
    >ここでいう品質は、「メンテナンス性」のことを指していると解釈しました。
    >「コードが汚い=メンテナンス性が悪い」ということなら、納得できます。

    はい、その通りです。
    開発標準に則ってコードを書いてもらわないといけません。メンテナンスやバージョンアップの際、担当プログラマが関わるとはかぎりませんから。

    また、開発標準に則り、単位時間あたりに書けるコードの量が多い方が生産性が高いわけですが、生産性と技術の優劣はは別問題です。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません