ランクA ～ コメントを読まなくても、関数名だけで使い方がわかる ランクB ～ コメントを読めば使い方がわかる ランクC ～ 中身を読まないと使い方がわからない ランクD ～ 書いた人の心を読まないと使い方がわからない（or 心を読んでもわからない） 元ネタ：[開発]ランクCのゴミコードを生産し続けないために、、、
コードの格付け++ - None is None is None
ランクA ～ コメントを読まなくても、関数名だけで使い方がわかる ランクB ～ コメントを読めば使い方がわかる ランクC ～ 中身を読まないと使い方がわからない ランクD ～ 書いた人の心を読まないと使い方がわからない（or 心を読んでもわからない） 元ネタ：[開発]ランクCのゴミコードを生産し続けないために、、、
SIerの下請け開発者ってレベル低すぎない？ - UXエンジニアになりたい人のブログ
ネット上ではSIer批判＝技術のことをわかっておらずプログラムも書けずPMも出来ない非効率でダメダメな上流工程と、 人月単位での労働力提供という業界の慣習に縛られ、持ち前の優秀な技術力・知識を生かせず非効率な作業を強いられているかわいそうな下請け開発者、という構図が確立されているように思います。 自分が関わるまでは、まあそうなんだろうなと思っていましたが、しかし実際にそういう立場のひとと関わりをもつにつれて、どうもそうではないのではないかと思うようになりました。このあたりの実情を書いていこうと思います。 なお、先に言っておきますが本記事で書くことは、上流工程がどうのとか、業界の多重請け負い構造がどうのとか、給料が安くてとか労働条件が過酷でとか、そういう話とは全く関係がなく、純粋にプログラミングのスキルの話だけです。 対象はおもに詳細設計、実装UTだと思ってもらえれば。外部仕様が決まった状態
ifの条件が2つ以上だと頭がパンクする
if(param==0 ＆＆ 判定(param2) || !param3){ //したいこと } みたいに3つぐらい条件がある場合、頭がパンクしそうになる。 この時こう考えている。 1:したいことをする条件は 2:paramが0 3：かつ 4：判定関数でparam2の条件を返して、true 5：またはparam3がfalseのときがtrueだから 6：trueだとだめなんだよね。falseが正しいんだ。でもfalseは偽なのに正？ 8:あれ、何したいんだっけ。まぁいいや、とりあえず実行してエラーなら直そう。 7：実行。 8:あれ？なんか違う。何がおかしいんだ 1へ戻る。 これを3,4回繰り返してウアアアアアアアアアアアってなってしまう。 誰か助けて
【プログラミング】退職した先輩が書き残していったコメントがひどすぎる・・・ - 意識低い系ドットコム
こんにちは、意識低い系サラリーマンのKENです。 今回は零細IT企業でシステムエンジニアをしている僕が遭遇した酷いコメントについて。 猫でもわかるC#プログラミング 第3版 (猫でもわかるプログラミング) 作者: 粂井康孝 出版社/メーカー: SBクリエイティブ 発売日: 2016/02/27 メディア: 単行本 この商品を含むブログ (2件) を見る 通常プログラムを組むときは、プログラミング言語を使ってソースコードを書いていきます。でもプログラミング言語だけでひたすら書いていると、第三者が読んだときや後から自分で見返したときにわかりづらいので、「コメント」と呼ばれるメモ書きを付記することがあります。あります、というかほとんどの人はそうします。 例えば、「C#」というプログラミング言語だと、行の先頭に「//」と打つと、その行はプログラムの一部としては解釈されず、単なるメモ書きとコンピュー
プログラマを悩ませること Top 10 | POSTD
10. 「何か」は分かるが「なぜ」が分からないコメント プログラミング入門コースでは、早い段階かつ頻繁にコメントを記述することを生徒に教えます。プログラムを書き始めた初期段階（ごく単純なコードであっても、時に理解し難いことがあります）では、これは実際に役立つことなのですが、習慣にとらわれてしまうプログラマが多くいます。 上記のコードが何をするのか分かりますか？ 私は分かりません。 問題は、多くのコメントがそのコードが 何をする のかを説明していますが、 なぜ そのコードが書かれているかが説明されていません。では、異なるコメントが書かれた同じコードを見てみましょう。 こちらの方が分かりやすいですね。何が起きているのかを完全に理解できるとは言えませんが、最低でもなぜこのコードが必要なのかが文脈から判断することができます。 コメントは、構文を理解してもらうためにではなく、読み手がコードを理解しや
科学者が書いた質の低いコードが、ベストプラクティスに則ったコードに勝る理由 | POSTD
今ちょうど、 科学者の手によるコードは質が低い という投稿を読み終えたところです。科学者の書いたコードは”ソフトウェア・エンジニア”が関与したコードと比べて質が劣るという内容でした。 私は10年以上同じ職場に勤めていますが、同僚の多くは数学や物理学が専門で、”ソフトウェア・エンジニアリング”の知識はほとんど持っていません。 そこでは、大惨事は必ずと言っていいほど、自分のことをいっぱしのプログラマだと思っている少数派によって引き起こされます。かくいう私も、少なくとも数件、いまだ解決を見ていない大きな不具合の原因を作ったことがあります。他にも大きめのバグをいくつか出しましたが、幸いその時のコードはお蔵入りしたため、私に無駄な給料を払わされた雇い主が被害をうけたくらいで、同僚の生産性を大きく損なうことはありませんでした。 その度（少なくともほとんどの場合）私は反省し、それまでにも増して退屈なくら
- 不吉な匂い
不吉な匂いとは、リファクタリングを必要とするコードから感じられる雰囲気を、比喩で表したものです。 ここでは、感じ取った不吉な匂いに対して、どのような解決法を選ぶことができるかを取り上げます。 匂いとして示されているのは、次の２２のケースです。ひとつずつ見ていきましょう。 また、解決法に添えられている数字は、参考書籍「リファクタリング」の何ページに記されているかを示しています。
初心者に理解あるふりしたモヒカンの自己満足に付き合うのはうんざり - mizchi's blog
インターネットのほとんどの初心者向けに書かれたと宣言されたコンテンツは、想定すべき初心者のペルソナを失っている。初心者向けの記事は、「これは(俺が想定する都合のいい初心者には)わかりやすい」であり、「実在する初心者」の方を向いていない。習熟すると初心者の気持ちがわからなくなるから、構造的な問題もあるんだけど、それにしても、と思うケースが技術者界隈には本当に多い。 初心者向けと銘打った発表をして、似たようなコミュニティから「わかるわかる、そう説明するよね」的な同意を得られることに満足して終わっているだけで、実際には誰も救っていないの、本当に滑稽だと思う。当人の自己満足と、コミュニティから賞賛を得る以上の価値がない。ネタでやってるケースだけでなく、本気で初心者のつまづきに理解があるよ的な前振りから、突然理解に困る技術的な飛躍が行われるの、やられる方はかなり迷惑で、しかし自分の頭が悪いのを認めた
「実装をテストする」とは？ - bluebird
TDD界隈の議論で、「仕様のテスト」「実装のテスト」という話を聞くことがあります。 TDDのよくわからない言葉をどうやって説明するか悩んでいるという話 #SWTestAdvent — うさぎ組 明日からTDDをやってみよう！ - 部屋とアジャイルと私（仮称） 今日のTDD界隈で「仕様のテスト」「実装のテスト」という言い回しを一番よくしているのは私だと思うのですが、勉強会の場などでは話をすることはあるものの、こういう形で残してこなかったので、自分の考えをまとめたいと思います。 公開されているインターフェースの仕様を満たせるなら、API(「リファクタリング」で言う「公布済みインターフェース」)のエントリポイントの内側のクラス設計をどのように組み立てるかは、実装者の裁量に任されているはずです。 品質保証の観点からは、APIの仕様を満たせるテストケースを記述すれば、ソースコードに対してのある程度の
ImperialViolet - Apple's SSL/TLS bug
Yesterday, Apple pushed a rather spooky security update for iOS that suggested that something was horribly wrong with SSL/TLS in iOS but gave no details. Since the answer is at the top of the Hacker News thread, I guess the cat's out of the bag already and we're into the misinformation-quashing stage now. So here's the Apple bug: static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bo
クソコード、あるいは技術的負債 - 時計を壊せ
クソコードについてここ数日で考えたことを書いてみる。 技術的負債まわりのえらいひとたちの議論を眺めてて、技術的負債って言うとなんかプロっぽいけど、クソコードって言ったほうが示したいモノを素直に表してるし分かりやすいきがしてきた。 クソコードを書くなとは思わないけど、クソコードをいつまでも放置するのはやめようって思う。 クソコードは次なるクソコードを生み出すし、バグを隠蔽するし、メンテナンスコスト増大の悪循環のキッカケになるし、新人の教育上良くないので無くて済むならもちろんないほうがいい。 ただ、ギークな人たちを除いて、さらっと60点*1のコードなんて書けない。僕を含め大多数のエンジニアは自分自身が書いたクソコードをリファクタリングして60点以上のコードを目指すための時間が必要になる。 そのうえ、そういうコードを書いてもだいたい時間経過に伴って事情が変わって、60点のコードの挙動を壊さないよ
UUIDをワンライナーで生成する - 元RX-7乗りの適当な日々
ちょっと調べたのでメモ。 UUID(Universally Unique IDentifier)の詳細については下記リンク先をご参照いただくとして、UUIDの生成については様々なプラットフォームでサポートされているのと、いくつかバージョンが存在します。 Universally unique identifier - Wikipedia UUID と Perl について - daily dayflower バージョン4(完全ランダム生成)を使う前提で、いくつかワンライナーで実行するやり方を残しておきます。 uuidgenコマンド(Linux) $ uuidgen f6574b6b-02f7-4255-865b-dda39dcd0979オプションなしで実行すると、上記の通りデフォルトはバージョン4で返してくれます。 (UUIDの 00000000-0000-X000-0000-00000000
技術は発想やデザインの限界にならない
当時の思い違い たとえば、一般的なエンジニアが何かを作ろうとすると、その個人の「技術的な限界＝発想の限界」となりがちです。 ではデザイナーと呼ばれるような職能を持っているひとが、果たしてプロダクトを実装として理解すべきか、というと、それは分業上の実装サイドによるエゴ（こっちの都合もちゃんと考えて欲しい！的な）でしかないと思っていました。 多少、吹っ飛んだ話であっても、意図を失わずに現実的な実装に落とし込むのはコミュニケーションの問題であって、デザイナー職能の理解不足ではない、と。 コミュニケーションでも解決できる問題として、これは今も間違ってはいないはずですが。 しかし、これは適切なタイミングで、大きな青写真を描くための能力であり、デザイナー職能を全うする話とは違ったのです。 優秀とは 身の回りで優秀なデザイナーと呼ばれる諸氏は、ビジュアルを作るだけでなくステートの管理までよく考え、利用コ
Copeが教えてくれた、TDD否定派論文の紹介 - 2013-10-31 - やっとむでぽん
来日中の James O. Coplien と話をする機会があり、いまTDDをクライアントに推薦していると話したら目を剥いて "Are you still doing TDD!?" と詰め寄られ、TDDの問題について大変熱烈に語ってくれました(ディスカッションをした体ではあるんだけど、だいたい10対0くらいで押されてました)。 Cope はその後、丁寧にfacebook上にもTDDの話を書いてくれました。ここで読めます。 さらにメールで、TDDの問題を指摘した論文などをいくつか教えてくれたのでした。そこで紹介してもらった論文を、自分の理解の整理も兼ねて、サマリをしてみようと思います。とりあえず1つだけですけど。 "A Comparative Case Study on the Impact of Test-Driven Development on Program Design and T
単体テストフレームワーク(xUnit)に関すること - 勘と経験と読経
このブログエントリの言いたいことがわかるようでわからなかったので、整理してみる記事。ドキュメントベースの単体テストとxUnitの類いの単体テストフレームワークの違いに関する私見。ツール(手段)の話ではなく、目的を中心に考えれば良いと思っている。 もし、ドキュメントベースの単体テストをそのまま踏襲したままで、xUnitを導入しようとするならば、もう一度テストの対象や目的を確認してください。xUnitは手段でしかありません。xUnitは小さなプログラムを動作確認するために作られたツールです。 ドキュメントベースの単体テストでxUnitを導入する前に考えて欲しいこと | DevelopersIO ドキュメントベースの単体テスト 例えばこんな「ドキュメントベースの単体テスト」が行われていて、いきなりxUnit類のツールを適用するとかなり混乱すると思われる。 割と「単体テスト」というものを実施するこ
ハッシュ値の生成にXORするのはなぜか
ヒロ @cz75hiro こことか http://t.co/seUXLH74yb こことか http://t.co/8t7hso6TP1 見てるけど、ハッシュコードの生成時に、「各値のXORを取って素数をかけた値を元に計算」って書いている理由がいまだにわからない。 2013-10-16 16:16:09 ヒロ @cz75hiro 例えばboolなプロパティ2つのみ持ってる同クラスのインスタンスのハッシュ値は、真･真と偽･偽の場合、XORとったら同じハッシュ値になるんじゃないかと思ったんだけど、何か勘違いしてるのか・・・？ 2013-10-16 16:18:27
ダブルMVCの意味するところ [GoGaRuCo 2013] - ワザノバ | wazanova.jp
[Video] http://www.youtube.com/watch?v=s1dhXamEAKQ TildのYehuda KatzのGolden Gate Ruby Conference 2013での講演。 Ruby on RailsのクリエーターであるDavid Heinemeier Hanssonが、「JavaScript勢はダブルMVCで苦しんでいる。サーバとクライアント両方にMVCが必要で複雑すぎる。」とTwitterで発言したのに対して、Yehudaは、それでは誤解を与えると危惧し、GUIプログラミングが歴史的にどのようにMVCに発展してきたかを紹介することで、ダブルMVCが本当に意味するところを解説しています。 DHHの発言は、盛り上がってきたMeteor / Node.js勢に対する単なる批判っぽいですが、それに対してYehudaはロジカルに話をまとめてます。 スライドを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
パソコンが好きで情報系学部に入った..
正規表現が構文として必要かどうかという話から
ソースコードを表示するためのフォント「Source Code Pro」をアドビがオープンソースで無料公開 － Publickey