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

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

2019-07-11

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

こんな感じ

2019-05-20

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

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

おしえて増田

2019-05-17

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

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

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

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

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

2019-04-05

世間的には同じSIerといわれる目立つ企業の話を書く

anond:20190326233147

に触発されて似たような記事を書く。

おそらく世間的には元増田SIerといわれる某目立つ会社の話をしよう。

この目立つ会社世間的には同じと見られているようだけど、意外と過ごしやす場所もある。

あくまで半径5m以内の話であって、もちろん環境の悪いところも結構ある。

開発環境普通

8GB i5のSurface Proとi7 16GBの開発用PCを使っている。営業メインの人はシンクライアントのみらしいが、開発部署なら

これぐらいは「頼めば」くれる。自動的にくれるわけではないのでそのへんは流行りのWeb系に比べると微妙かもしれない。

Windowsなのがクソといわれるかもしれないけどアルゴリズム関係の開発なので正直それほどこまってはいない。

Ubuntu環境必要場合は社内クラウドインスタンス立てるのも自由。また社員自由に使えるOpenStackクラウドとか

Slack風のチャットシステムGitLabもある。

上環境も普通

流石にアーロンチェアは買ってくれないが椅子はイトーキの5万円クラスのを支給される。机は個室やパーティションはくれないが

普通事務である

事務環境はだめ

流石に電話会議を自席でエンジニアが全員やるなんて光景は見たことない。

が、イヤホン音楽聞いてる人は基本的にいない。怒られはしないと思うのだが、雰囲気的に不可。

あとしょっちゅうしかけてくる人が多いのは結構うざい。

評価制度の納得感はない

完全に上司に気に入られるかどうかにかかっている。

古い方法へのこだわりはない

開発基準はあるが、「ちゃんと開発できる実力があるのならば」自由に開発できる。いつもチケット駆動で開発して

ユニットテストコードと同時に書いているが怒られたことはない。

ユニットテストコードと同時に書いて怒られる」という言葉意味がわからない人に説明すると、

SIerではユニットテストでN件以上バグが出ないと品質が悪いとみなされ、バグが出るまで延々とデバッグさせられる、

という文化がある。そのため、ユニットテストコードを同時に書いた場合ユニットテストの摘出バグ件数が0件と

認定されてしまい、追加でバグが出るまでひたすらデバッグさせられるという恐れがあるのだ。

ただそのようなプロジェクトは単にPL/PM無能なだけであり、最近ではそういう人は淘汰されてきた。

新しい方法技術の導入の難しさ

少なくとも開発部署として新しい導入の壁はほぼない。本人が開発できるのなら新しい技術でもどんどん使えという感じである

ただし、間接部署がとても足を引っ張る傾向がある。特に社内情シスは糞中の糞で、フリーソフトの導入ですら

1週間コース手続き強要してくる。MSDNライセンスを開発で購入しても、MSDNからダウンロードしたVisual Studio

情シスに無断でインストールしようものなら目の色を変えて説教しに来る。

残業時間評価

先程評価制度は気に入られるかどうか、という話をしたが、気に入られるかどうかに残業時間は大いに関係がある。

まり残業時間評価に直結する。なので私は去年度の月平均残業時間は-10時間程度である

何を言っているのか分からないという人もいるだろう。つまり、毎月の残業時間が60時間を超えるような人は

評価が下がるのだ。残業時間が60時間や80時間を超える場合上司幹部承認というとてもめんどくさい作業

しなければならなくなる。そんなのを毎月やってしまうような部下は当然だが評価は低い。

ちなみに残業は下命だからそれはおかしいという人もいるかも知れない。しかし、その目立つ会社はほぼすべての社員

裁量労働制採用しており、残業するかしないかはすべて個人裁量なのである

また当然だが残業代なんてもの存在せず、(たとえその月の残業時間が-50時間であろうとも)数十時間分の残業代相当が固定で支払われる。

スキル無関係の異動

業績のよい部署であればそれなりにやりたいことをやらしてくれるし、海外異動も基本は本人希望による。

ただし、業績が悪いところが解散するために徐々に人を無関係のところに放り出す、というのはよくある。

外資なら部署ごと売り払われることを思うとまだマシなのではないかとは思う。

社内技術への関心のなさ

社内でしか使われてない技術はみんな嫌いである。もちろんプロプライエタリソフトウェア製品をいくつか作ってはいるが、

出来が悪いものはことごとく嫌われている。その結果、糞アプリを量産していた部署の業績が悪くなったと

聞くが知ったことではない。余談ではあるがGitが使えないのは論外だし、SIerの標準言語であるJavaとその周辺技術は当然として、

若手はだいたいPythonの基本は一通りマスターしている。分析チームではそれに加え基本的Python分析ライブラリ

の使い方は大体マスターしているようである。40↑のおっさん連中は流石にそこまでではないが。

なんちゃってフレックス

コアタイム10から15時ぐらいである。そのため、私は12時ぐらいに出社している。

何をいっているのかわからないと思うが、コアタイム適用されるのは入社2年目までで、それ以降は

裁量労働制になるためコアタイムすら関係なくなるのである。ちなみに退社は19時ぐらいである。

リモートワークは予定さえあいていれば自由可能であるわたしは自宅にいることが結構ある。

人が均質的だがたまにすごいのがいる

尊敬できる人が少ないのはある。ただしたまにCVPRに通してる研究員や、現代的なReactのWebさらっと書いてしまうような

フロントエンド技術者、数千ノード分散システム開発者、競プロバリバリやってる人などを100人に1人ぐらいの割合ですごいのはいる。

未来のほの暗さ

これはイケイケのWeb企業でなければどこでも似たような感じなのではないかと思う。今の年収40歳手前で諸々込み1100万程度であるが、

かなりITバブル的な要素が多く、来年ぐらいまでは良いかと思うけど20201年以降はガクッと下がる可能性は高い。

転職可能

これだけ見るとSIerとしてはだいぶ恵まれいるかもしれないが、それでもやはり転職してしまう人が増えてきたのは確かである

今はITエンジニアバブルなこともあり、私と似たようなスキルの人では最高1500万のオファー結構あるときく。

大抵は1200万ぐらいでメガベンチャーあたりに行く人が多いらしいのだが、やはり年収と言うよりも

足を引っ張らない間接部署や、マネジメント業務なしの開発に集中できる環境を求めて出ていくようである

もちろんこの目立つ会社では、事務ソフトOfficeOutlookであるし、社内システムもクソで

MacBookなんて夢のまた夢だし、社内Proxyにいじめられる環境ではあるのだが労働時間の半分以上は開発に当てられており

残業時間マイナス年収もそこそこということを考えるとあまり転職モチベーションが沸かない。

一方で、一回ぐらい転職経験しないとスキル的にだめになってしまうのではないかという懸念はかなりあるので、

周りに転職者が出るたびに少し焦りがあるのも事実である

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人か、とか、らくだや住井が含まれてない根拠とか、関係無いよね。

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

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

2014-11-14

CVSって何よ状態で困ってます

俗にいう「使えないシステム」ってやつをつかまされたのかもしれない。

今、オブジェクト指向言語みたいので、業務ツール作っているんだけど設計が見えてきた段階で実は環境ボロボロなことに気が付いてきた。たとえばpushとかpullみたいなレポジトリ挨拶するコマンドが何種類かあるんだけど、なんかhageっていうコマンド打たなきゃいけなくて憎い。TortoiseHgpushしようとするとhage hair pushみたいなエラーが出て全然pushできないし、そもそもcommitとpullの違いがよくわからない。社内のSEに聞いても、commitは個人レポジトリに反映するだけで、pushしないとマスターレポジトリには反映されない、あとmergeが必要って言っている。TortoiseHgにMergeしてっていったら「それは無理」の一点張り。そうする間に新しい変更が反映されていたりして、もうぐっちゃぐちゃ。CVSだけじゃなくてほかにも必要自動ビルド環境の画面が執事だったり、そもそもユニットテストのAssertionが欠落しててすべてSuccessになってたりとかしてどうにもならない。

このまま実装がすすんでテストフェーズになったら大変なことになるって言っても「CVSくらい使えるのが当然だし、ブランチとかなにそれ美味しの」とかサラッというし。40代のクソガキが!つうかpush/pullがよくわかんねぇのは俺のせいだけどいくら何でも今の時代CVSはねーよ!っていうかCVNじゃねーかよ!まぎらわしいなって、ベテランに文句言ったところでツールを変えたがるとは思えない。だからといってPerforceのライセンス買う金もない。push and pullしてgitgitする時間金もない。死にそうです。

つかれた。p4mergeが使いたい。

http://anond.hatelabo.jp/20141113134907

2014-08-02

戦う気力をなくした

普通の人からすると大したことじゃないと思うけど、もう会社の中に貢献しようと思う気が失せたので、その実態を書いておく。

ソフトウェアを自社開発していて、顧客自身Webアプリケーションを作れるようなマルチテナントサービス提供しています

直属の部長

上下関係にとにかく弱い

後述する彼の上司であるCTOの言いなり。

全てをイエスで返していくからCTOには都合がいいみたい。

とある機能設計CTOが「コレ出来るよね?」ってすごい適当な図((丸と線をつないだだけ))を書いて説明してて、

別の部署の部下がちゃんと理由((CTOには言葉意味すらわかってなかったらしい))を説明して何度も断ってたのに、

無関係なうちの部長が呼び出されて「出来るよね?」って詰め寄られて「簡単にできますよ」ってさらっと援護してた。

自身はその機能に関して別に作業も具体的な設計をするわけでもないので、頭を悩ませるのは援護射撃をもらった担当開発者たち。

社歴が長い分既存製品に関する知識があり度々オブザーバーとして呼ばれるが、今はその製品を開発している部署所属しているわけでもなく、

最近方向性技術動向に関しては全然理解していないにも関わらず。

普段は雑談しながら笑ってることも多くて人柄は悪く無いと思ってるけど、仕事に関しては全部CTOの発言を決定事項として下ろしてくる。

自分が板挟みになりそうなら部下を責める。あなた意図はどこ?

前例主義

思考停止と思えるほどに「今までもこうやって来たんだし」がバンバンから出てくる。

それを変えるやり方や新しい概念の導入に戸惑うとイライラして険しい顔でとにかく前例に合わせるようにする。

そうやって前例にこだわってきたからなのか、ちょっとしたエピソードがある。

たった4人の小さい部署から毎週のMTGの余った時間で持ち回りの勉強会を提案して実施してたけど、

彼以外の3人がミドルウェアフレームワークや新製品の説明をしているのに対し、彼は割とすぐネタが無くなったのか既存製品の話とか会社規則に関する話が出てくるようになって、

最終的に「忙しいから」というよくわからない理由で勉強会が消えた。

3人共「楽しかったのになぁ」って口を揃えたんだけどね。

製品開発

部長がいる僕の部署は新製品と銘打って開発を進めてるけど、例によってCTOの発言によって既に現行製品をなぞる方向でただの焼き直しを進める形になっている。

僕とサシで話した時は「現行製品と同じ機能を作っていくんだったら新製品を作る意味ってなんだろうねぇ(´Д`)ハァ…」とか言ってたくせにCTOの前ではハハハと笑っている。

以前指摘したけど、彼は新製品に関するプロダクトマネジメントステークホルダー立場ではなく、あくま開発者らしい。

じゃあ誰が責任者ステークホルダーなんだよと思ったけど、そんなもの既存製品にもいなかった。

おかげさまで「あの時はこんな事情があって…」ばかりで迷走しまくってるんだけど、そういう反省は生かさないんだな。

CTO

CTO(最高技術責任者)とは名ばかりの役員

CTO技術

基本的技術に疎い。もともと企画をやってた人らしいけど、アイデアマン((その場の勝手な思いつきは多い))ではないなぁ。

バズワードは大好きだけど肝心の内容は何も知らないし間違いを指摘しても「そんな解釈もあるよね」ってごまかす。

でもそれでCTOっぽく技術リードしていると思っているらしい。

その他にもいろいろ。「ifとforが使えれば何でもできるだろ」だの暴言も多い。

社長は彼がCTOとして問題があることに気づいているらしいが、役員だしなぁ。

来期は彼を開発部署の上から外してくれるといいな。でもその頃には僕はいない。

CTO案件相談と業績

目の前の利益にはすぐ食いつく。

「こんな案件の依頼が来ていてお金はいいんですが、確実に専用のカスタマイズ必要なんですが…」というのに開発陣にヒアリングなしに受注を確定させる。

サーバだってもともと予算はないけどサクッと購入する。開発者たちにサーバを買う予算はないって渋りまくってるのに。

うまく行けば自分の実績として社内で大々的にアピールしまくるが、火消しに走るときは営業に文句行ったり開発者に文句行ったり。

そして保守のことは全然考えてないので、積み残されたカスタマイズサービス群が開発者運用者、更には顧客への次の担当者を苦しめる。

現行製品仕様を切り替えた時にカスタマイズ問題が起こったおかげで製品仕様カスタマイズ考慮したあれやこれやを要求されてがんじがらめ。

ええっと、マルチテナントって一体なんだろう。

ちなみに、コレよりひどい自称SIerの営業が居るが、とにかくカスタマイズ案件を取って受注しておいてPMをしないもんだから

突然「お客さんが明日欲しいっていうんだけど」って焦って飛んでくる事態を連発する。

もちろんそんなことを連発してても「大型案件」を受注するから営業成績はMVPとりまくり。そこからずっと続く保守運用は彼の仕事じゃないしね。

CTOと新製品

CTOの話に戻ると、僕らが作っている新製品(?)に関してもとにかく自分理解範囲内に収めるべく発言しまくるし、

新しい概念を持ちだされて意味がわからない時は「それって現行製品のコレはできるの?」で畳み掛けてくる。

もちろんそれを聞いた部長は「そうですよね。それも必要ですよね!」って援護してきて考えてきた設計がことごとく旧製品になっていく。

どうやらCTOの中では既存ユーザが内容を移行できる新製品にする予定で、機能まで全て踏襲するらしい。

そんなもん誰が使うんだろうねぇ。

「新製品を世に出していくには実案件で実績を作っていかなければ」って話をして、案件を持ってきた。

最初は短期間で終了する案件だったけど、運用期限の決まっていない案件が発生している。

そのために製品名もリリース時期も何も決めてないけど、メインから分離した保守ブランチができ、APIv1は提供済みだから今後はv2にならざるを得なくなり、

それすら新しい案件で潰されていくことだろう。

当初は「お客さんにはあくま実験的なものと説明し、お金は取らない」((そんな話を受けるお客さんはたぶんいないって指摘したけど聞いてくれない))とか言ってたのに、

今は「売り上げあげなきゃこれまでの開発費がリカバリできない」とか言ってる。

現行製品の話

まともなデバッグシステムエディタを使わず果たしてユーザPHPコードを書いて開発をするだろうか?もちろん、否。

お客さんから依頼を受けたら営業担当者四苦八苦しながら開発代行を行い納品する。

それでも難しい場合パートナー企業に依頼をして開発をしてもらい、納品する。

あれ?うちって受託開発会社だっけ?

そもそもPHP以外の機能自体も複雑になってて、開発者自身が「ここに機能追加しろって言われたけど、そもそもこの機能どうやって使えばいいの?」と迷うレベルだし、

想定してた使い方を超えてバグを付く動きを相談なしでお客さんに提供しちゃってるもんだから

どれが正しい仕様なのかすら不明瞭になっている。

現行製品の開発の話

Javaってオブジェクト指向プログラミングが出来るはずの言語なんだけど、オブジェクトなにそれ美味しいの?って状態。

クラスがただの関数置き場になっててメンバー変数をいじるもんだから副作用のせいで同じオブジェクトを使う処理がことごとく影響を受ける。

それを避けるにはどうするか?もちろん似たような機能を持つ別オブジェクトを作ったり、別関数で違うメンバーを使うようにしたりする。

とにかく既存の流れを邪魔しないように新しいコードを作ればいい。おっと既存機能と同じ処理をする部分があるな。コピペコピペっと。

もうリファクタをしようと思う開発者はいないし、単体テストもないからできない。いや、無いんじゃなくて単体テストを作れない。

あちこちにDBコネクションとか埋め込んであって都度データ取得するからさなコードでも動作するにはDBコネクションが必要なんだ。

僕は新卒メンバーには「会社内の書き方は(どの会社でもそうだけど、ここは特に)独自のやり方だから、コレが正しいと思わないように。

今後も開発者であるためにはxUnitとかバグの少ないコードの書き方とか自分自身勉強するんだよ。」と言っておいた。

どの部署保守的

Conwayの法則とはよく言ったもので、まさしくリファクタできない密結合で暗黙のパラメータの多い組織。

自分部署立場を守る発言は多いけど、1年後2年後3年後どんなふうに仕事を進めていきたいからみんなでこうしていきましょう、って意思決定していくことは無い。

未来像を描いて推し進めようとする人とよく飲みに行くけど、その人もCTOからとにかく押さえつけられてたりする。

製品の結合度や他社サービスとの連携を図っていく基盤となる部分を提案しているのに、内容も全然理解してなくて「話が大きすぎて工数かかりすぎ」と言われ、

役員会でCTO勝手に「仕様検討にかかった時間負債になった」と報告したらしい。

僕の話

「なにより、こんなことで諦める俺が憎い!」じゃないけど、そんな中途半端に辞めようと思う僕も駄目なやつだとは思う。

誰にも頼まれないまま開発インフラを変える動きを有志で立ち上げて色々やってCI((例によってユニットテストできない))が回るようになり始めたけど、それも中途半端

運用インフラを変える部分もやっと使える状態になったけど、まだまだ中途半端

製品の1モジュールもきっと中途半端になるだろう。

そういった点は大変に申し訳ない。

でも、今のまま居たって僕に未来はない。

僕は僕自身未来の為に活動していかなきゃと思った。

こんなところでこんなグチグチ言ってちゃダメなんだ。

から、ゴメン!

2013-10-01

http://anond.hatelabo.jp/20131001123851

本末転倒というが、君はユニットテストの導入によって初回リリースが早くなることを期待していたのか?

だとしたら本末転倒以前の問題だ。ユニットテストの意義を勘違いしている。

2013-05-24

http://d.hatena.ne.jp/totopon114689/20120111/1326266304

事情で眠れない。

1) 仕様あいまい場合適当コーディング

仕様曖昧からこうしておくね、よろしく」という一方的な通知をメールでぶん投げて終わり。

曖昧な箇所とは、どうでもいいと思われている箇所なので、たいていの場合実際にどうでもいい。

「ケース自体は洗い出せているが、具体的にどのようなエラーメッセージを表示すべきか?」お前は小姑か。どうでもいいに決まってんだろそんなもん。

このようなコーディングは作った本人以外にはよく分からない、いわゆるブラックボックス化され

コメントを書けよ糞馬鹿野郎。見られたくないならコミットコメントチケットにひっそり隠すという裏技もある。

2) 進捗報告

進捗などというもの存在しない。0%か100%かだ。中間報告が必要タスク粒度が荒すぎる。

こんなもんは21世紀ITエンジニアにとって基礎スキルすぎるので割愛する。

3) 面倒な繰り返し作業やテスト

自動しろよ糞が。以上。

その程度の事もできない低脳だから、周りに迷惑をかけないように刺身タンポポワークに回されているのだろうが。次は机の上に内線電話しかない部屋で一日中座ってる仕事かな。

4) 他人の担当箇所だからいいや

俺ならチームのいるチャット問題点だけ書いて終了。

担当者を探すことすら放棄する。直らなくても気にしない。それらはリーダー担当者自身の仕事であり、俺の仕事じゃない。

無視してもいいが、指摘と無視では、大体無視の方が総コストが高く付く。

5) 後から気づく

自分自身がサーバ管理者になっていれば、夜中に誰にもバレないようにコッソリ修正してしまう事もできるかもしれないが

越権行為をする、つまり自分キャリア危険晒してまで修正するほど仕事熱心な奴は勝手にやればいいが、俺は死んでもやらない。

「ここにこういう不具合が残っている、どうしよう」とリーダーに丸投げするだけでいい。システムを止めて入れ替えとかそういう事はリーダー勝手に考える。勿論「軽微な不具合なので放置する」という判断もあり得る(大規模なシステムには大抵「既知の不具合リストがある物だ)。「面倒なので客には黙っておこう」というのも、夜中にコッソリ修正するのと同じく、ハイリスクな判断であり、そんなもんは自分でやらずにリーダーに丸投げすべきだ。

6) 誰も知らないかもしれない仕様

ユニットテストを書けよ糞が。こんなもんは21世紀ITエンジニアにとって基礎スキルすぎるので以下略

番外) 極端に有能なプログラマー

人間は、能力限界まで能力を行使していないと劣化する。優秀な人間はそれを知っているので、「自分仕事を減らすための嘘」は、自分を守るために必要最小限しかつかない。糞みたいな仕事で一杯になったら?黙って転職するんだよ。

あるいは、時間仕事の精度を上げる方に費やすテストの充実、ドキュメントの充実、開発用ツールの整備、リファクタリング時間の都合でオミットされがちな要素などいくらでもあるし、優秀な人間ほどそうした要素が沢山見えている。

総じて、ブログ執筆者が無能すぎるだけだな。つうか、なんで2012年の記事がホット入りしてるんだろ。

2013-03-02

からプログラマ馬鹿ばっかだとか空気読めないとか言われるんだよ

一部で話題になってるこれだけど、投稿件数100越えてる割には、他のネット論争と比べて比較コメントが読みやすい。これについては、投稿してくる人も d:id:perlcodesample も余計なノイズ一言を入れずに投稿してくれているからだと思う。見習いたい。

にもかかわらず、ここを読まないでトラバ突っ込みを入れてくる奴は馬鹿ばっかりだから話は全然収束しないし。トラバ投げる奴は、ただ自分が気持ち良いエントリを書きました、って話しかしてない。

d:id:perlcodesample は「perlだとスカラーも各種リファレンスも全部 my $var って書くだけで受けることができる! 楽!」って話しかしてない。(そこから派生する色んな"利点"については「お前がそう思うんならそうなんだろう、お前ん中ではな」レベル主観だらけなので"インデントをスペースにするかタブにするか論争"のように対話しても万人に納得のいく結論は出ない)

そう言う話に「そんなことをしてると(あらかじめコンパイル時にチェックが入らないから)後から大変なことになるぞ!」ってツッコミが入り、それに対して「後から大変ってどういうことですか? どうせ全部テストするんですから(コンパイルを行った時点である)最初から大変なのも、(プログラムテスト実行した)後から大変なのも、大変度合いの総和は大して変わらないでしょう?」というあたりで止まっている。

この d:id:perlcodesample の主張は、(本人にとっては)暗黙の以下の前提がある。

  1. (perlで言う)すべてのモジュールにある全サブルーチンに対して、全パターン自動ユニットテストが用意されている(されるべき)
  2. モジュール間の結合試験についても、全パターン自動ユニットテストが用意されている(されるべき)
  3. コンパイル時のエラー検出&修正コスト」と「(コンパイルエラーにならないため発生する)ユニットテスト実行時に検出されるエラー&修正コスト」はほとんど等しい。
  4. プログラム品質保証する根拠のほとんどすべてはテストである

この前提のどれかに無理があることを直感的に示さない限り、この対話は終わらない。

2012-04-25

無職が一ヶ月かけてWebゲームみたいな奴を作った

Webゲームっていうか、ブラウザ上で動くような奴。PHP(5.3)で突貫工事したので、ペラペラな感じだけど、なんとか公開できて、たまに遊びに来てくれる人がいて(一時はVIPに募集スレも立ったらしい)、何戦かして帰っていくので、とりあえずサーバー代を払った価値くらいはあったかなーという感じ。

で、どういうゲームかっていえば、人狼みたいに「陣営に別れて、決められた目標クリアするゲーム」です。

レジスタンス』っていう卓上ゲームというのかな?それを参考にして作りました

レジスタンス・チャット

ちょうど開発してから、一ヶ月程度になったので、宣伝をかねて、現状みたいなのをメモ

俺のスペック

一応、前提としては、Pythonだったら、何かしらのシェルプログラムを書いてcronしてるけど、それ以上のことはしていない程度の、技術ワナビー

ほぼ業務経験なし。継続してスクリプトを開発したのは、今回が始めてという感じ。

作ろうと思ったきっか

単純にPHPで何か作りたいなーと思ったから。一度はPHPを書くべきだなあと思ったりした。それで、何かいい題材ないかなーと思って探してた。

「昔、人狼BBS遊んだとあるなー、でも同じ人狼ゲームを作っても芸が無いしなー」と考えていたところ、知人と遊んだレジスタンス』ってゲームにピンと来て、「こういうゲームWeb上で遊べたらいいかな。調べたところ、Web上でも人狼っぽいって言われるし、上手くそういう層にアピールできそう」ということで作り始めたのでした。

反省

綺麗なコード意識する

はいえ、最初は勢いで書き散らしたので、本当にClassとかまったくなかった。それを徐々に整え直して、なんとかファイル分割できるようになった。それでも、全く足りない。具体的には下のような部分が汚い。

MVCをちゃんと意識する

本当はCakePHPとかそういったフレームワークを使えば良かったんだろうけど、「重いんだったら仕方ないしなー」というわけで、フレームワーク無しで使ってみたんだけど、結果として表示部分にやたらと処理が入って醜いったらありゃしない。

表示部分と、実際のシステム部分はわけられるべきだし、フレームワークを使わないまでも、そういう風な機能分割は必要

そうなるとある程度までは綺麗なコードになるような気がする。

で、そういうコードを書いたせいで、下のようなことが起きる。

テストは丁寧に書いておく

PHPUnit使ってユニットテストは書いているんだけど、まったく足りない。

全部グリーンにはなるんだけど、実際に動かしてみるとバンバンエラーが出る。

幾つかの関数テストを先に書いたりしたんだけど、表示部分とかは「ここテスト書きにくいから誤魔化しちゃえー」といって書いたりした。

で、何が起きるかっつーと、リファクタリングするときガンガン機能が落ちる。そして死ぬ

さすがに一つのClassが1000行くらいになってきたので「うっわー、これは駄目だわ。分割するべき」って、ゴミみたいなコードに手を入れ始めるんだけど、全く歯が立たない。

とりあえず、既存テストグリーンになるけど、どこかで処理がつまづいているという状態でこれは駄目。

「うわ、この部分、テスト書きにくい!」って思った時点で、何かを嗅ぎつけてちゃんとテストに落としておけばよかった、と反省することしきり。

結果として手作業で複数ブラウザ起動して……みたいなことになっちゃう。バグの温存。

楽ができるならば、楽をする

CSSとか勉強のために、自分で1から書いているけれども、これは本当にだるい

知人から、綺麗にコードが書けるから、と薦めてもらったSaSSを使っているけれども、なかなか綺麗にできない。

一応、Twitter BootStrapは知っていたけれども、それに頼るよりは一から書こうと決心して書いたためか、ようわからないし、デザインとしてもこなれていないために気持ち悪いことになっている。

上記のフレームワークについてもそうだけど、流行っているものには、それなりの理由があって、それをわざわざ避けても、結果として、それ以上のものは(素人に毛が生えているくらいでしかない以上)ならないような気がする。

ならばとっととそういうものを使って、さっさと済ませてしまえばよかったなーと思ったりした。

ゲームという性質である以上、どんどん情報量が増えていくために、そういうのを表示しまくっていると、本当に画面がぐちゃぐちゃになる。

ユーザーインターフェイスまじで苦労する。

セキュリティー……

セキュリティーには本当手をつけられていない。(徳丸本読めという話になると思う)

ドキュメント……

(略)

一ヶ月間続けてみてよかったこと

で、本当にボロボロになりながら作ってみて良かったことをメモしておく。

単純にプログラミングって楽しいよね

自分は割と現実逃避の為に何かに没頭することがあって、その逃げ先としてプログラミングっていいなあと思ったりした。

あと、自分が書いたコードがヒョコヒョコ頑張っている姿をみていると、すごくかわいくなる。形にもなるし、「こういうものを作ったよ」とも言える。それは単純に楽しい経験

自分が作ったものが単純に楽しい

元々、自分が好きそうなものから題材をピックアップしただけあって、自分が作っているものが、自分が一番愛用しているというのは幸せなことだなと思う。

自分が楽しむためのものから自分が一番のユーザーであるし、自分が快適に使いつづけるために改良を続けてる。

から「こうしたらいいんじゃないの?」というのも勉強になるし、自分がちゃんと&楽に機能拡張できるように、ちゃんと勉強しようとも思う。そういうのは本当にいい循環。

使ってくれる人がいる

大抵は、自分が使うから自分だけのものだったので、あまり他の人が使ってくれることを期待していなかったんだけど、今回のは、ときどき遊びに来てくれる人が居る。

例えば、VIPスレが立ってたり、あるいはニコニコ生放送プレイ実況を配信してくれたり。

割と「くっだらねー」と思うけど、一人で細々と開発していると、そういう些細なことが嬉しかったりする。

なので、ついついみてしまったり、場合によっては、プレイしているところをいつまでも一緒に徹夜して観戦していたりする。人のプレイしている姿が楽しいというのも、自分が作って良かったなあと思う。

逆に言えば、使ってくれる人がいるからこそ、一ヶ月間開発が続いているようなもので、「ああ、自分プログラムで楽しんでくれる人が居るんだな」という手応えみたいなものが、モチベーションになっている。

遊んでくれる人が見えるというのは、自分にとっては、モチベーション維持に大切になってる。

今後として

だいたい三日坊主で終わっている自分としては、開発が長く続いているほうだと思う。

目指すところは、もっと綺麗なソースコードにして、Githubで公開すること(いや、もうアカウントは既に持っているんだけど、公開するのは凄く恥ずかしい)。

まだまだ勉強することが多いなー、というわけではてブPHPの記事をあさったりしているところです。

2012-03-29

http://anond.hatelabo.jp/20120329080751

ユニットテストデグレを避けるためにやるもんだと思ってたよ

どうせ修正が入るんだからデグレは起こる

2010-04-20

SIerアウトソーシングに起因する人材問題

人材の流動化か囲い込みか(http://remote.seesaa.net/article/147006872.html)」で示される問題は、SIer案件であれば1つや2つはよく起こっている。ここまで問題が積み重なっててひどいのはあまりない(...と思いたい)以下は実際にみてきた現場の惨状。

2.ドキュメント無茶苦茶

excel方眼紙はよく見かけます。修正にやたらと手間がかかるので苦痛です。継続的にメンテナンスする必要があるドキュメントには向いてません。あと、ソースコード日本語訳したようなひどい設計書が多いです。そんなもんソースコードで十分だろって思います。

3.プロダクトのソース管理無茶苦茶

本番環境コンパイルしたりとか、恐ろしい事をしている現場がありました。それでソースコードレポジトリとの同期が取れてなくてどのファイルが実際に稼働しているコードなのか分からなくなったりもしていました。

4.ユニットテストコードがない

ユニットテストがないのはデフォルトです。テスト仕様書が残っていればまあいい方ですが、テスト項目に「正常に動くこと」としか書かれてない場合もあって信用できません。

5.GUIがひどすぎる

RDBMSをつかったシステムで、会社の休業日を管理するテーブルの編集画面レコード番号が必要かどうかで議論が始まり一時間くらいぐだぐだと会議をしたりします。そんなもん年月日でユニークキーにしておけば十分。いちいちユーザに番号を振らせるという手間をとらせたいんだろうか。

アウトソーシングSIerの開発力は空洞化した

自社で一貫して設計から実装まで担当しているSIerは別として、そうでないSIerには実際にモノを作っている人間は居ない。仕様の検討段階での資料作成から、アーキテクチャ設計設計テスト運用までほとんど外注にたよりきっており、ざっくりなマネジメントをしているだけだったりする。

設計から外注に丸投げしているSIerでは、日本式のやりかたとか言う以前に、そもそもSIerの社内にシステム開発を行ったオリジナルメンバー存在すること自体少ない。

すでにSIerでは内製することすら出来ない状態まで空洞化している。

元記事のコメントより

コストダウンの名の下に人減らしだけは進みましたが、そのことがどれくらい破壊的な影響をもたらしているかを、上の人が全く理解できていません。上の人ほど開発経験に乏しく、細部を理解できていないのです。

『鉄筋減らしてコストダウン』して住めないマンション大量生産したマンション販売会社がありましたが、IT業界は減らすどころか「鉄筋も柱も無くしてコストダウン」を目指してる感さえあります。

IT業界は減らすどころか「鉄筋も柱も無くしてコストダウン」を目指してる感さえあります。

ってのは言い得て妙だ。

技術力がないのでマネジメント不安

SIerはモノを作るのが仕事ではありません、マネジメントするのが仕事です」キリッ!

ってよく言うけど、マネジメントに関しても、技術的な問題が起こっても解決するだけの力がないので、下請けに残業してくれという根性マネジメントしか出来てない。顧客から仕様変更の要求があった場合でも、どういう影響があるかも理解できてないので、全部請けてきて下請けに丸投げとか。

たちが悪いのは見当違いなルールを課して管理したつもりになっている事。

外注に頼り切っているSIerでは、アーキテクチャ設計ドキュメント整備、ソースコード管理テスト自働化GUIデザインは社外の他人まかせになってしまっており、現状の開発方法でどのような問題があるのか気づくことができない。そういった現場から遠い場所にいる連中が現場をうまく回すためのルールを作れるとは思えない。

SIer謹製足枷にしかなっていないルールの例には事欠かない。

2009-05-10

ステップ

うちの会社はIT業界なんだけど、プログラムステップ数を

開発規模やテスト項目の指標として使ってる。これって変だよね?

実力のある人が設計実装すれば、同じ機能を実現するにしても少ないステップ数で実現できる。

ファンクションポイントで開発規模見積もるべきじゃないんだろうか?

テスト項目数もユニットテストならステップ数に依存するかもしれないけど、

結合テストならステップ数より、ユーザ入力できるパラメータ数に依存するよね?

他の会社は開発規模やテスト項目数どういう指標使ってんだろう?

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