「ユニットテスト」を含む日記 RSS

はてなキーワード: ユニットテストとは

2021-08-01

素直に『わかりません』と言ってくれるプログラミングスクール出身エンジニア

最近案件自分メインで担当することが増えた。

自分仕事としては案件進めているうちに出てくる課題とか機能追加とかバグ修正とかを設計してIssueとして作って他の人に振ったり自分作業に当たったりと色々なんだけど、

最近とあるプログラミングスクール出身の同僚エンジニア(最近同じ部署になった)が自分案件アサインされた。



先日その同僚エンジニアとあるIssueを初めて振った。

内容としてはとあるテーブル特定カラムバリデーション処理が漏れいるから追加してもらって、なおかつユニットテスト修正する、というもの。まあ簡単な奴。

Issueを振ってからしばらくすると同僚エンジニアから質問が来た。

ユニットテスト実装方法がわかりません。」

「ん?」と思った。いや別に特殊ことなんて何もないIssueだし似たようなテストケースリポジトリ上に山程あるしどうにでもなるじゃんって。

まあ特に考えず1個のテストケースを例として自分で作ってみて、「残りは○○の場合とXXの場合と△△の場合テストケース網羅してください」みたいな返信をした。

しばらくするとまた質問が来た。「△△の場合テストケース実装方法がわかりません。」

いやいや、そんなん頭使ってどうにかこうにか考えろよって。案件特有ビジネスロジックのことを聞かれるならわかるけどこんなレベル対応どの企業のどの案件で振られても同じことやるだけやん。

この質問してるのが未経験入社1ヶ月目の新入社員なら自分笑顔で答えるけどこのエンジニアは俺よりキャリアが長いらしい。

その同僚エンジニアはわからないことがあるととにかく素直に「わかりません」と言ってくれる人だった。

成果物についても指摘事項があまりにも多く、自分(というかその人以外)がやったら10分くらいで終わる対応に数時間以上かけて説明して修正してもらうという感じになった。何のための仕事をしているのかよくわからくなっていた。


自分ITエンジニアが「わかりません」という言葉を使うのは例えばどうしても再現性がなくてログにも何も残ってない謎の不具合とか、コンパイラインタプリタレベル不具合で現時点で解消方法がどこにも載ってない奴とか、そういうマジで「参りました」的な状況だけかと思ってた。

こんな公式ドキュメントデバッグツールだけでどうにでもなる状況で「わかりません」を使う人に遭遇するのは初めてだった。



その人はとにかく「わかりません」が多い。

レビューの指摘の意味がわからない、指摘内容はわかっても修正方法がわからない、影響反映を洗い出してほしいと言ったら影響範囲の洗い出し方がわからないと言われる。何ならわかるのか教えてほしいくらいだった。

うっすら評判悪いのは知ってたけど実際に仕事してみると尋常じゃないほど酷かった。

こっちもいろいろ対策を考えた。

Issue振るときソース上に「↓ここの○○をXXになるよう修正してください」とコメントを書いてから仕事を振るようにする、「わかりません」が来そうな部分は先手で予想して回答を載せる。

でもダメだ。こちらの対策なんてものともしないように全てを掻い潜ってくる。

もはやその人に仕事を振るのは「この作業担当してくれたら助かる」ではなく「この作業であれば流石に”わかる”だろう、そして単純作業の量が多いからしばらくは邪魔されないだろう」という感じにできる限り疑問点が少なく時間がかかる作業で”遠ざける”のが目的になっていた。

最低でもあと1年くらいは人事はこの状況らしい。。。

こういう状況ってどう扱うのがいいんだろうなぁ。

2021-06-10

日本の古き良きIT企業退職して3年がたった

3年前、世間一般にはメーカーSIerとして知られている会社退職した。ただ俺のポジションパッケージソフト開発であり純粋SIerとは異なる。

客ともSEとも会話せず、ひたすらドキュメントプログラムを書く部署だ。といっても別にペーペーではなく主任クラスであり、

会社の業績がとてもよかったこともあり年収1000万弱はあった。35歳。

これだけ見るととてもいい待遇に見えるだろう。でも耐えられないことがいっぱいあった。

Linuxで動くアプリなのにVMを動かすのも苦労する8GBしかメモリのないWindows PC、紙にコード印刷して説明しないと納得しない品質保証部、

作業実施Excelにチェックを付けていくテストjquery一つ使うのに3ヶ月かかる承認フロー、開発中にバグを一つ出すごとに

ひたすら反省文を求める品質保証部と一緒になって詰めてくるマネージャー、常にコンパイルできないtrunk、

Java 5の時代から進化しないコード、使いにくい社内ミドルウェアの利用を強制される設計、開発期間の半分以上を占める最上設計

一旦書いたコードは消してはならずコメントアウトしないといけないコーディング規約など、数を上げればきりがない。

色々改善活動を頑張ったものの、結局Subversionの導入も品質保証部がついていけないから、ということでClearCaseといわれる

今ではほぼ誰も使ってないであろうバージョン管理ツールが使われ続けることになった。使いにくい社内ミドルウェア

研究所がその道のプロと聞いたので一緒に改善を図った。そしたらRubyしかいたことがない文系新卒の子が出てきた。

一応研究所の人だし…と思って新バージョンプロトの開発を依頼したら、1分以上稼働できない状態になって出てきた。

研究開発は準委任相当なのでそれ以上修正を依頼できずに期間が終わった。

また前の会社独特の文化として、大きなバグを出した開発者反省会(社内ではとある固有名詞で呼ばれている)があった。

この反省会のターゲットになった開発チームはその資料準備で開発が1〜3ヶ月ほど止まるほど大掛かりなイベントだ。

このとき担当品質保証部は「連帯責任から」という理由資料レビューに大変な精を出す。余計なお世話だ。

このため1020ページほどの資料を毎週レビューにかけて最高のものにしていく。でも結局本番では幹部からの怒号が飛んで終わりである

連帯責任かいっていた品質保証部は幹部と一緒になって詰めてくる。連帯責任ではなかったのか。

幹部によると、この反省会があるから今の会社があるんだそう。これを経験して一人前らしい。

こんな感じで開発の体制はひどかったが、世間一般ではホワイト企業と見られている通り有休は取りやすかった。

そのため、転職活動を始めた。そしたらなんと「メモリ32GBのマシン」「mavenが気兼ねなく使える回線」「自動テスト

GitHub」「CI/CD」 という発言ポンポン出てくる。メルカリだのGoogleだのといったイケイWeb系ではなく、

いわゆるSIerでもだ。最初は何だこの格差はと思ったが、まぁ営業トークなんだろうな、と思い直した。というわけで

ケイWeb系も内定は出たものの、つい安定をとってしまい某大企業のDX系の部署転職した。

そしたら何だこれは。最高スペックMacBook ProからGitHubpushするだけで自動デプロイで即サービスイン、

問題が発生したら社用携帯に通知が飛んできて、クラウド監視サービスログをチェック、即修正デプロイ

社内の連絡はSlackで、スタンプを押せばIssueがたち即関連部署対応に走る。OfficeツールGoogle Docsで、

計算表はちゃんと表として使っている。開発者ちゃんと開発をしており、反省会の準備や品質保証部の接待なんて業務はなく

純粋エンドユーザーだけを見ている。ここはなんて最高の環境なんだと歓喜した。また個人的にはおまけ程度であるが、

年収は30万ほど増えて大台に乗った。

さて、それから3年がたった。人間というのはい環境になれると対して喜びを感じなくなる、というのはそうだと思う。

今では別にdeployブランチマージされたらCIが走って自動テストが走りデプロイされるのも、だから何?

って感じだしま普通仕事として淡々とやっている感じはする。待遇面で悪化した点もちらほらあるし

(例えば年間休日が5日ぐらい減った、残業が月5時間ぐらい増えたなど)などもある。

ただ一つ言えることは前の会社には戻れないな…ということである人間一度生活レベルを上げてしまうと下げるのは

とても苦痛に感じてしまものである

ただ、一つだけ今の会社転職してよかったと感じ続けられることが一つある。それは人だ。

前の会社では家でプログラムを書いているなんていった日にはおちょくられたり、人生楽しいの的な目で見られたりした。

芸能人ゴルフの話ができないとコミュ障扱いされた。そのため仕事の話はしても、飲み会にはできるだけ行きたくなかった。

でも今の会社では雑談としてFastlyが落ちても大丈夫CDN構想とか、AtCoderの話をして盛り上がることができる。

ダイバーシティなんていうが、人間所詮同質な人間同士で集まったほうが快適なんだな・・・という複雑な思いを抱いている。

追記

皆さん読んでくれてありがとうございます。いくつか質問が出ているので答えられる範囲で答えます

真面目な疑問なんだけど、Java5のコード書いてる人を1000万で雇う会社があるの?どういうモチベーション??

製品自体90年代から脈々とバージョンアップしている企業向けのソフトウェアなので、コードベースが古いというのがあります

またユーザーからすると中身がJava17だろうがJava5だろうが関係ないわけで、要は業務が滞りなく進めばよいわけです。

そのため昔から受け継がれたスパゲッティコードを地道に解き明かし、新しく出てきた要件を今までのコードベースを壊さずにバグなしで追加していく、

もとからあったバグについては、その他の数百万行のユニットテストもないコードに影響なしで修正を施す、といった技能必要になります

こう考えると意外と希少なスキルなんだな・・・と思えるかもしれません。

clearcaseよりもsubversionの方が100億倍導入も運用簡単だと思うんだけど品管どうなってんの?

ClearCaseご存知な方がいるんですね!一から作る製品だとSubversionのほうが簡単かもしれません。ただ、ClearCase専用の

社内ツールがいくつかあり、そのツールで出力した情報を社内資産として持っているという理由があったりします。

例えばお客さんから「この機能バグってるっぽい」というクレームを受けた際、その機能周辺の情報をそのツールから検索し、

コードレベルで再発防止策を関係部署総出で練った上でお客さんに回答する、という運用フローになっています

そのため、Subversionに変えるためには開発陣の一存では無理で、品質保証部やマネージャー層など全ての知識アップデート

必要になり、そこまでコストをかけて説得して回る必要はあるのか・・・という話になってしまうわけです。

ただ、社内の生産性を向上させるのが目的部署としてはSubversionGitを社内に浸透させたがっているのも事実で、

新規プロダクトなんかはGitを使っていました。ただしGitHubプロキシでアク禁されているだけでなく、サービス名名指しで使用禁止

になっているので、相当の理由がない限り使えないかと思います

主任クラスでも1000万円近くもらえるのか。すごい。

1000万という数字に興味のある方が多かったので参考までに書いておくと、等級ランクというもの存在して管理職を除く最上位のランク

なると2人の子持ち、賃貸住まい、標準評価で大体900万になるという感じです。年功序列だが部署ごとに違うというイメージで、

研究所だと20代で到達する一方、利益を上げていない事業部や間接部署だと定年間際まで到達しない人も多い、ぐらいの感じです。

平均では30代中盤ぐらいでしょうか。

ちなみに私の場合は基本給は33万程度ですが、そこに裁量労働手当と住宅手当、家族手当がついて月給で50万を超えるぐらいでした。

ボーナス個人評価よりも部門業績に大きく左右されるのですが、部署が最高評価場合は夏冬とも150万以上でした。

最後最後ダイバーシティについては、ダイバーシティ勘違いしているように思う

なるほど、たしかに。ちょっと言葉の選びが悪かったかもしれないですね。

2021-04-12

会社自閉症エンジニアがいて辛い

辛い。

本当辛い。

マネージャーらしき人間がいないカオス職場から、この自閉症だかアスペだかわからん同僚は完全に放置状態で本当困っている。

そこそこのプログラムは書けるんだけど、もうトレードオフの考え方がゼロ。やることが何もかも極端すぎ。

なんでユニットテスト書くのに条件判別のための複雑なコードを書くんだよ、これが間違ってないって保証どこにあるわけ?

コードの可読性をまったく気にしない。統一感のあるコードが、このアスペだけは気にせず好きなように書く。

何か気に入らなければ狂犬のように噛み付いてくる。

人の話はまるで聞かない。エゴイストの塊。自分の言うことはどれだけアホなことを言っていても常に正しいと思っている。

アスペ、チームワーク、無理すぎ。

自分はこいつとはこれ以上働けないか職場を去ることが決定しているんだけど、どういう会社なら、こういう人間面接で落としてチームに健全性や秩序を担保しているんだろう?

これは割とまじめに考えているので、知恵のあるはてなー、是非教えてほしい。


アスペとは金輪際一緒に働きたくない!!!!!

2021-04-01

作業実態がほぼない先輩エンジニア

自分とある地方IT企業に勤めている。

最近自社で利用してる社内サービスの大型改修があるということで別案件に配属されたのだが、

そこに元から配属されてた先輩エンジニアコミットログがどうにもおかしい。

先輩は数ヶ月くらい前から俺が担当するのとは別の新機能を3つほど任されてたのだが、

この新機能というのは実態としては別で運用されてる類似サービスとほぼ同機能で、使ってるフレームワークとかも同じ。

相違点はあれどほとんどは項目が減る、とか不要機能がなくなる、みたいなところが中心で、大体はコピペで終わるはずだ。

複雑にデータ依存しあってるとか項目数が膨大とかそういうこともなく割と単純なCRUDだけのよくある管理機能

正直自分ならユニットテストとかリファクタリングとか含めても3つ合わせて1日もあれば終わると思う。

その単純な新機能の開発に何故か先輩は数ヶ月かけていた。

毎日投稿される作業報告書を見るに、それ以外の作業実態ほとんどないみたいだった。

コミットログには、自分が出社して朝礼が始まるまでの5分くらいの間に終わる程度の修正を超細切れに2~3日に数回くらいコミットしてそれっぽく見せていた。

これは完全に社内の体制問題なのだが、今たまたまその部署にいる上長あんまり実態工数感とかわかってない人で、

んでその上社運用サービスってことで納期とか突っつかれることも少ないか適当に口でごまかして今の状況を作り上げたようだった。

ちなみにやってることは「保守要因だから待機が仕事なんだよ」っていうわけでもなく、ガチ業務時間の99%くらいYoutubeやらまとめサイトやら見てんじゃねえのって感じ。

うーん。。。。

だって在宅勤務中に一切Youtubeも5chも見なかったって言ったら嘘になるよ、いやぶっちゃけ割と見てる側だよ。

監視がないのを良いことに犬と散歩出たりお昼休み気持ち長めにとってちょっと遠めのレストラン行ったこともあるよ。



いやにしたって1日の作業に数ヶ月とかかけるのはいくらなんでも攻めすぎだって。。

俺は一応突っ込まれて困らない程度には成果物出してると思うよ。

ここまで極端だと「あの人数ヶ月ほぼ作業実態ないですよ、証拠はこれで~」とか誰かが上にチクリ入れたらどうするつもりなんだよ。

別に俺に実害はあるようなもんじゃないんだがどうすっかなぁ

2021-01-16

実装の一部を変更したときに大量に落ちるテストコード脆弱テストコードと呼ぶらしい

今までの振る舞いと変わるのであればテストは落ちるべきでは?

使っているフレームワークにも依存するけど、controllerのユニットテストDBジョブキューまで確認できたほうが安心じゃないの?

2020-12-20

プライベートメソッドテストすべきか

「すべきでない」というのがたぶん多数派

テストすべきでない理由としてだいたい次の理由があげられる。

プライベートメソッド関数テストする必要は無いと考えていますプライベートメソッドは、実装の詳細であるからです。

多くの場合、そのクラスパブリックメソッド経由でプライベートメソッドテストも同時に行えます

プライベートメソッドのテストは書かないもの? - t-wadaのブログ

ほとんどの場合プライベート メソッドテストする必要はありません。 プライベート メソッド実装の詳細です。

プライベート メソッドがある場合は、パブリック メソッドを見つけて、そのメソッドに対してテスト記述します。

単体テストを記述するためのベスト プラクティス - .NET | Microsoft Docs

プライベートメソッドテストするな」と強く主張されるのは、ケント・ベックの影響もあるかもしれない。

例えばtwitterで、パブリックメソッドにだけテストを書き、テスト必要なほどプライベートメソッドが複雑ならそれを別のオブジェクトに切り出す必要があると発言している(twitter/kentbeck)ように、プライベートメソッドテストに強く反対している。

またベックの書いたSUnit(xUnitの源流にあたる)には「ひとつテストひとつオブジェクトで表し、それによってテスト独立性を高める」というアイディアが使われている(そのアイディアを実現するためにとても複雑な設計をしている Simple Smalltalk Testing: With Patterns)。テスト自身ひとつオブジェクトとして独立しているなら、テスト対象となるオブジェクトプライベートメソッドテストできないのは当然のことになる。

しかし「プライベートメソッドテストがしたい(したくなることがある)」と感じる人も相当数いる。

そう感じる人にとってはむしろここからが本題で、

問題になる。

テストファーストで開発するなら手を動かしながら軽い気持ちで書きたい。

例えそのクラスがprivateメソッド依存関係があっても。

コンストラクタインジェクションされたクラスのprivate メソッドでもテストファーストしたい - Qiita

privateなルーチンの自動テストは面倒だ。実際にコーディングするとき最初publicにしておいてテストしてうまく動いていそうならprivateにするのだけど、この「いそう」がくせ者。いっそのことすべてpublicにしたくなる。

私は元々メソッドはprivateにしない主義なのでメソッド場合問題ないのだけれど、ファイル内の「関数」が問題になる。和了計算だと和了形判定とか符計算とか和了役判定とか単体でテストしたい内部関数が山ほどある。(twitter/koba0367)

private メソッドテストすべきか問題原則論だけだと袋小路に入りがちだから、private メソッドテストしたくなる具体的な場面について議論したほうがいいと思う。

自分レビューでよく見る例としては、複数の public メソッドの重複部分を private メソッド抽出した結果、濃い private メソッドと薄い public メソッドが一対多関係になる場合が挙げられる。設計としては間違っていないし、わざわざ public メソッド経由でテストする意義があるかというと微妙。(twitter/ts7i)

きれいなインターフェースを作ろうとすればするほどpublicメソッドじゃない部分に複雑性を追いやることになり、壊れた時に手戻りが大きすぎると思ったら、プライベートバックドア開けてでもテスト書くようにしてます (twitter/mizchi)

しかプライベートメソッドに対するテストを書こうとすると大概リフレクションなどで可視性の制限をすり抜けるとかメソッド可視性を変更するといった回りくどさやコストの導入が必要になるので、じゃあプライベートに対するテストはそうしたコストに見合うのかが問題になる。

伊藤さんの答えは「原則書かないほうがいいという大前提のうえで、どうしてもというときは、"これはテストのためにpublic"にしているというコメントの上でpublicにする」だった。

自分は「テスタビリティのためにメソッドをpublicにする」っていう"実プログラム挙動を変えること"の方が、「privateなメソッドテストコードのみsendで叩く」よりも怖いって思ってることに気がついた。(twitter/highwide)


メソッドプライベートパブリックかという話とそれをテストするかどうかは別問題だろという意見もある。

単体テストホワイトボックステストだとするなら、publicかprivateかでテストの有無が変わるのは明らかにおかしいだろ。ややこしいロジックはprivateに隠蔽すべきだが、そこがテストできないなんて。 (twitter/kmaebashi)

private メソッドテストするかどうか? まず最初に言っておきたいのは public/private は抽象設計問題であって、テストすべきかどうかとは当然無関係だろうということ。(twitter/qeigoi)

特定言語の貧弱な機能思考制限を受けて誤った結論を出している典型的な例。

"テストを書くべき"と"上位層から可視性"は直交する概念

https://b.hatena.ne.jp/entry/4684049296462116226/comment/megumin1

テスト粒度メソッドアクセス権は独立したものなので、「プライベートメソッドテストすべきか否か」という切り方自体ナンセンスではあるのだが、現実問題としてはアクセス権がテストに影響するので難しい。(twitter/AoiMoe)

private メソッドテストはすべきかどうかというより、「できるべき」であって、それができないというのも、ある種、言語機能テストインピーダンスミスマッチと言えるのではないだろうか、と思っている。(twitter/aetos382)


プライベートメソッドテストがしやす言語での意見

RustやGoではプライベートメソッドに対するテスト簡単にできる。

そのためかプライベートメソッドテストすることに対して拒否反応があまりないようだ。

Rustのテストファイル内とtests/以下の2箇所に書ける。

テストには開発用のホワイトボックステスト仕様確認用のブラックボックステストがあり、前者をファイル内に、後者をtests/に書けば良い。

例えば度々議論になるプライベート関数テストについてはもちろんホワイトボックステスト。(twitter/blackenedgold)

Rustではプライベートに対して何の手間もなくテストが書ける。

概念的にはプライベートに対するテストは外部コードではなく内部コードの一部として見るべきなのだろう。

Rust入門を兼ねてプロジェクト・オイラーの問題を解く - 再帰の反復blog

Rustでprivateなメソッドテストを書きたいなら、そのメソッドのすぐ隣に書けば内部アクセスになるから普通に書けるよ、ってのは目からウロコだった。できるだけ近いところにテストを書こうっていう文化と相まって最高。(twitter/kuy)

Rustみたいに単体テストは同ファイルに書ければいいのに

assertionチックにprivateメソッドのすぐ下にテスト書きたい

ドキュメントにもなるし (twitter/takaya_tim)

Rust のようにユニットテストプロダクションに混ぜる方式はおれもいいと思ってて、テストプロダクションを分離することで private 関数テストができない問題があるけど(テストしたければクラスを分けよ/メソッドを公開せよ/テスト必要なし、に分かれるよね)、そもそもこの議論不要になるよね (twitter/nunulk)


go言語だとプライベートメソッドテスト普通にやりますね。(twitter/mattn_jp)

昨日「private method の単体テストは書くか否か」という話題がちょいとあったのだが、わしは当然書く感じの昨今を送ってきたもんで何で書かんのやくらいに思ってたんだけど、Go だと private なやつのテストが書きやすいってのがデカそう。(twitter/pankona)

golangのテスト書いてたけど、テストプログラム名前空間(パッケージ)が、対象プログラムと一緒で、そのためプライベートメソッドでもテストできるの良い感じ (twitter/74th)

Goテストコードテスト対象と同じパッケージにすればエクスポートしてない関数でもなんでもテストコードから参照できるんだけど、これってプライベートメソッドテストすべきか議論するよりテスト書けと言われているようで好き。(twitter/plan9user)

プライベートメソッドテストするか?」とは別にドキュメントソースコードと同じファイルに書いていい(文芸プログラミング)なら、単体テストテスト対象と同じファイルに書いてもいいのでは?」というのも論点になるかもしれない。

2020-12-09

anond:20201209142311

入門書ユニットテストとか書こうと思うと厚さが辞書になってしまう…ただでさえ「ほどほどカラーで、ほどほど厚い」以外は売れないってのに

めっちゃ薄いのはそれはそれで売れないらしいっすよ世の中よくできてるね

2020-10-03

anond:20201003082451

コードが書けない奴を使ったテスターなんて

テスト仕様書に従ったあるいはランダム適当な手動テストしかできないだろ

ユニットテストコードやe2eテストコードが書けるとは思えない

手動テストしてエビデンススクショがいいところ

2019-10-05

Jenkinsってぶっちゃけ必要か?

例えばテスト走らせるだけならcron使うかwebhookでユニットテスト走らせるようにして結果をSlackかに吐けばいいだけじゃない?

そのくらいなら1日もあれば構築できるやろ

Jenkinsって色んな意味で重いのに享受できるメリットグラフィカルに結果を確認できるくらいしかないみたいなの多くない?

多分俺が詳しくないせいなんだろうけどイマイチ魅力がわからない

2019-09-08

文系女性エンンジニア」を「技術力がない」という意味で使うな

もし文系卒の女子エンジニアが5年もののiOSアプリにユニットテストを導入しようとしたらというLTを聞いた。


資料ここにあるが、要約すると

1. 私は開発経験が浅く、一年前まで自動テストを書いたことがなかった

2.しかし、自分たちが開発しているアプリ自動テストがないことに問題意識を持った

3.やるべきか迷ったが「まずは始めるのが大事」 というアドバイスを受けて、最初自動テストを書くことができた

という内容になっている。


タイトル文系卒」女子も内容に関係ない。


発表者が「文系エンジニア」や「女子エンジニア」を「技術力が低い・ない」と同じ意味だと考えているようで不快だった。 いくら発表者自信が文系女性エンジニアからといって、同じ属性の人を馬鹿にしていい理由にはならない。


これを

参加者の皆さまは他の参加者の様々な背景に配慮してください。あなたの何気ない発言や行動で悲しむ人がいるかもしれません。 注意深く、優しく振る舞ってください。

という行動規範を掲げるイベントで発表するのは不適切だと思う。

2019-07-11

中堅Web制作会社から自社サービス企業転職した率直な感想

こんな感じ

2019-05-20

ユニットテストって引数省略時の戻り値テストも書くの?

GitHubで公開する程度の、多くて10人くらいが関わるプログラムと想定

おしえて増田

2019-05-17

この本、クラスの話が10章まで出てこない

いわゆるmain関数自作プライベート関数を呼ぶだけのコード構造がなんか200ページ近くある

初心者向けに写経公開しまブログみたいなの作って「ここは実はテストを作ると楽です」みたいなTips書いてアフィで10億円くらいゲットして不労所得で暮らそうと思ってたんだが

プライベート関数戻り値標準出力するmain関数しかないんじゃ初心者向けの記述ではどうにもならんなコレ

えっ単に可視性変えてユニットテスト書くよう仕向ければいいんじゃないかって? 何言ってるんですかプライベート関数ユニットテストしないんですよ

2018-11-14

[]11月14日

○朝食:なし

○昼食:ぶたのごはん

○夕食:納豆トルティーヤうどん

○間食:柿の種

調子

今日は、真面目に受け止めきれないことがあった。

まずはもうすでに書いていた仕事の話を切りのいいところまで書いてから、それの話を書く。

ただ、自分の中でそれを受け止めきれていないので、まずはいつかこ日記を読み返した時に振り返られるよう、書くだけ。

今日はそれだけ。

仕事で「ユニットテストコードを書くことの是非」みたいな、よくある議論になった。

議論相手の「俺は今までそんなことしているプロジェクトを見たことないし、これからもそれが多勢派になるとは思わないから、やらなくていい」という論に、割と真面目にぐうの音が出なかった。

いやこれって、もうこの論で話されると返しようがない。

これがはてなブックマーク世界だったら歴戦の先輩方からブコメの数で圧をかけられるのだけど、現実ではどうしょうもなかった。

それから帰宅してからすぐに、家族から電話があった。

倒れて病院に運ばれたらしい。

生きるか死ぬかの話題ではないものの、緊急治療室に入って大変なことになっているそうだ。

お見舞いというか、面会に行った方いいのだろうけど

どういう心持ちでいればいいのか、さっぱりわからない。




3DSDS互換

ポケダン

ニャースペルシアンタネボーコノハナ進化させた。

はいってもこれ、レベル上げが不要ポケモン進化手続きしただけで、プレイ時間は五分ほど。

iOS

グラブル

日課をこなしただけ。

今日やれたこ

OK・1.仕事ちゃんと行く

 トラバアドバイスをもらったので、このコーナーは楽しいことだけを書くことにします。

 なので、仕事ちゃんと行く、みたいな自分の中で重いことは今後やめておき、コーナー名も「明日やりたいこと」から明日やりたい楽しいこと」とします。

OK・2.グラブル:島H、マグナ(火、闇、光)、討滅戦マニアック二週、共闘デイリーイベントデイリーをこなす

△・3.ポケダン青:レベル上げをして仲間を進化させる 

 二匹だけ、しかレベル上げが不要なやつなので、△です。

NG・4.なにか新しいゲームを少しだけでもいいからする

 上の事情があるので、さすがに仕方ない

明日やりたい楽しいこと

正直、ちょっとそういう気分じゃないわ

2018-01-15

https://anond.hatelabo.jp/20180115025904

書きすぎを避けるために、ユニットテスト必要だけど粒度は粗いほうが良いって主張をすることが多いな

ユニットテストそんなにいる?

ユニットテスト書きすぎじゃない?って話です

かつてこのブログがバズって否定的意見が多かったけど

http://kenn.hatenablog.com/entry/2014/01/03/095026

今はこのブログで言ってることがその通りだと感じる場面が多い

筆者は大手企業スマホアプリを作っている

スマホアプリの開発現場では、MVVMやクリーンアーキテクチャと言った手法を用いて

Viewロジックに近い部分までユニットテストしようというのが主流になっている

この空気感では最早テストを書くのはやめよう!という人は居ない

テストを書いたほうがいいか、書かなくてもいいか、迷うくらいなら書けという感じ

その結果、仮にバグが有ったところで大して痛くもないところまで緻密なテストが書かれ

コード量は爆増し、開発速度ははっきりと低下している

テストを書いておいたほうが結果的リリースまで早くなる箇所もあると思うが

テスト礼賛の現状、よっぽど強い意志を持っていたり強い権限を持っていないと

そうでないところまでテストを緻密に書く流れにどうしてもなってしま

もうApple審査も昔のように一週間もかかったりしないんだから

リリース優先して、バグ考慮漏れがあったらテストケースを追加すればいいのにと思う

2017-12-01

ツイッターブログ仕事関係の人も読んでいるので、ここで書く。ちょっとした事情Uターンして、とある地方のしがないWEB屋で働き始めたのだけれど、半年経って、もうこれは限界かもな、と思っている。


コードレビューが無い

社員が少ないし時間がないのもわかるのだが、コードレビューがあることによって、バグコード書いた人の目に届かない部分の影響への指摘などができると思うのだ。


テストしない

フロント状態管理が大変なので、限界があると思うんだけど、バックエンドテストコード書いて、ユニットテストくらいはやろうぜ、と思っている。まあ、自分も以前まではやっていなかったので人のこと言えないのだけれど。


タスク可視化されていない

何をやっているのかわからん上にダマで変更加えてmasterにマージちゃうしかも変更しているのはモデル。もちろんテストはしないぜ。masterからブランチ切って自分作業に取り掛かってみると、知らない変更が加えられている。影響範囲なにそれ美味しいの?状態なため、変更に伴って他の部分/モジュールにはバグまくりテストコードコケまくりエラーまくり


これを誰がやっているかと言うと、上司にあたる人間がやっている。ちゃんと技術的な知識も持っているしコードもちゃんと書ける。自分よりも。なので余計にタチが悪い。一人で開発するんならそれでいいのかもしれないけど。ちなみにバックエンドエンジニアはその上司自分だけ。

働き始めて2年も経たないペーペーだし、年も離れているし、どういうアプローチをすればいいかからないんだよね。職場文化(?)を変えるのはそれなりの労力がいるし、とっとと転職して自分環境を変えた方がいいかもな、と思っているけど、如何せん地方なので、あんまり職がない。

2017-11-14

anond:20171114130012

たぶんテストメソッド単位ユニットテストで、ひとつメソッドに対してたくさん条件渡してたくさん書いてるのだと思う

ひとつメソッドに対して1画面ぶん以上のテストコードがあったらテスト初心者さんにとって危険信号

ひとつメソッドを書き換えただけで結果やIDEが真っ赤になるようなら緊急入院

ひとつひとつ細かく書くことで整合性管理できなくなってぜんぶ放り投げるくらいなら、最初から機能の大雑把なテストにしておくといいよ

テストを並行して実行メンテするという習慣がついてから、細かいテストどうしようかって考えるといいよ

2017-10-10

anond:20171010123949

ええか? 前提からして間違っとるんや。

巨大なオールインワンIDEでペチペチ開発したいんやったら言語の時点でJavaなりPHPなりを選ばなあかん。こういう言語はそういうIDEが無いと使いもんにならんから、たくさん転がっとる。

一方Rubyは巨大なプロジェクトカスタマイズしたVimで書き進められるんや。問題は軽量なリントとユニットテスト解決する。DBシェルからみる癖つけろ。Rubyを始めるってことはそういう流儀も取り入れるってことや。わかるな? どうしてもIDEがええなら有償のを買えばええ。

2017-02-11

http://anond.hatelabo.jp/20170211015458

> ユニットテストはすぐに金銭的な効果に結びつくから、はじめてしまって実績をつくればいい。

そうなのか。新しい機能じゃないとお金もらえないかユニットテスト導入は金銭的な効果に結びつかないのかと思っていた。

ちなみにもう勝手に導入してるがいくら言っても自分しかテストを書かないしCIがないのでいつのまにかテストが通らなくなっててメンテできなくなってる。

http://anond.hatelabo.jp/20170211012719

ある程度の規模のある会社だが、部署によって驚くほど文化が違う。20年以上も変化なく、他の部署と比べて恐ろしく効率が悪い部署がある。会社としても明らかに負債となる人間をその部署に配置している(ように見える)がまだ船は沈まないのだから、たいしたもんだ。死期は近づいているが。

ユニットテストはすぐに金銭的な効果に結びつくから、はじめてしまって実績をつくればいい。それでも変わらないのならば、その職場泥舟、いつか沈む。その前に価値のある職場を探したほうがいい。

2016-10-30

趣味アプリWebサービス開発することの魅力

ってやっぱり『価値のあるものを作りやすい』ところにあると思うんだよね

システム開発会社で働いているとシステム開発って本当に金がかかると感じる。

市のHPにあるクソみたいな検索システムとかでも云千万単位の金がかかってることなんてザラにあって、

なんでそんなにお金がかかるかっていうとプログラミング作業以外のコストがでかいからなんだよね。

システム会社システムを作りたい人からどんなシステムを作りたいのか聞き出すのにもかなりの予算がかかるし

それを資料として落とすのにも、それが全体に共有されるのにだって予算がかかる。

設計が終わっても自分用の便利アプリを作るのとはわけが違って品質保証するために

テスト仕様書を書いて、ユニットテストを書いて、他機能に変な影響を及ぼさないか調査して、

コード書いてる時間よりその周辺の作業の方が時間がかかったりする。

会議なんて始めてしまえばもう最悪で、給料×参加人数×時間分の予算がかかるし、

勿論それらには僕達労働者有給休暇分や社会保障費分も含まれしまう。

最終的な見積もりを出す頃には「なんでこんなしょぼいシステム作るのにこんだけ金がかかるんだよ」

って自分でも突っ込みたくなるくらい本当に金がかかる。

例えばJaneStyleや2chMateを代表とする2ちゃんねるブラウザ

アレなんか長年に渡り積み重なったユーザー要望が集約されてるから機能数はかなり膨大で、

これをそこらのシステム会社に作ってくれとお願いすると恐らく数億どころじゃ済まなくなるはずだ。

でも、これらは実際に数億円かけて開発されたわけではない。

規模は個人か多くても数人で、予算だって開発者モチベーション予算という感じで

数億円どころかむしろ0円に近いはずだ。

例えばこれを建設業界に例えてみよう。数億といったらもう豪邸だ。

「そこらの会社にお願いしたら数億円かかる豪邸を大学友達3人で集まって作りたい。

僕達バイトしてないか予算は1万円。お金はないけどやる気だけはあります。」

なんて言ったら「アホか」で一蹴されるだけだし、どう考えても現実的じゃない。

でも、IT業界に限ってはこれは十分現実的に考えられる話だし、そういう例は実際に何個もある。

まず企画設計開発全部自分個人開発ならコミュニケーションコストが0に等しいし、

技術力がある人だけで集まれば一番開発効率の良い技術を好きなように採用できる。

『数億円の価値があるもの自分で生み出せる』なんかロマンがあるじゃない。

数億円の価値があるものを生み出せるスキルがあれば、アイディアさえ良ければ一攫千金も狙えるかもしれない。

なんか夢がある。

2016-05-25

http://anond.hatelabo.jp/20160525213232

バグがあって、ストリームに変な値が入った時、どこがバグなのか、追跡するのが困難でしょ?

第一に、それは、ストリームFRPの値の定義)の問題であって、ユニットテストすれば良い。もしくは単にFRPログを取れば良い。

グローバル変数ではそういうことはできない。FRPでは、岡部氏のFRPライブラリ特にそうだけど、基本的ミュータブルな値同士が関数リアクティブ連携されて常に整合性を保っているのだからグローバル変数の、各所で更新されたそれぞれの値によって全体の整合性が損なわれないように気を配らなければいけないという(テスト自体困難な)問題は発生しない。それがFRPの唯一とも言えるメリットだとも言える。

使用する関数問題じゃないし、「印」として引数に加えても別に構わないと思うが、君のいうグローバル変数問題と一緒というのはまったく違う。

岡部氏との争いって「OCamlGUIアプリ純粋関数型(状態渡し)で簡潔に書けるか」ってところじゃないよね?

いや、それがそもそもの発端であるブログの経緯には書かれている。説明されている方式GUIアプリまで書けるのか?と疑念が呈されたことがきっかけ。

岡部氏はFRP状態関数の外部に持ってても純粋関数型だ、と言ってて、そこで争ってるんだよね?

この論点は聞いたことがない。岡部氏がこだわっているのは非手続き型の宣言型で、純粋がどうとか議論はされてないように思う。

あと、OCamlGUI状態渡しで書いたら簡潔で無いのを「書けない」、「不可能」って言ってるのはわざと印象操作しようとしてるよね?

原理的に可能かという議論ではなく、実用的な範疇か?という議論。反対派ブログで出てきたコードは、本人が認めるように普通のやり方ではなく、実用的なコードだとは思えない。あと、FRP状態渡しは同じ複雑さだという主張も崩されている。そこが重要

Haskellで書けて、OCaml冗長になっても、書けるなら「書ける」、「可能」だよね?

段階を踏んだ上で、非FRPHaskellのIOモナドコードを誰かが書いたらいんじゃない?当面、最初OCamlの話だったのに、いきなりHaskellやElmのコードで書いて、そういうのがごちゃまぜに、何がどの言語でできるのかできないのか、誤魔化しがあると見做されたか制限されたんでしょ。実際には、OCaml関数型では冗長しか書けないと実証されたけど、そういうのがバレないように、別の言語を利用していたと看破されて当然の状況だと俺は思うね。

俺の書き込み他人といきなり結び付けられたから、電波だな、と思ったの。

俺1人か、とか、らくだや住井が含まれてない根拠とか、関係無いよね。

関係ある。君ひとりは、そうじゃない、と君ひとりが言ってもそれが本当だとは確認のしようがないし、

書き込みをみれば、君以外の書き込みもすべて、その一派ではない、とでも言いたそうだ。

ログイン ユーザー登録
ようこそ ゲスト さん