具体例として、OpenSSLなら、実際に作るよりも、使ったほうが早い場合のほうが多いし、今回はそうだろう。という話だよ。
今回の話はそうじゃないよ。後輩はもう実装物を持ってきた。
実際に作るよりも、使ったほうが早い場合のほうが多いけど、今回は違ったんだ。
どうする?じゃないだろ。もう物はあるんだから。
オープンソースに対して後輩の持ってきた物が劣ると言うのであれば、
何処が劣っているのか、つまり何処が要求仕様を満たしていないのかって部分をコメントするのが最初。
で、例えばドキュメントの厚みが足らないって話になる。そこからが交渉。
増「代案としてオープンソースがあるよ」
後「それだと手戻りになりますよね」
って話だ。
それを素っ飛ばして、元増田にあるように、
「オープンソースの読み込みが足りないなぁ。それ、わざわざ自分で書かなくても、有名なオープンソースあるのに。」
っていうのはオカシイ。それもうお前の中で結論出てるやん、となる。
オープンソースは何でも神なんて、ヒトコトもいいってない。
僕もヒトコトも聞いてないし、増田の神が誰だろうと構わない。興味が無い。
だから、両方の可能性にずっと言及してる。
オープンソースを知ってる事が、そんなに大事なら、→教えてやればいいじゃない。
どっちでもいいなら→自由にさせたらいいじゃない。
言うわけ無いねぇ。でも外注なら言うわけだ。つまり、そういう状況にならないのが一番にいいねぇ。
元増田は、後輩がオープンソースを使ってない点を惜しいと言った。
俺はそうは思わなかった。
ああ、これは簡単。僕は最初にこういった。
http://anond.hatelabo.jp/20110122011509
そしてこう〆た
「まぁ良し悪しの話じゃなくて、ポリシーの話だけど。」
以下は本筋と関係ない話。
今の世の中そうだけど、他人のガキを怒らねーだろ。 他人にコメントするのはスゲー労力なんだよ。 嫌いな奴は何も言われない。もしくは褒め殺し。
増田がその後輩の事を好きかどうか、僕は知らない。
でも、例えば、僕と増田の間には親愛の情は無い。
そしたら、それを見た第三者は
「こいつらは、言いたい事があったら、相手が他人でも労力かけてコメントする人種なんだ」
って思うよ。仕方がない。それは仕方がないよ。
以下もポリシーの話
・相手が好きでも嫌いでも、一緒に仕事をする相手に対して言葉数は変えるべきではないと思う。
自分で気を付けていても勝手に態度は変わる。加えて褒め殺しとかやりだすと、周りの空気までおかしくなる。
・言うべき事というのは、嫌いな相手でも言うべきこと。
・その人に任せたプログラムに悪い点があったら、その人に直してもらう。
受入れ側が黙って直すのは納期間際の緊急手段。
ソースコードのレビューをした。 あー、オシイなぁ、すごい優秀なんだけどなぁ・・・ オープンソースの読み込みが足りないなぁ。それ、わざわざ自分で書かなくても、有名なオープン...
ケーズバイケースなのは大前提として。 能力があるなら自分で書けばいいと思う派。 ・実装工数<テスト工数。逆転する奴は優秀では無いよね。 で、オープンソースでテストを省け...
具体例として、OpenSSLなら、実際に作るよりも、使ったほうが早い場合のほうが多いし、今回はそうだろう。という話だよ。 今回の話はそうじゃないよ。後輩はもう実装物を持ってきた...
よくわからんが、後輩が作ったものを使わなくちゃいけないという理由はどこにもない。 よければ使う、悪ければ、よくなるまで治すか、他のものを使ってもらう。 今回は、ドキュ...
よくわからんが、後輩が作ったものを使わなくちゃいけないという理由はどこにもない。 できれば、よくわかった上で発言してくれると嬉しい。 さて、元増田が「オープンソース...
温度の問題だと思うけど、 プログラムつくるときに、その場でかまとめて定期的にかはしらんけど、ベンチマークとらないって事はあるの? プログラムってさ、辿りつくところは職人...
補足になるけど 感情論で蹴ってるわけじゃないから 議論にはいくらでも、付き合うし わからないところがあると言われれば、一緒に調査して 一緒にコードも書く 彼女とデートとか...
元増田の主張→調査の不備 僕の主張→要件仕様の不備 僕は、「調査の必要な要件だと知らなければ、調査対象からは外れる」と主張。 元増田はそれを、「当然」調査するだろ、とい...
「レビュー指摘事項:実装者の調査不備」と起票していたら、 俺は、「指示者の指示漏れでしょ」と言う。そんだけ。 うん、指示漏れだとして、指示が漏れていたから、レビューし...
自由にさせろと言ってみたり、指示漏れと言ってみたり・・・ だーかーらー、 別の人に「OpenSSLを1から書き起こすのには」って例を出していたけど、これは元増田の話としては...
よくわからん。 どういう問題が起きても、指示する側が責任を取る。つまり、指示するほうにも責任がある。というのは、アタリマエのことだよね?わざわざ言うことか? そもそもなん...
つまり、惜しいのは私だから、元増田を書くわけだが? 自分が書いた元増田を読んでみ。最初の奴。 ソースコードのレビューをした。 あー、オシイなぁ、すごい優秀なんだけど...
増田じゃ無く、レビュー書に書こう。 そのとおりだね。実際の会社では実際の会社のやりとりに従って、粛々と進めていくよね。 「あんたのお話、おかしいよ」って言ってるだけ。 ...
聞いてない、知らない。そらそうだろ、増田なんだから。聞いてない、知らないこともたくさんあるのに、レスしてきたのは、増田でしょ。 聞いてない、知らないこともたくさんある...
OK 1つ話を 言わせてもらっていいか? そんなルールなくないか? ここは小説でもなんでもないから、伏線張って回収というわけでもないだろ。 メモ帳やチラうらに そこまで求め...
自分だけが使うなら、何でもいいんだけど・・・他人も使うからね。 たとえば、新入社員がそのコードを引き継いだとして ドキュメントやマニュアルが揃っていて、いざとなったら、コ...
テストのコストを含め結局仕様を満たすためにかかるコストがどうだって話なんだから オープンソースを使う=正ってのはありえない 元増田がオープンソース信者なのだけはわかった
元増田がオープンソース信者なのだけはわかった そんな事はどこにも書いていないんだが? 両極端すぎるんじゃない? ちゃんと、テストして、自分でコード書き起こして ベンチマ...
これを書いて小休止ですか
休みに趣味でやってるプログラム(アルゴリズムの研究)の小休止中ではあるな・・・
名前でぐぐってみたけど、君のプロジェクトなくなったの?
新入社員に引き継がせるなら、質問は社内でやらせたい派。 そりゃ、勝手に社外のコミュニティで訊いて解決してくれれば先輩の手間はかからないけど、 業務の一環の中で、先輩の知ら...
程度問題だけど ドキュメント・コメントについては、それも設計・実装の内という認識。あって当然。無いのが異常。 業務できれいなドキュメントが、10年残っているというのをウ...
業務できれいなドキュメントが、10年残っているというのをウォーターフォール以外ではあまりみない。 10年前の話じゃなくて、今の話をしてるんだよね? 10年前のプログラム...
新人が「レビューしてください」つってモノを持ってきた、でも内部設計書が無い、ってのは昨今ありえないな。 そうじゃない。書いたものを10年間 更新し続けられるか?って話...
時間と予算がある初期開発では作られるが、あとあとの予算がなかったり急だったりしたときに入るメンテナンスで変更が入って、ドキュメントが置いて行かれるってのはよくある話。...
途中のバージョンからドキュメントが雑になったりスカスカになったりするかもしれない。 よくわからんが、そのとおりだろ。同じことを言ってる。 だから、危険性は同じで、どう考...
あたりまえだが、そんなコメント出す段階で、その部分のドキュメントに多くのコストを掛ける金はない。 あったら、そういうコメントにはならん。 他方 オープンソースはOpenSSLク...
完全横だけど 後輩の事が嫌いなんだろうよ 仕事ができないから嫌いと人物が嫌いって 分けているようで分けてなかったりする
このエントリ気になるなあ。 ある要求を実現するにはどのような技術を用いるか、オプソがあるならどれを使うか、どの範囲を我々がコードするか、事前に経験豊富な(はずの)SEが決め...
元増田ですが・・・自分ならw Zend Frameworkは捨てる。 他人に言うなら、Zend Framework使ったほうがいいんじゃない?という確率のほうが高いと思われる。(相手にもよる) こういう言...
コードレビュー? そらもう、レビュアー「これなんでこうなってんだっけ?」レビュイー「○×△だからよ」レビュアー「あーなるほど or これもっとこうしてよ」の繰り返しの作業でし...
免責条項や瑕疵担保責任を考えたらオープンソースなんて使えたもんじゃないんじゃないの? まあ、販売用や受託開発だったらって話だけど・・・
免責条項や瑕疵担保責任っていうけど、 サービスや商品だから 売れる時期ってあるよね。 治しますけど1年後じゃ意味が無い。 自社でつくろうと、外注でつくろうと オープンソ...