ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
「ソースコードを書くだけがプログラマではない」事を知った半年 - その手の平は尻もつかめるさ
「プログラムを書いてお金をもらう」というアルバイトを始めて早くも半年が経ったので、 そういった「職業プログラマ」の世界に触れて気づいたことを振り返りたいと思います。 僕自身はまだまだ「職業プログラマ」などとは呼べないへっぽこですが。 1) ソースコードを書くだけがプログラマではない これは知っていたことでもあり、知らなかったことでもありました。 アルバイトを始めるまでは 「ソースコードを書く以外にすることって、せいぜい設計だとか仕様だとかを決めたり、 あとはテストケースを書くくらいなんじゃないの？」 という認識だったのですが、 実際にはこれをはるかに超える量の「ソースコードを書く以外の作業」が待ち構えていました。 それは例えば…… Redmine でチケットを作る作業であったり、 そのRedmine の処理済みチケットの報告を行う作業であったり、 メールを打って開発チーム内でコンセンサスを
辞めていった人達が作ったシステムの保守を楽しいものにする - ariyasacca(2012-03-18)
▼ [Software]辞めていった人達が作ったシステムの保守を楽しいものにする はてなは「絶対すべきでないこと」をやらかしたのか？ nabokov7; rehash : ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた？(下) この辺りの話題を眺めていて思うところあったので少し書いてみる。 別にはてな社やライブドア社がどうだって話ではなくて、システムやソフトウェアを開発する仕事の話です。 まず、大前提として、 新しくスクラッチから書き起こす 既にある機能と互換性を保ちながら改修する プログラマにとっては、前者の方が圧倒的に楽しい仕事だと思ってます。（最近無くなったらしいけど）グーグル社の20%ルールは、開発者の創造性を巧く引き出せるよう上手に設計された制度です。 ただ、現実問題として、IT業界では後者の仕事を行う機会の方が
3回に1回出力するだけの簡単ではないお仕事 - やねうらおブログ(移転しました)
なんかさ、3回に1回出力するだけの簡単なプログラムのお仕事ってあるじゃん。 if ( (++counter % 3) == 0) printf("Fizz\n"); これって意外と難しいんだよね。 ……なんてことを言うと「おいおい、天下のやねうらお、ついに頭おかしくなったか」とか言われるだろうけど、これ実際うちの仕事であった話で、このコードが原因でお客さんと大きなトラブルになった。 あまり具体的には言えないので、ちょっと別のものに置き換えて話すけど、それは、ひよこの餌やりプログラム(仮)だったわけ。 上のプログラムは、3回に1回だけど、このソフトには、N時間に1回、餌をやるロジックが書いてあった。 if ( (++counter % N) == 0) printf("餌やるでー\n"); なんかこんな感じな。それでNの値は、UI(ユーザーインターフェース)で調整できる作りにしてあった。一度
オブジェクト指向開発を理解した開発者に、設計書は不要：アジアのソフトウェア開発現場にて：エンジニアライフ
シンガポールでアジアのエンジニアと一緒にソフトウエア開発をして日々感じること、アジャイル開発、.NET、SaaS、 Cloud computing について書きます。 わたしのソフトウェア開発者としての経歴は10年程度。10年間、いろいろなものを作ったが、「設計書」と言えるもの、つまり「基本設計書」「詳細設計書」がある形でプログラム開発したことは一度もない。たぶん、これからもないかと思う。 「大したものを作っていないのでは」と、わたしのソフト開発者としての能力を疑う人が出てくるかもしれない。しかし、大企業で大勢の人に使われるようなシステム――規模にして数十年月のしっかりしたシステムを作ってきたことは事実である。ということで今回は、「設計書なしでかなりの規模のシステムを作る」ことに関するわたしなりの方法論を少し書いてみる。 オブジェクト指向は必須である。「設計書なしである程度の大きさのソフト
電車内プログラミングの生産性が高いのは何故かに関する考察 - 西尾泰和のはてなダイアリー
Twitterから転載 電車の中でやるコーディングは自由意志でやりたいと思ってやるコーディングなので生産性が高い 電車の中ではインタラプトが入らないから生産性が高い 近づいてくるデッドラインが明確なので締め切り効果が発生して生産性が高い 電車の中では調べ物ができないので、調べ物が必要なタスクが後回しにされて、結果として下調べが済んでいるもしくは脳内の知識でできるタスクを実行するから生産性が高く見える タイミングが予想出来る乗り換えインタラプトが存在するので、乗り換えの間に考えていたことを忘れないようにファイルに出力すること、そして歩くことが問題の整理に役立っている 電車の適度な騒音や移動していることによる海馬への刺激がなんか集中力を高めたりするのかもしれない 「目的地につくまで15分だからその間にアレを実装出来るかな？」というのがまさに「自発的に設定した制限時間へのチャレンジ」なのでドーパ
スピリチュアルエンジニアリング入門 - 昼メシ物語
先日 hack05 というイベントで LT をしたので、そのときの資料をまとめておきます。 スピリチュアル エンジニアリングとは システム開発・運用にスピリチュアル要素を取り入れることでシステム安定化を目指します。 皆さんご存知の通り、人間の技術力には限界があり、予測不能な事故（バグ）はまさに、神の領域といえます。 そこで「ジンクス」「縁起かつぎ」「妖精さん」などの力を借りることで、人間の手ではどうしようもない事態を回避するというのがこのスピリチュアルエンジニアリングです。 スピリチュアルエンジニアリングの基本原理 スピリチュアルエンジニアリングの基本は「祈り」にあります。「絶対に動く」という祈りの強さがよりよいコードをもたらします。 スピリチュアルはすべてのエンジニアの身近に！ 以下に当てはまる人がいたら、あなたも立派なスピリチュアルエンジニア！ コーディング中に神が降りてきたと思う瞬間
ロートルの嘆き、アジャイル開発って何 - 未来のいつか/hyoshiokの日記
20数年前に大学を卒業しプログラマになって、この変化のとっても早い業界でまだ禄を得ている。最近でこそコードを書くことはないが（今でも職業としてコードを書きたいと強く思っている）、それでも、ソフトウェア開発について20数年前に得た知識、経験、スキルが役に立っているように思える。 日進月歩で日々新しいバズワードが登場し、若い人たちはそれをフォローするのにひーひー言っている。クラウドだアジャイル開発だなんだかんだ。 プログラマの一日は、会社に来て、テストを書いて、テストをして、不具合があればコードを修正し、またテストをして、問題がなければコード管理システムにチェックインする。その作業を淡々と日々こなす。この日常の流れというのは、使う道具立てこそ変わったとしても、基本的に変化がないように思える。コードを書くのは20数年前も今もプログラマだし、テストを書くのもそうだし、テストを自動化することは20数
「俺のソースだから」というプログラマは死んだらいいのに - 神様なんて信じない僕らのために
最近こんなやりとりがあった。 「Cって標準のコンテナ（双方向リストや可変長配列など）がなくて不便。 Cのプロジェクトってコンテナ自体ないこともあるし、コンテナがないとプログラムって書きにくいよね。 その点C++はSTLが(ry」 ... 「コンテナ？ STL“も”いいけど、自分で書きたい」 正直、自分は「え？ 何を言っているんだ？」と思った。 STL“も”いいけど、“自分で書きたい”だって？ その人はプログラマとしては十年選手だが、C++に関して、特にテンプレートに関しては稚児に等しいレベル。 で、どうして「自分で書きたい」ということになるんだろう？ それを使わされる人の苦労はどうなる？ それともプロジェクトに同一の事をするための複数のコンテナが存在するのか？ 俺俺コンテナを書きたい理由はなんだ？ 要するにここにおいて「自分で書きたい」はSTLがよく解らないので、 機能や動きを隅々まで把握
プログラマでよかったなと思える瞬間を増やせたら - GoTheDistance
今年ももう終わりですねぇ・・・。 スーツ・ギーク論争に参加してた頃に僕と知り合った多くの人は、僕が技術系に戻ると知った時に驚かれた方が多かった。あんだけスーツでいたいって書いていたからそりゃそうだなって、過去エントリ読み返して改めて思った。 この２年ばかりどんな心境の変化があったのか、思い出しながら書いてみたいと思う。新卒はツライよ！みたいな感じで。 僕は大きなSIerに入ったにもかかわらず、幸運にもバリバリコードを書く部署に配属された。相当レアだったと思う。そこで仕事をしているうちに、僕の立場はプログラマという作業員でしかなかったことにひずみを感じるようになった。技術が無ければできないしそこは間違いなく意味があるんだけど、僕は仕事をもらっているから力関係で言えば、間違いなく下なワケで。そういう状況だと、グダグダなプログラム開発を強いられることが多くなって辟易とし始めたってのもあったかなぁ
「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey
日本での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数％程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。 このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。 意志決定を先延ばしすること 質問 日本のSIerに務めています。日本では、設計書をエクセルを使って画面や処理などの書類を作成しています。海
エンジニアがタイトル買い、著者買いすべき本 - Fight the Future
著者買いすべき本！ ファウラー、ジョエルは知名度もあり、改めて僕がどうこう紹介する必要はないと思うけど、ここではスティーブ・マコネルを特に推したい。 読んだ人には非常に高い評価を得ているけれど、その分厚さや価格もあってなかなか広まっていない。 特にCode Completeはすべてのエンジニアが必ず読むべき本だと思ってる。 これを読んで理解する／しないが(職業プログラマとしての)初級と中級の境界だと言えるくらい。 タイトルにはCodeとあるけど、別にコーディングをターゲットにした本ではない。 設計、テストも含めてコーディングを考えている。当たり前だがコーディングだけではコーディングはできないからだ。 上下巻1,200ページの大作だし、2冊で12,000円だがその価値は大いにある。 スティーブ・マコネル ソフトウェア見積り―人月の暗黙知を解き明かす 作者: スティーブマコネル,久手堅憲之,S
あなたの履歴書を向こう5年間戦えるものにするために--今後必要な開発者スキル10選 - builder by ZDNet Japan
最近の経済の変化から、現在多くの開発者が短期的な仕事を探している。同時に、スキルを習得するために時間とエネルギーを投入するのであれば、そこから確実に最大の収入を生むことが重要だ。ここで紹介する10のスキルのリストは、あなたの履歴書を向こう5年間戦えるものにするために、今すぐ学ぶべきものだ。このリストはとても網羅的とは言えないし、カバーし切れていない業界の分野も非常に大きい（例えば、メインフレームの開発者はカバーされていない）。とはいえ、平均的な主流の開発に対しては、少なくともこれらのスキルの7つを学んでいれば間違いはないだろう。就職の面接で説得力を持って話せるというだけでなく、これらは実際に仕事でも役に立つ。 1: 「ビッグスリー」の1つを学ぶ（.NET、Java、PHP） 開発業界に（レッドモンドに隕石が落ちるというのに匹敵するような）劇的な変化が起きない限り、ほとんどの開発者は少なくと
Javaを教えろ．しかしオブジェクト指向は教えるな． - カレーなる辛口Javaな加齢日記
http://d.hatena.ne.jp/t2y-1979/20090510/1241958803 先日、SIer の友人が新人研修の講師として Java を教えるというお話を聞きました。会社側からは「Java を教えるのではなく、"プログラミング" を教えてほしい。オブジェクト指向は教えないでください。」との指示を受けたそうです。 「それはひょっとしてギャグで言ってるのか？」 ．．．．日本のSIerの未来は暗いなあ． http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/t2y-1979/20090510/1241958803 id:fukken 期間が限られているなら、文法的事項を設計思想より優先すべきなのは自明。「オブジェクト指向は教えるな」ではなく「オブジェクト指向とか抜かす前に義務教育レベルの事をきちんとやれボケ」だと思う OOPは
エンジニアの勉強法について
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。 サービス統括部に所属しております、堀 邦明と申します。 普段はYahoo! JAPANトップページのフロントエンドエンジニアとして、JavaScriptやPHP,Perlといった言語を利用して開発しています。 この度、デベロッパーズサミット2009というイベントにおいてエンジニアの勉強法というテーマでJavaScriptの勉強法についてお話をさせていただきました。 今回は、そのときのお話について発表しきれなかった部分も含めてご紹介できればと思います。 勉強の分類 勉強には大きく分類して2つのステップがあると思います。 1. 情報収集 1つは情報収集です。 技術書やウェブサイト、ブログを読んだり、勉強会やセミナーに参加
エンジニア的発想は危険な気がしている - 矢野勉のはてな日記
雑談「エンジニア主導で作ると、動いたところで満足してしまう。『ちゃんと動いているから、あとは使う人が分かってくれるだろう』と、考えをストップするところがあった。本当は、動いたものを説明して分かってもらい、使ってもらうところまで来てやっと完成なのに」近藤社長「未熟だったと思う」 はてなが目指す“脱IT系” (1/2) - ITmedia News なんかね、私がコンピュータにはまったときに理想とされていたことから比べると、それでもまだ足りないと思っちゃったんです。 自分ができているかどうかは棚に上げて、理想とするところを考えてみる。目標がどこにあるかっていうのはすごく大事なことだと思うし、上記の発言は目標を吐露したものだと思うので。 私はMac OS Xが生まれる前の、漢字Talk 7とか作ってた頃のAppleの、Macintoshを買ってコンピュータの世界に没入しました。そのころのコンピ
プログラマーにとっての読み書きそろばん : 小野和俊のブログ
基礎的な学力を表す言葉として読み書きそろばんという言葉があるが、 私はプログラミングについても読み書きそろばんに当たるものがあると思っている。 まず読みというのは、プログラムを読む能力である。 たまに、人の書いたソースを見て、すぐに 「全面的に書き直さないと使い物にならない」とか、 「グチャグチャですよ」とか、 「気持ち悪い」といったことを口にする人がいるのだが、 多くの場合、なぜそのように感じるのかを聞いてみると、 単に自分が今まで書いてきたコードと違ったスタイルで書かれている、 ということだったり、ごく一般的なデザインパターンが使われているのに、 そのデザインパターンを自分が知らないだけで 「わかりにくくて読めない」などと言っていたり、 人のコードを使い物にならないと簡単に口にする人であればあるほど、 その人自身が使い物にならない、という傾向がある。 もちろん、全体の整合性を取るために
初心者はプログラミングをどうやって学ぶと良いのだろうか？:Geekなぺーじ
最近、初心者がプログラミングを学ぶ(もしくは、初心者にプログラミングを教える)にはどうすれば良いのかが良くわからなくなってきました。 ここで言う「学ぶ」や「教える」というのは、授業などではなくゆるいつながりで知人に教える事を想定しています。 (まあ、学校の授業でもいいのかも知れませんが。) 色々ある Ruby,PHP,Perl,Java,JavaScriptあたりがWeb界隈で最近良く見るプログラミング言語だと思われます。 初心者にとっては、生でHTMLやCSSを書くことも「それ既にプログラミングでしょ」という感覚もあるようです。 さて、「全くの初心者だけど何でもいいからプログラミングを学びたい」という人は何から手をつければいいのでしょうか？ 個人的にはC言語の方が入門者向けだと思う 個人的には、オブジェクト指向的な「難しい」ものを最初から理解できるのだろうか？というのがいつも疑問に思えま
ソフトを一人で作るということ：ITpro
最近，WebアプリケーションやWindowsソフトの取材で，“このソフトは担当者が一人で作っています”という事例に続けて遭遇する機会があった。フリーソフトや趣味のソフトではなく，会社が商品として提供し，不特定多数のユーザーが使っているアプリケーションを一人で作って，一人でメンテナンスしているという点に興味を覚えた。 先週都内で開催された開発者向けイベント「ITpro Challenge!」でも，ドワンゴの戀塚昭彦氏がニコニコ動画を一人で（しかも3日間で）作ったと語っていた（関連記事）。よく考えてみれば，ITpro Challenge!に登壇したようなハッカーとかアルファギークなどと呼ばれる優れた開発者でなくても，企業内で一人でソフトを作っているケースは思いのほか多いのではないだろうか。 アプリケーションの規模や内容，また開発者のスキルにもよるだろうが，おおむね一人で開発するほうが， ・低コ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
最低予算1万ポイントで。iPhoneアプリの審査でリジェクトを食らった事例をお教えください。 - 人力検索はてな