「単体テスト」を含む日記 RSS

はてなキーワード: 単体テストとは

2018-08-11

http://blogos.com/article/317015/

例えば次の一文を取ってもこの人がシステムというものを何も理解できていないことが分かる。

コンピュータは考え得る限りの状況をテストしてから製品となり、日時を扱うシステムなら「2100年に2月29日はあるか」という処理までチェックするものです。」

テスト実施には、時間費用人材などのリソース必要だ。

リソース無限にあるなら「考え得る限りの状況をテスト」することが可能だが、実際のリソースは有限だ。

極論すれば、1万年後、10万年後までのテストをするのか、考えてみるとよい。

また、テストには局面というものがある。

「日時を扱う」処理はライブラリにするのが普通だ。

ライブラリ単体テストでは、「2100年に2月29日はあるか」というテストを行うかもしれない。

しかし、結合テストシステムテストテスト局面が進むたびに、いちいち「2100年に2月29日はあるか」というテストを行うと、テストケースが爆発的に増えてしまい、これも現実的ではない。

「2100年に2月29日はあるか」というケースは、ライブラリ単位では保証されるかもしれないが、システム全体として保証されることはまずありえない。

2018-06-04

ここもちろぐ

生産性志向SEが、IT業界での奮闘記や仕事生活で学んだことをはきだします。

 2018-05-15

みずほ銀行炎上プロジェクト支援に行ってきた話|問題

プロジェクト

gizeh-2272008_640

こんにちは。もちです。本日は、みずほ銀行プロジェクトで2か月限定支援に行った時のことを話したいと思います

あの頃は、ちょうどポケモンGOリリースされた時期でした。 プロジェクトのお昼休みに、わくわくしながらアプリを立ち上げて、メンバーの方と遊んだものです。

そんな次期システムが、いよいよ、2018年6月9日から徐々に移行開始されるそうです。

みずほ銀、9日からシステム移行 「世界最大級プロジェクト」 ATMネットバンク臨時休止日 (1/2)

みずほ銀行みずほ信託銀行は、入出金や口座管理などを担う勘定系システム統合した次期システムへの移行作業を9日から始める。4000億円超の資金を投じて進めてきた世界最大級プロジェクトが、最後のヤマ場を迎える。

www.itmedia.co.jp www.itmedia.co.jp

www.itmedia.co.jp

移行が発表されてから、「あの頃が懐かしい」と感じたため、せっかく浮かんだいろいろな想いを残そうと思って記事しました。

記事では問題点のみ扱い、

▼次記事で学んだことを記載します。

ここもちろぐ

ここもちろぐ

id:cocoamocchi

みずほ銀行炎上プロジェクト支援に行ってきた話|まなび編

みずほ銀行プロジェクトで2か月限定支援に行った時の話、まなび編です。 ▼前記事問題編はコチラ www.cocoamocchi.com 古参メンバー仕事を奪う デキる古参メンバーはとにかく忙しいです!! 新規参入者でもやり方さえ一度知れば、できそうな仕事もありそうだということで、積極的仕事を奪いにいきました。 たとえば…

2018-05-17 22:53

www.cocoamocchi.com

職場的に嫌だったこ

毎朝エレベータに長蛇の列

人気アトラクションかな?と思わせるほどの大行列タイミングが悪いと10分以上待たされました。

現場10Fくらいの階層だったので、階段も諦めました。。

スマホは鍵付きロッカーで集中管理

テストフェーズがちょうど一個上の段階に進んだためか、チーム内のスマホは鍵付きロッカーでしっかりと管理されるようになりました。

カバンも窓際に追いやられ、セキュリティ面が厳重でした。

荷物取りに行くだけで時間がかかりました。

インターネットが使えない

security-265130_640 これが一番厄介でした!!!

新入社員であれば、まずはググり力を鍛えろ!と先輩に教わるも方もいるのではないでしょうか。

わたしみたいなIT業界で働く方々は特にインターネットで調べまくる生き物です!

なのに使えないので厄介でした。

・・・はいっても、わたし場合は、こっそり休憩スペースにスマホを持ち出して調べてました。

他には、書籍にもお世話になりました。

ここで 「ネットが当たり前だと思うな、腕を磨こう」という教訓を得ました。

ありがとう執筆者の方々。

改めて書籍を生み出す方々に感謝です。

印刷用紙が真っ赤で読みづらすぎ

持ち出し抑止のために、プリンタ用紙が赤くなっておりました。

(特に持ち物チェックがあるわけではないので、悪意のある人なら持ち出せたかと思います。)

印刷してみるとまあ~わかりづらい。 気持ち的にもなんか落ち着かない。

でも一定の効果はきっとあったのだろう。。

残業前提の雰囲気

ただでさえ生産性の低い環境なのに、働き方もやっぱり残業ばかりされている方だらけでした。

特に既存メンバー古参者は大量に仕事を抱えているので、いつもヘトヘトです。

他の人へのレビューも、当然荒い。

また最終退館者名簿を見ると、お客さまサイドも負けずと毎日23時台まで残っているようでした。

※ちなみに

ごめんなさい、わたしは最長でも21時には帰りました!寝不足すぎると生産性ダダ下がり逆効果なので苦笑。

単体開発 バグ改修

私の場合、残念ながら新規開発部分は残ってなく、仕様取り込みやバグ改修をちょこっとやったくらいです。

開発ではなく、ほとんど仕様整理やJP1いじっている時間が多かったです。

命名規則がつらい

短い単語アルファベット1文字表現する文化があったため、それらをつなげて作成されるDBテーブル名やカラム名新規参入者にとってはしぬほど分かり辛かったです。

銀行システムなのに単体テストが荒い

1箇所の修正で5個もケースはないし、誰も見ないのではないかなというくらい、ゆるふわテスト結果が置いてあったりと、とてもじゃないけどもお金を扱うシステムだとは思いませんでした。

これ、結合テスト以降、バグ爆発するのでは?という印象だった。

今度、どなたか生き残った戦士に聞いてみたい。

構成管理がずたぼろ

the-1865639_640

ファイルサーバジャングル

階層がとにかく深く、無秩序に置かれた何千のフォルダ群はまさにジャングル

既存古参メンバーであったとしても、過去単体テスト仕様書の在り処を探すだけで10分以上かかっていました。

IDEなど開発に使用するツールも、各チーム持っている情報が異なっていて、結局、既存メンバーの持っているものを丸ごとコピーして使ってました。

テスト環境へのプログラム配置申請が3日ほどかかる

個々の期限がタイトにも関わらず、申請日時を厳守しなければならないのはつらかったです。

この申請は、数チームで1つのエクセルファイルにまとめて申請します。

プログラムファイル1つ1つのパス記載していくのですが、 誰かが1ファイル既述を誤るだけで、

申請した全チームのスケジュールが3日遅れます

どこぞやのチームのせいで2連続申請ミスされたこともあり、こちらとしてはたまったものではありませんでした。

しかしたら、誰かが休みたいがために、わざとミスしてるのではと疑いたくなるくらい大変でした。

まあ、とはいっても緊急リリースみたいな1~2日でできる裏技も時に使うことができたため、そこまでではなかったのかもしれません。

プロジェクトマネジメント

child-waving-goodbye-595429_640

メンバーが急に離脱する

うちの会社だけかもしれないけど、メンバー離脱が、作業指示を出しているチームリーダーまでなかなか届かない印象でした。

「来週からこの作業お願いするね」と言っていた矢先に、彼らがいなくなることを知らされる。

リーダーは大変です。多大なる無駄です。

作業工数ほとんど見積もられていない

これは、どこの炎上プロジェクトもですが、各タスクの期限だけ決まっていて、工数考慮されていない事案です。

この事案は仕方ない場面もありますので、メンバー側がリーダープロマネに少々寄り添って、自分仕事を考えていればOKです。

親切なプロジェクトじゃないのは分かっていることなので、他責にせず、ざっくりと工数を伝え、助けていきましょう。

新規参入者の実力が怪しい

少し言語知っている程度(for、if文はできるけど・・)で意思疎通の難しいプログラマー国籍わず、たくさんおりました。

猫の手も借りたいくらい忙しいプロジェクトだったので、自分主体的仕事を考え、動き、古参メンバーを助ける必要があります

しかし、

古参メンバーに何から何まですべて聞く

進捗が良くないことをごまかす

理解できていない部分をごまかす

よく分からないけど、なにかやばい

など、この中のどれか1つ該当ではなく、複数持ちのプロジェクトキラーが何人かいました。

特に進捗ごまかす人はひどかった。

他の人も急に想定外残業フォローをしなければならなくなるし、本人は無駄に悩み続ける時間増えるし、誰も幸せにならない感じでした。

まとめ

炎上プロジェクトには人的問題がつきものです。

特に銀行プロジェクトは、生産性の低い現場やずたぼろな構成管理など、環境問題も多いことがわかりました。

同時に他責にせず、主体的に行動すれば、新規参入者でもそれなりに活躍できることもわかりました。

しかし、わたし場合、2か月限定が配属前から決まっていたこともあり、

心までしんどくならずになんとか戦えたことが大きいかもしれません。

正直、炎上案件には参画したくない笑。

もし炎上案件出会っても、 心や身体をやられるようなことがあれば即刻辞退をおすすめします。

残業による残業という負のスパイラルが、もし嫌なら、早く抜け出すほうがこれから人生豊かです!

断言できます!!

一時的な損はあるかもしれませんが、長い人生においてそんなもの一瞬です。 ではでは、良き人生を!

2018-04-28

ステップ

数年前に開発会社から全く別業界システム部門に入り、受注者から発注者立場が変わったので良い発注者になろうと頑張ってきたつもりなんだけど

日中途で入ってきた同僚が、長く付き合いのある開発会社に「改修案件の見積もり根拠が分からないので改修対象ステップ数とソース数を出せ」とか言い出して、それを止めようとした自分喧嘩になった、しかも「改修見積もりをしたのならステップ数は当然すぐに出せるはずだ」と言いながら

そいつは以前にも「単体テストの結果も全て説明付きの画面キャプチャエビデンスとしてつけろ。これは当然の事で、テストをしたのなら作っているはず。だから追加工数も払わない」と言い出してこれも喧嘩になった


残念ながらうちのシステム部門は専門の人材がいない為、こいつの言うことのおかしさを理解してもらえない

「規模を知るためにソース数を貰うのは当然の事です」とか言い出して、それをまわりが真に受けてしま

いくら自分反論しても1対1の話なので「やり方は色々あるからね」と窘められてしま

さらに本人には少し反論すると絶対に認めずかなり攻撃的に返されるという厄介さ

感じた事の無いレベルストレスを感じています。助けて…

良かったら対処案とか下さい…連休けが憂鬱だ…

2018-03-13

ひたすら単体テストをするにはどうしたらいいのか、単体テストをするようにコードを変更した後、その旨を安心して確認するにはどうしたらいいのか、

みたいなことを考えている(まぁ、こういうの好きやし、前のチームとタスク的に差がないからありがたいんやけど)

2018-02-14

anond:20180214191853

外注が「単体テスト自動化してますんで」って言うから意識高いな」って思ったんだが

納品物見たら、テストフレームワーク独自で、テストレポートカバレージも出ないし、テストコード中に「何をテストしているのか」のコメントも無いし、ほんとクソだな、と思ったことがある。

プログラマとして「あっ俺コイツに負けたわ」と思う瞬間

単体テストをちゃんと書いてるコードを見た時

2018-01-19

事業会社データサイエンティスト 会社退職しました

元々コンサル会社から事業会社のほうでデータサイエンティストをやるようになって1年経つが辞める。そのきつかったことを匿名という場所卑怯ながらも話したいと思う。

元々私は大学院でそこそこ統計をやってきてからコンサル会社に行きデータサイエンティストとして事業会社へ移った口だ。

根本的にデータサイエンティストとしての資質としてざっくりいうと以下の3つが必要だと思われる。

1. 統計能力関係及びそのプログラミング可視化能力

2. KPI設計及び事業からKPIへの落とし込みからそのKPIからどう事業繋がるかというビジネス設計能力

3. 上を基にしたコンサル能力

能力的には1がやや強く、その次に2がまぁまぁそして3はまだまだといった所で事業会社データサイエンティストとして孤軍奮闘をすることになった。

 入社理由

データはあるが、なかなか活用できていないこともあり、分析から企画から関われるという事で入社しようと思った。

後そこそこ大きな会社で働くのも良い経験と思い入社を決意した。ニッチな分野ではあるが、この分野ではTopカンパニーである

 実際の業務

最初の4日ぐらいは会社研修とかで潰れるのは仕方ないもので、それが終わり早速の業務を行う事になった。

まずはデータ各部門に依頼してから頂くのだが・・・

貰えない。

許可申請関係で3週間程かかってからまず最初データを頂けるようになった。この時点でやる気を削がれた。

更にデータ確認という事で事業へのヒアリングを進めるだけで・・・6週間程かかった。更にやる気を削がれた。

この辺りで気付いた事だが、コンサル会社でいたときは、データ確認がスピィーディーだったのに何故こんな遅い作業なったかというと

日本企業部署跨ぐというのはとても大変で、コンサルとしてやっていたときは単価も高いし、期間内でやらないといけないという事で

いろいろと調整がスムーズに進んでいたという事がこの時に分かった。コンサルとして外から見ているとやはり分からない事は多い物である

分析ツールエクセルだけ

データ確認も終わり、分析をし、改善を行うテーマを決めて進める事になった。この時点で2カ月ぐらい過ぎていた気がする。R/Python自分パソコンへの許可申請を出すが、降りない・・・会社的にはCならばOKだと言われる。でもCの追加ライブラリー関係ダメらしく・・・悩んだ結果エクセルを基に分析をする事になった。現状把握のために基礎集計をするが、エクセルSQLで言うGroup_byやら違うデータ同士をくっつけるためのJoinを32 bit エクセル関数ベースでやると何度も落ちる・・・。この時点でやる気は地の底へと落ちていた。

この辺りでCベースでもう書き直そうかと悩むが、流石にCのライブラリーがない所でフルスクラッチ調に書くのは工数的にかかると考えたのでvbaを用いていた。

エクセルベースでの可視化から上司関係者にデータ分析の結果を見せていく。この辺りでデータ分析から改善策はまとまっていた。しかしこの辺りでやる気をマイナスにして頂ける言葉を伺う。

私がVBAを書いているのをちらっと見て

プログラミング何かやっていても仕方ないし、プログラマーではねぇ・・・。今後会社ではプログラマーなんていらないか企画できるようにならないと」

勿論これは直属の上司からのお言葉ではないが・・・正確には同期である・・・もはや殺意すら覚える。因みにこの人の既存サービスの改良プロジェクトが回った時のデータ収集したら分析する事になっていたが、プロジェクトスケジュール感を見ると

要件定義 2週間

画面設計及び機能設計 3カ月

開発 4カ月

単体テスト・移行テスト 5カ月

運用以降

みたいな形でうん?何か少なくないか?と思ったら既存サービスに関してのギャップ分析無しに既存サービスの改良を進めているらしい

・・・その上取れるデータは〇〇〇で〇〇〇は無いらしい。あっそんなん改善出来んやん・・・。一応私はアリバイ工作のためにメール会議にて発言する

・・・空気を読めないと言われ会議呼ばれなくなってしまう(因みにこのプロジェクト要件定義から運用以降まで外注である)。

最早これは逃亡しかないだろうと心に固く決めてしまう。

私のコンサル的な能力がなかったと言えば確かにその通りである。でもいやうん日本企業の中で、分析をやっていくのは本当に難しいというのがよくわかる。

一人だったというのもある・・・でも殆ど基礎集計レベルで難しい用語を使わず改善を行おうとしたいやでもこの日本企業では無理だった。そしてやりたいと思わなかった。

たまに日本企業でのエンジニアの不遇差を嘆く記事を見かけるが、割と同じようなパターン臭いがする。

追記

新規リニューアルは当然のごとくつぶれ、また私がよくわからない事にawsへの移行だけは上手くいき(?)

200万pvの会員サイトAmazon aws料金を月々リザーブインスタンスで80万ぐらい払っていてクラウド安くないと社内的に炎上しているらしい。どんな設計したのかは

もはや手をつっこみたくないレベル

2017-12-22

転職失敗した

失敗した。直属の技術リーダーがクソ。

入ってすぐ担当した案件自分ギリギリ納期間に合ってテストフェーズに入ったんだけど、そのテストテスト担当ソフト全般的機能をチェックしていったらソフト全般不具合だらけだった。自分担当した範囲ではない。自分入社からあったやまほどのバグの山。

それが、なぜか自分単体テスト不足にされ、激しく責められた。袋叩き。

いや、担当違うし、今回のリリースでの改修はここからここまでって決まってたでしょ、ってワイがいくら言っても無駄リーダー、本気で単体レベル不具合多すぎのクズプログラマだと思ってる。あなたがいたその数年間に生み出された山ほどのバグなのに、だ。クソすぎる。胸糞。別の上長かに相談してるし相談は今後もしていく。

「どうしてそれを直そうと思わなかったの?疑問にも思わなかったの?」って、それ言われるなら、こっちからしたら「なんで入社から数年単位であったものばかりなのにあなたたちそれを直そうとしなかったの?」なんだが。

金曜の夜に思い出して激しく不愉快

2017-04-21

単体テスト盲信してる皆様へ

そもそも意味あるのかちゃんと考えてる?

単体テストを書けばバグが減ります!」

単体テストのお陰で精神的安定を保てます!」

馬鹿じゃねーのかw?

テストコードメンテなんてデバッグの手順書メンテしてるのと大して変わらねーよw

その単体テストが本番と同一の動作テストできてる保証はねーって気づけボケ

本番と同じ動作テストたかったらデバッグしろ

なんで別のコード書き始めちゃうの?無駄じゃん馬鹿じゃん

それと「テストコードがあるから安全です」なんて寝言まだ言ってるの?

プロジェクトが進むにつれソース依存ライブラリも変化する以上

いつも同じ結果になるわけじゃねーだろが、(保守しないって選択はあるけど金入ってこないだろ)

本番でもテストコード動かしますってやつら以外無理して単体テスト書く必要ないんじゃねーか?

お前らが欲しいのは軽いデバッグモードであって単体テストじゃねーだろ?

工数削って単体テストを書いてソースが変わったらエラーになるからテスト書き直して・・・ってどう考えてもお前らが望む世界じゃないんじゃねーか?

流行りのTDDするくらいなら新人デバッグやらせた方がよっぽど筋がいい

というわけでよく考えなおせ

みんなが単体テスト言ってるから無理やり使うって運用やめろ

http://anond.hatelabo.jp/20170309040708

追記: 元ネタを茶化したジョークです

2017-03-23

わたしはしごとがあんまりできない。

具体的に言うと、

日本語での説明あんまりうまくできない。今日も後輩にJVMってなんですか、Staticってなんですかって聞かれたけど、なんかうまく説明できなかった。

あーなってこうなってっ説明しても、相手は「???」みたいな顔をしている…。

・深く考えられない。相手から意見言われと、思考が停止して「それが正しいまさに正解だ」という気持ちになってしまう。

たぶん他人から「1+1は3だよ」って言われたら、「えっ!?そうなの?そうなのか…」みたいな気持ちになって、最終的に納得してしまう。そんなレベル

不適切な場面で万能感が湧き上がることがある。「なんかできる気がする!!!スイッチが突然入る。

ただ、それは大体「気がする」止まりで、最終的に痛い目をみることが多い。

今日JVM説明するとき説明筋道考えてる最中に突然「なんかできる気がする!!!スイッチONになってしまい、

その勢いのまま説明を始めてしまった。結局、私の口からはぐしゃぐしゃした言葉しか出てこなかった。

単体テスト仕様書を作ると、割りとテストケースが足りてない。しかもそれは難しい観点のケースじゃないんだ。

自分の中で、もはや当たり前になってた観点なのに、ときどきボロンと抜け落ちる。

・誤字脱字などのケアレスミスも多い。印字切れとかもよくやる。

主体性がない。責任感がない。当事者意識がない。進んであれやりますこれやりますって、言ったことないなあ。


…もし上記を読んで「あーああいタイプ人間ね」みたいに想像ついた方いらっしゃったら、

恐れ入りますが現状を改善するためのアドバイスいただきたいです…。

上司に「そのままのキャラでいいよ」といじられるけど、本音は"もう諦めてる"なのかなあ。

ちゃんとした人間になりたいよ。

2017-01-26

とあるFのFなSIer現場

他を知らないからひどいのかひどくないのか分からない。教えて

受託開発だよ編
環境
  • 会議用の長机に2人。仕切りなし、狭い
  • 引き出しは2人で1つ。共用
コンピュータ
開発環境
バージョン管理システム
ソースコード
規約
構成管理

2016-12-18

EXCEL使いとしてこのまま沈没していく

はてブでよく見る意識高いIT系記事では、EXCELとにらめっこするだけが仕事技術力のないSEは今後淘汰されていくという話をよく見る

まさに俺のことだ。

入社して10年、EclipseもVisualStidioもロクに触っていない。

流行りのテキストエディタには触るけどやることは構築手順書の執筆だ。メモ帳でもできる。

 

日々やってる業務といえば要は代筆業。

営業が色んな客から仕事を取ってくる。仕事内容については、客によって方言がある。

あっちの客が要件定義と呼んでるやつはこっちの客は基本設計だ。そっちの客が機能テストと呼んでるやつはうちでは結合テスト単体テストの一部を指す。

こういうのをいちいち内情に合わせて翻訳し、うちのエンジニアに伝える。

エンジニアは単にアウトプットを出せばいいだけなじゃく、うちの会社品質保証チームのルールに合わせて物をつくらないといけない。そうでないと会社名前リリースできない。

そんな内向きのルールで作った物をまたそれぞれの客向けに再翻訳してリリースする。チェックの結果足りないものは俺が書く。

 

品質保チームの言ってることは間違ってはいない。

世の中はアジャイルカンバンリーンだ。彼らの提唱した業務改善に従っているお陰で、一時期のように無駄な後戻りも属人的作業もだいぶなくなった。

タスクカンバンレベルで分割したことで、エンジニアの手が足りなくなった時にも技術力のない俺が手助けできるようになった。

要は仕様書類や評価計画書を代筆したりすればいい。ここは正直認める。

ただ、アウトプットをお納めする先の客はまだまだウォーターフォールのところばかりだ。奴らは○×設計書、△□評価報告書要求する。そのギャップは誰が埋めるの?

 

はじめはエンジニアチームがみんなでやってたり管理者がやってたんだが、次第に俺に集約するようになった。

そのほうが効率がいいからだ。

そうなったきっかけは、同僚よりわずかながら俺ができなかったからだ。その時点で俺が悪かったのは認める。

ただ、分業してるうちに同僚エンジニアたちは最新の技術と開発環境でどんどんスキルを上げるのに、

俺がやってることといえば客のフォーマットに従ったWORDソースから自動生成されたクラス図を貼り付けて説明を書くとか

Redmineバグチケット数をEXCELに集計して提出書類にするとか、そんなの。何の生産性もない。

 

このままこの会社で働き続けるなら問題ないと思う。特に俺だけ負荷が高いというわけでもない。

しかしこの環境がいつまで続くのか、誰も保障はできないだろう。

もし何かあった時、同僚エンジニア達は市場価値も高く、どんな環境でもやっていけるだろう

じゃあ俺は?EXCELWORDしか使えないエンジニアでもない俺はこの会社から放り出されたら何もできない。

 

じゃあ何したらいいかっていうのも考えられない。日々仕事は積まれていくし、もう決定的な差がついた。

あとは会社が存続することを祈りながらEXCEL使いとしてこのまま沈没していくだけだ。。。

2016-11-05

なぜソースじゃなく詳細設計を欲しがるのか

Javaを始めとするオブジェクト指向言語による開発になると、設計手法も従来とは大きく変わる。

その結果、不要になるドキュメントが出てくる。

詳細設計のことだ。

ここでいう詳細設計とは、本来コード記述する処理を、逐一日本語で書き下したものを指す。

てか、そんな物を読むくらいなら、現物ソース読めよって話だ。

だいたい、ソースに書くレベル粒度記述を、なんでいちいち日本語なんて表記揺れも甚だしいフォーマットで書かにゃならんのだ。

何よりソース修正が入ると、遡って詳細設計も直さないと整合性が取れなくなるので、言うなれば二重に工数を掛けることになる。

「違うよ、設計を直して実装するんだよ」というが、合理性を重んじるSEPGという人種が、実質同じ内容を何度も書きたがるわけがない。

それに、単体テストくらいまでの段階ならともかく、開発要員が縮小される結合テストシステムテスト以降で、そんなことをしている余裕など現場にはない。

結果、実装と合ってないドキュメントけが放置されてしまう。


でも、そうなることが目に見えているにも関わらず、欲しがる客や元請が後を絶たない。

負担ばっかり増えて、尚且つ無意味作業やらせるなって感じ。

なんでそんなに「日本語訳」が欲しいの?

ぶっちゃけソースコードレビューでいいじゃん。

もし客がソースを読めないなら、その時に客が読みたい部分だけを元請が訳して説明すればいい(全部読みたがるヒマな客なんてそうそういないだろうし)。

そして元請はITプロなんだからソースなんてスラスラ読めて当然なわけで。英語読めない英語専門家存在しないのと同じ理屈ね。

それこそ読み取り専用でリポジトリアカウントの一つや二つくらいいつでも作れるので、ソース抜き打ちレビューどうぞって話だ。


はいえ、別に何も「真実ソースただ一つ!」なんて言うつもりはない。

ソースに行き着くまでにも考えることは色々あって、その考えた結果は全て形に残さなければならない。

ソースもまた考えた結果の成果物の一形態であり、他の形態が、各フェーズで書くドキュメントなのだと思っている。

そしてドキュメントがあるお陰で、システムがトラブった時もいきなりソース問題箇所を探し回る苦労から解放されるのだ。

ドキュメントを手がかりに「このクラスの、このメソッドが怪しい」まで行き着いてから、そこで初めてソース確認すればいいと。

Javaだったら、ユースケース図、アクティティ図、クラス図、シーケンス図、Javadocによるメソッド説明と読み込んでいってアタリを付け、それから当該メソッドソースを読めばいい。

逆に言えば、記述粒度が同じ成果物は2種類以上も要らない。整合性を保つための手間が増えるだけなので。

詳細設計書は不要というのはそういうことだ。

つーか「ソースが読めないか日本語訳を渡せ」とか甘えんな

2016-06-20

http://anond.hatelabo.jp/20160619234906

超訳すると

テストコードカバレージが100%だったとしても実際の打鍵結果でエラーは弾けることが多いのにリリースしてしま

は、

単体テストコード100%合格だったとしても実際の打鍵結果ではエラーが発生することが多いのにリリースしてしま

ということかな?

2016-03-04

単体テスト落ちたRSpec死ね

キーワードとかマッチャとか多すぎだろ。

あと「最近RSpecの書き方じゃない」ってなんだよ。

俺はRubyを書きたいのであって、最近RSpecの書き方なんて興味ないんだよ!

2016-02-16

http://anond.hatelabo.jp/20160216154744

基本設計書:UIを書く

詳細設計書:アルゴリズム(入出力)を書く

であって、どちらもドキュメントベース必須だって認識はワイもある。

テスト単体テストならともかく、結合テストだとテストケース文章になるのが当たり前なのでこれも資料必要やな。

いづれも、省くと後が怖いで。

SEの多いはてな民達に色々教えて欲しい入社4年目のワイ

入社して4年目である

まりコミニュケーションが得意ではないのもあって、入社直後は非常に苦労した。

正直人見知りだったのでわけのわからないことをのたまっていた時期もあった。

はいえもう4年目であり色々と手馴れてきて精神的にも余裕ができてきた。

しかも、最近現場は9時-5時で帰宅できるようになり肉体的にも余裕がでてきた。


と、ここらでレベルアップを図りたいと思っており色んな設計書の問題点を指摘した記事とかを読み漁ってきたわけだが

どうも、いまいち記事を読んでいてもしっくりこない。


アジャイルだの詳細設計書がゴミだのいろいろ指摘しているのは見かけるのだが今の自分現場環境があまりにも違いすぎてピンとこないのだ。

なんせ、入社してからやったのがガチガチのウォータフォール型の開発でアジャイルだのなんだのをまったくやったこともないからだ。


Gitなんて使ったこともないし、eclipseSVNソース管理し、古いシステムならCVSだって未だに現役がちがちだ。

幸いにもドキュメントはがっちり作ってあって過去システムがどういうものなのかはよくわかるようになっているが。


もちろん転職しちゃえとか色々まぁ考えようはあるが別に今の会社に大きく不満があるというわけではない。

そこでSE経験の長いお歴々に色々尋ねたいことがある。

機能設計書とか詳細設計書の具体例がぜんぜんわからん

http://nantonaku-shiawase.hatenablog.com/entry/2014/05/18/012107

↑上記のサイトウォーターフォール型開発の例を逐一説明してくれているがこんな一文がある。

ネット検索すると、みんなが批判している。私も作ったことがない。というか時代遅れと言われがちなSIerの私ですら書いたことが無いのに、書かせる企業 is 何。

詳細設計書という名のゴミ | Gm7add9

詳細設計書ってよくわからない - 未来のいつか/hyoshiokの日記

詳細設計書に何を書くべきか? - Sacrificed & Exploited

EXCEL設計書 Vol.1 怪文書大公開 | Same Old Lucky Day

詳しすぎる詳細設計書 - SiroKuro Page

設計書の非常識1.設計書には詳細な実装方法を書く - Sacrificed & Exploited

職業PGにわかFizzBuzz - 日々常々

ネット検索すると、みんなが批判している。私も作ったことがない。

なんだって!!!

俺は入社してからずっとガチガチに詳細設計書を書いていたし、先輩も皆書いてる。

一体どこの世界の話なんだ。

いくつかの現場にも出向したがそこでも普通に詳細設計書を書いていたぞ?


どういうことなんだこれは。

俺の想像している設計書とは実は違うものなのか?

だいたい、機能設計書なんて書いたことがない。


でもよくよく考えたら、なんだか説明されている詳細設計書と機能設計書は俺が書いている「詳細設計書」ではひとつにまとまっている気がする。

まり俺は業界標準がぜんぜん良くわかっていないのだ。

そもそもそんなのないかも知れないが。


そこで尋ねたいのは事例として機能設計書や詳細設計書の具体例が欲しい。

文章説明してるだけだとよくわからんのだ。

書籍でもWEBページでもなんでもいい。

そうじゃないとなんだかそもそも話に付いていけない。

あと、詳細設計書がかけなくなりそうだ(切実)。


テストが良くわからない

JUnitとかで機械的テストをするというのは良く聞く。

ところが俺の住んでいるところではExcelテスト項目を俺が書いて俺が単体テストを手動でやって、結合テストも俺が手やる。


結果列に○だの×だの書いて失敗したらまたやり直しだ!

延々とこれを繰り返す。


別にそれがいやだといってるわけじゃなくて(嫌だけど)、皆テストとかどうやってんの。

テストとかそもそもやってんの?

いや、テスト仕様書がないだけでテストしてんのか?



アジャイルだの何だのに手を出すのもいいのかもしれないがそもそもウォータフォールなV字モデルをぜんぜん理解し切れてない。

誰か教えてくれ。

2015-07-09

プログラムむずかしい

バージョン管理してない

テスト一度もしたことな

ユニットテストとか単体テストとか聞いたことあるけど分からん

Hello worldに毛の生えた程度のコードしかいたことない、しかも写すだけ

Hello worldテストファーストで書くとどんな感じになるべきなの?

コミットってコンパイルのこと?

はじめての○○しかやったことなからはてな話題全然分からん

仕事プログラムしない人には未知の世界すぎてついていけない

2015-05-21

ドキュメントを残さなプログラマ

どうもスーツです。

実際にはスーツは着てないけどギークではありません。

某社に見るシステム開発における社内政治無駄さ加減について

http://b.hatena.ne.jp/entry/d.hatena.ne.jp/NOV1975/20150512/p1

これのはてブと元記事見て血圧上がったので、チマチマ反論するよ。

時間がない人向けのまとめ

記録を軽視するな。

今日常識」が未来永劫担保されることはない。

スーツからすると、ギークに釘を指しておきたいこと

業績が個人について回ったら、誰も保守しないだろ。

金を生むのかそのドキュメントレビューリファクタリングでいくら稼げますか?

ロボットアニメ博士みたいにな、空中から予算が湧いて出たりしないんですよ。

誤解があるみたいだから言っとくが、評価には減点も加点もある。

ただ、スケジュール前倒しで予算が浮くようなシステム作ったりしてないだろ。

何故ならばスケジュールは常にキチキチで、間に合わなきゃ減点されて当たり前だ。

そこは同情する。

見積は常に過少で、調整は過小評価され、日程だけが評価軸になりがちだ。

  • 隣の島の人は同僚ではなく調整相手
  • 文書のない調整結果は意味を持たない
  • 1分で済む会話より3往復かかるメールを選択する
  • やったという証拠を残すためだけのレビュー実施する

オマエらが椅子を滑らせて隣の同僚と1分会話して実施した内容は、キサマが風邪引くと誰にも共用されない。

コードレビューした。仕様書レビューした。まあギークが言うなら内容に間違いはないんだろう。

だが、その部分は三年前に転職した同僚がやったはずです?それじゃダメなのは判るよな?

オマエ独りで完結するプロダクトをオマエがケツもって仕事するなら文句は言わないが、違うよな?

記録に残せ。ドキュメントを書け。やったという事実を示せ。

本来は「指摘事項ゼロ」「問題がないか再精査しろ」「再精査したが無い」「一筆書け」「書いたから通せ」をやるのが正しいというのは判る。

やって欲しいのか。

ギーク不要だと思ってるレビューに、さらチェックリストが加わったり、書類が増えたりするぞ。

  • 予定と違う報告は許されないので報告の数字捏造される
  • できないから遅延するよりも中身が空でも枠だけで出来たことにするのが政治的に正しい

正しい数字で出せ。

恐らく上から順番に怒られた上にいらん書類を書かされた上に再発防止策を延々と書いた挙句本業であるコードを書く仕事が遅延して、さらに同じことがループするが。

政治的に正しいんじゃ無いんだよ。

そうした方が、ギークの遅延が少なくなると思うからスーツが知恵絞ってんだ。

杓子定規スーツが付いてみろ。

ギークが一度遅延したが最後、遅延が無くなるまで延々と再発防止策(しかも一度着手しているのでスケジュール見積もりについて以外でだ)書かされるぞ。

  • どんなに正しくても政治的に間違っていると判断されたことは闇に葬られる

その「どんなに正しくても」は、どこの誰が担保してるんだ。

ギークの勘か?

それ違約金を含んだ形で書面にして公正証書として頂けますか?

  • 言ったもの負けで誰も言わないので全員が負ける(実は言ったら勝てることが多いが賭けを許容しない

オマエが言えよ。

言えないならその立場に無いってことだ。

そして立場のあるもの理由があって言わないんだ。

  • 常識で考えればこうするでしょということを決めるのに年収1000万超の人の判子が100個必要
  • そもそも常識で考えればこうするでしょという選択がなされない

常識で考えればこうする」というのは、何時の時点の誰の判断だ。

未だにCOBOLが現役で使われていると想定してたか

たった30年前までメインフレーム全盛だったが、常識的に今後はオープンシステムだと断言できたか

その選択が為されないのは、ギークの提案が間違ってるからだ。

コンピュータが間違ってると言うタイプか?

違うだろ。

オマエの書いたソースが間違ってて、コンピュータソース通りに正しく動くんだよ。

  • 事前にわかっている問題を指摘するよりも蓋を開けてみたら問題があったということにしてしまうことを選択する
  • わざと調整を怠り認識相違という理由を残す

バッドノウハウなのは認めるが、誰も幸せにならない正しさを貫くことはギークとしての職責の一部か?

もしそう思うならそうしろ

責任は取られてるんだよ。

はんこの数だけな。

機械学習の重み付けと同じでな、それがスーツ出世パラメータに影響してんだよ。

ギークに向けて

記録を軽視するな。

証拠を残せ。

ログ無しにサーバ管理しろと言われたらどう思う?

「なんでバグが無いのが判ってるのに単体テストするんだよ」とか言って、テスターがサボったら困るのは誰だ。

バッドノウハウなのは理解してる。

ただ、監視システムタイムレコード追加するより、カメラ範囲内に時計を置くのがハックなんだろ?

コードスニペットは溜め込むくせに、口頭で言った内容をメールで送れないのは何故だ?

ギークなら可読性を上げろコメントを残せソースを引き継げるようにしておけ。

JavaコンパイラC++ソース突っ込んだってエラー吐くだけだ。

クソコンパイラだと思っても、作法には従って書け。

まあ、見通しが悪いと思うなら、オマエが新言語作ってくれても良いんだぜ?

2015-05-13

http://anond.hatelabo.jp/20150513093805

学習コスト問題より、関数型がベストマッチ問題ビジネス現場に少なすぎるだけだと思うよ。

パズルを解くような、ロジックが複雑で本質的副作用が少ないような話題ならいいけど、

現場問題副作用だらけだし外部システムとの連携も多いしで

単体テスト書くのさえ苦労してるのが現実じゃねえの?

HFT会社関数型言語使ってるって話はなるほどなって思うし羨ましいとも思うね

2015-02-05

http://anond.hatelabo.jp/20150205151244

どの単位単体テストと呼ぶのか問題は闇が深いので触れませんが、

まだ仕様書フォーマットが決まって無いから仕方ないのです。

来週の頭には出来るそうなので、それまでは後回しです、ちかたないね

とか言ってたら、早速Dto周りのフレームワークがNullを想定してないという斜め上のバグが見つかりました。

やったぜ!

2015-02-04

[]2月4日

○朝食:なし

○昼食:ホットサンドサンドイッチ

○夕食:納豆卵かけ御飯

調子

単体テストはまとめてやって欲しい、と言われたので、仕方なく製造を前倒しで始める。

コピペコーディングで四つぐらい画面を作った。

ださいけど、リーダーが決めたことだから、従わないとねえ。

時間の余裕があれば、ベースクラスをちゃんと作ってあげたいなあ。

遊戯王タッグフォーススペシャル

紋章獣で汎用ランク4を連打するだけの簡単なお仕事

ダークリベリオンつおい。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん