プログラミングが速く組めるようになる初歩的な3つの心掛け - 遥か彼方の彼方から

プログラム雑用兼プログラマーとしてアルバイトしていた頃のこと。僕の最初の悩みは、どうすればもっと速くプログラミングできるか、でした。訳あって3時間ほどしかバイト時間を確保できなかったうえ、雑用もしていたので、気付くとほとんどコードを書かずに一日が終わるなんてこともよくりました。急がなくてもいいとは言われてはいたものの、プログラミング能力が低くて、要領も悪い僕としては、せめて時間内に終わらせられる程度にはプログラミングが速くなる必要があったのです。とはいえ、すぐにプログラミングが上手くなることなんて出来無い。だからせめて、プログラムで詰っている時間を減らせさえすれば、今よりもよくなるんじゃないか、とそう考えるようにしました。そう意識してからの作業は徐々に速くなり、最終的になんとか仕事についていけるようになっていたかなと思います。ということで、前置きが長くなりましたが「プログラミングが速く組め

[fusionstar]

「プログラミングが速くなる」と「プログラムが早く組めるようになる」がごっちゃになっている気がする。

[fumokmm]

みんなこのくらいは普通にやってるもんだと…

[Crimson_Apple]

TDDの根本的な考え方なんじゃないかなと思ってみたり。

[ystream]

あるある。ただ、テスト書くようにプログラミングすればこの問題は全部解決すると思うんだ。あんまりできてないので言うのが憚られるけれども。

[fujipara]

プログラミング以外でも心がけておくといいんじゃないかな。

[otchy210]

これはこれで分かるんだけど、デバッグ環境が充実してからは、ある程度の機能を一気に書いてから動かして、問題箇所を修正する方が早いと思うようになった。もちろん、実装の単位は細かいのだけど。

[ku-kai27]

詰まった、その時に。

[kireifish]

1.少しずつ確認する 2.問題を小さくする 3.何をしているか理解する

[northlight]

日本語が・・・

[matsuko1103]

なるべく小さい単位にわけてやるっていうのは、むしろそういうふうにしかできないからやっていたりする。見てる方は多分イライラしているのだろうけどｗ

[takehikom]

『1. 少しずつ確認する』『2. 問題を小さくする』『3. 何をしているか理解する』

[takigawa401]

アジャイルですなぁ。事前にテストコードまで書くとTDDになるんじゃないかと思われ。

[koogawa]

うんうん。1.は自然に身に付くよね〜

[iwasiman]

みんなTDD連想してますねｗ　細かい処理単位でメソッド化してテストで動作確認、問題発生箇所切り分けを容易に、この繰り返しでより大きな単位の動作保証……みんなやってるんじゃないかな。

[tmatsuu]

自戒を込めて

[doroidpanic]

「仕様をエスパーしないよう」　⇒　いいね！ｗ

[richard_raw]

これがTDDだ！

[katanttk0221163]

参考になりました。

[warriorking]

プログラミングが速く組めるようになる初歩的な3つの心掛け - 遥か彼方の彼方から

[baroclinic]

さすがやねー。さすがやのー。

[myrmecoleon]

「そもそも何をしないといけないのかを理解していなければ、ろくにプログラムは作れない」うむうむ

[ymoage]

それでも一気に全部コーディングして紙に打ち出し「机上デバッグ」を行ってからコンパイル（ビルド）するのがCOBOLer

[kazusap]

みてれぅ: プログラミングが速く組めるようになる初歩的な3つの心掛け - 遥か彼方の彼方から

[manji6]

開発イテレーションを自分の中でも小さい単位で区切るってことですね。

[tamu222i]

仕様をエスパー

[lettas0726]

TDDもこんな感じだったとおもう

[skoji-jp]

テスト駆動開発を再発見してるみたい

[luccafort]

基本っちゃー基本。

[zentarou]

テスト駆動で万事解決

[Tomato-360]

参考になりそうだ

[GegegeMokeke]

細かく作業記録をつけるようにすると自然にこれができるようになる。

[bekifuu]

「GTDがうんたらかんたら〜」ってブコメで書く人出てきそう感あるエントリー