優れたコーダーになるための 7 つの手法？ 88
ストーリー by reo
×「優れたコード」○「優れたコーダー」 部門より
×「優れたコード」○「優れたコーダー」 部門より
ある Anonymous Coward 曰く、
優れたコーダーになる為に役立つ 7 つの型破りな Tipsなる記事がある。元ネタは 7 Crazy Tips That Will Help You Become a Better Coder という昨年 9 月の記事なのだが、色々とツッコミどころがあるのでタレこんでみた。
簡単にまとめると、「jQuery などのフレームワークは使うな、Firebug のようなデバッグツールやコードジェネレータも使うな、コードは完成するまでブラウザを使わずに脳内デバッグしろ、解説書のコードを手で書き写せ、エディタには notepad.exe を使え、車輪の再発明をしろ」という主張だ。
一部は同意できなくもないが、これを全部実践したらその苦労の割には使えない人ができそうな気がするのだが……。
'優れたコーダー' ne '仕事のできるプログラマ' (スコア:5, おもしろおかしい)
きっとマス・オーヤマばりの「コーダー バカ一代」が出来上がって、
他の同僚から浮いてしまって辞める羽目になり、
「でも俺は地上最強」って言うんでしょう。
清澄山の山奥にこもって独自フレームワークを脳内デバッグしているうちに人里恋しくなって
片眉剃り落とす…と。
「わはははは、これぞ コーダー バカの顔だ！！」
---- ばくさん！＠一応IT土方
Re:'優れたコーダー' ne '仕事のできるプログラマ' (スコア:2)
案外、外に出て行けるようですよ。
片眉剃って仕事に集中しよう （北村ヂン) (2012.04.11 11:00) [nifty.com]
Re: (スコア:0)
過剰反応。
原文は別にOS作れともコンパイラ作れとも控え目に言ってもコアなライブラリを再開発して書けとも言ってないが・・・
逆にこの程度のフレームワークも解析できないorやる気が無いならコーディングを続けても自分の掘った穴に落ちるばかりという気もする。
何故ない！！ (スコア:3, おもしろおかしい)
本物のプログラマは pascal を使わない (スコア:4, 参考になる)
私も「本物のプログラマは Fortran を使う [osaka-u.ac.jp]」を連想しました。ネタ記事でしょ、たぶん…。
clausemitz
Re:何故ない！！ (スコア:2, おもしろおかしい)
あーだこーだ言わずにAdaでやるべし
Re:何故ない！！ (スコア:1)
本物のプログラマはPascalを使わない
http://www.genpaku.org/realprogrammerj.html [genpaku.org]
Re:何故ない！！ (スコア:1)
アセンブラを使いなさい。
そして、高級言語を使った時も、機械語が思い浮かべられるようになりなさい。
Re:何故ない！！ (スコア:1)
けれど、フレームワーク使うなって言ってるなら、スクリプト言語や便利な組み込み関数の整っている言語を使うなってのもあっていいよな。
1を聞いて0を知れ!
Re: (スコア:0)
シム等の計算用途ではごく普通に使ってますからねえ
90や95ならそこそこ見通しのいいコードも簡単に書けますし、ネタとしては弱いです
#N88BASICくらいじゃないとだめでしょ
コーダーをなんだと思ってるの? (スコア:2)
「優れた社畜になるためのTips」みたいなものでしょ。
と、思ったんだけど元を見たら要は「暇な時にでも実際に自分で作ってみて勉強しな」って
ことだからまぁ、そうなのかも。実用的ではないとか、仕事じゃできないって書いてあるし。
実戦で使えるコーダーになるために! これで君もヒーローだ! だったらネタだけど。
効率面で言ったらブラックボックスはブラックボックスとして楽をするのがいいと思うけど
新しいものの開発を主導するようなエッジの人になりたかったら中にも手を出しておいたほうが
いいんでしょうね。
# そういう意味でいわゆる「コーダー」向けではないとは思う。
# コーダーってコード書くだけしか能がないという蔑称かと
# 思ってたけどあっちじゃ違うのかな。
# うまいこと釣られてるだけかもしれんけどそれはそれで説得力があって感心する（ｗ
スルースキル：Lv2
Keep It Simple, Stupid!
学習方法としては同意出来るが (スコア:2)
学習方法としては、同意出来なくもないが、仕事でこの方法でやれと言われたら工数かなり増えそうだなぁ（苦笑）
>日々の業務あるいは重要なプロジェクトで使用される類のTipsであるとは思っていない。
ま、結論にもこう書いてあるし、あくまでも学習方法に関する話なんだろうな。
通知の設定いじったから、ACだとコメントされても気づかない事が多いよ。あしからずｗ
Re: (スコア:0)
初学者、学生さんの勉強の仕方としては妥当なアドバイスのように思います。
職場的にも、新しく入ってきた人がこの様な勉強をして来たのであれば、
フレームワークやデバッグツールの使い方ぐらい喜んで教えますよ。
Re:学習方法としては同意出来るが (スコア:1)
ですね。こういう手法そのままに勉強してきたのなら、教えがいがあるってもんです。
「教えて君」じゃないこと。これって、第一条件じゃないですかねｗ
通知の設定いじったから、ACだとコメントされても気づかない事が多いよ。あしからずｗ
コーダーとしての引き出しを増やすためのTipsですね (スコア:2)
そう思いました。
中身について理解が深いなら実プロジェクトでもよりエレガントなコードが書けるし、
何か難問に当たったとき、他の人が思いつかない解決法を思いつける。
昔はフレームワークやツールが少ないために、この学習法が仕事で実践されていてプログラマのスキルの底上げになっていたが、今はそうではない。
だから今の仕事では勉強がてらとしてはやれないにしても、自分プロジェクトでこれらをやっておくといいよってことですね。
Re:コーダーとしての引き出しを増やすためのTipsですね (スコア:2, 興味深い)
『達人プログラマー』（原題： "The Pragmatic Programmer"）にも同じことが書かれていたのを思い出した。
・偶発的なプログラミングをしないこと
（当てずっぽうで動くまで適当に試すスタイルをとらないこと）
・理解できないウィザードのコードを使わないこと （理解していないコードを使うのは
偶発的なプログラミングをしていることになる）
なおテキストエディタについては、メモ帳で満足していて生産性も高いならそのままでいいが、他のエディターが
いいと感じることがあれば考えを改めてほしい、となっていた。
原文のサイトを見ると、コピペをするな、自分の頭で処理した情報のみ使え、と繰り返している。
妥当だと思いますね。
Re:コーダーとしての引き出しを増やすためのTipsですね (スコア:1)
達人プログラマーの話を否定するわけじゃないです。
工数あてにされているプロジェクトでそれやっちゃまずいだろうけど、自分で新しいことを勉強する時=具体的な成果物は自分の成長だけでいい、という場合なら、ある程度あてずっぽうで適当に動かすみたいなスタイルもいいと思います。新しい言語を勉強するときにサンプルプログラムをちょこっと変えて、うまく動かなくなって、悩んだり、マニュアルを深く読んだりとか、普通の勉強法じゃありませんか?もちろん勉強段階で作った「何だか動いてそう」なレベルのコードを、本番で使うなら色々考えなきゃいけないことはあるにせよ。
ひょっとして、新しい言語を勉強する時って、言語の仕様を完全に理解してから初めてサンプルプログラムを書き始めるってのが今風なのかな。だとしたら、長年使っているどの言語も私は初級者レベルだ。
# 否定はしない。(笑)
vyama 「バグ取れワンワン」
Re:コーダーとしての引き出しを増やすためのTipsですね (スコア:1)
昔はフレームワークやツールが少ないために、この学習法が仕事で実践されていてプログラマのスキルの底上げになっていたが
この認識は間違いだと思うな。
それは、新し目の技術や分野に手を出すとスキルの底上げになるという話かと。
そうではなくて、普段機械任せの事や当たり前になってるからこそ、意識して目を向ける必要がある、という事。
HTML5とかスマホへの対応とか、今やってる事が将来言われるかもしれないし、
昔はHTTPd書いてみろとか、アセンブラ出力を読んでみろとか、自分で半田付けしてみろとか、
その分野その時代にはそれぞれに基礎と呼ばれるものがあって、学習にはそれに目を向ける事も大事、という話でしょう。
一発完動教 (スコア:2)
机上デバッグでバグは全部出し尽くして、コンパイルしたら一発で完動すべき、と言う教えがあったそうです。
Re:一発完動教 (スコア:1)
「一発完動」って、悪くないと思うけどな。
知っていることと、知らないことが明白に認識できていて、知っていることの
範囲は思ったとおりに動く、知らないことは調べてから理解して理解した
とおりに動く、ということだと思ってますが。
# 来週あがるＣＰＵボードに載せるＲＯＭを今週作って、「これ載せて動かなかったら
# ハードにバグあるから」といって渡して動いたのは私の人生の最高の思い出。
# そう、あれ以降・・・。
読む価値のない記事を見分けるたった一つの方法 (スコア:1)
「○○なの方法」とか、数付きのタイトルの記事は、
基本読み飛ばしても問題ない。
Re:読む価値のない記事を見分けるたった一つの方法 (スコア:1)
でもパタリロで『人をおちょくる50の方法』というタイトルだけ示されるとあーでもないこーでもないと想像して自説を繰り広げたり、その難点に突っ込みを入れられるのを期待したりする自分も同時にいる。
入手希望! (オフトピ: -1) (スコア:1)
心の準備(または心の折れる準備)のために読んでおきたい。オレは今どん底に向かっているかもしれない皆さんにもおすすめしたい。
Re:読む価値のない記事を見分けるたった一つの方法 (スコア:1)
元々の元祖は、アスキーでしたっけ？
見た目が地味で紙質も安っぽい雑誌付録のような本でしたが、内容は面白かったですね。
あのシリーズは今でも何冊か持ってますよ。
通知の設定いじったから、ACだとコメントされても気づかない事が多いよ。あしからずｗ
各スレの全ネタにマジレス (スコア:1)
# 知ってたはずなのにWeb制作会社の面接で『得意分野はコーディング』と答えて photoshop と格闘する羽目になったのでID
Re:各スレの全ネタにマジレス (スコア:1)
マークアップエンジニアしか知らんかった。HTMLコーダーは初めて聞いた。
#つーか、今時、HTMLは動的生成するもんだと思ってた。煽りではなく、マジで。
通知の設定いじったから、ACだとコメントされても気づかない事が多いよ。あしからずｗ
意図は理解できる (スコア:0)
こういうやりかたは上の人間に嫌われます。
人件費の圧縮に反してますからね。
「会社でやるな、自宅でやれ
だけどスケジュールはぎゅうぎゅう詰め込みますね」
それでおしまい
Crazy Tips (スコア:0)
日本語タイトルに"crazy"のニュアンスがすっとんでます。（記事中には「型破りな」とありますが、これもちょっと違う気が）
> これを全部実践したらその苦労の割には使えない人ができそう
ええ、crazyな御仁ですから。
# 最近、省略タイトルに釣られすぎなAC...
Re: (スコア:0)
4/1に出さないとネタをネタと見抜けない人がいるんだなあと思った。
時代が違うのかもしれないが (スコア:0)
90年代のプログラマはたいていこんなもんだったと思うが、
それで優れたコーダーかっていうと・・・ねぇ？
Re: (スコア:0)
クラッシュしてコアダンプ始まると休憩に入るような時代だし、いちいち動かして
確認なんてしてられないもの。脳内デバッグするしかない。
Re: (スコア:0)
コンパイル中は、休憩。
もしくは、コンパイル開始して終了するまで椅子で寝る。
Re:時代が違うのかもしれないが (スコア:2)
コンパイル中にコーディングする環境くらい、有ったと思いたい。
ツッコミどころって (スコア:0)
これ逆説的なべからず集じゃないの?
しっくりこない (スコア:0)
「1.独自のフレームワークを作りなさい」はよくわかる、「7.一から作りなさい」もわかるが
その他は時間の無駄にしか思えない。これじゃ「昔の苦労を繰り返しなさい」と言ってるようなもんじゃないか。
そろそろ古いプログラマーになってきた自分でも違和感があるな。
Re:しっくりこない (スコア:1)
うん、仕事の話だと思って読むと違和感あるよね。
でも、自分で作らなくなった人がプログラマ名乗るのも違和感あるよね。
通知の設定いじったから、ACだとコメントされても気づかない事が多いよ。あしからずｗ
Re:しっくりこない (スコア:1)
notepad.exeを使え、だけにはちょっと同意できないかな。
Emacsなどのプログラミング向けエディタではシンタックスハイライティングとか括弧の閉じ忘れチェックとか適切なインデントとか、不適切なコードを書かないための支援機能があるわけで、これを使わないと変なコードスタイルが身についてしまうような気がします。
あと、「車輪の再発明」は否定しませんが、だいたい劣化したものができるわけで、優れたコードを読んでそのエッセンスを取り込んだほうがよいような。フレームワークも使わないよりも、中で何をやっているかを読んだ上で使えば勉強になると思うんですけどね。
Re:しっくりこない (スコア:1)
はじめにまず自分用のエディタを開発せよ、というのが真意なんじゃないかと思います。
ニュートンは自分でレンズを磨いた、クヌース は TeX を書いた、みたいな。それらは例としては大げさですが、それほどではなくても toolsmith 的精神を忘れるな、ということではないかと。
;; 現実には、たまには忘れなきゃならない場面のほうが多い気がしますが、現場を知らないのでなんとも。
Re:しっくりこない (スコア:1)
「車輪の再発明」と言うか、
「作って完成させ(車輪の再発明)、そのコードを廃棄してもう一度作り直しなさい(再発明の再実装)」
だったら分かる気がする。
考えながら作るとゴチャゴチャしたものが出来上がるけど、一度作ってしまえば全体は頭に入ってるから、
最初からそれを踏まえて作れて見通しのいい物が出来る。
Re:しっくりこない (スコア:1)
「勉強のため」ならば車輪の再発明も同意していいんじゃないでしょうかね。
ソース読むだけより、自分で実装してみるほうが得られる知見は多いと思います。勉強なんだから、劣化したものしかできなくても別にかまわないし。
その上で更に既存のソースも読めば、なおよしと。
Re:しっくりこない (スコア:1)
「優れたコーダーになるための」
ですから、勉強のために車輪の再発明をしなさいってことではないのですかね？
目的に合うフレームワークやライブラリが見つからなくて、結局自分で作ってしまっています。。。
優れたフレームワークを参考にして作れば、もっといいものが作れると思いますけど、、、
それよりも、他人が作ったフレームワークを使うのが苦手になってしまいました。
Re:しっくりこない (スコア:1)
Re: (スコア:0)
「昔の苦労を繰り返しなさい」と言ってるようなもんじゃないか。
そのまんまだと思う。補足すると「昔の苦労から考えなさい」だと思う。
現在の優れたコーディングのツールは、当然のように与えられ、それを当然と思ってしまえば
それのどこが優れているのか、あるいは優れていないのではという疑問すら失ってしまう。
もし手元にnotepad.exeしか無いのだとしたら、自分はどのように開発環境を構築していくのか。
そのときには、エディタそのものを改良するのではなく、自作のマクロ言語を活用して
最小のテキストで開発を進めるようなスタイルに至るかもしれない。それは時に
今世間で良しとされている優秀なツールを上回る性能を発揮するものになる可能性もある。
Re:しっくりこない (スコア:2)
そのためには、基礎というか原理を知ることも重要と言う意味
に捉えたんだけれど違うのかな?
その道具が何をするものか? だとか、あんまり分かってないけど
単に使っているという人も周りにちらほらいるような気がする。
うわべだけ学んじゃうと、あとあと応用が利かないし
とは言っても、基礎ばっかりに時間を使っても。。。
さじ加減は重要なんだろうなと思いますが
記事に完全に同意 (スコア:0)
本物のプログラマになるための必須事項だと思いましたね。
タレこみがなぜこんなにネガティブなのか、そこが最大の疑問。
know howとknow whyの違い (スコア:3, すばらしい洞察)
記事で指摘されている項目って, 実際にプロジェクトで各種のツールを理解する上で必要になることですね. このあたりを把握していると, ツールを使う際に採るべきスタイルや避けた方が良い機能なんかが事前に予測できますし, ツールの使い方を完全に覚えなくても使えたりするとか.
一方, そうしたスタイルやルールを天下り的に受け入れる立場だと, そうしたknow howをいかに多く記憶するかが勝負で. 開発基盤が変わらないのであれば, know how重視型はリニアに開発効率に結びつくので好ましい戦略と思われるのかも.
でも, 開発基盤が変わることを前提とするなら, know how重視型は再教育のコストが大きいので不利なんですよね. 下手すると古いbad know howを捨てられずに, いわゆる老害になったり. 言い方を変えればツブしが効かないってやつで.
短期のプロジェクトで使い捨てが前提のプログラマなら, know how型の促成栽培でかまわないと思いますが, 将来の未知の環境に対応して, プロジェクトのスタイル等を決める上級プログラマを育てるのであれば, know why型の教育が必要でしょう.
Re:記事に完全に同意 (スコア:1)
０から書いて自分で何らかの仕掛けの根本を覚えるって後々役に立ちます。
そしてどういうわけか、このTipsを「仕事で実践できる」ものとして読んでネガティブツッコミを入れてる人が多いのが不思議。
翻訳文にもちゃんと「プロジェクトには適用できないよ」って書いてあるのに。
Re: (スコア:0)
IT土方とかそういう文脈でしかコーダーという名前が使われないからでは？
Re:記事に完全に同意 (スコア:1)
test (スコア:0)
test