経験からそれは当然と思います。
純粋なコーディング自体はプログラミング言語文法通りに書いていくだけです。あくまで「純粋」なコーディングの場合です。
デバッグは、まずバグを発見する作業から始めるわけですが、常に再現するバグならある程度修正箇所が見えたりしますが、場所、時間、その他の環境でバグが出現しない再現しないバグというものもあり、これが厄介です。運用中の本番環境でのみ起きるバグという地獄があったりします。
昔から、「三行より大きいプログラムには必ずバグがある」という諺があります。実用的な規模のソフトウェア、全ての条件でテストを行う事は不可能です。大規模なソフトウェアには何年も見つからないバグが残っているものです。
デバッグが単純作業なら良いと思いますが、ソフトウェアに限らず「システム」にはバグが潜んでます。
1990~2000年に、私は原子力発電所や人工衛星を作る大企業に勤めていました。
この会社では半年間のプロジェクトを立ち上げると、最初の3ヶ月で書類を作ります。企画書、外部設計書、内部設計書などです。次の1ヶ月間でコーディングします。残りの2ヶ月で試験を行い、不具合を徹底的に追い出します。
私は企画書以外の全部を担当していました。まあ妥当な時間配分だったと思います。
ベンチャーに行くと、設計書類を書いている暇がないとか、上司に試験期間を打ち切られるとかして、担当者が責任取れないレベルのソフトウェアを出荷します。
これはほとんど100%その通りだと思います。歴史的にも世界最初のプログラム内蔵式コンピューターと言われるEDSACを作り、そのプログラムをしていたモーリス・ウィルクスという人が、ほぼ世界初のデバッグ作業(プログラムを実行して、エラーを見てそれを修正する)をしているときに「私の残りの人生の良い部分が、自分のプログラムのエラーを探すのに費やされてしまうことを感じた。」と言ったという史実がとても示唆的です。
いろいろなプログラミング手法や新しいプログラミング言語など、「プログラムが書けさえすればエラーはなく動く」というような触れ込みのものはこれまで多々あります。ただ、複雑化する要件、「動かして試してみないとわからない」ユーザー・インターフェイスやデータ処理のスピードやタイミング、そしてなによりも部品の数が増えるにつれて幾何級数的に増える組み合わせの複雑性増加により「書けさえすればエラーなく動く」というスタイルが通用する領域は、プログラムで書きたいと思う領域が広がる速度に追いつけていないのが現状です。もちろん、実際に使われることになったシステムには「完成」ということはないことが多いので、組み合わせ問題は一度動き出した後でもずっと付きまとうわけです。
というわけで、方法論としても、バグが少なくなるような技法を使うものの、作り始めてみないとわからない問題があるということを前提に置いて、いかに早くテストし、修正の可能性を残しながら開発を進める、つまりはデバッグするということを織り込んでいくことになります。
ブライアン・カーニハンという有名なコンピューター科学者も「そもそも、デバッギングはコーディングよりも2倍難しい。従って、あなたが可能な限り賢くコードを書くとしたら、定義からして、あなたはそれをデバッグできるほど賢くない。」と言っています。これは方法論や言語にあまりにもこだわるのではなく、開発を進める時にデバッグする必要があることを常に織り込むべきである、ということになりますし、2倍、かどうかはわかりませんがデバッグの方が難しい、という知見は今も昔も変わらないと思います。
コーディングの定義によります。
質問者が言うコーディングとは、おそらく 設計 + コーディング作業 という広義のコーディングのことだと思いますが、設計・コーディング作業 (製造)・デバッグ (テスト含む) に 3 分割すると、設計に力を注げばデバッグは少なくなり、注がなければ多くなります。
設計に力を注ぐというのは、バグを埋め込まないよう事前に脳内デバッグをしているようなものです。
設計とテストというのは (本来は同時に考えるべき) 表と裏であり、設計の熟慮によりコーディング量を、テストの熟慮によりデバッグ量を極小化させます。
設計なくコーディング作業をしていれば、当然それはデバッグを膨らませることになります。コーディング < デバッグ、という感覚を持つのも当然でしょう。
設計の重要性を理解している人は開発フェーズの属性を 3 分割しますし、3 分割する人はコーディング作業もデバックも設計に比べれば軽いと考えると思います。設計 > コーディング作業 + デバッグ、という感覚です。
よい設計は日頃の学習と鍛錬の結果としてできるようになるものです。その意味で、広義のコーディングに含まれる設計はデバッグとは比較にならないほど長く重いものであり、コーディング作業やデバッグは "ピカソの 30 秒" だと言えます。
どういうソフトウェアをどういう方で開発しているかによります。
大規模な業務用のソフトウェアであれば、デバッグに時間をかけるのは最悪です。きちんと設計してテスト用のプログラムも設計しておくべきです。そうすれば、設計には時間がかかりますが、デバッグの方に時間がかかるということはないと思います。
個人でプログラミングをする場合は、設計をする必要はありませんが、コーディングの時にテスト用のプログラムも一緒に作っておくのが効率がいいと思います。
デバッグに時間がかかるのは、ハードウェアのドライバーのプログラムやネットワーク関係のプログラミングです。これらのプログラムは、テストをするのが大変で時間がかかります。
リクエスト頂きました。
本職ではないですが、チェックテスト含むデバッグが時間かかると思います。
自分でコーディングする際は、エラーになりそうな箇所が大体わかるので、コーディングと平行で、チェックとデバッグも進めますと、少し楽です。
デバッグも含むテストの方が時間かかりますね。
真面目にまともなテストをすれば。
もちろんテストコードを開発する分の時間も含めてですが。
かかります。というかテストにすごい時間をかけます。できあがったシステムを直す時ですけれど、コーディングが1だとするとテストは10～30くらいの時間と人を入れます。他のシステムに影響があると困るからです。みずほが良い例ですね。
一般的にかしらないけど単体テスト合格相当の品質をコーディング完了とするのでデバッグはコーディング時間に含めていいと思います。
何万行を未検証で書き上げられる人は希有というかいないと思いますね。
自分も何万行か書くと20回位エラー除去して通るとかそう言うイメージです。
まあ、机上検証繰り返しまくってた大昔の人はそうではないかもしれませんがね。
昔に比べてデバッグが手軽になってますし、このスタンスで問題あるとは思ってませんね。
初期には紙テープ付くってスケジュールの予約70年代くらいでも、1行間違えたら1ファイル？まるごと修正の世界観でしたでしょうし。
コーディングという作業の中にデバッグがありますし、デバッグという作業の中にコーディングがあるので、どっちがどっちという事は無いです。
一部の変態プログラマーを除くとその通りです。
ステーブジョブスの
Take out debugging と言われた後の表情を見るとわかりますね。
デバッグの方が大変でしたが、テスト駆動開発やデプロイツールでテストさせるやテスト用のSAASなども充実しており、いまはそんなことありません。レガシー環境なんじゃないの？
古いジョークを引用するには…
エンジニアのグレイビアードは引退し、数週間後にビッグマシンが故障しました。これは会社の収益に不可欠でした。マネージャーはマシンを再び動作させることができなかったので、会社は独立コンサルタントとしてグレイビアードに電話をかけました。
グレイビアードは同意します。彼は工場に足を踏み入れ、ビッグマシンを見て、スレッジハンマーをつかみ、マシンを一度叩くと、マシンがすぐに起動します。グレイビアードは去り、会社は再びお金を稼いでいます。
翌日、マネージャーはグレイビアードから5,000ドルの請求書を受け取ります。マネージャーはその価格に激怒し、支払いを拒否します。グレイビアードはそれが公正な価格であることを彼に保証します。マネージャーは、それが公正な価格であれば、グレイビアードは項目別の請求書を送るべきだと反論します。グレイビアードは、それが公正な要求であることに同意し、それに従います。
新しい項目別の請求書には次のように書かれています…。
ハンマー：$ 5
ハンマーでマシンを打つ場所を知る：4995ドル
技術的に言えば、地球上のすべての仕事は、挿入と削除として要約することができます。何を挿入するか、どのように挿入するか、何を削除するかによって、すべてを要約できます。
したがって、CEOが何を挿入するか、いつさまざまなビジネス会話に参加するかを知るために1億ドルの価値がある場合、プログラマーは実際に何かを行うものを挿入するためのその価格の1000分の1の価値があります。
仕事場とか、すぐに聞ける教師的な先輩がいるとか、そのような環境を作れると、学べるのははやいですよ。
あとは同じ立場の仲間もいたらよりよいです。
独学の参考値ですが
20年以上前なんだけど、社会人になったときに営業職配属で挫折してから、家で引きこもってプログラマーになるための勉強をしていて、その時は1日10時間以上は勉強していて、その後、シェアウェア作ってマドモリで紹介されてもらうまでに、5ヶ月程度かかっているので
12時間x30日x5ヶ月で、1800時間くらい
また、その20年後、
.NET系のプログラマーではありましたが、JavaScript未経験でその仕事に従事したときには半年くらいはだいぶ混乱していましたが、半年後くらいには、ようやく実戦レベルになれたかな、という感じで、こちらも、ざっくりと、
8時間x20日x6ヶ月で、960時間なので、1000時間くらい。
こんな感じでした。
十分に思うような成果を出せるってところは、毎日やって6ヶ月程度が、目安かな。
6ヶ月も苦行というわけではなく(苦行なら耐えられんし)
はじめのわからないこと多すぎも、つらい、と思わずに、楽しみを少しずつ身につけて、続けていくのがコツです。
わかる範囲で楽しむように心がけて、そのわかる範囲をどんどん広げていく、というのを最初の段階からやれると、いいですね！がんばってください。
世の中、そうはなってないんですよー
プログラマーが今非常に人手不足感があり、
それ故に、プログラミング自体はお金になります。
技術的負債というもののない、効率よい、修正しやすい改良しやすく機能追加しやすくできあがっているシステムを作るには、それなりのプログラマーの腕が必要です。
そして、それなりのプログラマーの腕をもっている人は更に少数になるので、高いお金を仕払ってくれる人のところだけに、そういう人がいくんですよね。
プログラマーで、実際に誰かが何かを求めていることを実現させてきまくった身として観察して世の中をみるのですが
大事なのは物事を実現できる力なんですよ。
プログラマーは、その能力の高い低いはあるものの、基本的にはソフトウェアで物事を実現できる力を持っている仕事なんです。
なので大前提として、プログラマーは実際の物事を実現するという非常に優れた仕事をしています。このIT時代に非常にマッチしているからともいえますが、時代の最先端を走っている仕事で、もっともっと評価されるべき仕事です。(ポジショントークでもありますけれども。ｗ)
プログラマーは誰と比べて非常に優れた仕事をしているのか、っていうとですね。物事を実現できる力の無い、口だけ番長というか口先だけで机上の空論を語る人とくらべてってことです。
プログラマーに依頼してくる人は、人によっては「物事を実現できる力」がなくても、絵に書いた餅だけで、実現できない事を語ってくる人っていうのもいるのです。
プログラムを書かずに、新世代のOSを作る、次世代の進化したグーグル検索を作る、チャットAIを組み合わせてもっと進化させて、あれやこれやを作り出そう！
って、実現可否関係なく、口先だけでも言えるでしょう？
そういう人、今の世の中、すごく多くないですか？
「何を作るか考える人」の中には、そういう人がいて、そういう人の口車が大事だ、って言われると、それは違うかな、と思うわけです。
世の中を変えるシステムを作りビジネスを成立させて、ビジネスの舵取りをして大きく成長させる人、それはとてもとても優れた素質があると思います。そういう人が描くビジネスの将来像は空想妄想ではないです。
そういう人はプログラムを作れるかどうかは関係ないですが、「物事を実現できる力」が実際にあるわけなので、それは素晴らしい！ということになるわけです。
難しいのは、
プログラミング技術、ソフトウェア技術が全くわからずに、何かを作ろうとしてそれは実現不可能だったり、実現するにはコストが正しくなかったり、作っても売上にならなかったりして、そうすると、「物事を実現できる力」ではなく、妄想空想の類になりますよね。
プログラミングを知らなくても優れたプログラマーとしっかりコミュニケーションしないと、システムってのは作れない気がします。
長年プログラマーしていると、そういうシステムを妄想で作ろうとしようとしている人も、少なからず見てきました。
作っている自分でも大変だー、と思うのですから、よく知らないのに作ってくれと依頼する人は実現可否を考えたりスケジュールを見積もったりするのはより大変ですから、ソフトウェアで何かを実現するのって、なかなか大変だよな、と思います。
大事なのは、アイデアを考える人ではなくて、そのアイデアを実現できる人です。
ビジネスだとより広範囲ですし、システムのプログラムだとより狭い範囲ですが、どちらにせよ実現能力が大事です。
プログラマーとしてソフトウェアの特定の狭い範囲ですが、アイデアを実現できる人になっておこうと思いますし、それで、お金をそれなりに得ようと思っています。
何を作ろうか、というアイデアをもっている人も凄まじく大勢います。
その中でも、ビジネスを実現するスキルがあり、既に、いくつかのビジネスで成功して、すんごくお金を持っていてお金払いのふとっぱらな人からの依頼でお仕事するために、プログラミングのスキルは磨いておこうと思っています。
プログラマーやソフトウェア技術者の需要供給バランスで考えると、何を作るか考える人が激増すれば、需要が増え、それは供給側の仕事を受ける側の自分にとってもありがたいことなので、何を作るかがんばってたくさん考えてみてください！
太っ腹な人は、ぜひ俺にご連絡を！
JavaScript/TypeScriptしかろくにできないけどね！
ふと客を！ふと客を、是非にわたくしに！
巷での見積もりテクニック読んでると「一通り見積もってから安全のために2を掛ける」だの「思い切って3を掛ける」だの「10を足す」だのというものが多いですが、こういう意味不明な定数を掛けたり足したりするのはやめましょう。ナンセンスです。もっと意味のあるやり方をすべきです。
私のおすすめは、
「見積もりは3パターン作る」です。
見積もりで困るのは不確定要素です。未確定の外部接続や、実装途中での方針変更などがあります。
これらについて、ラッキーパターン、アンラッキーパターン、一番起こりうるシナリオ (先2つの中間)、の3つを考え、それぞれ見積もります。
場合によっては最小見積もりと最大見積もりで10倍以上差が出ることもあるでしょう。
問題ありません。3つ纏めてそのまま提出します。
依頼者はこの3段階の見積もりを見て、まず何処にどの程度の大きさの不確定要素があるかを知ります。(そうです、あなたの提出した見積もりを見て、依頼者はそれを初めて知るのです。基本的に、見積もりの依頼主はその件についてさほど詳しくありません)
そして、あなたには知らせていない「予算」と見積もりを突き合わせ、現実的な解を選択するでしょう。つまり、予算が足りなければ不確定部分についてあなたに譲歩し、予算が十分なら面倒をあなたに押し付けるでしょう。いずれにせよ、あなたは報酬相当の仕事をします。(ですから、どれを選ばれても後悔しない見積もりをすべきです。)
この方法の最大の利点は、小さい方の見積もりを依頼主が選択した場合、そこであなたの仕事の責任範囲が決まる事です。
例えばあなたがAWSに精通していて、「サーバーにAWSを使えるなら100万円、それ以外なら150万円」という見積もりを出したとしましょう。先方に予算が無ければ、AWSを使える方向で調整してくれるはずです。また、作業を開始してから「やっぱりAWSダメです」と言われた場合、再見積もりで追加請求する口実にできます。
「lisp 今更」「lisp 不人気」「lisp 現在」等でググってみてください。たいていの答はそこにあります。
というのは、「そんなの、ぜんぜん大事じゃないよ!」の最右翼がlispだからです。
何か書いたらそれが変数でイイじゃないですか。我々はコンピュータを使っているので、計算する時は数字、文字列と扱いたければ文字列だとコンピュータに解釈させればいいんです。
改行など気にする必要はありません。区切りはスペースでイイじゃないですか。前から順番に読むとは限らない? 演算子の優先順は? そんなの、カッコで括ればすべて解決です。
おおっイイじゃん! と思えばそのまま突き進めばよいです。ええっコレかよ・・・と思ったなら、それがそのまま回答の裏付けになります。
まず、そもそも論としては、面倒なデバッグ作業が必要となるようなプログラミングはしてはいけません。
小さい単位で疎結合となるようにモジュール化して、モジュール単位でテストして完成させていくみたいな、いわゆる「定石」にしたがってプログラミングすれば、「面倒なデバッグ作業」が発生することは基本的にありません。
つまり、もし「面倒なデバッグ作業」が必要になってしまったとしたら、その人のプログラミングのやり方はどこかおかしい可能性が高い（改善の余地がある）ということを意味しています。
とは言っても、現実には、環境の制約とか、単に面倒とかいろんな理由で理想的なプログラミングのやり方ができないで、その結果、「面倒なデバッグ作業」が必要になることはあります。
そして、そうなったときの「デバッグの面倒さ（かかる時間）」は、はっきり言って、人によって全く違います。「優秀なプログラマーの生産性は一般的なプログラマーの10倍以上」みたいなことを言われることがありますが、こと、デバッグ（とくにバグの原因特定）に関しては、優秀なプログラマーと一般的なプログラマーとの差は軽く100倍を超えると思います。デバッグほど、プログラマーとしての経験やセンスの差が残酷なほど如実に表れる作業はありません。（だからこそ、一般的なプログラマーは、デバッグを可能な限りしないですむようなプログラミングのやり方をするべきです）
ものすごく身も蓋もない言い方をすると、ブレークスルーを生み出すような一人の天才が世の中に必要であるのと同じくらい、「束になっている天才ではない人たち」も世の中に必要です。天才だけでは世の中は回りませんからね。
ちなみに私は前職では研究開発部門のトップをやっていて特許管理などもやっていましたが、私自身は発明して有名になることにはあまり興味を持てず、ビジネスの前線でバリバリ仕事をしたいという気持ちが次第に強くなり、転職して今は経営に近い立場で企画や開発をやっています。
ここでそもそも論な話をすると、プログラマーも含めてエンジニアという職業は、世の中の人が困っていることを解決するのが本来の役目であって、別にエンジニア同士が戦うことが仕事ではありません。日々勉強をしていると言っても学校で受験勉強してるわけじゃないですからね。なので、あまり競争意識ばかり強いと、世の中の役に立つという本分を見失ってしまうんじゃなかろうか、と思ったりしています。自分のスキルのことばかり考えて世の中の人が何で困っているのかを知らない人は、単独では何の役にも立ちません。Googleの検索エンジンにしても、世の中をどう良くしていくかということに関する創業者たちの立派な理念があってこその発明だったからここまで普及したわけです。単に技術的に優れているだけではダメなのです。
私はもともとビジネス寄りの思考をする商売人タイプなので、エンジニアが世の中のことを深く知ろうとせずに内輪で技術的な知識を競っている様子を見ると、どうしてもコップの中の争いに見えてしまいます。
「束になっている天才ではない人たち」は、単なる「天才でないその他の人々」ではなくて、「世の中のあらゆる現場の役に立つために仕事をしている実行部隊」なわけですから、各自がそういうエンジニアとしての存在意義をしっかり意識することが大事だろうと思います。
意味はあります。
「最初はなぜ動くのかよく分からなかった、だけどプログラムを書き続けてたら分かってきた」
というのは実際あり、手を動かすことに意味はあります。
しかしそれは、その裏に理解したいという感情があるからこそです。
理解したいと思っていないなら、脳は情報の収集をしません。
また、学習のレベルには「抽象理解と具象理解」があるように思っています。
端的に言えば、
- 抽象理解 ・・・ 表面的に何をしているか理解しているので使用したり、技術力によっては同じようなものを作れる
- 内部理解 ・・・ 内部的に何をしているか理解している
ということがあります。
具象理解の方が理解はより深いです。
例えばあるライブラリを使用するにあたって、そのソースコードまで読んで理解している場合です。
このレベルまで達するのは、よほど頭が良くないと時間がかかります。
もし、具象理解のレベルまで達している同僚がいれば、その道のエキスパートであり非常に頼れる存在でありますし、学ぶことも多いのでとてもラッキーです。（というかQuoraにはそんなヤバい人たちがたくさんいます…）
一方、抽象理解は、ソフトウェアのアーキテクチャやインターフェースの意味を理解していて、技術力によっては真似たモノを作ることも可能です。
真似たモノを作る過程で、対象のソースコードを読んで、具象理解に至る場合もあります。
それぞれ「ココからココまで」という線引きはないのです。
しかし、昨今のソフトウェアは総じて抽象理解がしやすく、簡単に利用を開始できます。
抽象理解だけでもしていれば、うまく活用して新しいプロダクションを生み出すことができます。
裏を返せば、最低限の抽象理解は必要ということです。
よって、理解せずにお金をもらうプロダクションに反映するのはまずいです。
「なぜ動くかわからないけど、動いた」
のレベルが、
○「中身までは流石に知らないけど、動いてることは確認している」
ならいいんですが、
☓「よくわからんけど、とりあえず動いた。なにしてんだこれ。」
というレベルではプロダクションとしてデリバリーできません。
抽象理解に至るために、トライアンドエラーでプログラミングをすることは決して悪いことではないですし、新しい技術を導入したり他人のコードを読み解く上で、仕事中でも向き合う瞬間は必ずあります。
重要なことは、「今わからないこと」ではなく、「わからないことをわかるようにする」という、苦しい工程に慣れ、思考力を養い、仕事や普段の学習に活かすことです。
これは面白い質問ですね。
かなり労力を要しますが、「自分なりの解釈で実際に自分で作ってみる」というのはIT業界で超有名な人がやっています。 完璧なものを作るのが目的ではなくて、あくまで学習目的でやるそうです。
例えば、Web Serverだったらセッション管理の大切さ、HTMLを読み込んで表示する手順など、かろうじて動く程度でよいので自分なりにチャレンジしてみるのです。 そうすると、プロが作ったものをみて「なるほどね！」とか「その手があったのか！」と思いながら頭に入れてゆくそうです。 私が尊敬しているJulia Evans(Kubernetes Projectのmaintainer)さんもこの方法で学んだそうです。
あと、前職のAdobeにいた頃、Day Softwareという会社が買収された際にそちらのサポートチームと少し働いたことがあります。 なぜか、彼らは下手な開発より１０倍優秀なのです。
質問してみると、採用試験で「自分なりにJavaでWebサーバを作ってみて。簡単なのでよいから」と言われたそうです。 愕然としたのを覚えてます。 理解のレベルが違うわけです。 「やってみるとできちゃうもんだよ。 時間は掛かるけど、おまえも試してみれば？」と言われましたが、今日に至るまでやったことはありません。。。
というわけで、高い目標を持っているならWeb Serverはいかがでしょう？ 丸々でなくても、例えばレンダリングの部分だけ作ってみるとか。
参考にならなかったらごめんなさい。。。
1文字間違えて何時間も無駄にするとかですかね・・・(syntax errorならすぐわかるんですが)
安心してください。世の中には２種類の人がいます。
プログラムが書ける人と書けない人です。
あなたはプログラムが書ける人（プログラマー）です。
後は自分用のサンプルソース（逆引き事典）を作りましょう。こうしたいときにはこういうコードを使うという小さな動いたコードをメモっておくやつです。ブログなどを使うと検索が楽でいいですね。
そうすれば早く組めるようになります。
だいたい早く組めるというのは自分がかつて組んだことがあるからなんですよ。
実際に自分が使っている言語用の「逆引き事典」を買って、自習しておくといいかも知れませんね。
どの言語でも必ず「逆引き事典」はあります。ネット上で公開されているかも知れません。
そういうのを覚えていけばプログラムを書く時間は早くなりますよ。
とりあえず、目の前にあるもの、今からすること、全て「もっと楽にするには？」と、考えるクセをつけたらいかがでしょう？ｗ
私の中では、爪切りと散髪が果てしなく無駄なのですが。いやじゃーハゲにしろよと突っ込まれるとさみしいので散髪は除外してもいいんですが。
次にトイレと風呂と、そして食事ですね。なんで繰り返さないといけないのか？回数は減らせないのか？
と、普通考えますよね？（普通の定義・・
その延長でNETFLIXからアマプラに切り替えたりすると、あーもー統合ソフトねぇかな？と。
つくっちゃう？とか。
なんか生活の中で無限にある「めんどくさい」もの。というのを洗い出してみたらいかがでしょう？
めんどくさがらず黙々とするのが当たり前の人達もいらっしゃるので、そちら系の方ですと難しいかもしれませんが。
私などは爪切りとか産まれて何度目の詰めきりなのか。無駄でしかない。どうにかしたい。と、子供の頃タンパク質をとらなければいい！と母に進言したのですが、強烈に却下されましたがｗ
そのレベルで「めんどくさい」事をどうすればやらなくてすむか？というのをプログラムで解決できるなら。（それ以外でもそれ以外の方法でできるなら）と日々、四六時中考えてると、ネタはむしろ無限大にあると思いますよ。
もっともっとめんどくさがる事です。
いや、一生カロリーメイト食ってろ。なんてツッコミは禁止ですｗ
食事はめんどくさいけど、食事を楽しむ事は楽しみたいのです。（どっちだ？ｗ
そんな矛盾をかかえつつ生きてればプログラムのネタに困る事はないです。
今自作してるのは、アルコール検出とCAN通信で車の車速を抜き出してスマホ転送してそのままWebサイトに飛ばす（位置情報も付与して）のを暇つぶしにやってますねｗ
プログラミングにおいて完全にマスターというものはありません。
常に新しい技術が出でくるし、使えなくもなっていくので常に勉強し続けなければいけない分野なのです。
検定試験のようにこれを取れば将来安泰なんてこともありません。
しかし、一人前と呼ばれるまでの期間はおおよそ設定されています。
これはプログラミングに限った話では無いのですが、 10000時間が最低ラインだと言われています。
何事もこれぐらいの時間をこなしていれば、1人前だと問われるレベルまで達することができます。
1日8時間やっても、3年弱かかる計算になります。
プログラミングの場合コードをかけるようになるだけじゃなく、その世界に触れている時間も重要になります。
もちろんこれだけの時間をしなくても、等の言語を集中的に学習すればある程度は書けるようになります。
しかしプログラミングは多くの要素が絡み合うものです。
したがって生半可なものでなく、ある程度の時間こなすことが重要だと私は考えています。
問題ないと思います。かくいう私がプログラミングをすることを目的としてプログラミングをしています。
ここでは、プログラミングすることを目的とするということを、何を作りたいとかはなくて、ただコーディングすることが楽しくて、それを目的としてプログラミングを勉強したい、ということだと解釈します。これをプログラミング目的論としておきます。
よく言われるのが、プログラミングを使って何を作りたいかを考えないといけない。プログラミングは所詮道具だ。みたいな話です。これを成果物目的論としておきましょう。
成果物目的論には、プログラミングは言語の文法や仕組みなどをただ勉強するだけではつまらなくて、挫折しやすいといった背景があると思います。
そのため、自分の身近にある問題を解決することを目的としてプログラミングを勉強したほうがモティベーションの維持がしやすく、上達にもつながるということです。
しかし、ただパズルを解くみたいにプログラミングを楽しみたいというプログラミング目的論の立場に立つ場合、役に立とうがたたまいが関係ありません。プログラミングをできればいいわけですから。
ところが、何かつくるものがないとプログラミングができませんから、必然的に成果物を適当に定めて書いていく必要があります。そこで、一番身近で書きやすい成果物が、自分の仕事や生活を便利にするプログラムになります。
結局、何か作らないといけないのです。巷で言われる成果物目的論とプログラミング目的論では、そのモティベーションの主たるものをどこに置くかが違うだけで、やることは変わりません。勉強を続けることが出来さえすればいいのです。
役に立つものに興味がわかず、プログラミングをただしたいというのであれば、競技プログラミングとかをやったほうが楽しめるかもしれませんね。
以下に競技プログラミングの参考記事を張っておきます。
競技プログラミングって何？ (はじめての高校生向け) - Qiita
——————————————————-余談
最初に私は、プログラミングを目的としているといいました。どういうことかというと、プログラミングする必要がないこともプログラミングをしながら仕事をしています。
ちょっとしたファイルの作成や計算もプログラミングをします。プログラミングをしなくてもできる仕事をあえてプログラミングをします。なぜなら、プログラミンをしたいからです（笑）
コーディングをするのって、パズルを解いているみたいで楽しいんですよね。ちょっと時間がかかっても、コードを書いてこっそり楽しんでいます。こうやって、日常的にプログラミングをすることで、自分の上達にもつながりますし。
あくまで、手段としてプログラミングをしている人はこんなことしないと思います。どうしても、プログラミングじゃないと解決できないから仕方なく使う。みたいな感じだと思います。
どっちがいいのかなぁとも思いますが、私みたいに必要がなくてもプログラミングをしてやる！という、ある意味変態のほうが上達は早いのかなとおもいます。
どういった環境でどこまでの範囲をプログラミングと呼んでいるかが不明なので、どんな答えを書いても一面的なものになりそうですが、私の経験ベースでの一般論を書きます。
プログラミングというのは単純作業ではありません。
システムを作る場合、以下のような分類ができる作業があります。個人でのプログラミング開発では、明示的に下記のような作業を意識するわけではないですが、まともなシステム作るためにはどの作業についてもなんらかの意識をするものです。
- 要件定義（システムはどのような機能を提供すべきか）
- 外部設計（システムがどう動くべきか）
- 内部設計（機能を実現するためにどのような実装が必要か）
- 実装（コーディング作業）
- テスト
- リリース
世の中でプログラミングと言ったとき「実装」だけを指すことは稀ですし、実装でもプログラムの構造をどうすべきか？ということは考えるのが普通です。そして大抵は内部設計を伴います。設計は基本的に複雑な作業です。ですので、単純作業ではありえません。
なお、私は見たことがないのですが、かつては（今もいるの？）詳細設計書としてコードの1行1行に対応するような文章が書いてある設計書を渡されて、それをコードに落とし込むだけという仕事をしている人がいたそうです。
そういった作業であれば、単純作業と言ってもいいかもしれません。
私は見たことがないですし、現代においてはそんな詳細設計書を作る暇があったらコードを書けばいいと思うので非効率すぎると感じますが。
大きなプロジェクトで炎上してるとそういう人が割とゴロゴロいるのですよね。「人が足りない！」とかで人が来たのに忙しいと言ってギアを合わせる努力もしないで放置してしまうので、まったく進捗に貢献できない人が出てしまうのですよね。それで「使えない」とか言ってしまう残念な状況はよくあるかと思います。
ご自分ではどうにもならないかもしれませんけど、どうせ何もできてないのでしたら、テストからやらせてもらったらどうでしょう。
テストはだいたいは動く状態になってて、テスト項目をあげて、動かすとダメな部分があったりするわけですよね。自動テストなら自動テストを書けばいいと思います。誰かとペアにしてもらってその人が今日書いた部分を確認するとかもいいと思います。
最初は「こうすると動かない」というテストケースをあげるだけでいいわけですけど、余裕が出てきたらソースも見せてもらって「これだから動かない」という原因も一緒に見ていくようにすると、だんだんプロジェクト全体のことも細かいアーキテクチャも理解できてきて、それから「簡単な修正なので直しておきましょうか？」といったお仕事から開発に入るとスムーズではないかと思います。
19歳(2000年)でWeb系のプログラミングを始めて、投稿時点で23年ほど経っています。
始めた当時と現在を比較すると、情報環境や言語の流行り廃りの変遷も大きく、「大体なんでも」が何に当たるかの感覚やしきい値が人によって違いがあると思いますので、あくまで参考値としてご覧ください。
n時間 というよりかは年単位です。
- 1年目 趣味ベースの簡単なHP、メールフォームや掲示板プログラムの作成、共用サーバを使用した公開
- 2年目 社会人となる。金融機関向けのローン計算プログラムの作成、専用サーバの設定
- 3年目 某猫のキャラクターが有名な会社の公式サイト向けシステムの開発、プリンター会社で社内検証ツールの改修
- 4年目 某ポイントサイトシステムの開発、データセンター運用
- 5年目 某ポイントサイトシステムのネットワーク入れ替え作業
プログラミング単体で見れば3年、データセンターのインフラも含めると4-5年、という感じでしょうか。
現在はそれらの経験を元にし、金融関係のシステムを一手に受けて、インフラにプログラミングにHTML/CSSコーディングにと幅広く対応していますが、浅く広くやっているため、その中でも手が届かない領域があります。
そうなると「なんでも作れる」と言い難いことになり、23年を経過してもまだできていないことになります。
業務システムならば、原則としてロジックの可読性が処理効率 (性能) に優先します。それは業務が移ろいゆくものであるため、コードは業務変遷に伴って生じうる改修に耐えうるものでなければならないからであり、一方で、多少の性能劣化はハードウェアの高性能化でカバーしうるからです。
しかし、どのような場面でも可読性が処理効率に勝るかというとそうではありません。
たとえば、ユーザ入力値に基づいて一定のデータをデータベースから抽出するとします。データベースのデータにある変換を掛けたものがユーザ入力値とマッチした場合に抽出対象とする、と業務的な意図に忠実に従ってロジックを書いてしまうと全件検索が走ってしまい、一定時間内にレスポンスを得られないという状況に陥ることがあります。このような場合は、ユーザ入力値の側に逆変換を掛け、それがデータベースのデータにマッチするか否かを判定するロジックを書き、DBMS の効率的なデータ探索アルゴリズムを活かします。
逆変換のようなものを掛けてチューニングを施すとコードの業務的な意図が分かりにくくなり、可読性は毀損しますし、改修、汎用化、拡張などその後の応用・展開がしにくくなります。このような場合にはコメントを付して、その可読性の毀損分を補うのが望ましいでしょう。
物事はすべてトレードオフです。コーディングにおいては可読性と性能（さらに汎用性・再利用性・拡張性と性能）は常にトレードオフの関係にあります。
そして、設計とは、さまざまな制約と要求の双方を勘案しつつ、トレードオフの関係にある二者の間で適切にバランスを取ることそのものなのです。どちらか一方を好みに従って選べばよいというものではありません。
基本は計算量(O(n))です。計算量O(オーダー)ぐらいは理解しないとどうしようもありません。
O(n)は、データ量が多くなると、そのデータ量分処理時間がかかる、という意味になります。O(n^2)とはデータ量の2乗かかることを意味します。
それらを早くするためには、ループ処理を削減するとかして、計算量を減らすことをまず考えます。
例えば、O(n^2)になるのは二重ループをするからです。2重じゃなくて、一回ループして終わりになるように処理を変更すれば早くなります。
もちろん上記は一例なのであって、実行速度を上げるためには、自分が何をしているかをちゃんと理解することが重要だと思います。
O(n)でも遅いなら、ループしている処理をCPUごとに割り振ってしまえば早くなります。それらは並列処理といい、実行速度を早くするのに使われる手法です。
ただし、計算量以外の方法は、なんらかのトレードオフがあります。並列処理は思うほど簡単ではありません。O(n)をO(1)にする方法はありますが、その分メモリ容量を使用することになります。
ということで、実行速度を上げるなら、まずは計算量程度は当然クリアし、後は計測その他方法で、いったい何で実行速度が遅いのかを把握する必要があります。
何が遅いかが分かって、初めて具体的な方法が分かります。
上達し得るものは目的になります。
人生の目的は、成長することです！みたいな人は多いです。
はい、使い捨てのつもりでやれば早くできます。
例えばクラスなどを作らずべた書きする、変数名などを短い意味の無いものにする、エラー処理を省く等、クオリティに必要な事項を排除してとりあえずの目的を達するだけのプログラムを書くなら早くできます。
再利用やメンテナンスに不具合を生じるので、使い捨てである場合、障害やセキュリティ対応作業などで相当急ぐ必要がある場合以外には行いたくはありません。
ノーコードとは最近良く聞く用語ではありますが、定義が今ひとつ明確ではありません。
ノーコードを謳う製品では、ある種のパラメーターを入力すると、それに合わせた動作をするソフトウェアである場合が多いように見受けられます。あるいはビジュアルなインターフェースで部品を並べることでソフトウェアを構築できる製品もノーコードと呼ばれるみたいです。
このようなツールの最大の欠点は、柔軟性のなさ、あるいは言い換えると適用範囲の狭さです。パラメーターを入力するタイプのものは、表現できるソフトウェアの幅が限定的です。任意のソフトウェアをこれで作れるわけではありません。ビジュアルなタイプのものは、部品さえあれば作れるが部品がなければ何もできないものと、任意のソフトウェアを記述できるがある程度複雑になると記述が爆発して手に負えなくなる(ので、結局は任意のソフトウェアを作れるわけではない)ものであるような印象をもっています。
もちろん、今後ノーコードのツールが発展して上記のような制限や不満を解消しないとは言い切れないのですが、現時点では柔軟なソフトウェア開発にはノーコードでは足りないというのが正直なところではないでしょうか。
ですから、ノーコードでカバーしきれない領域は限りなく存在し、その領域に対応するためにはプログラマーは今後も必要とされると思います。
もっとも、たとえばFORTRANが初めて登場した頃には「これは自動プログラミングである」と言われたそうですし、確かにそれ以前のアセンブラやマシン語直接入力のプログラミングに比べたら格段に省力化ができたのだと思います。そういう意味で、プログラミングの進歩は省力化にあり、未来への進歩の選択肢のひとつとして、いわゆるノーコードのツール(の延長線)があるのかもしれません。
旧来のプログラミングに慣れきった私としては、今から制約の多いノーコードツールに移行するつもりは(少なくとも現時点では)ありませんが。
私の知る限り、その言葉の初出は『バッドノウハウと「奥が深い症候群」 』です。
何でこんなことを覚えないといけないのだ ろうか、とストレスを感じつつも、それを覚えないとソフトウェア を使いこなすことができないためにしぶしぶ覚えなければならない、 といった類いのノウハウは多い。そうした雑多なノウハウのことを、 本来は知りたくもないノウハウという意味で、私はバッドノウハウ と呼んでいる。
とにかくコンピューターというものが初めて市販されたので、何もかも新鮮な体験でした。
今から40年くらい前ですね。
プログラムを打ち込むとその通りに動くのが面白くマニュアルがボロボロになるまで読んでいました。
言語はBASICでしたね。こんな画面です。
オルゴールが一番直感的にわかりやすいかもしれません。ドラム上の突起が櫛状の鉄の板を弾いて、様々な和音からなる曲を時系列に沿って奏でます。ドラムを入れ替えれば曲が変わります。
ドラム上の突起がプログラムで、オルゴールがコンピュータで、プログラムの出力が音楽ですね。
オルゴールの次の段階としては、ジャカード式織機があります。パンチカードのような制御の板紙を制御入力として、様々な模様の布を作り出します。
ジャカード織機はパンチカードを用いて制御を行った機械である。この方式は、カードを入れ替えることで布の模様、すなわち織機の操作パターンを簡単に変えられることから、その後計算機や集計器（タビュレーティングマシン）に応用されることになり、コンピュータの歴史の上でも重要な発明である。まず19世紀半ばにチャールズ・バベッジが解析機関のプログラミングへの利用を試みた。解析機関は実用化されなかったが、後にパンチカードによるタビュレーティングマシンへの入力が実用化され、さらに後にコンピュータへの入力方式として20世紀後半まで広く用いられた。
これは事実上のコンピュータの機構上の祖先となります。織り機に設定された糸やバーを操作するのではなく、そろばんのたまを移動させれば、あとは、そろばんを使っての自動計算ができそうなのは想像できるのではないでしょうか。具体的には、そろばんの玉ではありませんが、歯車を使って実現したチャールズ・バベッジの階差機関や解析機関がそれに当たります。
階差機関（かいさきかん、difference engine）または差分機関（さぶんきかん）は、歴史上の機械式用途固定計算機で、多項式の数表を作成するよう設計された。対数も三角関数も多項式で近似できるため、そのようなマシンはかなりの汎用性があった。
解析機関（かいせききかん、analytical engine）は、イギリス人数学者チャールズ・バベッジが設計した、蒸気機関で動くはずだった機械式汎用コンピュータであり、コンピュータの歴史上、重要なステップを刻んだ
…
その機械は扱いにくかったが、現代のコンピュータと基本的アーキテクチャはよく似ている。データとプログラムは分離されており、命令に従って動作し、演算器は条件分岐が可能で、本体とは別に入出力装置を備えていた。
…
解析機関はジャカード織機のパンチカードのループで計算機構を制御し、前の計算結果に基づいて次の計算を行うことができる。逐次制御、分岐、ループといった現代のコンピュータのような特徴すら、いくつかを備えている。
原理としてはだいたいはそれで十分で、あとはそろばんにあたるものを歯車からリレーや真空管やトランジスタや磁心に置き換えるとコンピュータになります。
「だいたいは」と言ったのは、もう一つのブレイクスルーであるストアドプログラム方式が重要だからです。解析機関ではプログラムとデータは別扱いでしたが、ストアドプログラム方式ではプログラムをデータとして主記憶に配置します。制御入力としてのパンチカードに当たるものを、メモリ上に持ち、データと同じく読み書きするということです。ストアドプログラム方式を考案したのは、かの有名な天才科学者フォンノイマンです。
参考
どこにミスがあるか、一件一件点検していく作業
どこかにミスがないか、一件一件点検していく作業
解決方法を延々と探す作業
それらが深夜まで続くこと
機械いじりや職人に近いんですが、常に分からないことや新しいことと向き合うためいつでも素人のような反応になってしまいます
気持ち悪いです。なのでソースをじっくり見てみたら、どう考えても動くはずが無いじゃんこれ、と気づいてしまうことがあります。その途端、動いていたそれが動かなくなります。観測した途端にバグが確定するので、シュレーディンバグ
と呼ばれます。そういうことがあるので、気持ち悪くても波動関数は無闇に収束させない方がいいです。
.
.
.
.
.
.
.
真面目に答えると、自分の書いた範囲では「動くべくして動いている」状態でないと落ち着かないですが、ブラックボックスなコンポーネントが入ってきたり本質的に非決定的な動作があると、「こっから先は見えないけれど信じるしかない」って境界はありますね。
なおシュレーディンバグは過去何回か経験したことあります。おそらく(1)当初実行していたプログラムは手元のソースからコンパイルされたものではなく、バグ発見後に再コンパイルしたものが動かなくなった、とか(2)当初動作していた環境と、バグ発見後に検証した環境で条件が違ってた、といった理由だと思いますが、実際に遭遇すると実に不思議な気分になるものです。
脚注
今まで作られたシステムへの機能追加。
自分のコードを読んでる時間が一番ながいかも。次がチームメイトの書いたコードで、残りのわずかが、他人のコードです。
書いてる時間はわずかです。
自分ができるプログラマーかどうかは知りませんw
上流工程を「やる」が具体的に何を指すか、によると思います。
全く触れない、興味関心も持たない、上から流れてくる仕様を、純粋にプログラミング言語に翻訳するだけの仕事をしたいという考え方であれば、その人の将来を考えると「お勧めしない」とアドバイスせざるを得ません。
なぜならば、プログラミング対象である何かしらの「仕様」や「要件」の深い理解なくして、よりよいプログラミングは行えません。全ての設計を上流工程に任せるのなら、それは正直「数年プログラミングをやったぐらいの、初心者を脱した程度の人」でも行える仕事です。年齢を重ねるにつれ「あの人でなくてもよいよね？給料も高いしコストかかるから、別の人にやってもらおう」ということになると思います。
一方、上流工程の仕組みや考え方も理解していれば、指定された仕様について「その意図」が判るようになるので、最新の下流工程が判らない設計者のやりかたを程よく「今のやり方」に置き換えつつ、要件を満たした最善の方法を採るといった選択や細かい実装手法の切り替えが可能になります。そのためには、アプリやシステムの利用者がどのような人で、どういう交渉ややりとりが上流工程で行われ、どのような意図でその設計がなされたのかを汲み取る必要があり、そのために上流工程について知るということが必要になります。
なので、上流だろうが下流だろうが、開発工程を一通り最低限こなすくらいの知識や経験は積んだ上で、「その中でも自分はこの工程を担当する」と、数ある工程の中からプログラミングという泥臭いけれど必要な仕事を選ぶ。そういう気持ちで取り組める人が、将来的に幅広い仕事を担当でき、柔軟な実装や、新しい技術やその業界のトレンドなどにも眼を向けられる余裕のあるエンジニア、プログラマーになりうるのではないかと、私は考えます。
あくまで、一個人の意見なので参考程度に見てもらえれば幸いです（正解かどうかはわかりません）。
0 コメント:
コメントを投稿