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

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

2019-11-02

[]2019年10月はてブあとで読むトップ30リスト

はてブホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ

441あとで/2227users 未経験でも1カ月で即戦力クラス知識が身に付く『webデザインドリル』公開 | knowledge / baigie

319あとで/2886users 賃貸住宅の退去費用として13万円請求された時の対応方法をまとめます|犬笛|note

305あとで/1662users 非デザイナーの僕がデザインぽいことをする時に使う便利なツール18選|かずたか@プログラミング独学して起業した人|note

260あとで/2214users 【朗報Youtuber中田敦彦、うっかりまともな資産運用を数十万人に広めてしま・・・これには金融マンも真っ青 | ライフハックちゃんねる弐式

228あとで/1529users 研修資料まとめ.md · GitHub

214あとで/1017users 技術ブログをバズらせたくて必死で身につけた情報収集術 - omuriceman's blog

191あとで/1517users 社会人の不幸の8割は合意のない期待から田中邦裕|note

185あとで/1788users この法律日本を「生産性が低すぎる国」にした | 国内経済 | 東洋経済オンライン | 経済ニュース新基準

182あとで/1222users 科学的で現代的な「人を動かす」──『事実はなぜ人の意見を変えられないのか-説得力と影響力の科学』 - 基本読書

180あとで/970users 3年かけてたどり着いた英語記事を読むための方法 - Qiita

172あとで/796users 文系大学生機械学習を0から始めて9か月でKaggle銀メダルを獲得するまで - Qiita

170あとで/669users いま知っておきたいLinuxWebアプリOSプロセスとしてどのように見えるか? を運用に生かす - エンジニアHub|若手Webエンジニアキャリアを考える!

170あとで/1344users 機械の立体図をフリーハンドでとんでもなく上手に描く人が製図のテクニック解説「恐ろしいレベル」「弊社に欲しい」 - Togetter

169あとで/2472users 食べログ3.8問題検証 - クイックノー

168あとで/1146users 質問が出ないのは話し手責任が8割。だから質問が出る」ようにルールを決めたら、大成功した話。 | Books&Apps

166あとで/898users 貧困を減らす実験アプローチ安田 洋祐|note

165あとで/679users 社内勉強会で作ったDocker/Kubernetes入門の資料公開しました - inductor's blog

164あとで/695users データサイエンス機械学習をやるためのエンジニアな本まとめ - 2019年版 - Lean Baseball

157あとで/1090users 20年の営業マン生活でわかってきた「仕事本質」を全部話す。 - Everything you've ever Dreamed

154あとで/953users 【インスタ、エアビーSlack等】人気サービスの初期ユーザー獲得方法

153あとで/1292users 【四川料理のスゴい人】家庭のキッチンの火力で「プロ並みのチャーハン」をつくる方法 - メシ通 | ホットペッパーグルメ

151あとで/1150users 0から100万円貯める、節約サバイバルガイド 

149あとで/1972users 巨乳炎上に見る進化文化ミスマッチ - 本しゃぶり

148あとで/637users WebサービスのA/Bテスト機械学習でよく使う「確率分布」18種を解説 - paiza開発日誌

147あとで/1149users フライドポテトチェーン店別徹底比較 :: デイリーポータルZ

143あとで/598users プログラミング命名規則ガイドラインを規定するオープンソースプロジェクト「NamingC - エンジニアプログラマのソーシャルITメディア

143あとで/661users ワークフロービルダーが新登場 : Slack簡単タスク合理化 | The Official Slack Blog

142あとで/564users 「単体テスト」再入門! 開発の現場バグを確実に洗い出す最適な手法と、テストケースの作り方 - エンジニアHub|若手Webエンジニアキャリアを考える!

140あとで/1334users 13歳から43年間野宿していた「洞窟オジさん」はかつての住処でナニを食べていたのか?【極限メシ】 - メシ通 | ホットペッパーグルメ

138あとで/963users 自称IT企業があまりITを使わずに嫌になって野に下った俺が紹介するWindows自動化方法 - Qiita

138あとで/1513users あまりに多い嘘。探偵調査で見抜いた高知小2水難事故深い闇 - まぐまぐニュース

2019-09-24

プロはやっぱり業務で使えない

職業プログラマシステムの開発保守をやってるんだけど、色んな人が競技プログラミングにハマっているのをみてatcoderを始めてみて一ヶ月が経った。未だにF問題が解けなくて実力の無さを痛感してるけど、これ、たしかめっちゃ面白いアルゴリズム考える力もつくし、これからも続けようと思う。

それと同時に、やはり競プロ業務では使えないって思いが強くなった。「アプリを作るのが好きで、趣味で競プロもやってます」って人であれば面接で速攻でとると思う。問題となるのは「競プロ青色なので、プログラミングは得意です」という言い方をする人。その時点で俺なら落とす。

普段仕事プログラムを書いていると可読性とか保守をどうするとか、ほとんどの時間はそういうことを考えてコードを書いている。幸いそのお陰で、自分の関わるシステムは5年以上開発を続けても苦もなく保守できる状態が保たれている。しかし、atcoderに参加してみて、競プロ中は普段と全く関係のない知識を使っていることに気がついた。いや、使っているではない、使わざるを得ないのだ。

例えば、普段の開発では単体テストを必ず書くが、atcoderでは提出時間が早いほうが有利なため、簡単問題では単体テストが完全に無駄だという思いが脳裏に浮かんだ。システムを作るときには絶対にあってはいけない発想だ。回答を通す、という目的けがはっきりしているのも問題だ。参加中は可読性を上げるために変数名をつける、読みやすいようにリファクタリングする、などの行為がすべて無駄と感じられてしまった。回答を通すためだけに、 ad-hoc な if 文がどんどん付け足されていく。そして、回答が通った時点ですごく達成感が出てしまい、完成したコードにはまったく興味がなくなってしまった。atcoderに参加しただけで、普段システム開発をしている自分の頭がそのような発想に至ることがあるなんて全く想像していなかったので、恐ろしくもあり、競プロマインドシステム開発とは全く違うと痛感させられる経験だった。

こんなマインドプログラミングを覚えた人間は、絶対にまともな開発はできない。ひどい手癖が染み込んでいる上に、そこに自信を持ってしまっているのが非常に恐ろしい。ずぶの初心者よりももっと悪いと思う。

2019-08-17

考え方を変えたほうが幸せになれる。

エンジニアをしているが、

テスト仕様書を書きますねって言ってくれるディレクターがいる。

インフラからアプリケーションまで一人でやっているからか、自分仕事を奪われたようでちょっと悔しくなった。

これではシステム屋ではなくて、ただのプログラマーでは無いか…。

そこまで手が回らないって情けなくなってしまう。

ただ、

ディレクターがやってくれるのはあくま総合テストの事であって、

単体テスト結合テストエンジニアがしなければいけない。

それに、時間がないから「実際に使ってみて変な所があったら教えて?」

って言うつもりだったのを前もって準備してくれるのだから想定どおりでありがたいこと。

自分だってディレクターをした時は、エンジニアの為に色々補助や書類周りの作成してたっけ…。

そこで優越をつけてもしょうがないし、

素直にありがとうって言ってもいいよね。

自分嫉妬深さが嫌になる。

2019-03-18

anond:20190318185938

追記 0号相当は単体テスト用非動作機だったりメーカー通し(〇〇社試作第10031など)だったりして確かに現実には少ないかもしれない。

試行錯誤で出来た原型機がある場合は0になり得るが、ない場合には上に書いたような1番始まりの試作シリアルと量産シリアル体系がそれぞれ用意されるケースもある。

例えばボーイング787は試作機がMSN 40690/LN 1(ZA001)からMSN 40695/LN 6(ZA006)まであって、次の量産機が巻き戻ってMSN 34485/LN 7, MSN 34488/LN 8らしい。MSNとLNというのはボーイング通しの製造業者製造番号と787のラインナンバーだそうだ。

このケースでは試作と量産は同じシリアル体系のうち40kと34kという範囲違いだな。

F-15場合米空軍シリアル71-0280から71-0291が試作機として存在している。0280は0号機と言えるかもしれない。空自F-15DJの一号機二号機は02-8801と02-8802で、次の8機が飛んで12-8803から22-8810らしい。このNN-NNNNという体系は米空軍では共通のもの。頭二桁は初年度の会計年度かな。

ブコメで言われてる心神がX-2だかX-3だかいうのは米のXプレーンを真似たもので、F-15C-135などと同じように「X-2」までが機種名になる。

2019-02-20

メーカーSIer要求する単体テストが酷すぎる

メーカーSIer(仮にF社とする)のプロジェクトのもとで単体テスト工程に参画しているんだけど、非常につらいものがある。

テスト仕様書がつらい

エビデンスがつらい

障害報告がつらい


まとめ

この状況でテストする身にもなってくれよ...。

もう疲れた

2018-12-29

現場の他社の人たち、みんな口が達者で

さすがお客さんの会社系列だけあって、教育もしっかりしてんだろうな〜とか関心してた

けど、バグをけっこう出してた

バグ自体はまぁ、テストで出るものだとは思うが

プログラムコメントデバッグログ出力もきれいに削ったものだった

DB周りの処理やら他機能連携やら、異常としかさな

複雑な機能なのにこれでよく単体テストやれたなと思った

設計書で求められているログは出力している、とは言っていたが

そう思うとうちの会社の同僚はインターフェース周りの文書の食い違いに実装前に気づいて確認取ってたり

DB周りのエラーログを出力するようフレームワークに組み込んでたりと

実装周りではい仕事してるなと思った

トークはうまくない人が多いけど

2018-12-20

Clean Architectureから削ぎ落とせるものは何か

Clean Architecture良いねと言いつつ、みんな実務で採用しても何か削ぎ落として軽量化している。

そっちのほうが楽だからだ。

単体テストそんな書かないしね。

いや書いてるんだけど必要なところだけとか。

カバレッジ100%目指すわけじゃないんすよみたいな。

では一体、なにを削ぎ落としてるのか。

僕にはわからない。原理主義者が僕をイジメるのが怖いから。

2018-11-27

anond:20181127140718

単体テスト結果提出させないの?

ってか単体テスト項目を一緒に作らないの?

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-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

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字モデルをぜんぜん理解し切れてない。

誰か教えてくれ。

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