プログラミングやってて発想の転換が必要だなって思う事、または重要な考え方って何？

あったら教えて、ただ覚えるだけじゃ飽きてくる

実際作ってる中じゃないとなんとも

>>2
教えて下さい

教えたらまたそれを覚えるだけになるじゃん

>>4
なるほど…
じゃぁ視点みたいなのを教えて下さい

いや考え方は自分で考えて身に付けろよ…
教えて教えてって結局それただ覚えるだけじゃねえか

>>8
いや感化されて新しい考えが生まれますから

独学で覚えたから中途半端な知識で昔作った力技に近い処理とか見ると感慨深くなる

目の前にあるコードを疑ってかかる

>>7
コード自体意味不明だから始まりはそこからです

アルゴリズムの閃きが大事だと気づく事かな
例えばＡの方法では実装できるけどＢの方法で実装ができない
Ｂの方法で作りたいのに何度やっても作れない
断念してしばらく放置してるとある日突然
「ああ。Ｂのやり方の場合こうやれば出来るのか」と気づくときが来る
大体そういうときはその通り実装できる
根つめない事が重要

>>9
考え過ぎるのはよくないってことですか？
ある程度分からないと飛ばすってことですか？

>>11
いや精一杯考えないとダメ
考えて考えてそれでも無理なら後に回す感じ
ある日突然ふってくる
「あー。あれこうやればいけるんじゃね？」っていうのが
時間が解決する

>>15
0秒思考ってご存知？

>>16
知らんな

>>17
ある程度考えても新しい解放が思いつくとは限らない
即断即決が大事っていう本があったんで…

それに多くの人が熟考タイプだから
プログラマーは熟考なんてよっぽどゆとりのある環境じゃないと無理だと思うから

だから申し訳ないけど俺はID:L87PZ20e0さんの考えには断固反対する

>>19
んー。まあそれでいいんじゃないだろうか？
俺の言葉が理解できる時がきたら思い出して非礼を詫びてくれればいいよ
教えていただいた人に対しての礼儀に反するから今謝って欲しいものだがそれは期待してはいけんのだろうなぁ
まあ去るよ

>>25
ごめんなさい…

熟考は俺のもっとも嫌うキーワードでして…
今まで深く考えてたつもりが同じ考えの繰り返しみたいなのがあったんで
非常に嫌ってるキーワードなんですよ、これだけは聞きたくなったんです

え、何この人…

俺がこう思うから！
本に書いてあったから！

ならもう他人に聞くなよ…

プログラミングなんて根性だから
極々一部の天才を覗く

例えば全く分からないコードがあった場合

左辺と右辺を意識するって重要ですか？


xyz=xyzsuper;

全くわからないことはまず調べろよ…
考え方の応用は理解の先にしかねえよ…

人によると思うけどプログラミングにおいて
アルゴリズムの部分はあまりぐぐらないほうが良いと思うわ結果論的だけど
もちろん言語の仕様についてはぐぐるしかない
まあものすごい良いアルゴリズムを無料で公表してくれてる先人もいくらでもいるけど

それに俺はアルゴリズムの話はしてない
分からないコードを見たときどういう判断をすればいいか聞いてる

だからわからないなら調べるしかねえよ
調べること（ググるだけじゃねえぞ）すら思い付かないなら
何を考える力もないから諦めろ

深く考える＝実は頭はそんなに働いてない

つまり新しい発想をするには誰かのアイディアを見る事が重要

熟考しろ→同じことを繰り返し考えろなんて誰も言わないだろ…
何で全てがお前基準なんだよ…

誰も反論できないな

(あかん奴だこれ)

>>48
(だよな)

>>48
深い思考ができないやつはそう思うかもね

24について言えば
・ブラックボックス的な処理
よくわからん誰かの作った自作関数とか投げた値と帰ってきた値を総パターンでやってみるとか
・ソース読み解いてみる
確実だけど心折れるかもしれない
でも作者の考え方が理解出来て共感できたらすごく勉強になると思う
ただし自分よりちょっとだけ上のレベルって感じの都合のいいソースじゃないと厳しい

>>36
ソースが読み解けない人にとっての思考方法を考えてるんだよ
本末転倒じゃん…

読み解けたら苦労しないっつの…

>>39
ブラックボックス的処理書いたっしょ
餌食わせたらいろんなうんこするんだから
・いろんな餌与えれ(考え付く全パターン)
・そしてうんこ見れ

これできないならそんなの使うなとしか言えない

>>43
それ出来る人の考え方じゃん

覚えるのも考えるのも嫌ならもう辞めた方がいいんじゃないかな

>>30
考えることは好き、でもプログラミングをする際に考えるより
その前の準備として考える事の方が好き、いってる事分かるか？

大抵の人間はプログラミングしながら考えるだろ、これがダメなんだよ

>>32
んじゃあ考える幅広げたらいいんじゃね
・作者目線
・ユーザー目線
・引き継いだ後輩の目線
そんな感じで考えると面白いんじゃね

>>34
それプログラミングできる人前提の話じゃん
もっとできない人が考える話をしてる

>>35
それならドミノひとつずつ並べるイメージ(手作業)
そのドミノを先頭の倒したらうまいこと倒れる(システム化)ことをイメージするとかどうだろう

フローチャートかけないレベルならここでコケるはず

>>40
じゃぁ全ての関数の意味が分からなくて、今から１時間以内にコードを解読
せよって言われたらどうしますか？
上司に質問できる回数は１回とします。

どうです？切羽詰まった状態での思考が重要なんです。

>>42
目的によるし

なんらかのテストで解析してその進み具合を見るためなら解析するし
その関数を使うことが必須だったりするならブラックボックスとして扱う

そもそもそんな自体に陥らないし
それを上司が持ってきたならできないので自分でやれといえばいい
チームのスキル見誤ったゆえの結果とそれに対しての責任を問うわ
「反論あるなら、明日までに100m9秒台出してください。俺もその心意気で頑張ります。さあ急いでください。」でいいんじゃね

>>45
それも１時間以内に解読しないとダメだとしたら？

>>47
こんな状況に陥ったから解決策を乞うてるのか
相手を言い負かしたいがためにこんな難癖つけてるのか
どっちなんだろ

>>52
前者です…

>>55
上司殴れ

いろいろあるだろうけど幸せはそっちのルートが近いと思われる

保証はできんが

>>55
他人の作ったプログラムっていうのは暗号に近い
だから、本来は説明をしっかりいれてくれてるはず
それがないなら前任者は糞だったという事

関数が分からないのはお前の勉強不足
そんなんでプログラマーとか笑わせるな糞が

上司も糞
会社辞めろ

答えは

仕事をやってプログラミング勉強できるんだから必死に食らいついて上司に
質問しまくるが正解

無駄だよ
こいつ自分がわからないことの解決法すら自分で考えられず
かと言って他人の発言からも何も見つけられず
自分ルールで無視するっていう物事を思考するのに最も向いていないタイプ

>>41
何言ってるんですか？思考方法を考えるという思考は誰にも負けません。

ないよ

教科書通りにやるのが一番優秀なプログラマー

いろんな人が書いたプログラム見るのが一番かな
基礎的な文法を記載して説明している本やサイトはゴマンとあるけど
いざ業務で書くコードは違ってくるからな

>>61
突き詰めると大枠になっちゃうけど問題解決力になっちゃうよな

プログラミングのスキルより万人に伝わる誠意ある土下座スキルの方が最適な事もあるだろうし

愛と夢と希望を持ってる人間の方が向いてると思う
割とマジで