5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

コーディング、テスト、デバッグ、エディタ技術総合 [無断転載禁止]©2ch.net

1 :デフォルトの名無しさん:2016/08/26(金) 10:40:24.82 ID:QNADLP5T
・特定の言語や設計、アルゴリズムではなく、
・あくまでも「実装の方法論」について議論するスレです。
・補完、スニペットなどの「コードを構築する」効率的な手法や
 テスト、デバッグ自の「操作」の省力方法や、画面構成、必要な構文を
 調べる方法、コードベースの中を「移動」する方法、コマンドライン、
 ファイル、ディレクトリ関連、必要なドキュメント、参考にするソースコードにた
 どり着くためにコンピュータやインターネットを「探索」する技術などについて議論しましょう。
・なるべく、特定のエディタやフレームワーク、ツールなどの専用のワードを多用
 せずに、他の人はそのツールを知らない前提で一般用語で議論しましょう。

2 :デフォルトの名無しさん:2016/08/26(金) 20:40:36.97 ID:X/oxOwFp
何のスレだか分かりにくいな
開発環境の使い方がメインか

3 :デフォルトの名無しさん:2016/08/26(金) 21:51:59.40 ID:QNADLP5T
>>2
いや、開発環境ありきじゃなくて、どんな工夫をすればコーディングが
しやすいかを考えていきたい。
同じ開発環境やフレームワークを使っていると、ふと「俺は何かを創ってい
のか、それとも創らされているのかわからなくなってくるときがある。
だから、例えば、「○○製の××のノコギリは便利」じゃなくて、
「どういう状況で、どういう性質の工具を選ぶべきか」
「自分だけのオリジナル工具、オリジナルの使い方があってこういう意図で
 使っている」とかを議論していきたい。

4 :デフォルトの名無しさん:2016/08/26(金) 21:53:50.14 ID:+1Se1aJm
>>1
心意気や良し

5 :デフォルトの名無しさん:2016/08/26(金) 22:14:48.43 ID:dDBcLzC2
こういう焦点がはっきりしないスレは意外と伸びるもんだよな。雑談で。

6 :デフォルトの名無しさん:2016/08/26(金) 23:01:14.73 ID:fnAyGTx3
道具の問題じゃない。

使ってる人間の問題。

7 :デフォルトの名無しさん:2016/08/27(土) 10:22:03.81 ID:wMJm9/8J
意外とIME辞書って使いようによっては強力なツールだと思ってる。
日本人ってアメリカにはない「文字変換」という優れた習慣を持っている
と思うんだが。

8 :デフォルトの名無しさん:2016/08/27(土) 16:58:24.06 ID:SmFG8gRK
      ク    ク || プ  //
      ス  ク ス  | | │ //
       / ス    | | ッ //   ク   ク  ||. プ  //
       /         //   ス ク ス _ | | │ //
         / ̄ ̄\     /  ス   ─ | | ッ //
       /  _ノ  .\     /         //
       |  ( >)(<)       ___
.        |  ⌒(__人__)     ./ ⌒  ⌒\
        |    ` Y⌒l    /  (>) (<)\
.         |    . 人__ ヽ /  ::::::⌒(__人__)⌒ \
        ヽ         }| | |        ` Y⌒ l__   |
         ヽ    ノ、| | \       人_ ヽ /
.         /^l       / /   ,─l       ヽ \

9 :デフォルトの名無しさん:2016/09/01(木) 19:52:06.60 ID:u1NNMosT
パブリックな名前空間でのネーミングに時間を費やすやつは有能。
そういう輩をdisるやつは無能。

辞書を作っておくのが効率的

10 :デフォルトの名無しさん:2016/09/01(木) 19:56:50.68 ID:4EaPp0tJ
早い段階で命名が整理されてると混乱しないな

xxx、xxx2、xxx2bみたいに
行き当たりばったりにつけていくのは無能

11 :デフォルトの名無しさん:2016/10/30(日) 22:21:39.28 ID:r3eRdHaA
オブジェクト指向は「再利用の記述」の省力化を目指しているが、
記述を省力化しすぎて「既存コードを読むストレス」を無視している
と思う。「読みながら部分的に手を加えるストレス」というべきか、
もうすでに出来上がったものをどう利用したらいいのか、
手を加えたことで、どう変わったのか恐る恐るやるよりも、
いっそ一から書いた方がずっと楽な場合もある。そっちのほうが安心できる。

12 :デフォルトの名無しさん:2016/10/30(日) 22:33:20.64 ID:Fp8V0MSu
NuGet、Excel、VS。
Excelは表からコードを作るのに使える。
RFCとかUnicodeとか表が提供されるもの結構多い。

13 :デフォルトの名無しさん:2016/10/31(月) 09:48:34.51 ID:Laym3P58
>>11
オブジェクト指向はけっして「再利用の記述」(の省力化)を目指しているわけではないように思う…というのはさておき、

「既存コードを読むストレス」を無視しているように見えるのは、きっと不完全な開発ツールを使っているからだろう
まず既存コードがどのようなネットワークを形成しているか、具体的にはコードを抽象化してメタ情報(使われている
メソッドがどこに定義されているか、読んでいるメソッドがどのメソッドからコールされているか、インスタンス変数は
どのクラスで定義されどのメソッドがそれを参照・変更しているか等々)として得ることができればかなりストレスを軽減できる
で、実際そういうツールは少なくとも80年代から普通に提供されている(例:Smalltalk環境)し、00年代にはほぼ整っている
「手を加えることでどう変わったのか」を把握する方法はすこし時代が下るけど、xUnitやバージョン管理で把握・制御可能だ

14 :デフォルトの名無しさん:2016/10/31(月) 14:49:14.87 ID:Uhsyfejv
>>13
ってことはオブジェクト指向はそもそも「サポートしてくれるツールがある事」
が大前提であり、理論より、ツールの使い方ありき、ツール覚える方が先。
ということになるな、そうするとよくありがちなParsonやCarなどをとりあえず
作って抽象的な説明から入るオブジェクト指向の講義はナンセンスということ
にならないか?
「まずこのツールをDLして、操作方法を覚えろ」の方がいいのでは?

15 :デフォルトの名無しさん:2016/10/31(月) 15:37:43.02 ID:znOSB0V/
>>14
どうしてそういう結論になるかわからん
ネットワークのたとえを引き続き用いると
まず最初に小さく単純でいいからネットワークを作ることを学ぶにあたって
どういう風にネットワークを形成していくか、それはどうあるべきかという抽象的な説明は必要ないとでも?

16 :デフォルトの名無しさん:2016/10/31(月) 17:04:52.62 ID:lW2bcIPg
ツール覚えるのに必死で創造性を発揮するどころではないな。
覚えたころには次がでてくる。W

C#を使うと便利すぎて不満など全くない。使い込んで行けば不満もでるのだろうが
不満をさがしたら自分の未熟以外のものはでてこない。このオブジェクトの海の
なかのどこかに問題をスマートに解決する方法があって、それを自分が知らない
だけという感覚に陥る。こんな意識状態ではきっと創造性などは生まれない。

17 :デフォルトの名無しさん:2016/10/31(月) 20:43:50.21 ID:V2E0sHSG
>>14
Parsonてなんぞwww

18 :デフォルトの名無しさん:2016/10/31(月) 21:18:21.78 ID:Uhsyfejv
Personのタイプミスだよ。
いやさ、オブジェクト指向やってると疲れんのよ、主 publicとか private
とか protected とか static とかプロパティの辺がさ、
「クラスの作り方、派生、変更の仕方」なんてもんあまり勉強した内容じゃなくて、
俺が習得したいのは「言語組み込みクラスのメソッドの使い方」なんだよ。
そこらの他人が書いたコードやすでにあるコードなんてどうでもいいの。

19 :デフォルトの名無しさん:2016/10/31(月) 22:52:59.24 ID:2T9pwv3J
>>18
ぱーか

20 :片山博文MZ ◆T6xkBnTXz7B0 :2016/10/31(月) 23:14:28.80 ID:taQA+O7Q
>>18
まずはそのクラスがあるヘッダーを#includeする。
次に、変数宣言を使ってそのクラスのインスタンスを作成するコードを書く。
必要ならば、そのインスタンスを使って、メソッドを呼ぶ。

21 :デフォルトの名無しさん:2016/11/01(火) 05:45:27.04 ID:myyUxu1+
確かにガチガチにオブジェクト指向で塗り固めたコードは見苦しいよ。
訪れるかどうかすらもわからない、「後々のために」を理由に
いろんな修飾子付けてゴテゴテにデブったコード書いて、
「オブジェクト指向ししてる俺は意識高い」みたいなのってなんだかな~
と思う。策士策に溺れるというか、本末転倒なんだよ。

22 :デフォルトの名無しさん:2016/11/01(火) 10:41:54.82 ID:h/aYm7ZV
ツールを使いたくない(使えない)ならオブジェクト指向やめるか、一時記憶を強化するしかない

23 :デフォルトの名無しさん:2016/11/01(火) 12:06:28.92 ID:hFVadVBb
継承したときに使いたいものだけ見えるようにする方法ってあるの?
2つしかいらんのに邪魔なのが100個も見えるという状況は気分が悪いよね

24 :デフォルトの名無しさん:2016/11/01(火) 13:28:29.79 ID:afRn0kaD
>>23
その2つだけを使いたいことをIDEが知る方法はあるの?

25 :デフォルトの名無しさん:2016/11/02(水) 12:10:38.60 ID:txovE4qH
>> 23
interface

26 :デフォルトの名無しさん:2016/11/14(月) 19:01:39.35 ID:6IAxrkLB
このスレのタイトルに適した本ってなんだろ、コードコンプリートとか、
オライリの実践でバッグ技法とかかな。
おまいらコード書く順番ってどうしてる、
関数の具体的な中身を決めないまま mainから書き始めるか、
関数の部品の中身をつくってから関数同士の組み合わせ方をあとで考えるか、
クラスありきで作り始めるか、クラスの必要性に駆られてからそれまでのコード
をクラスに書き直すか。

27 :デフォルトの名無しさん:2016/11/15(火) 04:07:44.74 ID:ChVV2XmK
まずはピンコンフィグかな

28 :デフォルトの名無しさん:2016/11/17(木) 07:46:25.96 ID:c78wZOKz
リーダブルコードは有名なのか

29 :デフォルトの名無しさん:2016/11/17(木) 18:56:03.28 ID:TXdVmO9D
で、Rubyのデバッガでいいのある?

30 :デフォルトの名無しさん:2016/11/29(火) 14:59:26.52 ID:W5pjxeIa
プログラムが何をもって「完成」になるかわからないときってない?
なにが成功でなにが不十分なのか明確な基準持っていないっていうか
そもそもあまり関心がないみたいな、テストケース書こうとしたとき
急にどうでもよくなる感じ。
問題がおきたらなおせばいいや、って。

31 :デフォルトの名無しさん:2016/11/29(火) 18:45:56.10 ID:GF2v+9TM


32 :デフォルトの名無しさん:2016/11/29(火) 20:48:54.69 ID:hd8eXtYv
初歩的なことかと思いますが
テスト要領書って、本来コーディング前に作っておくものでしょうか?

うちの会社じゃ
いつもコーディングの後半に作ってるんですが
一般的にはどうなんだろうと思いまして

33 :デフォルトの名無しさん:2016/12/10(土) 07:29:52.95 ID:Z90C8bQK
要領書は設計書書き始めたら並行して書く

34 :デフォルトの名無しさん:2016/12/10(土) 11:51:31.58 ID:5+0zsndy
デバッグテクニックって大事なのにぜんぜん共有されないよね
あってもブレークポイントとか変数ウォッチの使い方マニュアルみたいな役に立たない情報しかない

35 :デフォルトの名無しさん:2016/12/10(土) 12:32:45.44 ID:GIIm67Zu
>>34
基本的に関数の行数は数行(10行未満)長くても十数行で
それらはテストしやすいように、呼び出しやすい関数になっている。
なのでブレークポイントや変数ウォッチなんか使う意味がない。

36 :デフォルトの名無しさん:2016/12/10(土) 12:39:39.05 ID:5+0zsndy
>>35
それはまあ確かに理想的だけどレガシーコードや若手の書くコードは実際そうなってないわけじゃん
そういうダメなコードをデバッグする効率のいい方法というか原則とか考え方みたいなものを共有できたらいいと思うんだよね

37 :デフォルトの名無しさん:2016/12/10(土) 12:54:38.43 ID:GIIm67Zu
ダメなコードをデバックする効率的な方法?

ダメなコードを簡単に直すのが一番効率的な方法だよ。
その方法のことをリファクタリングという。

38 :デフォルトの名無しさん:2016/12/10(土) 12:55:26.86 ID:GIIm67Zu
× ダメなコードを簡単に直すのが一番効率的な方法だよ。
○ ダメなコード(複雑なコード)を簡単なコードに直すのが一番効率的な方法だよ。

39 :デフォルトの名無しさん:2016/12/10(土) 21:18:18.70 ID:SCCkpZrN
バッチ処理がダメだった時の修正案を実行前実行中に
考えて作っておく。
バッチ処理が失敗した時は速やかに代案を実行する。
バッチ処理が失敗した時の焦りや怒り、うろたえは馬鹿にならないから
そんな状態で代案は生まれにくいし、コーディングミス
をしてハマる可能性がある。
だから健全な精神状態で代案をいくつか用意しておく。

40 :デフォルトの名無しさん:2016/12/12(月) 06:32:25.58 ID:d/o8M1q0
最近deltadebugに興味がある

41 :デフォルトの名無しさん:2016/12/12(月) 07:51:08.90 ID:pcIBU1jC
なんだいそれ?

42 :デフォルトの名無しさん:2016/12/18(日) 11:38:27.43 ID:ZhJYWf2y
Lnuxでインテリセンスのついた開発環境をおしえてくだされ。まさか
そんなものはない?

43 :デフォルトの名無しさん:2016/12/18(日) 11:47:33.47 ID:05Ug+E6t
>>42
LinuxアプリはWindowsで開発するんだよ。

44 :デフォルトの名無しさん:2016/12/18(日) 11:57:25.73 ID:ZhJYWf2y
例えばC#アプリの例でお願いします。

45 :デフォルトの名無しさん:2016/12/18(日) 23:18:04.70 ID:aCKcGLhu
Eclipse, NetBeans, Emacs, Visual Studio Code, Atom

何でも、ソースコードを所定の場所に置けば、インテリセンスが働くだろ?

46 :デフォルトの名無しさん:2016/12/18(日) 23:40:52.78 ID:XOBRXwmr
オライリの実践デバッグ技法は良書
ただ、GDB DDD Eclipse の使い方を同時並行で解説しているから
少し混乱しやすい。

47 :デフォルトの名無しさん:2016/12/18(日) 23:44:05.58 ID:wEstYhpF
ツールの使い方じゃなくてもう少し上のレイヤのデバッグテクをテーマにした良書はないのか
ブレークポイントの説明とか何度も読まされて辟易するよ

48 :デフォルトの名無しさん:2016/12/19(月) 00:34:24.03 ID:WXYJQtbi
>>47
お望みの書籍はこれかな?
https://www.amazon.co.jp/%E9%81%93%E5%85%B7%E3%81%A8%E4%BA%BA%E9%A1%9E%E5%8F%B2-%E6%88%B8%E6%B2%A2-%E5%85%85%E5%89%87/dp/4787712101/

49 :デフォルトの名無しさん:2016/12/19(月) 06:04:58.15 ID:Jj0jZDjW
>>47
オライリーのデバッグの本(なんか蝶の書いてあるやつ)は科学的な手法とかアルゴリズムとかが中心だよ

50 :デフォルトの名無しさん:2016/12/19(月) 21:49:43.65 ID:BI+h437s
>>47
テスト駆動開発とかは?

51 :デフォルトの名無しさん:2017/04/11(火) 07:43:01.86 ID:5mMBtI5q
DAOのテストってどうしてる?
テスト自体はデータをクリアしてインサートしてDAOのメソッド呼んで戻り値を調べてAssertって感じで普通に書けるんだけど
テストがDBに依存しちゃってるからサーバーが落ちてる時とかメンテナンス中に
にテストが通らなくなって困る
JUnitだけど一時的に機能無効化するオプションとかあるのかな

52 :デフォルトの名無しさん:2017/04/11(火) 11:38:08.44 ID:Ei1BFwyD
>>51
> テストがDBに依存しちゃってるからサーバーが落ちてる時とかメンテナンス中に
> にテストが通らなくなって困る
ローカルにDB作れば?

> JUnitだけど一時的に機能無効化するオプションとかあるのかな
DAOのテストで、何を無効にするの?

53 :デフォルトの名無しさん:2017/04/11(火) 23:42:02.49 ID:5+HsoANQ
>>16
GUI周りは大いに不満です

C#のCollectionの快適さは異常

54 :デフォルトの名無しさん:2017/04/12(水) 09:06:08.45 ID:v99/uLaR
>>53
> Collectionの快適さ

具体的にはどこらへん?

55 :デフォルトの名無しさん:2017/04/12(水) 21:32:52.95 ID:jPM7CyEE
一番がAny()
isEmpty()じゃないことに感動した

大概の拡張メソッドがラムダ突っ込めるし

56 :デフォルトの名無しさん:2017/04/12(水) 21:41:41.61 ID:jPM7CyEE
冗長にも思える拡張メソッドの一群おかげでやりたいことが直感的にできる
Javaもラムダ扱えるってなって喜んだのもつかの間
C#に比べてあまりに貧弱で悲しくなった

57 :デフォルトの名無しさん:2017/04/12(水) 23:10:54.64 ID:v99/uLaR
なるほどなるほどAny()ですか

58 :デフォルトの名無しさん:2017/04/13(木) 01:22:43.82 ID:hMsy2pR8
明らかにパクリと言われないようにちょっとズラしてパクらないといけない
でもズラしてパクると使い勝手悪くなる
JavaがC#に追いつく日はもう来ないだろうね

59 :デフォルトの名無しさん:2017/04/13(木) 01:27:23.06 ID:IFJ42qsr
>>58
そんな事気にしてる言語なんてない…いや、Javaを持ってるOracleは気にするかもな。とりあえずJavaで訴訟するために

17 KB
新着レスの表示

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50
名前: E-mail (省略可) :


read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)