Q&A
HTMLしかタグがついていませんが、エラーとはHTMLのエラーのことですか？内容を読む限り、JavaScriptなどのエラーなのではと思いますが。
開発歴1年未満のプログラマーなのですがどうも開発のスピードが上がりません。エラーが発生するとその解決に時間がかかってしまいます。原因の究明に苦労してしまいます。
エラーの文を見たりその時に出来る解決法をやるようにはしていますが、どうしても他の人がやるより時間がかかってしまいます。他の人がすぐ気付くことを自分はすぐ気付けなかったりしますし。そしてわからないことを早めに聞いとこうとすると、原因が単純なもので自分の無知さを晒したり・・・。ミスしてもいいほど若くなく（３０歳前後）常駐で働いているので常駐先からの印象が悪くなってしまいがちです。
どうも理解力というか、気づきの力が弱い気がしまいます。まだ経験が浅いとはいえ、この力はひらめきとか地頭の良さが必要な気がして経験を積むごとに培われていくように思えません。自分はこの仕事に向いていないのかなと弱気にもなります。
何か気づきを早くするためにいい方法があったらご教示願います。訓練してできるものであればその訓練方法を、できないとしたらその中でどう仕事をこなしていけば良いのかなど知りたいです。もう職を変えることはできないでしょうし。
今はコピペパワーでなんとかなっている面が強いですが、長くやるとなるとそうもいかないでしょうし。
回答17件
0
エラーの原因は「気づき」でみつかるものではありません。論理的な考察と推測、そこから実証を繰り返して探り出す物です。プログラムのミスが見つからないのは、そもそもそのプログラムを理解していないからです。自分が書いたプログラムを本当に理解しているのであれば、なぜ、間違った結果になるのかを論理的に推測できます。
まずは、自分の書いたプログラムについて何をしているのかを一行一行説明できるかを自問してください。**それが最低限の前提条件です。**よくわからないけど、どこかで書いてある物をコピペしたら動いた…はプログラミングとは言いません。
次に、動作をエミュレートしてください。何がどう動いているかを説明できるのであれば、エミュレートできます。エミュレートにより、正しい結果になるには、何がどうなっているべきかがわかります。ほとんどの場合は、この時点でエラー原因が見つかります。
最後に、途中経過を見てください。デバッガでもプリント文挿入でもユニットテストでも何でもかまいません。一行一行が想定通りなのか、つまり、先ほどのエミュレートと同じになるかを見ていきます。
そうすることで、どこが間違っているのかを少しずつ狭めていけます。どこかで想定通りの動作をしていないからエラーになるからです。このように推測と実証を繰り返し、最終的な場所に辿り着きます。ときにはライブラリのバグ等もありますが、ほとんどはコーディングミスかコードの理解不足です。ただ、そこまで狭めていけば、何を修正したらいいのかは自ずとわかります。
これは科学の実験に近い物があります。また、考察は数学の問題を解く方法に近い物です。論理的に問題点を追い詰めていき、最終的に間違っているところを探り出します。できる人は簡単にできますが、できない人には一生できません。よく、文系でもプログラマーになれる！とかいう話を聞きますが、正確には、こういった論理的に思考ができる文系でもプログラマーになれるだけです。文系だろうが理系だろうが、論理的な思考ができない時点で、本物のプログラマーにはなれません。
投稿2017/03/21 22:28
総合スコア21735
コメントありがとうございます。
なんというか、気づき＝論理的な考察や推測力の賜物ということのように思えてます。
raccyさんの語調は厳しいかもしれませんが、気付きの条件は丁寧に書かれているので、「なんとなく」しか理解できずに読み飛ばすようならこの職業は辞めた方が幸せです。
あれにベストアンサーつけてますが、気付きは推理力やパズルではありません。
気付きが早いというのは、事前に把握できているということです。
先に答えがあるならパズルですが、プログラミングは最初は白紙です。
私たちは書く側ですから、まず「バグを探さなくていいように組み立てる」ことが大事なのです。
コードを書き始めた時に勝負が始まっているのであって、バグが出た時の対処力ではありません。
コピペした方が早いと思っている時点で間違っています。
それは目先の完了を求めて後に仕事を積み上げているのです。
そのようなコードはほとんどの場合、負債の積み立てでしかありません。
コードには品質があります。
これはマグレで熟練者と同じものができあがるようなものではありません。
0
コピペは内容を理解してからしましょう。
コードを書くということは「目的」を実現するために「適切な方法」を選択することです。
「目的」は１つですが、「適切な方法」は複数あります。
コードを書くときに、多くのプログラマーが行うことはネットで「目的 やり方」と検索し、出てきたコードをそのまま「適切な方法」だと思いコピペしてしまいます。おそらくプログラムは動きます。
この時、検索で見つけた方法が完全に自分の「目的」を達成する「適切な方法」だと思い込んでしまいます。
コピペしたコードにはプログラマーが「目的」を達成するために「考えた過程」がすっぽり抜けてしまっているため、「本当に適切な方法」と「ネットで見つけた方法」のずれにプログラマーは気づくことが困難になります。
またこの場合、プロジェクトはコピペの多用により「考えた過程」が抜けた状態でツギハギだらけになり、ますますエラーの原因を見つけることは困難になります。
また、コピペには「考える過程」を省略してしまうためプログラマーとして何の経験にもなりません。
投稿2017/03/21 17:14
編集2017/03/21 17:16
総合スコア18155
0
開発歴1年未満のプログラマーなのですがどうも開発のスピードが上がりません。
1年程度なんだから、そんなもんでしょう。デバッグには確かにコツはあると思うけど、なかなか教えられない。なぜなら身体感覚に近いような言語化しにくいものです。デバッグが早い人はそれなりに経験をつんでいるからできることです。
可能なら、上級者のデバッグしているところを、黙って後ろから眺めてみるというのが一番参考になるかも。デバッグが上手な人はなにか、あなたの思いもつかない方法で原因を突き止めているかもしれません。
投稿2017/03/21 15:10
退会済みユーザー
総合スコア0
回答ありがとうございます。
上級者のデバック、盗みたいですね。そういう機会どこかで得られないかな・・・。
teratail の回答を書いている時のスクリーン動画を撮ったものがありますが、デバッグの参考にはならないかも。
http://qiita.com/ShibuyaKosuke/items/cb0942112e12110faee0
教えていただきありがとうございます。例にはなりますね。
0
問題が発生したら、その問題を再現できるギリギリまでコードをどんどん削っていくということはしてますか？ その過程で原因が分かって自己解決できることが多いと思うのですが。自己解決できなくても、そのコードを見てもらう（例えばここにアップして質問する）とかできるのでは？
あとは、検索能力でしょうか。日本語のサイトだけで十分な情報を得るのは期待できないです。検索のキーワードを英語にして、英文のサイトを含めて検索できるようになるのは必須だと思います。
投稿2017/03/21 16:10
退会済みユーザー
総合スコア0
0
訓練では難しいのではないでしょうか。
それを補うとしたら、記憶（or記録）ですね。知恵が無いなら知識量で補うしかないと思います。
投稿2017/03/21 15:15
総合スコア84498
その通りだと思います。
知識量増やして対応できたらいいんですけどね。瞬発力がつくかどうかが気になります。
知識とは本で学ぶいわゆるIT知識だけじゃなくて、「以前こういう間違いをした」とか、Teratailのようなサイトを見て「こういう障害はこれが原因だったのか」という自分や他人の経験を自分の知識として蓄えると言うことです。
あと、コピペは成長の拒否です。
> Teratailのようなサイトを見て「こういう障害はこれが原因だったのか」という自分や他人の経験を自分の知識として蓄える
私はこれで随分疑似経験をためました。ちょうど、xxx_aoi さんと同じくらいの経験の時に見始めたので、タイミング的にも teratail 漬けになるのがイイかもしれないですね。半年ちょっと経ちましたが、随分変われましたよ＾＾
なるほど。テラテイル日常的に読むのは勉強になりそうですね。
0
yonaさんもおっしゃっているように、
『「こぴぺ」は 「内容を理解してから」やりましょう。』
まぁ、こぴぺでも仕事ができるかもしれませんが、
実力はつきません。
私は基本的にC/C++ですがPHP, Rerl, JavaScript 等でも同じだと思うので。
確かに組むこと自体は可能ですが、
いつまでたっても実力はつきません。
コピペすることとは、「課題等を第三者 ( クラスメート etc. ) に解いてもらったり、丸写しする行為」と同じです。
課題提出に関してはノルマは達成するかもしれませんが、
はたして実力になっているでしょうか?
それと同じことが言えます。
"気づき" ではないですが、
私は、「データ構造とアルゴリズム」をやったり、
「C言語ちゃんからの課題」みたいなものを(?)解いたり
して簡単なものなら何とか理解できるようになりました。
( 画像処理とかは無理ですが... )
C++に移行してからは、C++はオブジェクト指向を取り入れているので、
「デザインパターン」もやってみたり...
とにかく考えながら組んでみるという感じです。
そうすると、ある程度(デザインパターンでなくとも) パターンが見えてきます。
いったんプログラミングから離れて別のたとえでやって見ます。
サスペンスものを見ていると、
■ 主人公が 最初から犯人を特定し、証拠を集めて追い詰めていくパターン
■ 主人公は最初 犯人特定ができていないが、証拠を集めていると特定するパターン
がありますね。
流れも
友人や恋人,家族といった身内で馬鹿やったりしてほのぼのとしたシーン -> 温泉かどこかに旅行に来る -> 殺人事件の現場に居合わせる -> 警察が来て『また、あんたらか。』と呆れられる -> 場合によっては主人公や主人公の身内が疑われる -> 疑いを晴らす ( または警察の動きにしびれを切らして ) ために警察ではないが独自に調べる -> 証拠集め -> 犯人がボロを出す -> 主人公が崖等で犯人を追い詰める -> 自白 -> 逮捕 -> その後の展開および 主人公の日常...
という感じのパターンが見えてきますよね?
それと同じで、
ある程度やっているとパターンが見えることがあります。
そういう風にして鍛えるのだと思いますよ?
投稿2017/03/22 05:38
総合スコア4958
0
エラーが発生するとその解決に時間がかかってしまいます。原因の究明に苦労してしまいます。
確かにエラーを解決するのが目的でもありますが、見方として「人はこんな風にエラーを作るんだ」の視点でも見られてはどうでしょうか。言い換えれば「自分はこんなエラーを良くするんだ」に繋がると思います。
新入社員の起こしそうなエラーも多くの先輩SEさんはご存じですし、使っている言語により起きそうなエラー、業務特性により発生し易いエラーも有ります。
この頃スクラッチからの作成はしていませんが、コピペにしても選んだものの素性は理解して、危なそうな処を気つけながらエラーの発生が少なくなる様に修正しています。
投稿2017/03/22 01:25
総合スコア4070
0
明確にエラーになる、バグについては
ログを見る能力が、問題の解析能力を引き上げていると思います。
どのログを見て、自分の操作の箇所を特定し、必要な情報から解決方法を探す･･･なんてことをやっていたら、どんな言語でも、どんなサーバでも、習熟度自体どんどん上がっていくと思います。
ログを読めるようになれば一人前だと、教育(洗脳)されました。
エラーにならないバグ(設定値ミス)については、
仕様書、要件、を正として抜けや間違いがないことを、チェックしながらやるしかないと思います。
こちらは、コーディング後に順繰り一通りさらっと確認するだけでも、精度が確実に上がるのでお勧めです。
※テストフェーズがあるからと、これをやらない人がかなりいるのに驚いた経験があります。。。
投稿2017/03/22 05:41
総合スコア278
0
今はコピペパワーでなんとかなっている面が強いです
コピペは内容理解できているならありかと思います。もちろん少々悩んだ末の話ですよ。いきなり答えをコピペするようでは頭に残りません。私の知り合いにコピペの達人？がいますが何年たっても並み以下ですね。
プログラムを組むときはどう進めていくか、また後でわかりやすく記述するのはもちろん、バグがあったときにどうデバッグするかを想定しておくのがいいです。
結局は最初の仕様、構想があやふやだと後で手こずることになります。
以上、既に回答した方々とダブるところもありますが参考までに。
投稿2017/03/22 05:39
退会済みユーザー
総合スコア0
そうなんですけどね。なるべく理解するように努めつつコピペしてます。本当はもっとじっくり行いたいんですが、コピペの力を使わないと業務が遅れてしまうというプレッシャーもあるんですよね。そこが難しいところです。
そうなんですよね。そういう場合はなるべく理解しているつもり？で心に留めておき、次回の糧になるよう努めています。塵も積もれば、です。
0
考えるカラス [理科 小1～6・中・高]｜NHK for Schoolの
観察（かんさつ）し、仮説（かせつ）を立て、実験（じっけん）をし、考察（こうさつ）する。
という考えはプログラマ（に限らず技術者）にも有用だと思います。
たとえばエラーの修正であれば
観察 : エラーがどこでどのように起こるかを特定する。
仮説 : そのエラーがなぜ起こるのかを推理する。
実験 : 推理に従って修正する。仮説が間違っていれば（観察～）仮説からやり直し。
考察 : エラーの原因をまとめる。次に同じエラーが起きても原因がすぐに分かる。
という流れになります。番組自体も面白いのでお勧めです。
投稿2017/03/22 01:43
総合スコア38256
0
私も業務上のスケジュールのためにどこかにあったコードをコピーしてやりたいことを解決することがありますが、それだとコピペコード同士が干渉することがありました。どこが干渉してどう直したらいいかもわからず。
読解力や類推力を上げるにはやはり自分でゼロから書く経験の必要性を感じました。たとえ車輪の再発明だとしても。それをできるのは業務時間外になるかと思いますが、自分のためだと思って。
まずは一望できるシンプルな規模のコードから初めて、うまく動かないときそのミスを探す、みたいな経験を積んでいくといいかと思います。（←自分にも言い聞かせています）
投稿2017/03/22 01:08
総合スコア99
コメントありがとうございます。
今の現場は時間がコントロールされていて残業もしづらかったりするんですよね。
残業代なくていいので、開発中のコードを学ぶ時間が欲しいところです。まあしょうがないですが。なんとか勉強の時間確保するようにしないと。
解決済みですが、もう一つやれそうなことを補足します。
取り急ぎコピペで済ませた場合、いろいろな方の書式がパッチワーク状に混在してますよね？
それもバグの時の読解しづらさの原因になっています。
その書式や改行、インデントを自分の書式に揃えるのもいいと思います。
その時に一度はそのコードに目を通すことになりますし、後からも読みやすいです。
ただ、特にバグがなく問題なく動いてしまったときは、そこに時間を費やさずに次の仕事をやらねば（汗）となってしまいますよね…。そうすると今後の拡張性、流用性の役立ちません。
私は割と試行錯誤が許される職場にいるのですが、それでも職場で全部は実現できません。
実現できないことは退社後や休日など勤務時間外にコツコツやるしかありません…。お互い頑張りましょう！
なかなか家で作れないほど複雑な環境でやっているんですよね。そして残業もきっちり報告しないといけないですし、その中で納期も迫っていて余裕がないという状況・・。
書きながら思いましたが、対処法と同じくらいスピードというものが重要だと感じてます・・・。
0
エラーの原因は主に２つあると思います。
・一般的なエラー
・業務的なエラー
一般的なエラーは、例えばゼロ除算やオーバーフローなど、業務に依存しないエラーですね。
これの問題解決は経験によるものが大きいと思います。
このエラーは良くあるやつだから、あの処理が原因だろう、という推測ができると思います。
業務的なエラーは、この操作をしたらこうなるはずなのにならない、といった仕様に関係するエラーです。
これは経験よりもその業務をどこまで理解しているか、その仕様に関するコードをどこまで理解しているかです。
質問文を読む限りではこちらのエラーが大きそうに感じました。
そして原因解決までに時間がかかるのはコピペに頼ったコーディングをしていることと推測できます。
コピペが悪とは言いません。
きちんと理解した上でコピペしてください。
投稿2017/03/22 00:57
総合スコア16998
0
ベストアンサー
バグの原因を見つけることって、技術力と言うより（もちろん知識と経験という下地は必要ですが）、推理力とかパズルを解く能力に近い部分もあります。
そういう意味では、単に技術知識を高めても駄目なのかなとは思います。
投稿2017/03/21 16:31
総合スコア13703
0
初心者でも上級者でも、ミスを減らすより、ミスを修正する速度の方が大事です。
若くも無いのに初歩的なミスを指摘されるのは、恥ずかしいことですが、身になることです。
身になっていれば、同じミスをしないようにチェックするのでどんどん上達することでしょう。
個人的には、あっと言う間に上達する人が初めからミスが少ないと言うことは無いように感じています。
むしろ、経験１年未満であれば年齢がどうあれどれだけ早く上達する必要があります。
上達することを最優先に考えることが大事だと思います。
また、失敗は発覚した時間を長引かせるだけダメージが大きいです。
進捗が遅れてから、初歩的なミスを指摘されるのは避けた方が良いです。
そのことから、このエラーはこの時間をかけて調べてわからないときには助けて貰おうと決めることを提案します。
ミスが初歩的であるほど、助けを求めるのは早いほうがよく、私であれば１分で答えて貰えそうな質問は１０分程度で聞きに行きます。（この時、質問の仕方や、お礼の言い方を大事にしたい。）
私が上司であれば、きいたら終わる仕事で１０分以上無駄にしてほしくないからです。
ほかの方法として、経験をつむために業務外でもコードを書くことです。技術書のコードを写して実行しましょう。同じ内容を技術書を見ずに書いて見ましょう。
投稿2017/03/21 16:02
総合スコア2883
0
概念的なことは皆様書かれているので特に追記するつもりはないのですが、
客先に常駐されているということなので派遣かSESだということを想定して、
客先の人に聞きにくいのであれば、自社の熟練者のプログラマに一度エラー推察の手順を一緒に確認してもらうなど、してもらったほうがいいと思います。
自力で克服するのも大変よいのですが知らずにこびりついた悪い習慣など、具体的に指摘してくれる人がいれば時間の短縮になると思います。
（参考：ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習）
病気とは違いますが上記が対処療法なら手順の確認を誰かにしてもらうのは処方箋みたいなものなのでしょうか、ペアプログラミングやフォーアイズチェックなどしてくれる方がいらっしゃったらまずは相談してみるのもありかと思います。（通常ＳＥＳ派遣元は常駐先の評価を気にするので教育体制が整っているはずです）
投稿2017/03/23 03:15
総合スコア214
0
解決済みになってますけど自分の場合はということで。（参考にはならないかもしれませんが）
他の人がどうしているかわからないのですけど、私の場合、データの流れやプログラムの動きが頭のなかでイメージできないとプログラムしません、というかできない。
イメージの仕方は人それぞれだと思うのでどんな形でもいいと思いますし、言葉で理解しながら進めていく人もいるでしょう。
私はマイコンのはしりのころからやってるので、当然アセンブラで記述になるんですが、フローチャートをまず書いてからコーディングしてました。フローを書かないとコーディング出来ないと行ったほうが良いかもしれません。レジスタの使い方からメモリーの割付など全て決めてからでないと、天才でもない限り無理だと思います。
そういう下積み(?)からやってきたので、頭のなかには自然とフローというか流れがイメージできるようになったんだと思います。
最近はフローチャートを書くことは少ないかもしれませんが、まだまだ有用なツールだと思います。また、UMLなども全体像を把握したり、各クラスの関係性を明確にしたりするのに有用なツールだと思います。
ちょいプロやテスト的なプログラムでもない限りドキュメントを書くと思うのですが、いきなりコーディングではなく、どんな形でもいいのでドキュメントとして言語に変化することが大事です。
私の場合は、イメージ先行型なのでイメージを書き言葉や言語に落とし込んでいく作業がドキュメント化やコーディングの作業になります。
投稿2017/03/23 02:40
総合スコア3579
0
自分はまず違和感から見ますね。経験則からなんだろうこの処理というのがあったり、これいらないんじゃないかなというところがあったりします。そこを覚えておき、とりあえず上から一行ずつ処理を見て行きます。解説しながらでもいいでしょう。
すると、その時にもなにかおかしな所が見つかったりします。それを一つずつ修正します。
エラーがあれば一番早いです。全部とまではいかなくても「なぜ？」が書いてあります。自分の中では70％くらいエラーを見ればわかると思ってます。それでもわからないのはありますけどね。地道な作業が重要だと考えてます。
訓練方法は人に説明するのがいいのかなと思います。説明するという作業はわかってないと出来ないことです。説明する過程で説明できないなと思ったところがわかってないところなので、ここは説明できないということに気づくことができます。
投稿2017/03/23 00:35
総合スコア2050
あなたの回答
tips
プレビュー
