  |
はてなキーワード: ソースコードとは
これはほぼ原因を特定している。
権利問題を自社に残しつつ、法律的な問題をクリアすると、指定された納期では終わらない
という
法律をしっていれば、しっているほど
期日には終わらず、
下手な話他社のソースコードをコピペすれば簡単に終わる（権利問題）というのは
作業完了だけなら、簡単。合法となると難しい。のはビル建設と同じ。
土台がどおでもいいなら、３倍の速さで建築できるが、建築基準法を満たせない。
あとこの件で謝るのは、謝れば許される程度と相手を侮辱しているから
何事もなければ社長が死んだショックだけで終わったかもしれない。
7Payと言えばわかるだろうか。詳しくは書けないのだけど、あれと似たようなことが起きてしまった。
かなりのストレスだったと思う。ネットで調べたところ、急性心筋梗塞はストレスでも発症することがあるらしく、そこが少し引っかかってしまった。
様々な理由から現状社長の訃報を知らせるページを検索エンジンにインデックスされないようにしています。
もし心当たりのある会社があった場合でもリンクは貼らないでいただけますようよろしくお願いします。
使うのであれば、ライブラリ、フレームワーク、ミドルウェアの更新（バグ、脆弱性情報）を一生追い続ける覚悟で使ってほしい。
テスト自動化とかそういう発展的なものではなく、もっと根本的なテストについて勉強してほしい。
コードレベルのカバレッジとかそういうのではなく、「境界値分析」、「デシジョンテーブル」、「オールペア法」、「直交表」こういう物について勉強してほしい。
他にもいろんな手法はあるのだけど、上記に上げたもので1個でも知らない単語があった人は今すぐ検索してほしい。
いくら進捗が悪いからと言ってお客さんに順調などと嘘をつかないで欲しい。
遅れている理由を正直に言って（例えばテストの工数が膨れているとか）相談すればお客さんもわかってくれるかもしれない。
また、テストの質もそこまでの物が求められていないとかがわかるかもしれない。
お客さんに相談しないで工数圧縮の為にろくなテストも書かないで動いてるからいい！っていうのは危ない。
自信がない、もしくは、やったことがない・使ったことがない、などは正直に話してほしい。
もしかしたらそのせいで給料があがらなかったり、出世できなくなったりするかもしれない。
だけれど、その嘘のせいで他の誰かに負担がかかったり、他の誰かが不幸になるようなことがあってはいけないと思う。
これに関してはいろんな批判があることは覚悟している。嘘をついてでもいろんな経験をした方がいいって言う人もいると思う。
それでも、どうしても書きたかった。
別にLPIC(LinC)は持ってなくてもいい。本屋で適当に対策本をパラパラめくって、聞いたことのない単語がないレベルであればいい。
インターネットには嘘が散りばめられている。昔は本当だったけど今は嘘になっているものだってある。
一番いいのはエラーメッセージを出している物のソースコードを読むこと。二番目はドキュメントを読むこと。それでもわからない時だけ検索してほしい。
そして、その情報が誰が書いているかをよく見てほしい。書いている人が本当に信用できる、かつ、更新日付が近かったときだけそこの内容を信じてほしい。
公開リポジトリにpush/commitされているメールアドレスを収集している人がいるということ、
公開リポジトリにpush/commitされている秘密情報を収集している人がいるということ、
RDBによってはSQLのIN句に指定できる数に上限があること、
他にもいろいろあるが、1個でも知らないものがあった人は検索してみて欲しい。業界にもよるかもしれないが、本来であれば最低限知っておかなければいけない知識。
これを知らないと適切な設計、ましてや適切なコーディングすらできなくなる。
ぼくはエンジニアに向いてない
プライベートなメソッドや関数をテストする必要は無いと考えています。プライベートなメソッドは、実装の詳細であるからです。
ほとんどの場合、プライベート メソッドをテストする必要はありません。 プライベート メソッドは実装の詳細です。
「プライベートメソッドはテストするな」と強く主張されるのは、ケント・ベックの影響もあるかもしれない。
例えばtwitterで、パブリックメソッドにだけテストを書き、テストが必要なほどプライベートメソッドが複雑ならそれを別のオブジェクトに切り出す必要があると発言している(twitter/kentbeck)ように、プライベートメソッドのテストに強く反対している。
またベックの書いたSUnit(xUnitの源流にあたる)には「ひとつのテストをひとつのオブジェクトで表し、それによってテストの独立性を高める」というアイディアが使われている(そのアイディアを実現するためにとても複雑な設計をしている Simple Smalltalk Testing: With Patterns)。テスト自身がひとつのオブジェクトとして独立しているなら、テスト対象となるオブジェクトのプライベートメソッドがテストできないのは当然のことになる。
が問題になる。
テストファーストで開発するなら手を動かしながら軽い気持ちで書きたい。
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でprivateなメソッドのテストを書きたいなら、そのメソッドのすぐ隣に書けば内部アクセスになるから普通に書けるよ、ってのは目からウロコだった。できるだけ近いところにテストを書こうっていう文化と相まって最高。(twitter/kuy)
Rust のようにユニットテストをプロダクションに混ぜる方式はおれもいいと思ってて、テストとプロダクションを分離することで private 関数のテストができない問題があるけど（テストしたければクラスを分けよ/メソッドを公開せよ/テスト必要なし、に分かれるよね）、そもそもこの議論が不要になるよね (twitter/nunulk)
昨日「private method の単体テストは書くか否か」という話題がちょいとあったのだが、わしは当然書く感じの昨今を送ってきたもんで何で書かんのやくらいに思ってたんだけど、Go だと private なやつのテストが書きやすいってのがデカそう。(twitter/pankona)
golangのテスト書いてたけど、テストプログラムの名前空間(パッケージ)が、対象のプログラムと一緒で、そのためプライベートメソッドでもテストできるの良い感じ (twitter/74th)
Goのテストコード、テスト対象と同じパッケージにすればエクスポートしてない関数でもなんでもテストコードから参照できるんだけど、これってプライベートメソッドはテストすべきか議論するよりテスト書けと言われているようで好き。(twitter/plan9user)
「プライベートメソッドをテストするか？」とは別に「ドキュメントをソースコードと同じファイルに書いていい(文芸的プログラミング)なら、単体テストをテスト対象と同じファイルに書いてもいいのでは？」というのも論点になるかもしれない。
マニュアル人間のように、マニュアル、ドキュメント化、文章化を悪とする風潮が日本にはあるように思う
これが良くないのではないだろうか
いや、Zガンダムでもいい
ガンダムのマニュアルがなかったらアムロはガンダムを大地に立たせることができなかったのではないだろうか
もちろん、武器をマニュアルから見つける時間はなく、偶然押したボタンで頭部のバルカンが出た
しかし、マニュアルがなかったら心細かったであろうし、諦めてしまっていたかもしれない
形だけであれ、まずマニュアル、ドキュメントが存在するというのは心強いのである
ドキュメントがない、issuesに知見が溜まっていない、Stackoverflowで話題にさえならない
そんなソフトウェアはどんなに優れていても使っていて行き詰まってしまったら投げ出しやすくなるだろう
ソースコードが公開されていても、ドキュメントがないのでトラブルのたびにコードを読む、これはとても苦痛だ
命名規則が無茶苦茶なソースコードがあったらプロでさえ投げ出したくなるだろう
コメントから自動生成だけでなく、チュートリアル、Getting Started、Installation、バカでも一通り学べる文章が必要だ
そうでなければそのソフトウェアは流行する可能性はまったくないだろう
インハウスツールであったとしても投げられてしまい、ちゃんとドキュメントや管理できる別の社員が作り変えるかもしれない
つまり、恋愛も同じであり、マニュアル、ドキュメントが寧ろ必要なのではないだろうか
そこには概要やインストールから始まるように、まず最初の一歩はどうすればいいのか、がちゃんと書かれている
そして、恋愛の一通りの機能を学べるようにチュートリアルが用意されている
Zガンダムのカミーユだって父親のコンピュータから操作方法のマニュアル、ドキュメントを盗んでいたと劇中で述べている
ブライト・ノアは才能だと言っているが、自分はそれは少し違うと思うのだ
カミーユに至っては母親も材料物性のスペシャリストである、つまり金属などの分野である
ドキュメントを書く、文章を書くというのは技術をまとめる、開発したものの操作方法をユーザーに伝える、大切なものである
それが将棋や囲碁であれ、あやとりであれ、必ずその分野のプロがいるのである
しかし、恋愛のプロが書いた本があったとしても、碌なものがない印象がある、なぜだろうか？
まず、恋愛のプロである筆者が自己を正しく分析できていないことがある
つまり、なんだかよく分からないがモテる、みたいな人は自分が自分でどう優れているのかさえ理解できていない、いわゆる天才肌とも言えるものである
一般的に、天才というのは他人に自分がなぜできているのか説明するのが非常に下手なことが多いように思われる
例えば水泳について考えるとして、水泳の天才は子供の頃からなんとなくできてしまうパターンが多いように思われる
しかし、天才的な水泳選手が他人に教える、子供に教える、となると非常に下手になってしまう
その理由は私なりに考えるに、天才は自分がなぜそれができるのか、できるようになったのか理解できていないのである、天才だからである
しかし、天才には敵わなかったが、努力の天才とでも言うか、努力で実力を積み上げた選手は他人に教えるのが上手いのである
なぜか？
それは彼らが、自分はなぜできないのか？天才はなぜできるのか？それをひたすら考え、天才のフォームを観察し、仮説や実験、検証を繰り返したからである
苦労をしてきたからこそ、できないプレイヤーの欠点、伸ばせる長所などが分かるのである
詐欺的なもの、単なる自己啓発的なもの、ポジティブシンキングになれば引き寄せの法則が、みたいなものは尚更無意味である
恋愛のマニュアルもまた、恋愛を上達させるために努力を積み上げてきた努力の天才、恋愛の天才に努力で太刀打ちしようともがいた人が書くべきである
以上、まず恋愛にもマニュアルが必要だということを述べ、そこにはステップアップ方式で学べるチュートリアルも必要であり、
それらを正しく書くためには恋愛の天才ではなく、恋愛の天才を目指した努力の天才が書くべきだということを述べた
まず、マニュアルがないのが悪い、マニュアル人間は悪くない、という発想の転換、逆に考えてみることが大切なのではないだろうか
自動車だってマニュアルがない教習所もない教官もいないでは事故って死ねというようなものである
なんか以前からずっと思ってたんだがRailsというかRuby界隈は宗教というか自己啓発ビジネス臭さえするのがイヤだ
金持ち父さん…とか７つの習慣とか、そういう詐欺のカモっぽい人も多いイメージがある
しかし、Ruby登場当初からやたらとエレガントに書ける、スッと書ける（この「スッ」という表現も詐欺で多い表現なので嫌い）とか、
そんなことは個人的にはどうでも良くて、ソフトウェアを使うユーザーは機能が便利かとかそういう視点でしか見ない、悲しいけど
保守の観点からも美しいソースコードを書こうという意気込みは間違っていない、というか正しいと思う
しかし、プログラマーが美しいコードが書けたと悦に浸る、自己満足におちいっているだけのようにも見えるのが納得いかない、不愉快にさえ思える
C++やJavaのような型のあった時代から、型なんてダセーよな、プレステの方が全然おもしれーよな、を経て、また型に戻ってきてる
型推論云々にかまけてパフォーマンスよりも綺麗なコード、富豪プログラミングからまた元に戻ってきてる
学習コストが高いものほど評価されるような傾向も個人的には感心しない
どうせ同じゴールなのに、そこに辿り着く方法が険しいほど評価されるなんて、プログラマーの美徳の怠惰だのから逆行している
実によろしくない
そういう点ではRustよりもGoやC#の方が評価できる気がする
もちろんRustの守備位置はそこではない気もするので単純比較はおかしいのだけど、ゴールが同じなら自分はC#やJavaで書いて終わらせるのにと思うことがある
別にWebだけでなくコマンドラインでの捨てコードにPHPやJavaScriptも適している
そういう意味ではPythonはやはり強い、Glueだからだろう
正直PHPなんかよりPythonの方が言語としてはおかしい気もするのだけど、正しいとかエレガントが生き残る条件ではないのである
しかし、学習コストとしては低いシェルスクリプトは便利ではあるが流石に古いというか罠が多い気がする
PowerShellの方が使える気がする、少なくともWindowsでは優先的な選択肢になった
生き残るというのはそういうことではないのではないか
とりあえず動くソースコードでそれなりの規模のが欲しければGitHubからcloneしてくればいいんだよなあ。
と言っても、元増田が「gitって何？」のレベルだとそこで話が折れてしまい、
gitとは？バージョン管理とは？ハッシュ値とは？みたいになってしまうので説明する側も辛い。
自分が説明される側でも説明する側でも辛いのは、それだけ専門性が高い分野ではあるのだろうけど。
自分だって自分の専門外のことをそれ専門の人にまくし立てられて説明されるの辛いｗ
ソフトウェアの命名規則が天邪鬼でなければ、スタート地点はmain.cppみたいに類推もできるはず。
デバッガでメインルーチンからブレークポイント打つなりしてポチポチ動作させたり変数の中身の変化を確認していく。
色々なクラスとかソースコードを眺めて全体像を把握し、そこからコアとなる機能、自分が知りたい箇所を目指す。
ソースコードがある、デバッグ情報があるなら、当たり前だが変数名や関数名があるので類推しやすい。
（Javaとかで難読化してると、逆コンパイルできても変数名や関数名は分からなくされていて読み辛かったりする。
いや、だから難読化なんだけどｗでも、.classファイルしかなくてもそれで中の肝心のアルゴリズムは読めてしまったりする）
自分には大した技術はないと自分でも思ってるけど、普段やってることをまったく知らない人に説明するのは難しいだろうね。
というか、できる人やプロだって新しいビルド方法なんて分からない。
C++ならcmakeやpremakeは分かるけど、ninjaってなんじゃ？みたいなｗ
そこで新しい道具に手を出して躓くことも多々あるし、
他人は他人で自分の知らない道具、好きでない道具を使ってたりもするわけで、ビルドするために嫌々最低限即席で学んだりする。
エンジニア歴の浅いヒヨっ子だけど、めっちゃわかるって思って泣いた。
自分は文系だけど一応大学は出てる。世間的には頭悪くはないかもしれない。
基本情報の勉強は楽しかったし知識詰め込むタイプの勉強は得意だった。
そもそも「頭が悪い」ことがITを理解できることに直接関係していないことはわかってる。なんというか、モノを理解できないときに「頭が悪い」っていう表現をするのはちょっと雑すぎると思う。
いろいろ考えた結果、「頭が悪い」って表現が適してる気がする。
1. 作りたい処理を自力で実装できなくて同僚に質問して教えてもらうところ。でも教えてもらったやり方は知っているやり方で、ドキュメントでも読んだことあるやつ
2. (技術的ではない)問題が発生したとき、簡単な解決法ではなく手間のかかる解決法しか思いつかなくて、「こうしたらいいじゃん」と言われて「冷静に考えればこうしたらいいのは当たり前だな、なんで思いつかないんだろう」と思う
3. 日本語の文章読んだときも、ライブラリのソースコード読んだときも、とにかく理解が遅い
4. 理解しないと覚えられない
1つめは、やり方の存在は認知してるけどそれを使うことができないから自力でできないんだと思う。
思えば自分は数学が苦手で、単純に計算ミスが多いのもあるけど、習った公式を使って応用問題を解くのができない。どの公式使ったらいいかわからない。エンジニアとしては致命的かも。
2つめは、よくわかんないけど解決策を精査し足りてないのではと思っている。まあでも時間かけたって思いつかないものは思いつかないと思う。
でも上司はいつだって最短経路で最適な解決策を導き出す。それは経験なのか、知識なのか、能力なのか、どれでしょうか。
3つめが、最も自分が「頭が悪い」と思うところ。何度も同じ説明されて、それを何度も聞いて/読んで脳内で噛み砕いて、理解したと思って自分から「つまりxxってことですか？」って質問して違うと言われたりしてまた確認して、それを何度かやってやっと理解する。
ちなみにそれは大抵、しばらくして同じもの読んでも「あれこれってどういうことだっけ」となってまた同じ説明聞いて同じ質問する。
質問すること自体は悪くないと思うけど。要領が悪い、頭の回転が遅い、とかが表現としては適切そう。だけど総合すると「頭悪い」んだなと思う。
4つめは、「理屈はわからんけど記憶する、使う」ができないのが問題。昔から自分は理屈を理解しないとスッキリしないし、応用することができない。公式がどうしてそういう公式として導かれたのかを理解しないと、応用問題で使えない。
元増田でも誰かが言ってたかもしれないけど、ライブラリの中身を完全理解しようとせずにただ「使用者」になるべきなんだけど、理解できてないとドキュメントの写経しかできない。
あと基本情報では「どういうこと？」ってなった分野は全然覚えられなくて正解率低かった。
5つめはそのまんま。ある作業中に他の仕事頼まれたら、あとでやるか今やるか判断するためにどんな内容なのか見る。内容の中で気になることがあって調べ始める。そこでメールの通知がくる。メール読んで返す。
ここで急に「そういえばあれやらないといけないんだった」と思い出す。やり始める。定時になって元の作業は全然進んでない。
あとちょっと似てるけど、アプリケーションのソースコード読んでてAの関数がわからなくて、その定義元を見る。するとその中で見慣れないBという関数が出てくる。
Bの定義元を見る。Bはライブラリの関数だった。Bの中身を読んで理解した時にはなんで今自分がBの中身を読んでたのかわからなくなってる、というのも悩み。
前にADHDのエンジニアのブログ読んで完全に自分だと思った。ADHD詳しくないけど。
プログラミングに才能は関係ないという。けどここまで来るとエンジニア向いてないかもしれない。
厄介なのが好奇心があって、現代日本でなくてはならない存在となったIT技術がどうやって実現されているのか知りたいし気になること。(元増田も好奇心あるタイプに思う。)
あとはものを作ったり、書いたコードが動いたり、技術で問題を解決できるとすごく嬉しいし楽しい。
けどそれ以上に自分の頭の悪さ、無能さに絶望することの方がつらい。耐えられない。頭が悪いせいで仕事もろくにできなくて周りにお荷物と思われてると思う。
正直今仕事楽しくない。転職する夢ばっかり見る。他の職種の方が向いてるかもしれない。前職はサービス業だけどもはや向いてるものなんてないかもしれない。頭悪いから。
でもなんかそれって「出来ないことを克服せず、耐えられなくて逃げた」ことになる気がして、変なプライドのせいと、度胸ないせいで別職種への転職は決断できない。
