もっと早く知りたかったプログラミングのコツは ? 74
ストーリー by reo
他人のコードを読み、他人とコードについて語ること 部門より
他人のコードを読み、他人とコードについて語ること 部門より
ある Anonymous Coward 曰く、
本家 /. 記事にて Ted Dziuba 氏のブログエントリ「もっと早く知りたかったプログラミングのコツ」が取り上げられている。
Dziuba 氏はここ数年スタートアップ企業に関わっているそうで、痛い目にもいろいろ遭ってきたとのこと。その経験から荒削りな知識で何とかするよりも、理にかなったやり方を身につけるべきだと痛感したという。振り返ってみれば「早く知っていればよかった」ことや「意地を張らずに学べばよかった」と感じていることがいろいろあるそうだ。
例えば Linux がカバーできることであれば、自分で開発するべきではなく、「必要以上の複雑化は防ぐ」ということ。また「パラレル処理は『自分がやりたい時』にではなく、『必要に迫られた時』にのみ行うべき」であり、「最新の技術はリスクを考慮すると割りに合わない」とのこと。そして「ハードウェアの重要さを侮るなかれ」とのことだ。
/.J 諸兄方がもっと早く知りたかったプログラミングのコツは何だろうか?
人のソースを読む (スコア:3, すばらしい洞察)
自分も未熟な状態であったときに、人のソースを読んでも意味がわかりませんでした。
もちろん1つ１つ調べていけば理解は出来ていたのでしょうが、自分で書いたものであれば「自分にとって判りやすい」ので人のソースを読むということをしませんでした。
読みやすい読みにくい色々とありますが、いま時間があるときに人のソースを見たりして非常に勉強になってます。
見やすくする方法とか整理の方法とか回避の方法とかで新しい方法とかトリッキーなものを見つける度にもっと早くから人のソースを見るようにしておけばよかったと思います。
Re:人のソースを読む (スコア:2, すばらしい洞察)
これしかないでしょう。
３５年間は有効です。
より短い変えようのないソースが最適です。
逆に、自分が作ったソースを短くできた人には、教えを乞いましょう。
Re: (スコア:0)
Re:人のソースを読む (スコア:1)
過去に自分が書いたのを読むと、可読性の大切さが分かる。(反面教師として・・自分だけど)
the.ACount
始めた頃はIDEも無かったけど (スコア:2, 興味深い)
-- 哀れな日本人専用(sorry Japanese only) --
Re: (スコア:0)
そりゃxUnitは本来コマンドラインから使うツールだったもの。
cproto (スコア:2, 興味深い)
これを知る前はどれだけ無駄に関数の定義のコピペをしていたろう。
大昔なのですが (スコア:2)
大昔、特定業務用の表計算ソフトを作りました。
あの時にyacc/lexを知っていれば、もっと簡単にかけたんですけどね。まあ、CでゴリゴリRPNを生成していったのですが、それはそれで楽しかったです。
＃あれが、Cで本格的（製品）を作った初めてのプログラムかぁ。
逆にその後NeXTを知ってから、その後にでてくるプログラミング技術を画期的と思うことが減りました。
Re:大昔なのですが (スコア:1)
簡単に書けるけど, その後のメンテナンスが全て自分に回ってきて公開するはめになるとか. 製品っていかに古くなっても面倒を見続けないといけませんから.
おお、オープンソースですか。 (スコア:0)
##そもそも、どんな作り方をしても、需要がある限り、作成者は手繰り寄せられてしまいます。
Re: (スコア:0)
yacc/lexって使ったら最後、誰にも引き継ぎが出来ないので一生面倒を見ないといけない。
ってほどマイナーなツールじゃないと思うけど。
Re: (スコア:0)
# まあこれだけが原因ではないハズだけど
Re: (スコア:0)
20年も前にアンテナをたたんでセンスが枯れちゃったんですね。
Re:大昔なのですが (スコア:2, すばらしい洞察)
その時程の衝撃は受けない、というだけかと。
昔に比べて、情報が逐次入ってくるようになってきたので
それなりの規模の技術がいきなりドンっと出てくる事が減ったという
ことも影響しているかもしれないですね。
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
viなんとかを使え、ってことですね。
インタプリタパターン (スコア:2, 興味深い)
というか、インタプリタを書くという発想。カーニハンのプログラミング作法にもあるけど、コードが劇的に減る。
あのときの苦労はしないで済んだはず…。
知らない人のために書いておくと、別に難しくないから。あと、恥ずかしいくらいチープで制限だらけの言語で十分だから。
emacs の dabbrev に類するもの (スコア:2)
かつて便利さに感動したものとして真っ先に思いつくのがコレ。
emacs における dabbrev (動的略語展開) 、もしくは他のエディタの相当する機能、です。
今時のIDEなら、クラスメンバや引数等の自動補完を行ってくれますが、
dabbrev なら極端な話、日本語で書いたコメントすらも補完してくれますので大変重宝しています。
ここに集う方々にしてみれば当然の知識でしょうが、実際にいろんな現場を回ってみると
こういった機能があることを知らない人が結構いらっしゃいます。
ということで、まだ知らぬ方の為に。スペルミスも抑えられるしコーディング速度も上がるし、いいことづくめですよ。
自分の心身の健康の維持 (スコア:2)
自滅した事が如何に多かったことか。
後世の人はますます泥縄 (スコア:2)
上層部のあとは野となれ山となれ
というポリシーに対して
いい加減に作っても、問題が起きたら
後世の人がなんとかしてくれるだろう
と言う期待と諦めで、いい加減な物を
制作してしまう訳ですが。
保守は新規開発より評価されないので
後世の人はますます泥縄で
酷くなることはあっても、良くなることは無い
という現実。
regular expression (スコア:1, 興味深い)
今でも大した技術者には育っていませんが、月並みなところですが「正規表現」ですかね。
当時流行った大量生産系のVBプログラマーでしたので存在も知りませんでした。
たしか掲示板でipアドレスやNGワードでのフィルタを付けようとしたのがきっかけだったと思います。
ワイルドカードしか知らなかった身には、柔軟なパターン設定が可能なのは衝撃的でした。
類似品をコピペする (スコア:1)
納期は延びて行くというマーフィー (スコア:1)
もっと早くperlを知ってれば (スコア:1)
Cで無理くりテキスト処理で文字列比較で悩まなくてもすんだのだろうな。
逆に今、perlでWindwosだとライブラリがシリアルポート115200bpsに対応していなくて悩んでいたりする。
そして、Cではchar使ったライブラリとCStrig使ったライブラリが、そのまま融合できなくて悩んでいたりする。
進捗状況 (スコア:1)
５割の時間を使って５割出来上がってるんじゃ間に合わないんだって最近やっと気づきました。
早かったねぇ (スコア:0)
Re:早かったねぇ (スコア:1, すばらしい洞察)
- SIビジネスには関わるな。
- 技術者だったら日本企業には行くな
- こんなアコギな家業からは30歳になる前には足を洗え
Re:早かったねぇ (スコア:1, おもしろおかしい)
Re:早かったねぇ (スコア:1)
>家業だったらちゃんと次の世代に伝えていかないとな
アコギな家業 [wikipedia.org]？
-- う～ん、バッドノウハウ？
高解像度なデュアルモニタ (スコア:0)
Re:高解像度なデュアルモニタ (スコア:1, おもしろおかしい)
紙のノートに鉛筆でコーディングするのは話に聞いただけで実際に見たことはありません
#ちっこい200LXでちまちまコーディングしたことはあるので AC
Re:高解像度なデュアルモニタ (スコア:1)
昔、シャープがZ80のアセンブラでコーディングするのに適してる枠を印刷したノートを販促グッズに配布してて、授業そっちのけで、それにコーディングしてた甘酸っぱい思い出が…
/* Kachou Utumi
I'm Not Rich... */
Re:高解像度なデュアルモニタ (スコア:1, 参考になる)
コーディングシートというのは既に伝説の存在でしょうか？
まぁパンチカードについては自分らが新卒で入社した頃にこの業界からキーパンチャという職分がなくなってたくらいなので
あまり見かけませんでしたね
１人に１台ちゃんとPC支給されてるなんてなんてどんなにすばらしいことだろうか…
と感動したのも既に昔
それ以前は紙に書いてレビューして承認もらった後で共有PCを奪い合う様にして打ち込んでましたよ
こういうのは冗談みたいに聞こえるのかもしれませんね
Re: (スコア:0)
PB-100 [infoseek.co.jp]でちまちまコーディングしてたからわりと平気です。
Re: (スコア:0)
Re: (スコア:0)
現場のソースコードはいつも複雑なダンジョンだ。
Re: (スコア:0)
※ただし、修正前のコードをコメントアウトして残すという規約がない場合に限る。
※ただし、的確にコメントが入っている場合に限る。
Re:高解像度なデュアルモニタ (スコア:1)
オレは最初にコメント書くぞ。
そしてコメントをコードに変換する。
the.ACount
知りたい (スコア:0)
知るな！ (スコア:3, すばらしい洞察)
カーソル位置の単語を言語名くっつけて検索する仕組み (スコア:0)
単語がfoobarなら
mylang sample foobar
とか
site:www.mylang.com foobar
とか
http://www.mylang.com/search?word=foobar [mylang.com]
とかでブラウザ起動
ローカルヘルプの貧弱なマイナー言語で重宝する
コメントは厄介 (スコア:0)
素人の時はコメントは書けば書くほど良いと思っていましたが
コードをコピペする際に、関係の無いコメントもコピペ拡散して
厄介なことに成ると気づきました。
コピペされる事を前提にコメントを付ければ良いんだ (スコア:2)
とか・・・・・・・・・・
Re:コピペされる事を前提にコメントを付ければ良いんだ (スコア:2)
無理です。コピペするときには
コードの内容は見ていませんから。
似たような機能や画面を探して、どかんとコピー。
ライブラリ化、フレームワーク化の時間がありません。
コピペで進捗したほうが評価されます。
あとは野となれ山となれです。
Re:コメントは厄介 (スコア:1)
それはコメントが悪いのではなく、コピペするのが悪い。
書けば書くほど良いってわけでもないけどね。
ちなみにこの問題はドキュメントだと、なおいっそう悪くなる。
コツではないですが、もっと早く知っていれば・・・ (スコア:0)
優秀としてな人として派遣されてきたのですが、
彼がプログラミングをしてエラーが１つもでなくったが
なぜか動作不安定でなかなか完成しなかった。
ちょっと助けてやってくれって、いわれたのでコードを見てみたらぞっとした
１つ例をあげると
//if(エラー条件){ エラー表示処理 }
のようなコメントに修正、確かにエラーはでないよなｗ
誰かが、「エラーでないように修正してくれ」とかいったんだろうな
もっと早く知っていれば・・・これから大変だ
Re:コツではないですが、もっと早く知っていれば・・・ (スコア:3, すばらしい洞察)
Re: (スコア:0)
try{
//いろんな例外が発生
}
catch( Exception e){
// てけとーな処理
}
くらいならザラです。
＃忙しいのに、SQL例外なのかFileNotFoundExceptionなのか、
＃或いはその他の例外なのかも分からなくてエライ目にあった。
そうだねぇ (スコア:0)
IT土方にならない人生を模索するべきだったことぐらいかな。