• 人気のコメント(10)
  • 全てのコメント
LukeSilvia LukeSilvia 最初に修正イメージを練る。あとは小さな変更を積み重ねる形で作っていく。修正中でも正しく動く状態を維持するのが目的。修正イメージを練る部分と上手く動作しないときの原因究明のスピードが大事だと思う

2017/04/10 リンク

JHashimoto JHashimoto “わけがわからなくなったら全部を捨ててやり直すこと。これは私もよいことなのかどうかはわからないのですが、私はある程度苦戦したらパッチ全体を捨てて元の状態からやり直しています。”

2016/08/13 リンク

sylvan_l sylvan_l ソースコードって実際のところどういうふうに書いていますか? | Rui Ueyama | note

2016/08/09 リンク

fujimuradaisuke fujimuradaisuke 大体同じ。先にクラスなりモジュールなりのAPIだけ書いて眺める、というのもよくやる。しっくり来るAPIになったら大体うまくいく。しっくり来ない場合は抽象化やモデルが間違ってる場合が多い

2016/07/22 リンク

Nobkz Nobkz 5千~1万行一気に書いてコンパイルして開発してる。

2016/07/20 リンク

Dai_Kamijo Dai_Kamijo "小さな変更を積み重ねていくことで最終的に構想通りの変更を行う" "なるべく何も壊さずにインクリメンタルにゴールまでたどり着くのが目的で、途中のコード量を削減することは特に目的ではありません"

2016/07/19 リンク

hamasyou_bot hamasyou_bot メモ: ソースコードって実際のところどういうふうに書いていますか?|Rui Ueyama|note(ノート)

2016/07/19 リンク

t-wada t-wada "小さな変更を積み重ねていくことで最終的に構想通りの変更を行う" "なるべく何も壊さずにインクリメンタルにゴールまでたどり着くのが目的で、途中のコード量を削減することは特に目的ではありません" とてもわかる

2016/07/19 リンク

richard_raw richard_raw オーソドックスなやり方じゃないかしらこれ。/私の場合は環境構築とかライブラリの使い方を調べるのが一番時間食ってますな。/たまにフロー状態のときは一気に書き上げたりします。

2016/07/19 リンク

matsuuZatsu matsuuZatsu ソースコードって実際のところどういうふうに書いていますか? | Rui Ueyama | note

2016/07/19 リンク

syogo0417 syogo0417 僕もどうやって書いているのか棚卸してみました。 http://qiita.com/sh-ogawa/items/f2158abbd98cf411f024

2016/07/18 リンク

hfmgarden hfmgarden "ソースコードって実際のところどういうふうに書いていますか? | Rui Ueyama | note"

2016/07/18 リンク

a666666 a666666 面白かった。自分のやり方も改めて整理してみた http://blog.kyanny.me/entry/2016/07/18/184125

2016/07/18 リンク

koheisg koheisg 僕がすごいと思ってるようなプログラマの方ほど普通な方法でプログラミングしているので、基本に忠実にするしかないと思い知らされる。驚くような書き方なんてきっとないんじゃないかな。

2016/07/17 リンク

kamipo kamipo こうすればうまくいくはずだを確かめるために愚直にprintデバッグしまくってるから人に過程を見せるのちょっとはずかしい

2016/07/17 リンク

wow64 wow64 ひらすらエラーメッセージをググってstackoverflowの解決策をコピペします。書きたいこと書いてるより不具合にハマってる時間のほうが何倍も長いので。

2016/07/16 リンク

haruharu1 haruharu1 やりたいことをテストとして書いてそれ通るようにコード書いて、終わったら、さらにやりたいこと書いてリファクタの繰返し

2016/07/16 リンク

tzt tzt 枠組みが固まってる既存コードを変更するときは自分もまんまこんな感じ。ただ、新規開発の最初のコミットは自分でもどうやってるかわからないくらいカオス……(その過程は全てfirst commitにまとめられて闇)

2016/07/16 リンク

abababababababa abababababababa ブコメ、ためになる。

2016/07/16 リンク

rin51 rin51 まずフォントを選びます

2016/07/16 リンク

psfactory psfactory ソースコードって実際のところどういうふうに書いていますか?|Rui Ueyama|note

2016/07/16 リンク

tana005 tana005 これ、あとで読む

2016/07/16 リンク

to4iki to4iki “数行といったレベルごとにコンパイルとユニットテスト実行”

2016/07/16 リンク

GOD_tomato GOD_tomato 失敗をわざと冒してから進む

2016/07/16 リンク

snowcrush snowcrush 自分のやり方とよく似てるんだけどこまめにコミットするところが出来てないことが多いな。なので無駄になんども書きなおすことが多い。気をつけよう。

2016/07/16 リンク

reijikan reijikan 慎重にやるときは、書く前に仕様をよく考える、かな。このとき紙で乱雑に書きまくることも多い。

2016/07/16 リンク

hogeanonym_20101012 hogeanonym_20101012 どこから始めるかで少し悩んで、書き出したら一気にカチカチと。自分は文系脳なんで、ちょっと作文を書くのに似てる。

2016/07/16 リンク

rti7743 rti7743 みんなそうやっているんじゃないの? 細かい範囲で動くことを確認しつつ、できるだけ動く状態を維持しつつ、バックアップを定期的に取りながら、失敗したらすぐに戻せるようにする。それ以上の方法はないと思う

2016/07/16 リンク

otchy210 otchy210 人の書いたコードに追加する時の基本的な方針は似てる。ただ、スクラッチ (既存アプリの完全新機能でも) からだと、1時間くらいひたすらコーディングに集中して、一気に書き上げるとドーパミン凄い。

2016/07/16 リンク

n314 n314 まず用途別にEmacsを5個くらい立ち上げて、考えながら何行かコードを書いて、それから見積もりを出して待機します。最初の数行のコードが見当はずれなら見積もりがヤバいです。

2016/07/16 リンク

    関連記事

    ソースコードって実際のところどういうふうに書いていますか?|Rui Ueyama|note

    プログラミング結構自信があるんですが、他の人の作業をつぶさに観察したことがあるわけでもないので...

    ブックマークしたユーザー

    • kazkaz032018/03/11 kazkaz03
    • tjun12018/02/24 tjun1
    • mfks172018/01/26 mfks17
    • labocho2017/12/05 labocho
    • msykxxx2017/11/03 msykxxx
    • djfji3ieojfj32017/07/20 djfji3ieojfj3
    • everysick2017/05/10 everysick
    • en302017/04/30 en30
    • LukeSilvia2017/04/10 LukeSilvia
    • cco2017/01/28 cco
    • karahiyo2017/01/22 karahiyo
    • ymmder2017/01/16 ymmder
    • escape_artist2016/11/29 escape_artist
    • rushopenedge2016/11/07 rushopenedge
    • jagua2016/10/29 jagua
    • jitsu1022016/10/19 jitsu102
    • ponpoko042016/09/27 ponpoko04
    • geshisesu2016/09/25 geshisesu
    すべてのユーザーの
    詳細を表示します

    関連商品

    いま人気の記事

    いま人気の記事 - テクノロジー

    新着記事 - テクノロジー

    同じサイトの新着

    Permissionsdispatcher by hotchemi

    1 users http://hotchemi.github.io/

    レノボ製PCのBIOSにゼロデイ脆弱性発覚、修正プログラム準備中。インテル供給のリファレンスコードから混入の疑い - Engadget Japanese

    48 users https://japanese.engadget.com/