  |
はてなキーワード: カバレッジとは
毎日仕事ができなくて凹んでます。元増田の2年目が羨ましいです。
研究室では解析アプリケーションを作るのにC,C++,Fortranをいじってました
また趣味でサーバの立ち上げやWeb系のJavascriptやPHP,Pythonなどもいじっていました。
まったく違う。組み込みとWebとアプリケーションで文化が違ったわけです。
ここからはあくまで私の体験ですが…
まず、組み込み系はハード（接続図）を読めないと話になりませんでした。
CPU、FLASH、SRAM、FPGA、CPLD、アナログ回路、バッファ、それらをつなぐバス、電源、接点、コネクタ、スロット、A/D、D/Aなどなど、
これらがどうつながってるか意識しなくてはいけません。SoCとか行っても接続図読めないと意味ありません。
次に、FPGA・CPLDの設計があります。言語はVerilogかVHDLです。Xilinx、Altera、Actel等のデバイスに書き込みます。
PLDって言うのは言語で書けるハードです。似ているようでCPUと違うので設計にはスキルが必要です。
この段階でシミュレーション(modelsim等)をしてもらいます。
次にCPUです。言語はC,アセンブラ、C++です。でもほとんどがCです。デバイスはルネサスのSHとかです。自分はここで見習いをしてます。
CPUに直接入ってくる信号（接点・バス等）もありますが、前述のFPGA・CPLDから入ってくる信号のほうが多いです。
で、アプリケーション・Web系と何が違うかといえば、ものすごい短期間にいろんなことが起こります。
リアルタイム処理っていうのでしょうか。割り込みとか聞いたことありませんか。
要はOSがないので自分でなんでも考えなきゃいけないわけです。
CPUの検証はMISRA-Cや専用のカバレッジテストツールで行います。
接点の調整とかLCDパネルとかメンテナンスのツールだとかがないと装置に指令を出せません。
これらにもCPUが入っているわけなので別にコードを書く必要があります。組み込み系の仕事です。
これは言語でかけるリレー回路です。リレーってのはスイッチです。
スイッチを操作することで接続されている機械を操作（電源の入り切りとか）します。
これもCPU,PLD等とは全く違う方式（ラダー）で書きます。十分組み込みの仕事です。
ユニット試験では通っても、組み合わせ試験で動かないというのは１００％あると思います。
試験の仕事じゃないと思われるでしょうが、自分はここも立派な組み込み系の仕事だと思ってます。
などなど一言で組み込み系の仕事といってもいろいろあるわけです。
上の中の2つ3つを仕事に使えるレベルまで持って行くには10年、20年はかかると言われました。
ここで表題の件なのですが、元増田の人は経験8年なので、例えばFPGAを8年やってきてCを書けと言われても大変だと思います。
特にその後にWeb系の仕事（これも一言で表すにはいろいろジャンルがあると思いますが）をされてきたとのことなので
いろいろとあったのだと思います。逆にずーとやっていた分野のことを任せるといいかもしれません。
まずどんなことをやってきたのか聞いてみたほうがいいと思います。
無い。C言語（＋＋含む）の開発能力で開発競争をしていては、開発が間に合わない。
その言語を介して、おそらくLLVMを通してネイティブへのダイレクトなコンパイルになると思われるからOSの壁はわりと超えやすい。
その関係上、OSに要求される機能はRTOS程度の機能になるだろうが、RTOSその物は余程の性能でない限りLinuxでもユーザーランドとドライバで解決可能。
それに、よく要求されれる機能はLinuxにパッチ当てても可能。
結果論として、OSその物の高機能化勝負にはならない。勝負になるのはOSのエミュレーターというか開発環境。
より開発しやすい環境を整えたほうが勝つ。正確には、自動車が要求する水準までのサービスの開発とテストを高速化して支える技術。カバレッジとかね。
OSその物は限られた天才が作るだろうが、その天才の質は日米共に大差は付かない。もしくは買ってきても構わない。
問題は、その下に必要な大量の普通のプログラマーと、そのプログラマーが作ったものを天才が書いたものと遜色ない品質まで持ち上げるシステム。
要するに、日本刀ではなく、火炎放射器やマシンガンのように普通の兵隊をどこまで強化できるか？という競争になる。
ただしまぁそれは、今の自動車メーカーが考えているようなものではないから、そこの開発装置の競争でGoogleにボロ負けするだろ。
とあるプロジェクトをフロントエンジニアとして手伝っていて、2500行程度のそびえ立つクソなJavaScriptの改修を頼まれていた。
git blame しただけで最低でも10人このJSファイルにコードを追加していることがわかった。最初のコミットは2010年の2月ごろだから。最初からいるエンジニアの人に話を聞いてみたらこのJSは20人近い人がいじっているらしい。
別に関わっている人数とかはどうでもいいんだけど、変数名が謎すぎたり、関数の名前と中身の挙動が合っていなかったり、まぁひどいコードで、それを半月ぐらいかけて、個人的な安心感を高めるためにも、最初はheadless testとかcapybaraでテストをもりもり書いて、カバレッジを高めて（期間的に100%にはできなかったけど、C0で70%ぐらい）からリファクタリングしていたら最終的にCoofeeScriptに変換して700行ぐらい（JSで1000行ぐらいかな）になる予定（追加開発があればまだ増えるかも）。消えた部分は使われていない関数とか無駄な処理とかコメントだったかな。
だいたいなんでこんなことになったかっていうと、経営者がアホな要求ばっかり今までドキュメントを用意していなかったりするからそびえ立つクソコードが生まれたという感じ。CoofeeScriptにしたのもある程度書式を固定したかったから。
同時にGithubのPRベースの開発も導入した。俺が入った時には他に3人のフロントエンジニアがいてその人達のコードを見ながらもやってた。その人たちはあんまりプログラマとしての能力が高くなかったのでPRベースでJSの基礎なんかを教えながらやってた。プロジェクトに入ってからは俺はずっとテストの環境を整備していて、今いるプロジェクトメンバーはまだテストをかける状態じゃないから、PR送られてきたらそのブランチに対してテストを追加したコミットをぶん投げるという感じで進めていた。
もちろん、PRだからJenkinsと連携してテストを走らせるようにしたらフロントエンドチーム、3人ともかなり安心感をもって開発をすることができましたとさ。俺はこのプロジェクトとは今月末でさよならだから、俺の仕事はドキュメント書いたりレビューをする文化を根付かせて終わりって感じかなー。
あと、JSのテストとかViewのテストの仕方3年前にくらべるとだいぶ情報が増えてきたし、フロントエンジニア〜な人達もテストに身を委ねてみるといいと思った。
事業環境は厳しいです。ドル箱だったiモードの栄華も今は昔、「ただの土管になりたくない」という強い意志も、いまや具体的戦略のないただの願望になってしまいました。通信インフラはコモディティ化していて他キャリアとの差別化はできなくなったどころか、LTEのカバレッジでは最も出遅れている始末。他キャリアへの流出が止まらなくなり、キャンペーンの甲斐なく何度も純減を繰り返しています。もはや減収減益の構造が定着しつつあるといっていいでしょう。
そこでiPhone導入が取り沙汰されるわけです。
確かに、まだiPhone人気が十分に高い日本では、短期的にはiPhone販売がMNP流出防止＆純減ストップの切り札になることはわかっています。それでもiPhone販売に踏み切れない一番の理由は、これまで株主総会でも日経記事でも繰り返し観測気球を出してきたとおり、Appleが課す高い販売シェアノルマ---一説には50％---がドコモの負担になると予測されるからです。
でも、「販売ノルマ率を切り下げてくれればウチも採用しますから、そこは何とかお願いしますよ」というドコモからの数年越しのメッセージに、Appleは反応しませんでした。確かに中国・インド・アフリカといった途上国の巨大市場に比べれば、ドコモはたかだか6000万契約の極東のいちメガキャリアでしかありません。最後発のドコモに対して契約条件を緩和したら、当然ソフトバンクやauも最恵国待遇を要求するでしょう。Appleからすれば、各社に販売ノルマを緩和したらトータルではツーペイになってしまうし、利益率を緩和したら、まだiPhoneが高い競争力を持っている地域の市場を自らスポイルすることになってしまいます。Appleがドコモに妥協してやる意味は今のところないのです。
だから、ドコモにはもう後がなくなってしまいました。とにかくiPhoneの販売ノルマをクリアできる体制を整え、iPhone販売契約に踏み切るのが喫緊の課題です。そのためはどうすればいいか？ iPhoneを豊富な選択肢のなかのワンオブゼムにしてはだめですよね。実際に数を捌かなければ、Appleが課すペナルティで今度は営業利益率がガタ落ちしますから。となれば、今は1シーズンに10機種も出しているAndroidスマートフォンの投入ラインナップをせいぜい3〜4機種程度に絞り、それらとは別格の位置づけでiPhoneを売りまくらなければいけなくなります（ソフトバンクやKDDIは実際そうしています）。「業績回復のためにやれるべきことは全部やっている」と株主に説明するためのステップとして、これはもう必須の条件でしょう。
さて、では実際にラインナップのどこを整理して、誰にiPhoneを売ってゆくのか。ドコモの既存ユーザーのうち、特に重視すべき移行見込層は、1）フィーチャーフォンのユーザーと、2）Androidに乗り替えたものの、その機能や操作性に不満があるユーザー…ということになるでしょう。1）はかつてブランドだった「ドコモのN」や「ドコモのP」などを長年ご愛顧戴いてきた層。2）は、Android機種のなかでも差別化に失敗しているコモディティ的端末、すなわち、N・P・F・SHのユーザー。これらのユーザーを「わかりやすいですよ」「使いやすいですよ」とiPhoneに誘導してゆくためには、これらのセカンドラインのメーカーが作るスマートフォンは、むしろ、選択肢から消えていてくれたほうがいいですよね。
こうして事前にキャリア内の浮遊層を作っておき、適切なタイミングでiPhone移行キャンペーンを投下すれば、そこは衰えたりとはいえ国内最大の契約者数を誇るキャリアのドコモですから、その数字的なインパクトはかなり大きいはずです。
だから今回話題になった「ツートップ戦略」は、巷間言われているように、スター機種のXperiaとGalaxyを重点的に売り込むための、攻めの施策というだけではありません。それは、来たるべきiPhone時代を見据え、長年ドコモと蜜月関係にあったメーカーたちと縁切りすることを意図した、非情な身辺整理の作業でもあります。今般報道されているNECカシオやパナソニックモバイルのスマートフォン撤退は、ドコモの販売奨励戦略の「失敗」ではなく、はじめからの狙い通りの「成功」だったというわけです。
ネット世界では投資家、ゲーム開発者、ラノベ作家、企業探偵、ベルロックメディアシニアマネージャーなどの華麗な経歴で知られる山本一郎さんという人に拙文へのリンク貼っていただけたようで、恐縮至極、汗顔の至りです。
【悲報】ドコモ関連で「いかにも」な与太記事が増田に掲載され局地的に話題に(山本 一郎) - 個人 - Yahoo!ニュース
はい、もし上の文章からそんな経緯を想像する人がいたら、企業経営には向いていないでしょうね。山本一郎さんがドコモの経営陣だったとしても、当然、Appleと今期以降のiPhone販売契約について話の筋道をつけてからの「ツートップ戦略」で年末大水計に打って出るのではないでしょうか？ 見込みベースで話を進めて裏目に出たら、ツートップ転じてオンリーツー状態になってしまいますのでね。もしここまでの話がすべて机上の空論なら、それはすなわち、「ドコモは次の機種サイクルから事実上ソニーとサムスンだけでスマートフォン市場を闘い続けることを選んだ」という話になるわけです。
しかし、本邦のモバイル業界のフラッグキャリア格ともいえるドコモが、たった2メーカー×1〜2機種の最新スマートフォン・ラインナップで次の秋冬商戦に挑むなんてことがあるでしょうか？ この会社は今年に入ってからの一連の動きのなかで、どんなコストを払い、何を仕込んでいるのでしょうか？ 山本さんが並べているリンクの数々も、ツートップ戦略が「単体では」純増の切り札として奏効しなかったことを示していますが、それは本当は「切り札」ではなく、さらなる戦略転換のためのひとつの手段だったのではないでしょうか？ 予定では2013年中に市場投入され、サムスンとの密な提携関係ならびにモバイルOSの第三極戦略の礎となるはずだったTizen派筆頭の永田氏をいきなり傍流に追いやってしまったことには、果たしてどんな意味があるのでしょうか？
さまざまな状況証拠から考えて、今のドコモがその機種戦略・プラットフォーム戦略の中に、何か大きなパズルのピースがはまるための「スペース」を作っていることを全否定できる人はそういないのではないでしょうか。そして、その巨大な空白に当てはまる商品は、現状では1つしかありません。
もう、おわかりですね？
みたいな感じで、関数コールを嫌う文化だからなぁ突き詰めると。
そういう事をしようと思わない。別な書き方をするとかじゃなかろうか？
いちおう、C++ならクラス内にクラスは書けるから似たような事はできる。
C/C++は文化的に速度とメモリを重要視する言語だから、あんまりね、そう言うのは主流じゃないと思う。
class A{
private:
int A:
public:
A=a;
}
}
みたいなことも・・・あまり、おすすめできないし・・・。論理的には美しいんだけど・・・いろいろ弊害もあると考えるのがC/C++
ましていわんや、関数内。
※一番痛いのは、設定関数が1箇所なので、動作変更がすぐできる＞＞大規模システムではコードカバレッジがあるので、
根元の関数の挙動を大きく変えられたら、上位のクラスの莫大なテストやり直しだから、1箇所変更で全箇所変わるのはデメリットｗ。上位で修正が基本。
というか、やっちゃだめｗｗｗ。
たとえば、intをdoubleにとかなら、それもう別物だから、上位も変更でしょ。普通・・・。とか。
あと#define関数はデバッガーでおえないので、なるべくC++のコンパイラ通してinlineで書いてぇぇぇぇとか。色々。むしろ#defineで複雑なことしないでー
ストアードプロシージャでビジネスロジックを実装するメリットを認めつつも、以下の点からビジネスロジックをクライアント言語で実装できる場合はできるだけそうした方が良いという結論に達した。
RDBMSによっては無料あるいは有料でソースレベルデバッガを使用できる場合もあるが、通常はクライアント言語のデバッグ機能を使う方がはるかに便利だ。何か問題があったときに、どこが問題なのかを見つけることがクライアント言語で記述した場合よりもはるかに時間がかかる。
また、Unit Testing Framework(xUnit)も使用できない場合がほとんどだ。
ストアードプロシージャ用の静的解析ツールの存在を知らない。巡回的複雑度を知りようにも知るすべはないのだ。それが行えるツールを知らないだけかもしれないが。
仮にストアードプロシージャの変更を全てAlter xx等で構成されたSQLスクリプトファイルで管理し、それをバージョン管理システムに含めたとしても（というか、最低そうすべきなんだが）、あるリビジョンのコード一式に対応するデータベーススキーマを取り出すのは難しいか面倒だ。
トリガーでビジネスロジックを実装する場合も、上記問題点が全てあてはまる。
さらにトリガーの場合は、どのような場合にどのような処理が実行されるのかを俯瞰することが難しくなるという問題もある。
一つは、Oracleで言うところのストアードファンクション、つまりSELECT等のDML内で使用する関数で、そうした方がパフォーマンス的にも良い場合。
