Hatena::ブログ(Diary)

novtan別館 このページをアンテナに追加 RSSフィード

2016-06-10

名前晒しあげなエンジニアにはご同情申し上げるがユーザーフロントエンドの目に見えるソースにコメント入れるなよ的な何か

タイトルのとおりなんですが。

パスポート更新申請のPDFの仕様が酷いと聞いたので確認してみた - Windows 2000 Blog

htmlソースとか、スクリプトとか、ユーザー側で見れちゃうところにコメント残す神経は正直わからないわけです。修正コメントとかそのへん怪しいですよのマーカーでしか無いし、処理の説明とかバックエンドの仕組みを創造させちゃったりするわけで色々と嫌であります。

官公庁って緩すぎるよな…あんなに監督先には厳しいくせにね。

2016-05-23

100人以上で3時間で14億

ATM不正引き出しの話ですが…

まず100人だとして一人頭1400万。リスク見合いなのかというのは大変気になります。1400万をコンビニATMで引き出すのはかなり大変で、大抵の場合一回あたりの引き出し上限額が決まっているので(セブンは忘れたけどイーネットだと20万。セブンは30万だった気もする)、何回にも分けてやらなければならず、本当はカード側で一日の上限金額が決まっているはずなんだけどそれはどうなんだろう海外カードだったりするんだろうし。200人としても700万、20回以上引き出すのは大変。当然ですが、1店舗のATMにそこまで入っている可能性はあんまり無いのでセブン-イレブン回らなければならない。3時間でこれを実現するのは正当な引き出しであっても困難な気がするのですよね。

相当綿密に計画されたのであろうとは思いますが…

2016-05-10

コードが設計を可視化するというのは幻想だと思う。

オブジェクト指向の問題点 - ビスケットのあれこれ

オブジェクト指向UMLとある意味セットだったのはそういうことなんだと思うんだよね。

だから、それは言語や言語の設計思想の問題というよりはツールの問題だと思う。

ビジュアルプログラミング言語にしたって、バックグラウンドに控えている実装に対してある程度の制約をつけた上でそれを隠蔽しているインタフェースに過ぎないんじゃないかな。

だから、UML的なものからコードの自動生成に繋がるようなツールの整備があったとして、それがオブジェクト指向言語の素晴らしさを示すわけではなくて、単にツールの実装を可能にするレベルで抽象化できていた結果でしか無いと思うし、逆にそういうのがないと色んな物が可視化されないということがプログラミング言語としての欠点の本質であるということも全然言えないよね。

2016-05-06

「堅牢」と「壊れない」は違うからね

製造業で実際にPC-9801が稼働している現場の立場からすれば、単に設備投資の..

PC-9801持っていた身からするとそりゃまあ部品の精度とかそういう意味では当時としてもかなりのお値段がした国産マシンである以上こだわりはあると思うんだけど、そもそもの記事からして部品がもうすぐ枯渇することは明らかなのにそれに対する有効な手を打ててないって時点でそもそも「単に設備投資の余力が無いという問題ではない」という評価には賛同できない。設備の更新を無駄金と言い切っている時点でそのラインには将来性がないし、とはいえ、もっとも将来性のないラインを死ぬ(=需要がなくなる or PC-9801の交換部品が尽きる)まで稼働させるという判断が経営上成り立つんであれば別に問題がない話ではある。だから、この話は一般論とは出来ない。

死ぬまで逃げ切るか、または、設備更新する、という選択肢がある場合にどちらを選ぶかはそれこそ経営の問題であるとは思うけど、生産が終了している装置に依存しているラインのリスクというのはきちんと評価すべきだろうし、設備投資の余力があってこの手のニュースが出てきたタイミングであれば何が何でもやるべきって向きもいて良いと思うわけで。

2016-04-22

ソースにコメントを書くのはなぜか

優れた設計、優れたプログラムであればあるほど、コメントは不要である、というのが真理の一つだと思う。もっとも、「優れた」の中にも「複雑なハックを駆使してとにかく高速化」とかそのたぐいの物はあって、そういうものにコメントがないのはパズルや入試問題を解かされているような不毛があるので仕事という面であれば避けたいものではある。

であるならば、コメントを書くのはどういう場合なのか。

至極簡単な理由は、優れたプログラマーなどそんなにいない、というまた別の真理によるものだ。コードにコメントを書かないことを目指すべきであることと、実際にコメントが不要なコードが書けることはイコールではない。業務プログラマーの世界であれば尚更である。そこで目指されているのは完璧なクオリティーのコードを書くことではなく、QCDが計画の範囲内に収まることであるから…

ただ、不要なコメントもたくさんある。特に処理そのものの説明をコメントにしているのは流石にどうかと思う。書くべきなのはその処理の仕方を採択した理由であったり、処理そのものの話であってもコードや仕様書からさくっと読み取れない仕掛けの部分(これは大抵の場合設計がクソなんであるが、プログラムをする段に至って設計のクソさは怨嗟の対象であっても今更直せねーよという場合も多いわけで)。

あと、設計書のどの部分に相対するかのガイド的なコメントはプログラマー的には本来不要であるが、メンテフェーズにおいてクソみたいなスキルしかない要員がそれでも職責を果たそうと努力する際の指針としては大変重要なものになりうる。

つまり、一生自分(やその同程度の人員)でメンテナンスが可能なものについてはおおよそコメントが必要な事態は発生しない。ということは、そうではない仕事において、コメントを一切不要とする判断はメンテナンス性を損なっている仕事であると「見なされる場合がある」わけだ。もちろん、正しい保証が仕組みから担保できないコメントを100%信じる必要がある現場はクソだと思うが。

もう一つコメントが重要なのは、どういう理由かはさておき、妥協したことが可視化されている場合だ。この記事は以下の引用部分をヒントに書かれているが、これがいわゆる仕事ってやつだ(悲しい。

さて、いまを遡ること10年ほど前。

会社の先輩が一身上の都合で会社を退職していき、僕は先輩が担当していたシステムを引き継ぐことになりました。

で、そのシステムの改修をすることになったのでソースコードを見てみたら、システムの肝に近い部分にこんなコメントがあったんですよ。

// その場しのぎの処理。仕方がない。

【プログラミング】退職した先輩が書き残していったコメントがひどすぎる・・・ - 私の戦闘力は53万マイクロです

ほんとこういうの書いておいてくれないと困る。書いてあった上で、見たことにするのか見なかったことにするのかを判断したいものだ。

参考エントリ

プログラムにコメント書かない文化もあるよって話 - NZ MoyaSystem

コメントを書かない理由 | おごちゃんの雑文