  |
はてなキーワード: Golangとは
これ見たけど、そんなにローレベルやりたいならC++で良いじゃんって思った。俺のユースケースだとgolangか。次のガチプログラムgolangで書いてみるか
(WEBエンジニアリング)未経験から(院卒新卒カードを使って)Webエンジニアになって(5年で)年収1000万円(の会社員と同等の手取りを本業副業合わせて)稼げるようになった話
工学部（情報系でない）の修士課程で、画像処理や機械学習を用いた研究をしていた。
PythonやLinuxについては少々経験したが、MVCに関する技術は一切触った事がなかった。
就活して、Web系のC向けの名の知れたサービスを自社開発している企業にエンジニアとして入社することになった。
※当時は今より牧歌的で自分のような人間が入社することができた。今はわからない。
PythonのFWを使ったWebサービスの開発を行なっていた。
とはいえ、腰を据えて開発している時間は少なかった。大きい企業の既存事業にいると開発とは無関係の運用や調整業務がかなりあった。
3年目くらいで副業を始めることにした。
上記の通り業務内で技術力を向上させることがむずかしかったのと、未経験で業界に来ているハンデを抱えていたのである。
Python以外の言語はほとんど書けなかったのでPythonでwebかスクレイピングの案件を探した。
5件ほどお祈りされたが、懲りずに応募し続けてたら採用された。Flaskの案件だった。Flaskは書いたことがなかったが採用された。
当時はその会社に Python が書けるエンジニアがいなかったので重宝されたし、仕事も任せてもらっていた。
契約は週15時間だった。その間にCOVIDが来て全てが在宅勤務になり、気付いたら週30時間まで稼働するようになっていた。。
当初の見込み通り基礎体力は身に付いていったと思う。
最初の案件を納品したあと、次の案件をもらい、段々仕事の幅が広がっていった。
Linuxサーバを触ったりDBサーバを触ったりphpを雰囲気で書いたりDockerfileを書いてECSの環境を構築したりなど。
※Golang, Rust, k8sなど人気の技術の案件は探してもちょうどいいものが見つからないのでチュートリアルをやる以上の勉強はできていない。
ちょうど良さそうな募集があったので応募したところ今度は一回で採用された。
給与も少し上がった。後ほど元の副業の給与も上がり、本業の給与も少しずつ上がった。
年収がいくらなのかよくわからなくなったので、月々の手取りを銀行口座から調べて、年収1000万円の会社員の手取りと比較すると大体同じくらいの金額になっていた。
犠牲にしていることといえば可処分時間くらいだと思っているので、TLDR節に書いた内容についてはそんなに無理がなくある程度再現性があるんじゃないかと思っている。
辛さでいえば大学院のほうが辛かった。
可処分時間ということでいえばCOVIDで通勤時間が無くなった影響はそれなりにある。
自分について
・要領は決していい方ではない
要領がいい人なら5年も掛けずもっと早く辿り着くのではないか。
今回、特にジョブホッパー的な動きはしていない。各職場（案件）に恵まれたこともあるし、器用さが足りないといえばそうだと思う。
エージェントは中抜きされるという意見もあるが、自分はSNSは長続きしないし、勉強会もあまり肌に合わずほとんど出席することはないのでエージェントを通してしか案件を見つけられていない程度の行動力しかない。
年収についてはおおむね満足するようになり、人間とは面白いもので段々欲がよく出てくるようになった。
モダンな技術は、レガシーな技術よりも、おしなべて責任範囲が明確であり、何かあったときのリカバーがききやすかったり、謎の負債が含まれるリスクも少なく、幾分か安心して開発ができる。枯れた理論は好きだが、新しい技術を先回りして身につけることにも興味が湧いてきた。
xRやブロックチェーンといった、技術で未来を作っていくことにも興味が出てくるようになった。
いろいろあるけど、自分の観測範囲ではRuby（やそれっぽい言語）が好きな人間ほどgolangを嫌う。
自分はRubyを書かないけど、なんとなく気持ちはわかる。詳細は書かないけど「Rubyを書く上でプログラマが気持ちいいと感じる」要素をgolangはことごとく否定しているから。
Rubyが綺麗に着飾ったキャバ嬢だとしたら、golangは出産以降、色気のかけらも無くなった嫁の様なものだ。
その2人に対して、「一緒に飲みに行くならどっちがいい？」と「家族にするならどっちがいい？」を各々勝手に選んだ者同士が言い争いしてるんだろう。
実際のところ、MatzがRubyを作るにあたってどれだけ「仕事目的のプログラミング言語」というものを意識していたのかはわからないが、golangは完全に「Googleが自分の仕事のために作った言語」という認識なので、キャバ嬢が「お酒で接待する専門家」としたら、嫁と対比した例えは、もしかしたら逆になるのかも。
「GoでオススメのWebフレームワークを聞かれたら」ってタイトルにクソブコメつけたら、こんなクソみたいなコメントつけるはてブのほってんとりにあがってくるzenn嫌い!!って筆者が本題以外の記事もすべて消してしまった。この人の他の記事を求めていた人もいただろうし、なんか申し訳ない。黙ってスルーすべきだった。単純に機能を書くための時間をショートカットしたい人(ライブラリごとに開発者が異なるし切り替える不自由さがある。フレームワークだと一本開発思想が通ってる楽さはあるのよ)や他の言語から入ってくる人もいるのに初心者が質問した前提って暗においてること、それに対してウェブフレームワークなんか使わないで自力でgolang書けるようになろうねって書いてあって、必要な機能は全部書けばいいってウエメセな傲慢さがさすがGoogle Developer Expert (Go)って感じに非常に鼻についたことに黙ってられなかったし今もぐちぐちいう自分が幼稚やな。はっはっは。
ごちゃごちゃしたモデルがほいほい操作できて、Formもちょちょいと書ける。
テストもモリモリ書ける。
想像していたよりずっと良い。
気持ちがいい。
私ハマっちゃうかも。
でもFormでちょっと動的なことをしたいな、ってだけで、CoffeeScriptと格闘する羽目になってとても苦しい。
CoffeeScript辛いから全部サーバに処理させたいけど、そうなると、簡単な動的操作でも画面更新と履歴積み積みになってそれはそれで酷い。
というかCoffeeScriptむちゃくちゃ見辛い。地獄。なんだよこのインデント。
辛い。
病みそう。
RailsはAPIだけやってろって言う人の気持ちがよくわかった。
プライベートなメソッドや関数をテストする必要は無いと考えています。プライベートなメソッドは、実装の詳細であるからです。
ほとんどの場合、プライベート メソッドをテストする必要はありません。 プライベート メソッドは実装の詳細です。
「プライベートメソッドはテストするな」と強く主張されるのは、ケント・ベックの影響もあるかもしれない。
例えば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)
「プライベートメソッドをテストするか？」とは別に「ドキュメントをソースコードと同じファイルに書いていい(文芸的プログラミング)なら、単体テストをテスト対象と同じファイルに書いてもいいのでは？」というのも論点になるかもしれない。
