プログラマが体験するべきではない50の危険なこと - Cube Lilac
Togetter - 「プログラマが体験するべき50の危険なこと」 が面白かったのでリスト化してみました（タイトルはこっちの方が適切な気がしたのでちょっと変えましたzzZ）．タイトルの元ネタは プログラマが知るべき97のこと かと思ったら 子どもが体験するべき50の危険なこと だそうです．類似シリーズとして，プログラマが知るべきではない97のこと，プログラマの嫁が知るべき97のこと も併せてどうぞ． twitterにハマる ノートPC持ったまま飲み会参加 なれる！SEを読む root権限を持つ rm -rf / crontab -r 「AAA」とかいう変数名 乱立するxxxStringクラスシリーズ ヘッダファイルがランダム 「コード汚いから1から書き直そう！！」 テストコードのないリファクタリング コンフリクトしたソースコードを強制コミット SVNでのコミット合戦 バージョン管理なしでの
プログラマの実力は経験だけであがらないことがレベル格差につながる - きしだのはてな
プログラマというのは、道具に慣れることが、実力があがることにならないのですよね。だから、勉強せず業務経験だけだとレベルが低いままということになってしまう。 Javaを10年さわり続けて、Strutsを5年さわり続けても、それだけでは、与えられた画面を手際よく作成できるようになるだけで、たとえばStrutsすらよりよく使えるようになるわけではなかったりする。 Javaにしても、「volatileってなんですか？」という問いに、まあ知らないのはしかたないとしても、解説を見ながらですら答えられない可能性がある。 プログラムの反復生産は、プログラミング能力の向上にあまりつながらない。設定や記述に慣れるだけだ。そして、この「慣れ」というのには「難しいからそもそも実装を回避する」というようなものも含まれる。実力の向上は、作業ができるレベルで止まってしまう。 プログラマとしての実力をあげるための勉強が自
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
プログラマは自分がモンスターペアレントになっていないか気にするべき - プログラマyasuhoの隠れ家
そもそもエンジニア、モノづくりをするひとたちには一度作ったものには愛着を持ってしまう。それは自分が労力をかけたことに対する強い思いなのかもしれない。だから、作った機能がユーザーに使われないムダなものだとしても、開発エンジニアに愛着があることによって変更がかけられないなんてこともあるしね。 http://jp.techcrunch.com/archives/jp20120420how_do_you_reduce_the_cost_of_development/ そういう感情は確かにある。プログラマにとって我が子同然のプログラムのミスを見つけるテスターは敵であり「それはバグじゃなくて仕様だ」って言っちゃうところとか。使いにくいから直せという顧客に対して「それには構造を大きく変更しなくちゃならないから直せない」とか。プログラムの問題を見つけてくれた人に感謝するどころか「私は間違ってない！」なんて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
