Q&A
初めて聞きましたが効果ありそうですね。
*いわゆるアンケート系です。不快に思われる方はスルーして下さい。
*頂いた回答は、現在の私ではベストの判断ができないものが含まれる可能性が高いと思います。恐縮ですが、多分ベストアンサーはつけません。ご了承下さい。
プログラミングをしていて気がついたのですが、技術以外に考え方や心がけにより、大きくプログラミングの効率が上がったことがありました。
私の例で言うと、
・自身の間違いを最初に疑う
プログラミングを始めたころ、サンプルコードを学習元として使用していたのですが、エラーが出てもまずサンプルコード自体を疑い、自身の行った行動（DBの作成や、ちょっとしたカスタム、構築環境の違い）を疑う事を後回しにしていました。
が、ある時から、自身の行った行動こそ間違いを内包することを前提に切り分けを行うようにしたところ、開発効率がかなり上がりました。
プログラミングを長くされている方であれば、多分同じような「技術以外のポイント」による効率向上を感じたケースがあるのではないかと思い質問を立てました。
今レベルの私に参考にならないケースも多々あることを期待しています。
将来の私のために、経験された精神的ブレークスルーポイントをご紹介いただけないでしょうか？
よろしくお願いします。
追記
問題/課題が含まれていないとのご指摘を多く受けましたので、追記します。
現在、余り効率の良い開発ができておらず、その改善を模索しておりますが、改善には、技術学習以外にも精神的なトリガーがあることに気が付きました。
しかし、独学/一人作業を行っている背景があり、先輩からの学びや、職場環境による気付きが得にくい状況であるため、今回の質問をしております。
恵まれた環境にいる方から見ると、切実に感じられないかもしれませんが、結構真剣な質問です。
ご指摘くださった方の中にも、開発効率を上げるポイントとなった心がけがある方がいらっしゃるのではないかと思います。ぜひご紹介下さい。
回答20件
0
「ねる」
ですかね・・・。いやまじめに。
1日かかっても解決しなかった問題が、一晩たって夜が明けると
なぜかアッサリ解決したり。よくあります。
投稿2016/08/23 07:55
総合スコア866
0
投稿2016/08/23 05:26
総合スコア759
これはちょっと寒気がするほど興味深いですね。
やったことないですが、客観視をテクニカルに解決する方法と言った感じですよね。
試してみたいです。試せるかなぁ。。。ｗ
最近はくまなんですね。
自分はあひる派でした。
>kopioさん
単純に「ペアプログラミング」とかけているダジャレだと思いますよ
「teratailに質問する」というのも、似たような事ですね。
それは、「答えが返ってくるから」ではなく、質問を丁寧にまとめて投稿した後に、自己解決できたなんて事は、よくある事だと思います。
もちろん、質問する姿勢にもよりますが。
何に困っているかを整理しているうちに、問題点が整理されて、頭の中も整理されて、解決策も見えてくるのだと思います。
> te2jiさん
そんな感じで、試してみてはいかがでしょうか？
"
独学/一人作業を行っている背景があり、先輩からの学びや、職場環境による気付きが得にくい状況であるため
"
私も、似た境遇ですので、よく解ります。
te2jiさんは、teratailでも勢力的に回答されているようですので、そういった活動も効果があると思います。
回答するからには、下手な回答できないでしょうから、検証したり、もしかしたらそこで知らない事も、知る機会になるかもしれないですしね。
回答にも玉石混交あると思いますが。
ただポイントが欲しくて、回答してる訳ではないと思いますので、せっかく貴重な時間をかけて、回答するわけですから、そういった姿勢で臨む事を意識してみてはいかがでしょうか？
まぁ、難しく考えずterateilで、どしどし質問して、じゃんじゃん回答してみてはいかがでしょうか？
> 運営さん
なんか、バッジください。
0
こんにちは。
・自身の間違いを最初に疑う
これ、本当にそうですね。まず自分を疑うと実に効率が良いです。自分で作っている部分なので中身を全て分かっているし、自分の担当なので自分で修正しても誰からも文句言われません。更にほとんどの場合、自分が原因を作ってますし。
他には、どう考えても可笑しな現象が起きた時、「原因が必ずどこかに存在するので、それをどうやれば突き止められるのか」を考えるようにしたことでも効率が上がりました。
例えば、「昨日までは問題が発生せず、今日問題が発生した。今日変更したのは問題が発生した部分とは全く異なるところなのに」みたいなケースですね。
ありがちなのは、廻り廻って意外なところに影響しているケースですが、外部のサーバがダウンしていたとか、ノイズで誤動作していたとか思わぬことが原因だったこともあります。
ノイズが原因の時は再現性が乏しかったので頭痛かったです。
それ以来、問題を再現させることを最重視してます。再現できれば不具合は大抵解決できます。
しかし、どうしても再現出来ない時は、時に身を任せることもしばしばです。
投稿2016/08/23 07:58
総合スコア23272
「問題を再現させることを最重視」
余り意識していなかったですが、無意識に模索していたと思います。意識することで新たなステージに登れる気もするので、今後気をつけてみます。
> 廻り廻って意外なところに影響しているケース
プログラミングでは未経験ですが、前職でよく経験していました。
全方位的に確認しなければならないので、巻き込まれる方も面倒なんですよね。。。
ちなみにですが、このコメントには異論があります！
> 自分で作っている部分なので中身を全て分かっているし
全然わかってないですｗ少し違うレベルで共感いただいているようです。
早くこのコメントを言ってみたい＾＾；
問題の再現は重要ですよね。再現できてその条件がわかったら半分判ったようなものですからね。
問題は、再現できない時ですね。条件が足りないか、条件が多数複合した問題になっているか、それを見つけるのが大変。1～2ヶ月に一度しか起きない現象とかなると何かテストコードを埋め込んで探るしか無いですが、ユーザーにも迷惑をかける事になるので身も細る思いになります。
再現できないケース、かなりしんどいですね。。。
これはよく経験します。現象がユーザからの申告のみで、環境を聞くのすら厳しい状況の時とか、本当にしんどい＾＾；
0
プログラミング能力がついてきて自信が出て来ると、「自分は正しくて、間違ってるのは他のことだ」と思うようになります。いわゆる自惚れですね（笑）。
そのうち、間違いが自分の部分にあり大恥をかくことになります（汗）。
で、悟るんです。「ああ、謙虚にならなければ」と。
そのうち、「プログラムは思う様には動かない。書いた通りに動く。」と気づくんです。
その他としては、「動きがイメージ出来ないものはプログラムできない」でしょうか。
他の人はどうか知らないですが、私の場合、プログラムの動きをイメージで捉えて考えます。データがルーチンの中を流れていく感じです。（ちょっと言葉では説明しづらいですが）
プログラム全体の構成もイメージで捉えています。そのイメージが何となく出来て、データが流れていかないと、コードに落としこむことができません。イメージがある程度出来てからとっかかることにしています。当然、仕様書などドキュメントを作成してからになりますけど。
投稿2016/08/23 08:09
総合スコア3579
> 私の場合、プログラムの動きをイメージで捉えて考えます。データがルーチンの中を流れていく感じです。
こういったコメントが嬉しいですね。今の私では全然理解できません。
「あの時もらったコメントはこれのことか！」
的な感動を早く感じたいです。ありがとうございます。
私の場合は気づくとそういう風に考えるようになっていました。
プログラムを始めたのはインターネットもなく、パソコン通信が始まった頃でしたから、情報といえば専門書や雑誌です。そこに載っている人のプログラムを読みまくっていましたね。
当時はアセンブラですから、フローチャートを書いてからプログラムをします。最近はフローチャートを書くことは無いですが、アセンブラの場合は途中であっちこっちにジャンプをしますから、フローチャートで流れを追わないとどのような処理になっているのかわかりません。おそらく、このフローチャートをとことん書いたことが今のイメージ化につながってるのかもしれません。
今はフローチャートは書きませんが、ブロック図はよく書きます。各ブロックの間をデータが行き来するわけですから、ブロック図やUML図またはマインドマップ的なものを使ってプログラムをイメージしてみてはどうでしょうか？
ブロック図やUML図またはマインドマップ、いずれも今は使用していないので、使用してみます。
0
設計書をちゃんと書く事。
UMLのオブジェクト図、クラス図、シーケンス図(苦手な方はアクティビティ図)程度でいいですが、とにかくその仮設計をそのままコードにするという気持ちで設計書を書く事。
ダレに見せるモノでもなくて、ただ自身の頭の中を整理する為に行う。
どうしても時間がない場合は、ユースケース記述をしっかり書く。
どうせ自分の頭の中にあるんだからととりあえず書き始めるのではなく、やってみると当初の自分が如何にヌケてたかがよくわかる。
デバッグと言うよりは、最初からバグを出さない為の手法ですが。
全体工数の50%くらいまでの間は「すぐに着手」した方が進捗いいですが、その後の進捗がシーケンシャルに進むかどうか、そして完成したコードの美しさは全く違うと思います。
投稿2016/08/23 08:03
総合スコア5405
> 設計書をちゃんと書く事。
やってないですね＾＾；
> 全体工数の50%くらいまでの間は「すぐに着手」した方が進捗いいですが、その後の進捗がシーケンシャルに進むかどうか、そして完成したコードの美しさは全く違うと思います。
やってないから、この辺の感覚が理解できません。
この回答も嬉しい回答ですね。
将来の私が、この感覚に気がつくのが楽しみです。
0
初めての言語に触れる時は、何より「デバッグ方法」を知ることを始めにやるようにしています。
得意なのはPHPですが、var_dump() を知らないでPHPのプログラミングなんてできませんし、Java で System.out.println() を知らずに開発はできません。
また、便利なツールを使いこなすことも重要かなと。FireBug を知ってからは、JavaScript のデバッグが驚くほど早くなった経験があります。
はまった時は、何かしら、自分の考えに 思い込み や 決め付け がないか、直感 に基づいて解決できる場合もありますが、はまった時は、直感 を裏付けるために適切にデバッグすること、これに尽きるのではないかと思います。
投稿2016/08/23 05:35
編集2016/08/23 05:38退会済みユーザー
総合スコア0
新しい言語/技術に対しての「デバッグ方法」の確認ですね。
確かに、nginx を設定している時にも、デバッグ方法を確認せず試行錯誤してハマりましたｗ
まず最初に確認するというのは、効率的ですね！
便利ツールの気付きはどのように行われましたか？ツールまとめ系のサイトでしょうか？
検索ワードで特徴的なものがあれば教えて下さい。
リンク先のできることを積み重ねるというのも、一つのきっかけになりそうですね。
ありがとうございます！
> 便利ツールの気付き
まずは「言語名 デバッグ方法」でGoogle検索ですね。
ありがとうございます。
そういえば、「PHP デバッグ方法」で検索したことがないことに気が付きました。
さっそくやってみます。
検索した結果、新しい気づきがありましたｗ
やってみるもんですね。ありがとうございました！
ちなみに、どんなことに気づいたのですか？
ツールなのですが「Chrome Logger」です。
表示画面に影響なく、メッセージが表示できるので便利です。
見たことなかったので、検索してはじめて知りました。
なるほど。試しに使ってみたことありましたが、
あれ、header() 使っているんですよね…
cookie 使っていたりすると
Already send by .... で結構画面に影響出たりして、使いどころ結構難しいかも。
やっぱり使ってみてはいるんですね。
テストした感じでは特に問題なかったんで、気が付きませんでした。
header はかなり汚れてましたがｗ
正直使い続けるかどうかは微妙ですが、発想として面白かったです。
拡張機能としても面白いので、もう少し調査して見ようと思ってます。
0
デバッグ時に直感を排除することは、早くから意識していましたが、そういえばある時からリリースやテストを書く際には直感を大事にするようにしました。
変更点がこの項目であれば、チェックポイントはあれとこれだなあというのを計画したときに、なんとなく不安になることがあります。ダウジングのように不安の発生源を探り一つずつ探り、不安がなくなるまで対応を考えます。
大体において、なれた作業のチェックポイントはすぐ出ますが、不慣れな作業は項目が出しづらいものです。そういったものは、言葉にはなりませんが不安になって現れるがあります。
精神衛生上もいいやり方だと自負しています。
投稿2016/08/23 07:34
総合スコア2883
「テストを書く際には直感を大事にする」
実はプログラミング歴が浅い上、独学かつ一人作業でサービス運営をしているため、最近までテストに有用性を見出していませんでした。
最近、リファクタリングやスクリプトの再利用を行う際に、テストの有用性に気がついたため、テストを学習中です。
この辺りの感覚が身についた時、共感できる事を楽しみに意識しながら学習します！
0
一通り出揃ったところでこっそり回答しようｗ
とりあえず、
・自身の間違いを最初に疑う
これは本当にそうですね、以前他の回答でも書きましたが、
コンパイラがバグってると思うときは自分の頭がバグっているという。
世界中の自分より頭のいい人達の作ってくれたおもちゃで遊ばしてもらってるわけですから
自分が間違ってるに決まってると思うようにしてます。
あと私の経験として書けるのは
「局所化する」ですかね
プログラミングを始めたばかりの頃、Java Scriptを勉強していて
どうやっても動かず悩みまくって、大袈裟じゃなしに三日三晩悩んで、
大文字と小文字の違いだったというオチだったことがありました。
Google Mapsとかが出てくる前で、今みたいに便利なデバッガも無い頃の話です。
で、Java Scriptが大嫌いになりましたがｗ でもそこで何か自分の中で開けた気がしました。
それまでは、動かないとだいたいその辺りというのを漠然とソースを眺めてましたが、
それからは、絶対ここというところまで局所化して切り詰めるということをやるようになりました。
まず、本当に問題はそこなのか、自分は何と戦ってるのか、敵は本当にそいつなのかみたいなね。
頭で考えるのも大事ですが、手を動かして問題を単純化していくという作業を
めんどくさがらないようにするのを大事にしています。
そこがずれると思い切り時間を無駄にするので、私としては、重要なポイントです。
投稿2016/08/23 14:34
総合スコア2208
「局所化する」
これ、やっぱり多くの人が意識しているんですね。私も意識はしていましたが
> 絶対ここというところまで局所化して切り詰めるということをやるようになりました。
ここまでの思いは持ってませんでした。
実践とともに成果が上がる系の手法だと思うので、今後少し覚悟を持って継続していきます。
ありがとうございます！
0
まだまだ効率的とは程遠い自分ですが・・・。
そんな中でも自分的にレベルアップしたとキッカケ、またはキッカケとなるとだろうと感じたのは以下となります。
- 一番の敵、それは自身の思い込みと知る
- 行き詰まった時、一度リセットする勇気を持つ(ソース的な意味でも)
- 急がば回れ(一気にやるとろくなことがないという意味でも)
###思い込みほど厄介な敵はなし
プログラミングに限らず、
何事でも当てはまることかと思いますが、なにより怖いのが思い込みです。
- 自分のコードが間違っているはずないんだけど
- この関数は名前からこのように動くはずなんだけど
- 標準でこの構文がサポートされてるから、どこでも使えるはずだけど
これらの思い込み程に恐ろしい敵はいないと思います。
(もちろん僕も漏れなく全て経験してます^^)
何よりこの思い込みたちの厄介な点は、
それが自分の思い込みと気づくまで時間がかかることです。
(恥ずかしながらC#経験後にJavaを触った際、文字列比較でハマり時間を食いました^^;)
僕も思い込み気質は強い方なのですが、最近はまず「〜のはず」というのは疑ってかかるように気をつけてます。(お仕事の時以外は割と適当なのが玉に瑕ですが^^;)
そのためコードが動かない場合などは、
先ずは自分が正しいコードを書けているかを疑い、
次にその構文・関数(書き方)は本当に正しいか・実装されているかを疑う癖をつけるよう奮闘中です。
更に言うと独自フレームワーク、独自モジュールを相手とする場合は中身が見れるのなら、
先ずはコードレベルで事実を確認するようにしています。
(関数名とドキュメントで判断したら痛い目みた経験より・・・。ただ本来ドキュメントと命名がきちんと整備されているならこのステップの負荷は減るはずなんですがね^^;)
ことSQLに関して割とよくあるのが、
標準として定義されているのに実装がバラついてたり、そもそもサポート対象外ですがそれはみたいなパターン。
ずっと１つのベンダでやってて、
いざ別のベンダのDBMSを使う場合、
思い込みにはくれぐれも注意をば。
(Ex:SELECT句のみでロックがかかるものもあれば、そうでないもの。DDLを流すと即コミットがかかるものから、そうでないものなどなど。)
###行き詰まった時は白紙に戻す選択肢も時には必要
度重なる仕様変更によるコード修正や、複雑なSQLを組み上げようとするとしばしば行き詰まることがあります。
この時ここまでやったんだからもったいないとかいう考えで一度リセットする選択肢を捨てることが、
トータルで見るとより効率の悪い作業を行っていることも多いということへの気づきはブレイクスルーには大事と個人的には思っております。
そもそも行き詰まりに陥るパターンとして、
- 度重なる暫定対応で構造が歪になり身動きが取りづらくなっている
- そもそものアプローチ方法が不適切
- 単純なスキル・知識不足
これらの類に分かれるかと思います。
3つ目は勉強するしかないのですが、
残り2つについては、一度リセットした方が実は早く終わるということもある訳です。
(1つ目は勝手リセットに戻す訳にもいかないので、現状の問題点を整理して偉い方と要相談となりますが)
後、気合いで大作を作り上げましたという所まではいいですが、
実は誰もメンテができないような代物でしたというオチが付くとトータルで見ると結局は時間のロスとなります。
そういう意味でも白紙に戻して、
作り直すという戦略も時には重要となるかなと思う訳です。
(ソースもその改修を契機にある程度すっきりさせることもできますしね)
###急がば回れ(でも本気の急ぎでは大抵は回れないorz)
これは上記２つの例で挙げた分ですと、先ずドキュメントを読むとか、
一度途中までできたものをリセットするとかした方が超短期的に見ない限りでは早いというのが当てはまるかなと思います。
後はトラブルが発生した時などは、
問題を一気に解決しようとするのではなく、1つずつ確実に解決することがノウハウを確立できるという面でも長期的には有益となります。
(一気にやって何となくで解決した場合は、2度目の対応で死ねる・・・)
でも本当の緊急時はそんなことどうでもいいから早く解決しろって話になるので、
その時ばかりは回る余力も余裕もなくなるのですが^^;
(ある程度は記録を残して、後から復習できる形であれば良いのですがね。)
###蛇足
まとまりはないですが上記のような感じです。
自分自身の大きな課題の1つでもありますが、
個人的には1つ目の思い込みをいかにして防ぐかというのが大事な所でもあり、難しい所でもあるかな所でも思います。
スマホから書きすぎて指が痛くなってきたので、この辺りで。
投稿2016/08/23 13:08
編集2016/08/23 13:23
総合スコア1636
「一番の敵、それは自身の思い込みと知る」
客観的視点が必要だと思いますが、なかなか成果が上がりません。
意識はしているんですけどねぇ。訓練かなぁ。
「行き詰まった時、一度リセットする勇気を持つ(ソース的な意味でも)」
これ、かなり重要ですよね。間違ったらスタートまで戻る勇気！
これも意識していてもなかなか出来ない。。。
「急がば回れ(一気にやるとろくなことがないという意味でも)」
むしろ、下のコメントに共感ですｗ
> (一気にやって何となくで解決した場合は、2度目の対応で死ねる・・・)
あるあるですね。
非常に全体的に共感できるのですが、どれも実践できてないorz
早く次のステージの見えるところまで実践したいです。
蛇足：スマホからって、マジですか！ｗびびった
0
こういうアンケートのような質問、自分も嫌いではないのですが、最初からBAつけない宣言をした質問って運営さんはどう思われているんでしょう？
たまに見かけますが（回答の上位ランカーさんから出ることが多いような気もしますが）、teratailさんは回答率だけでなく解決率も指標としていたと思います。
そういった意味で、最初から未解決で終わる予定の質問は運営的にはどうなのかな？とも思ったりします。
せめて期限を設けて、一番感銘を受けた回答をBAにするとか、自己解決でFAにするような対応をしてはいかがでしょうか。
自分は運営さんではないので正解は持っていないのですし、いらぬ心配なのかもしれませんが(^_^;
せっかくなのでアンケートに対する自分の意見も。
自分が作業をしようとしていて、でもなかなか手が進まないとき。
多くの場合、目の前にたくさんの作業が乱立し、何から手を付けていいのか迷っていたり、いろいろなケースを想像しすぎて考えがまとまらなくなってしまったりしています。
仕事上、大規模システムのカスタマイズをする機会が多く、その中には仕様も開示されていないブラックボックスも考慮しなければならなかったりして、よく行き詰っていました。
そんな時、敢えて条件を絞って小さな単位で考えるようにすることで、そこからサクサク進み始めたりできるようになりました。
こういう割り切った作業の仕方もできるようになって、開発効率があがったような気がします。
「木を見て森を見ず」ということわざがありますが、大きすぎる森に対しては敢えて1本ずつ木を見るようにすることも大事なのかもしれません。
投稿2016/08/23 10:43
総合スコア3013
先にこちらへの私見を書きますね。
「せめて期限を設けて、一番感銘を受けた回答をBAにするとか、自己解決でFAにするような対応をしてはいかがでしょうか。」
この質問の本質は、質問にも書きましたが、今の私では理解できないケースが多数あるので、自身でBAを選ぶことが出来ません。自己解決でFAってものありだとは思うのですが、それは様子を見ながら検討したいと思います。運営さんの推奨違反の認識はあるので、運営さんの判断でNGが出たら残念ですけど。
---
「割り切った作業の仕方」
いわゆるGTD、プログラミング以外も含んだ、作業の仕方全般に言えることですね。課題管理表の作成とかプロジェクト管理ではよく利用していました。利用の仕方は身についているのですが、意識しないと使用できないレベルでもあるので、これが無意識でできるようになると、仕事の苦が減るのかもしれないですね。修行しますｗ
0
「コードを書かない」
プログラミングをはじめたころは、いかに便利で優れたものを「つくる」かに一生懸命でした
仕事においても、コード量と出来上がりの品質や満足度は比例すると信じていました
ところが
コードを書けば書くほどにバグは増え、複雑になり、修正も改造も大変なことになっていきました
ある日、なんの本だったか忘れてしまいましたが
「ソフトウェアの効率・品質を上げる最も確かな方法は、コードを書かないことである」
的なことを読み、衝撃をうけました
＃コードを書くからバグが入る
＃バグを出したくない、品質を上げたければ新しいコードを書かなければいいのか！
＃なんて当たり前のことなんだ！！
「つくらない」ことの重要性に気づきました
それ以来、
・顧客の要求している品質はどのくらいのものか
・その機能は顧客の何に貢献するものか、本当に必要か
・別の機能で代用できるか
・過去に書いたコードの再利用（枯れた部品）で対応できるか
などの視点で仕事をするようになりました
投稿2016/08/29 02:58
編集2016/09/03 00:43
総合スコア3116
「ソフトウェアの効率・品質を上げる最も確かな方法は、コードを書かないことである」
タイミング的には設計とそれをコード化する際の気付きですかね？
今は「過去に書いたコードの再利用（枯れた部品）」のストックがないため、まだまだこのコメントの本質は理解できませんが、意識してコードを整理してみたいと思います。
ありがとうございました。
0
「自身の間違いを最初に疑う」の次に考えることとして、
「流用コードの"使用実績がある"は信用しない」という点に注意してますね。
世界中で広く使われている著名なOSSでもない限り、社内などで作成したソースコードの"使用実績"は、所詮「特定環境・特定の使い方においての限られた条件での使用実績がある」という程度の物で、他のプログラムに流用した時点で、その使用実績の前提となる環境・使い方条件などからは外れていると考えるようにしています。
投稿2016/08/23 11:27
総合スコア344
「流用コードの"使用実績がある"は信用しない」
まだそれほど、流用コードが原因でドハマリしたことがないので、これもこれからの気付きになるかと思います。
他分野では「前うまくいったやり方が通用しない」ケースは多々経験しているため、気を切り替えるのが難しいのはよく理解できます。
認識切り替えのハードルが高そうですね。ありがとうござます。
0
会社の外に出てコーヒーを飲む
会社の中にいて思い浮かばなかったことが外に出てコーヒーを飲みながら考えていると急に解決方法を思いつくことがあります。
投稿2016/08/23 08:02
総合スコア1820
私の書き方が悪かったのですが、頂いた回答はどちらかと言うと「問題点」に対してのブレイクスルーポイントですね。
脳科学的にも有効だといった説明を見たことがあります。脳のデフォルトモードだったかが効率化をはかるとか。
私はコーヒーブレイクだらけなので、もっといろいろ解決できても良さ気なのですが。
0
自分もte2jiさんと同じ感じですね。
まず自分のミスがないか調べる→解決しなければ5分程置いて落ち着いてからもう一度確認
→それでダメなら環境他の確認...というような流れでやっています。
それでもダメなら解っていそうな人に聞く、もしくはここに聞きにくるって感じです。
自分自身出来ると言えるほど自信はないのですが、二回目見るときは客観的に見るようにしています。
あと第三者による視点になれば解るといったことがあると思いますのでそれもありかなと自分では思っています。
投稿2016/08/23 05:20
退会済みユーザー
総合スコア0
> 二回目見るときは客観的に見るようにしています。
これはできると強いんでしょうけど、難しいですよね＾＾；
意識はしているんですが、できる気（できてる気）がしません。。。
そこが問題なんですよね…＾＾；
解決できる時もあるので良いのですが、出来ない時もあるので
その為の第三者という事ですw
0
機械ではなく人間に対してコードを書くこと
これを意識していると読みやすさ、
ひいては保守性が断然違ってきます。
機械に読ませる意識だと、
動けばいいからと書きやすく書く方向に流れます。
トリッキーで短く書けているけど、
後でそれを読解するのが大変という場合もあります。
人間が読みやすいように書く習慣は重要です。
読みやすく書くのは大変で、
しかも効果はすぐ実感できない、
しかし長く動き続けるプログラムを
書くのに大事なことだからです。
これは大したことないように思えるかもしれませんが、
しかし今では常識化した「オブジェクト指向」だって、
人間のために分かりやすくする技術です。
だって機械は最終的に機械語が読めれば動くのだから、
機械語やアセンブリで書かれてても問題なく動くわけです。
しかしそれだと、あまりに人間にとって分かりにくいので、
高級言語、さらにOO言語、あるいは関数型言語で書くと。
リファクタリングも人間のためにやってるわけです。
だから現代のプログラミングの大原則として、
機械だけでなく、人間が読むことを想定して書きます。
投稿2016/08/29 17:41
総合スコア5592
「機械ではなく人間に対してコードを書くこと」
結構大胆な回答ですね。面白いです。
メンテナンス性の面からは絶対的に正解だと思いますが、機能面や効率面で正解なのか、経験が少ないため、判断できません。
スクリプト系言語だと、人間に読めること最優先が正なんですかね？
少し意識づけて書いてみます。
0
私からはエンジニアの姿勢的な所の気付きを共有します。
最後のは有名なハッカーになろうの心構えその5です。
- ソースコードは美しく
- 実際に手を動かして作った分しか覚えられない
- 心構えは技能の代用にはならない
ソースコードが美しくない人はDRYやコピペは避ける辺りで妥協しますし、
読みやすいコードの為に問題を簡単に表現する努力もしないイメージがありますね。
結果同じような事をやって同じようにバグを出すので、伸びる速度に差が出る主原因だと思ってます。
（今の職場はソースコードの綺麗さだけで採用を頂きました。）
手を動かした分云々は経験則ですね。
本やブログの紹介記事を読んで知った気になるのと、実際に完成させるのとでは雲泥の差があります。
（漢は黙って写経、この事を意識してからタイピング速度を上げる練習も始めました。）
私の中では上記が前提としてあったからこそ腑に落ちたのが「心構えは技能の代用にはならない」です。
技能がある人は(心構えがあろうとなかろうと)それなりな事をやってきた人であり、
技能が無い人間は何を語っても所詮口先、実にシンプルで本質を表している恐ろしい言葉だと思います。
（営業、プロ野球、棋士…色々ありますが全て技能です。他人の技能を蔑む事はしないでいきたいですね。）
まだまだ人様に心構えや技能のなんたるかを語れる程の事はやってきていないので、
頂目指して精進あるのみ…ですかね。
投稿2016/08/27 03:46
総合スコア21194
「ソースコードは美しく」
コードの最適化と美化は必ずしもイコールでは無いと思いますが、意識として表現するにはいい言葉ですね。最近は単純化、美化の為、配列を多用すると良いのでは？と思いたち、いろいろ使用サンプルを眺めているところです。
「実際に手を動かして作った分しか覚えられない」
コピペで動かしてみることは結構あるのですが、タイピングするとまた違った経験となるんでしょうか？少し試してみます。
「心構えは技能の代用にはならない」
これは元のコメントを知らないので、真意がわからないのですが、「技能が無い人間は何を語っても所詮口先」と言い切ってしまうのは危険かと。技術がないからこそ本質をついてきたり、技術がなくても表現方法があるため、本質が伝わりやすかったりといったケースは往々にして存在するので。多分限定的な環境でのコメントだと思いますが、ちょっと共感できませんでした。
回答、ありがとうございました！
「ハッカーになろう」は日本語訳化されたものが下記URLで公開されています。
私の解釈という蛇足が付いた駄文よりよほど良い文章だと思います。
http://cruel.org/freeware/hacker.html
＞技術がないからこそ本質をついてきたり
技能とは何を指して技能と考えていますか？
技能というのはいくらでも細分化出来ますし、本当に様々な技能があると考えています。
まぐれ当たりでも、見極めた本質を説明しきるなら本当に素晴らしい技能と考えています。
高確率で的中させる能力は優れたポストに就く人間には必須の能力でしょう。
表現能力もまた技能の一つであり、長けた人程優れたポストに就くイメージです。
説明出来ずになんとなくそう思っただけなら本質を突いたとは言えません。
（とはいえ、もし単なる馬鹿ならかすりもしないでしょう、例えばパズルが好き、物理が得意、人の心を読むのが上手…様々な意外と馬鹿にできない要因が含まれているはず）
本質までたどり着く為に、「5なぜの法則」等といった手法がありますね。
プログラミングもそういう大きな枠では単なる一つの独立した技能です。
＞言い切ってしまうのは危険
捉えられ方によっては仰るように多少危険だったかもしれません。
ですが、見えにくい技能も正しく技能として取り上げる事が出来たのならば、
現在の技能を見ただけで、生き方、やってきたこと、努力したことは全て透けて見えるものです。
でも、優れた発想で劣った側が勝負をヒックリ返すかも知れない…というならば、
プログラミングを大工で置き換えて考えてみてください。
例えばプロの大工と、そこらに居るお父さん、同時に犬小屋を作り始めたらどっちが早く品質の良いものが作れるのでしょうか？
大工は釘の打ち方から、怪我をしない、力をかけずに簡単で速く高い品質で作る為のノウハウのセットを揃えています。
しかもそれは、先祖代々から弟子を取って口伝と修行で伝えられてきたアイデアの塊で、そんじょそこいらの思いつきでは歯が立ちません。
技術が無いからこその本質を突いた作業方法、大工を超える素晴らしい作業方法を閃いたりしてお父さんが勝ちそうですか？
要するに、この比較は大工さんを馬鹿にしてんのかってレベルの話で、
多少の思いつきでは絶対に覆せないものなのです。
プログラマーも速くて正確なタイプ、もしくはスニペット等を揃えていますし、最小で綺麗でバグの出ない書き方あれこれ(デザインパターン等)を熟知しています。
他にも使用する言語やフレームワークの選定、ハマりそうなポイントの避け方、バグの直し方、エラーログの読み方…山のようにあります。
大工もプログラマーも優れた技能は一朝一夕で身につくものではありません。
一時の閃きで勝てる程、エンジニアリングの世界は甘くなく、偉い人はそれを指してこういったそうです。
「エンジニアリング道にまぐれなし。あるのは実力のみ。」（西住しほ）
本質を捉える能力で「そもそも必要なのは犬小屋じゃなかったんや」「このロジック作るだけ無駄だったわ」みたいなのが分かったとしても、それは単純に別の技能が求められる勝負だったというだけの話です。
ただし、本質を見極めることは全てに於いてとても重要な事ですし、それが原因で負けたとしてもまぐれではなく必然であり、素直に頭を垂れるべきと私は思います。
> 「ハッカーになろう」は日本語訳化されたものが下記URLで公開されています。
こちらのページ、面白かったです。
ご紹介、ありがとうございました。
>「技能が無い人間は何を語っても所詮口先」と言い切ってしまうのは危険かと。
記載したとおり、「限定的な環境でのコメント」では正しいと思うので、追記していただいた個々の内容に関しては理解できます。コメントをキャッチーなフレーズにする際に誤解を与えやすい表現になっていることに違和感を覚えただけですので。
> 「エンジニアリング道にまぐれなし。あるのは実力のみ。」（西住しほ）
心意気として、イイコピーですね。
0
日常においてはTopCoderなどの「競技プログラミングサイト」
などに参画してコーディング技術をブラッシュアップする。
http://www.topcoder.com
実務においては時々、客観的な観点から設計やコードを見直すと
色々な意味で一気に進展がみられることがあると思います。
投稿2016/08/31 15:02
総合スコア1630
ご紹介いただいたサイトを確認したのですが、クラウドソーシング？のサイトですよね？
競技の入り口まで辿りつけませんでした＾＾；
競技プログラミングには興味あるのですが、初心者ですので、簡単で、シンプルさを競うようなものから学習していきたいのです。参考になるようなサイトはありますか？
> 実務においては時々、客観的な観点から設計やコードを見直す
客観視がなかなか出来ないんですよねぇ。。。くまを使うか検討中ですｗ
0
公式ドキュメントを、見る。
英語、日本語含めて。
公式ドキュメントは、どうしても情報量が多すぎて敬遠してしまい、ネットに転がっている解決先に頼りがちですが、公式ドキュメントを丁寧に見る癖をつけたら、私の場合、スムーズに行くようになったと思います。
何か、解決策を見つけようと、Google検索した際に、多分、2番目か3番目くらいに英語のタイトルで公式ドキュメントへのリンクが出てくると思います。
「英語は読むの面倒」とか「探すのが大変そう」と無意識のうちに、そのリンクを視界から外してしまう事が、私にもありました。
そこの意識を変えて、まずはたとえ英語であっても、公式ドキュメントを覗いてみるというのが、私のブレークスルーポイントでしたね。
安易なところで、誰かがまとめたサイトに行ってしまったりするんですけどね。
Q○○taとか、Q○○taとか、Q○○taとか
まとめられたものというのは、「その人の主観によって」抜粋されたものに過ぎず、全体像の中でどこに位置しているのかなどが見えにくくなるので、そういったサイトを見るのは悪しき習慣であると、私は個人的に思っております。
投稿2016/09/20 10:39
編集2016/09/20 11:45総合スコア256
回答ありがとうございました。レスポンスが遅くなり申し訳ありません。
公式ドキュメントを見るようになると一つステップをあげた実感がありますね。
だれかがまとめたサイトは新しい情報の要約を見るのには便利だけど、信じる根拠とするには取捨選択のための時間がかかりすぎます。
まとめサイトは、ちょっとやりたいことを勉強せず実現するには便利な場合もあるけど、学びのためには公式ドキュメントを見ることが近道ですね。
0
私も一言
- 手を動かす前に考えろ！
プログラミングもデバッグも推論（シミュレート）が作業の主体となるべきです。どんな高度なデバッグツールでも、人間の代わりに推論してくれることはなかなかありません。考えるのをサボって、手を動かすと必ず効率が下がります。試行錯誤やデバッガによるデバッグは推論で十分可能性を絞った後で無いと効率が悪いです。パズル系のゲームでも、当てずっぽうで答え始めると解けないですよね。
で、その実現方法として、
- 歩き回れ！
考えるためには脳に大量の血液を送る必要があります。心臓だけでは足りないので、歩きまわって第二の心臓と言われる太もものポンプ機能で脳に血液を送り込みましょう。あと、キーボードから離れれば、手を動かせなくなりますからね。
投稿2016/09/01 09:52
総合スコア3401
これはまた議論が分かれそうなｗ
「手を動かす前に考えろ！」
逆をすすめる人も多いですよね。どちらも正しそうなんで困ってしまう。
私は動かす前に考えてしまう方なので、今逆をチャレンジ中です。
また戻るかも。
「歩き回れ！」
いいですね。やってみたい。
座りっぱなしで、腰がいたいｗ
te2ji さん、
一休さんとか探偵ガリレオをイメージしてください。「彼がキーボードを叩き始めたということは、もう解決したも同然だ！」って、かっこ良くないすか。
あと、歩きまわる場合にどこを歩くかっていうのは結構難しいです。探偵ガリレオの場合はチョークさえあれば問題が解けるから良いですが、我々の場合は端末が無いと仕事にならないですからね。安全性も考えると、開発の部屋の中で動物園のくまのように歩きまわるというのがベストです。
ガリレオにあこがれていたんですけど、あそこまで頭良くないことに気がついたんで、青島刑事もやってみようと挑戦中ですｗ
ガリレオとどっちが合うか、気になるところですが、結果がすぐに出ないのが難点ですね＾＾；
あぁ、ルームランナーがほしいｗ
0
「githubを見る」
自分が扱っているフレームワーク・ライブラリ なんでもいいので、ソースリーディングをしてみることです。
１日３０分くらいでもいいです。
美しいソースを書く。 という話につながるかとも思うのですが、バグを出しにくい整理整頓の仕方を他人からどんどん盗んでいくことや、「こんなまとめた方があったのか」という発見が、過去の失敗も含めて自分の新たなブレークスルーポイント、引き出しを増やす鍵になることもあります。
投稿2016/09/20 05:55
総合スコア94
回答ありがとうございました。レスポンスが遅くなり申し訳ありません。
ライブラリやSDKを最近見るようになりました。
面白いですね。
独学している身としてはノウハウの塊に見えます。
1日30分はなかなかきつそうですが、少しづつ試してみます。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2016/08/23 07:57
退会済みユーザー
2016/08/23 08:45
2016/08/23 08:53
2016/08/23 08:58
2016/08/24 01:35
2016/09/20 05:47