同僚の書く酷いコード、どうやって気づかせる？ | スラド デベロッパー
私の同僚は非常に頭がよく、ソフトウェアの知識も豊富だが、想像を絶するほどひどいコードを書く。たとえば、 すべてのプログラムは1つの関数に詰め込まれ、際限ない繰り返しのせいで無駄に引き伸ばされている 変数名やクラス名から得られる情報は泣きたくなるほど少ない コードを短く、読みやすくするための基本的な言語機能は無視されている オブジェクト指向プログラミングの虐待は吐き気を催すほどで、戦争犯罪レベルといえる しかし、彼は私が生まれる前からプログラミングをしており、非常に頭が良いことで、人の意見に耳を貸そうとしない。そのため、「この関数をこのように書いたら良くなると思いませんか」といった簡単な提案は受け入れられないだろう。彼に事実を伝え、良いコードと悪いコードの区別をわかってもらうにはどうすればいいだろうか。
コーディング標準は役に立つのか | スラド Slashdotに聞け
私がこれまで勤めた職場はすべて、「キャメルケースを使うか、アンダースコアで区切るか」「中かっこの配置」「タブを使うか、スペースを使うか」といったコーディングスタイルのドキュメントが用意されていた。しかし、アルゴリズムをレビューせずにスペースの使い方を指摘するような人のがいるせいで、コードレビューのために数百時間を無駄にしてきた。実際のところ、このようなコーディング標準を適用することで生産性が上がることを裏付ける資料や研究があるのだろうか。そうでないとしたら、なぜこれらが必要なのだろう。いまどき、決められたコーディング標準を自動的にツールが適用してくれてもよさそうなものだ。
コードレビュー、修正前コードを残す悪習、構成管理警察のこと - 勘と経験と読経
コードと構成管理の取扱いについて。ソフトウェア開発プロジェクトで自分がプログラミングすることは基本的に無いのだけれども、プロジェクトマネージャとしてはかなりコードに触れるほうだと思っている。最近コードにまつわる興味深いブログ記事をいくつか見たので、これに対して自分の考えを少しまとめてみる。 コードレビューについて ここで紹介されている、構成管理システム(VCS)でのレビューコントロールがとてもエレガントだと思う。 レビューのために bug tracker や task management system を使うのはあまり良いとは思いません。 レビューでは非常に細かい点が議論されることがあり、これが仕事のタスクの一チケットに相当するとはとても思えないからです。 例えば、この変数名は短すぎて良くわからない、といったことのために bug tracker をブラウザで開き、チケットを切る、やってら
下痢とソフトウェア開発
Sep 6, 2012 9/3から昨日まで実家に帰ってました。目的は実家のインターネット環境構築という、そんなことのために実家に帰るのかというレベルの話なのですが、そんなことはどうでもいいです。 行き帰りともに高速バスを利用したのですが、帰りのバス乗車早々に腹痛が始まりました。 22:00 乗車&出発&腹痛開始 22:20 下痢の兆候 22:40 耐え切れないレベルの下痢の衝動 格安の深夜バスなので当然、バスには備え付けのトイレなどありません。パーキングエリアでの休憩はおそらく3時間後です。これは困った。 ここで考えられた選択は2つです。 運転手さんにバスを最寄りのサービスエリアで停めてもらう 計画されている、およそ3時間後と思われる休憩地点まで我慢する 元来が小心者で引っ込み思案の僕ですから、この段階では後者を選択するつもりでした。しかし、敵の侵攻は予想以上に早く23時を回る頃には確信し
いまだに知らないなんてありえない病 : 小野和俊のブログ
いまだに知らないなんてありえない病とは、プログラマー同士の会話の場で、 「いまだに○○という本さえ読んでいないなんてありえない」 「いまだに○○というフレームワークさえ使っていないなんてありえない」 「いまだに○○という言語を触ったことさえないなんてありえない」 「いまだに○○というパターンさえ知らないなんてありえない」 というように、自分が知っていて相手が知らないものについて、 「いまだに知らないなんてありえない」 と発言してしまう病の総称である。 発症例として、例えば次のようなものがある。 「いまだにマシン語が書けないなんてありえない」 「いまだにRubyを1行も書いたことないなんてありえない」 「いまだにVisitorパターンさえ知らないなんてありえない」 「いまだに高校レベルの数学も押さえていないなんてありえない」 「いまだに個人で開発したアプリが1つもないなんてありえない」 「い
特許庁の「開発中断」となった新情報システム、「54億円の支出は無駄だった」と認定へ | スラド
特許庁の新情報システムの開発が中断したのはたびだび話題になっているが、このたび会計検査院が、東芝ソリューションやアクセンチュアに支払われた合計54億円強の支出について、すべてが無駄な支出だったと認定する方針を固めたという（日経新聞）。会計検査院側はこのシステムについて「完成困難」と判断、かかった費用すべてについて、会計法令などに違反する「不当事項」としている。
新人プログラマーに読ませて欲しいネーミングの大切さ - プログラマー幸福論
Photo from Kıvanç Niş ネーミングについてまじめに長文を書いてみました。もし、あなたの会社にネーミングに疎い新人プログラマーがいたら読ませてやってください。 ちなみに、この記事はシステム開発のネーミングについて書いています。また、このブログの特性上、英語でのネーミングを想定していますが、日本語のネーミングでも同様に考えることができると思います。 1. ネーミングの重要性 一般に、熟練のプログラマーほど、プログラミングにおける ネーミングに時間をかけます。それはなぜでしょうか。 あなたが付けたその変数名 data は、その時点では、自分のために付けた「目印的なもの」であったかもしれません。しかし、そのソースコードを引き継いだ担当者など多くの人が、その名前を見ることになります。 // データを取得する var data = getData(1); そしてその名前は、そのソー
開発者向けのソフトウェア設計書は必要か？ - 勘と経験と読経
時々組織の内外で盛り上がるネタの一つに「設計書は必要なのか」談義がある。今回も後輩の一人から設計書不要論がぶつけられてきたので、現時点での個人的見解をまとめておくもの。個人的には、ソフトウェアの設計書は必須でもないし、開発戦略を練る段階で作成するかどうかを決めればいいと思っている。 議論の前提：仕様書と設計書 議論を簡単にするために、まず「仕様書」と「設計書」という言葉を再定義しておきたい。今回の整理は以下としている。 仕様書 … 開発者とユーザー(仕様決定者)が、ソフトウェアの振る舞いや動きに関してコミュニケーションするために必要な文書類のこと。 設計書 … 開発者どうしがソフトウェアを作成するにあたっての、構造や仕様についてコミュニケーションするために必要な文書類のこと。 要は今回議論しようとしている「設計書」は、ユーザー(仕様決定者)とは無関係なものであるという前提である。また、ここ
こんなプログラマはアジャイル出来ますって言ったらアカンやろ - メソッド屋のブログ
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
人気のAPI／フレームワークを作るための39カ条
ある仕様を利用するための網羅性の高いライブラリを用意したいとき 再利用性が高い（と思われる）プログラムをライブラリ化したいとき Webシステムを外部から利用してもらうために一部分を公開したい場合 多人数で開発する事柄で共通化させておきたい部分をまとめたい場合 ほかの言語で作られたアプリケーションをある言語で利用したいときの橋渡し用 ちなみに、JSP／Servletの世界でよく使われているStruts Frameworkは開発者のCraig McClanahan氏が休暇中に思い付いて開発したものだそうです。オレゴン州のビーチで、ラップトップに向かい、3日間の休暇中ずっとコーディングしていたそうです。 一緒に行った奥さんは機嫌が悪かったようですけど。 ここでは、作成したAPIが自分だけではなく、多くの人に使ってもらえるよう、便利に使えるポイント、広く普及するためのポイントをとらえていきましょう
IPAからAndroidアプリの脆弱性に関するレポート出ました
「Androidアプリを作っている（作ってもらっている）けど、脆弱性が心配」という声はtwitterでも目にすることがあります。そして、「『安全なウェブサイトの作り方のAndroidアプリ版』があったらいいのに」という希望を目にしたこともあります。 6月13日にIPAから公表された「IPA テクニカルウォッチ『Androidアプリの脆弱性』に関するレポート」は、この『安全なウェブサイトの作り方のAndroidアプリ版』に相当する位置づけのドキュメントです。なぜそう思うかというと、以下の性格が『安全なウェブサイトの作り方』と共通するからです。 Androidアプリの基本的な問題に絞っている 届出の多い脆弱性にフォーカスしている 以下、もう少し詳しく紹介します。 Androidアプリの脆弱性とは何か 同レポートでは、Androidアプリの脆弱性を以下のように定義しています（同書P3）。 ■ 「
派遣PG時代の思い出
@vjroba 某N社で「メソッドを作ると処理が上下に飛んで可読性が落ちるので、出来る限り一つにまとめてください」と言われたことがある。僕は300行で挫折したが、1万行メソッドを書ききった強者がいた。クラスを作るには申請書が必要だった。 2010-05-11 12:42:06
スピリチュアルエンジニアリング入門 - 昼メシ物語
先日 hack05 というイベントで LT をしたので、そのときの資料をまとめておきます。 スピリチュアル エンジニアリングとは システム開発・運用にスピリチュアル要素を取り入れることでシステム安定化を目指します。 皆さんご存知の通り、人間の技術力には限界があり、予測不能な事故（バグ）はまさに、神の領域といえます。 そこで「ジンクス」「縁起かつぎ」「妖精さん」などの力を借りることで、人間の手ではどうしようもない事態を回避するというのがこのスピリチュアルエンジニアリングです。 スピリチュアルエンジニアリングの基本原理 スピリチュアルエンジニアリングの基本は「祈り」にあります。「絶対に動く」という祈りの強さがよりよいコードをもたらします。 スピリチュアルはすべてのエンジニアの身近に！ 以下に当てはまる人がいたら、あなたも立派なスピリチュアルエンジニア！ コーディング中に神が降りてきたと思う瞬間
Artistic Style
A Free, Fast, and Small Automatic Formatter for C, C++, C++/CLI, Objective-C, C#, and Java Source Code Artistic Style is a source code indenter, formatter, and beautifier for the C, C++, C++/CLI, Objective-C, C# and Java programming languages. Written in C++, it can be used from the command line or incorporated as a library in another program. Options can be entered from the command line or from a
高木浩光＠自宅の日記 - 要約版：「サニタイズ言うなキャンペーン」とは
■ 「逆」にしたERBが登場 27日の「（略）とかERBとか、逆だったらよかったのに」の件、大岩さんが、逆にしたERB改造版を作ってくれた。 自動quoteつきERBの実験, おおいわのこめんと (2005-12-29) さて、使い勝手はどうだろうか。 ■ 要約版：「サニタイズ言うなキャンペーン」とは 27日の日記「『サニタイズ言うなキャンペーン』とは何か」は、いろいろ盛り込みすぎたせいか思ったよりわかりにくいものになって いるらしいので、結論から順に整理しなおしてみる。 結論: まず「サニタイズ」という言葉を使うのを避けてみてはどうか。正しく説明することの困難から逃げようとしないで。 例外1: 万が一に脆弱性があるかもしれないことを想定しての保険として、CGIの入力段階でパラメタを洗浄することを、サニタイズと言うのはかまわない。 例外2: 既存のシステムに応急手当としてCGIの入力段階で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
特許庁の新情報システム、開発計画から作り直しへ | スラド IT
長文日記
ソーシャルゲームのプログラマだけど質問ある？ : キニ速
Amazon.co.jp: Lessons Learned in Software Testing: A Context-Driven Approach: Kaner, Cem, Bach, James, Pettichord, Bret: 本
ここは地獄か戦場か？火を噴くプロジェクト 死闘編｜【Tech総研】