00:08
はい、みなさんこんにちは。kkeethこと桑原です。本日もやっていきましょう。
kkeethのエンジニア雑談チャンネルです。この番組では、ウェブ業界に関することや、
エンジニアリング、いろんな技術についての雑談などの情報を発信していきたいと思います。
で、今日は、まあタイトルにあります通り、個人的ソフトウェアエンジニアあるあるのネタを
喋っていきたいかなと思ってまして、まあよくあるあのヒヤリハットとかワードあると思います。
あのヒヤリとしたこと、もしくはハッとした気づきみたいなことをですね、ヒヤリハット。
だいたいこうリスク的な観点でお話されることが本当に多いと思いますけど、
まあヒヤリは特にそうですね、リスクの話にあることが多いですけど、
まあハットしたことは、なんかポジティブな面での気づきっていうのもあると思いますけど、
まあそういう話もあるんですけど、そういうあるあるネタですね、かなりいい学習になると思ってて、
もう一回そういうことをやらないようにするとか、他の現場ではそれを繰り返さないようにする、
また事前にそういうリスクとか落とし穴があるよっていうことを知っておくのはすごくいいことだと思います。
あるあるであるからこそ再現性が高いのであれば、それを倍知っておいて、
なんか事前に対処法とかを知っておくのはいいんじゃないかなと思ったりしているので、
最近はあるあるネタを割とかき集めたりとか、まあ見てて、
ああそうだねとか共感わかるみたいなことを集めるのがちょっと趣味になりつつあるんですけど、
まあそういう系のネタの話をはいくつかしていきたいかなと思ったりしております。
まあたくさんあります。かき集めれば集めること本当たくさんあるんですけど、
そうですね、スタートはですね、僕も個人開発をちょいちょいしてて、
最近もアップデート、自分のNPMにアップしているライブラリーのアップデートとか更新も去年もしてましたけどね、
やってるんですけど、なんか久しぶりに自作ライブラリーとかのアップデートするときですね、
だいたい久しぶりなんですよ。何ヶ月か、下手したら何年ぐらい放置していて、
まあなんか見てみたら、ああそういえばこんなコードになってたなとか、
当時はこんなプラットフォーム上にアップロードしてたとか、こういうことを想定していたなみたいなことですね。
まあ言語もフレームワークもライブラリーもだいぶ古いわけですよ。
で、それをアップデートしようとなったときに、よくあるのは開発環境を何にしよう、ですね。
開発環境の各ツールとか技術ですね。
まあ新しく、もうほぼほぼ刷新するぐらいの勢いで作り出すことってよくあるんですけど、
じゃあもうこれを機にあれも勉強したいし、そういえばやろうと思ってた、
この技術も一緒に学んでしまおう、みたいなことでやりがちなんですけど、
いざやり始めたり、いざ学び始めると、その学習とか学びが面白すぎて、
そっちの方にどんどん花が咲いてしまいまして、
本来やりたい自分の作ったシステムとかライブラリーの更新に返ってこないみたいなのがよくあるんですよね。
もうずっとインプットばっかりこうし続けると。
エンジニアってインプット、なんだかんだ好きな人多いと思うし、
自分の好きな技術とかおもちゃのインプットをしているので、
それは余計にそうなので、本来やりたい、本筋に返ってこない問題はよくあると勝手に思っています。
03:01
利用進歩はいくつか学んだんですけど、
じゃあいざ使おうとしたときに、このライブラリーとあのライブラリーの親和性だったりとか、
フレームワークとこいつとこいつはちょっと相性悪かったなというのがよくよくあるんですけど、
そのせいでなくなくてもこれをやめましょうとか、
やっぱこっちちょっと古いかもしれないけどやっぱ枯れてるし、
使いこなせてるし、慣れてるっていうのもあってやはりこれ入れるかというので、
新旧カオスみたいな開発環境が出来上がってしまって、
結果美しくねえぞみたいな開発環境になってしまうこともあるなという感じがありますね。
言語レベルとかフレームワークレベルで変えるってなると、
もうほぼゼロペースで作り直しに近いと思うので、それは別にいいと思いますけど。
あとは久しぶりに自分のコードを見たら、
コード書かなかったエンジニアだったらあんま変わんないかもしれないんですけど、
さすがにやっぱコード書き続けてる人間としては、
知らず知らずのうちにやはり技術は磨かれていったり、
自分のプログラミング、コーディング力っていうのがやっぱり鍛えられてて、
久しぶりに数年前、数ヶ月前の自分のコードを見ると、
汚ねえってすごく思うんですよね。
このコードを書いたの誰だよみたいな、
いや当たり前なんですけど自分なんですけど、
やはり過去の自分は他人なんで、
いやひどいなみたいなこともよくあったりしますね。
で、見たくもないけど仕方ないのでこう直していくっていうのはよくある。
それは個人開発だけじゃなくて、
プロジェクトでもそうだと思いますね。
ちょっとこのコードよろしくないなみたいので、
Gitブレイムとかを叩くと、
あれ?俺じゃね?ってなったりするんですよね。
本当に何とも言えないですけど。
あとはですね、チームで開発をしていたときに、
たまに思ったりするのは、
このコード普通にスタックオーバーフローから
コピってきたんじゃないみたいなコードとか、
たまに見たりしますね。
この人だったらこういう書き方するとか、
こういう癖あるよねとかあるんですけど、
明らかに違うコードだろうっていうのを見たりするときがあります。
それはチームで開発しているので、
他の方が作ったコードを参考にしながらとか、
やっぱりそのコードの統一性とかはあったりすると思うので、
参考と言いながらほぼほぼコピっているときもあったりしますけど、
そのコピーの元がチーム内の他のコンポーネントだったり、
他のモジュールの書き方ではなくて、
外から持ってきたものってたまにあるよねっていうのがあったりして、
動けばいいっちゃいいんですけど、
たまに明らかにこの人のコードじゃないなっていうコードを見たりすることはあるなと思う。
別に指摘することはないですけど、
たまに雑談するときとかに聞いたりしていますね。
そんなことをやったりするのもあるあるのひとつないかなと思ったりしますね。
さっきのクソコードの話をしたんですけど、
コードが汚いまではいいんですけど、
なんかバグったり、エラーが起きたときですよね。
起きて原因探っていくと、
よく見てら、その原因のコードを書いたのは私だったわみたいなのもよくあると思います。
いやいや、これエンジンが一度は通る道だと思うんですけど、
なかなかどうして面白いことにそういうこと起きるよねっていうのはよくある話ですね。
あとは、さっきの話に戻っちゃうけど、
技術を学び始めたら次々と技術にひも付いた技術が出てきたりとかあったりするので、
とにかくインプットを永遠にしちゃう系の話は出てくるので、
06:02
それはよくないと思いますけどね。
あとはあるあるの鉄板で言えばですね、
バグ修正とかエラー修正してるんですけど、
すげー悩みに悩んだとか、原因もぐりにもぐって探して特定できたと。
いざ直してみると、意外とコード1、2行で直ったりすることもたまにありますよね。
1、2行は滅多になくても、数行直せば実は直りましたってよくあったりするので。
エンジンやってほんと難しいですけど、ある意味でしっかり設計されたりとか、
セキュリティの分割ができてるんであれば、コードが短くなるってのもよくある話ですね。
それは良い話なんですけど、マネジメント系の人からすると、
結果的にやったことって言うとコード1、2行とか数行しか直してないみたいな話があって、
それまでの調査時間の方がやはりエンジンはとっても時間を使うんですよね。
コードを書く時間よりも設計をするとか、いろいろググったりとか、
先行事例ないですか?って調べたりする。
そっちの方に多分時間の個人的に7、8割使うんじゃないかな。
残り2、3割でコードを書いてプリク出してレビューしてもらってっていう感じな感触だと僕は思ってるんですよ。
コードの行数が結果短い系のこともあるあるなんじゃないかなと思います。
短くやれば短いほど、しっかり設計されたり原因が分離されたりするっていうのはあると思うんです。
良い話だと思いますね。
あとあるあるでいくと、これも鉄板ですけど、やはりドキュメントがない系のあるあるは
しょっちゅうありますね。今も繰り返してるし、
令和になりましたけど、そういう現場とかそういう話はいくらでも出てくるので、
そのドキュメントがないって言ってるのは、今この瞬間で欲しいドキュメントとか記述がないっていうのはよくある話で、
ドキュメント自体がないっていうのはもうだいぶ減ってきたんじゃないかと思います。
ただそのドキュメントが効果的なものはなくて、単なるメモ書きだったり議事録だけで書いてあって、
それがちゃんと仕様書というか今回のプロジェクトとかシステムのドキュメントになってないみたいなもの。
っていうのはドキュメントがないというふうに皆さん多分感じると思うんですよね。
特にシステムが長くなればなるほど、昔からどういう思想でこういうのが作られたとか、
なぜこのコードはこういう設計になりましたかっていうその意図がない時があるので、
せめてプログラムのコードの中にドックが欲しいわけですよね。
コメントでなんでこうなったっていうのが書いて欲しいんですけど、それもなかったりするので、
ドキュメントがない系の悲しみはよくあるので、
未来の自分を助けるのもそうですし、チームメイドを助けるのもそうですし、
今後メンテナンスをする、自分以外の人がメンテナンスする可能性もありますけど、
そのためにもしっかりドキュメントは残しておく。
そのドキュメントがちゃんと意味のあるもの、効果があるものっていうのを書き残すってのは必要だなと思います。
本当にこれを書くかないで、将来的な自分が絶対苦しむんですよね。
自分がシステムとかアプリを見る場合ですけどね。
他の人に託すんだったら極論自分じゃないしいいかっていうのはあるかもしれないですけど、
良いエンジニアは絶対そういうのをちゃんと書くので、
自分じゃないからいいやっていうのはあんまりよろしくないマインドだなと思ったりするので、
09:01
しっかりドキュメントも書きましょうっていうのはありますね。
あとあるあるネタでいくと、さっきのライブラリとかバージョンとかの話でもあるかなと思いますね。
最終的にアプリケーションっていうのはプラットフォームとかインフラの上に乗っかるので、
レイヤーが低い技術のバージョンとかに引っ張られて、
上に乗っかるアプリケーションのバージョンを下げたりとか、
使いたいものが使えないっていうのもよくある話ですよね。
枯れててちゃんと安定して動かすっていうことがすごく大事なんですけど、
その技術が枯れてメンテナンスされてないってなると、
それは枯れたんじゃなくて死に始めているので、話は別だよなっていうのがあるので、
この辺が上手いこと技術選定できればいいんですけど。
エンジニアあるあるでいくと、コードを書くよりも会議をすることが多かったりするみたいな。
そういう会社もあったりするかもしれないですね。
会議文化の会社は意外といっぱいあるので。
特にお客様と話すときもそうかなと思いますね。
定例会の会議が当たり前のように2,3時間、毎週1回やりますみたいなのがあって、
そんなに言ってないです。
正直僕も過去に会議中、
明らかにこれ私の話関係ないなっていうか、
エンジニアリングの話まで落ちてないなって時は内職したりとか、
オンラインで参加していたりでひたすらコード書いたりとかもしたりはしますけど、
会議ばっかりの現場ってのもよくあるなって思いますね。
あとはですね、最後エイヤで決めなきゃいけない場合とかもあったりします。
重い行動というか、責任が本当に重いような実装をしなきゃいけないとか、
やらないと困る。でもあんまメリットは生まれない。
ただデメリットがあった時に多い。
セキュリティとかの話もそうですけど。
ような行動のか意思決定をしなきゃいけない。
設計とかですけど。
その決断を下すのに、やっぱり個人で考えるのは正直しんどかったり、
経験値のある人にやってほしいと思いますけど、
経験値のある人も最後それでいけるというか、
保証ができるわけではなくて、結局エイヤで最後決めるんですけど、
それをみんなで相談して、
要は一曲あなた一人がやったんだよじゃなくて、
このチーム全体としてみんなで意思決定をして、
みんなで責任を分担しようっていう風な意思決定をしたいんですけど、
みんなそれを発言しなくて、
最終的には年長者とかこういうのをよく知ってる人が決めたからやりました、
みたいな態度を取るケースってよくあると思うんですよね。
これは自分も分からないことたくさんあるので、
そういう風にしたいんですけど、
とはいえ何か起きたときに結果、
自分は技術がなかったりそこに関して詳しくないので、
対応してくれるのは対応できる人にやっぱ任せてしまうので、
その意味も兼ねて、
もうその人に最後決断を委ねないというのはよくあると思うんですけど、
ただその人はいろんな人と考えて、
多角的に見てこれでいこうと意思決定をしたいので、
できれば手伝ってほしいというか、
一緒に考えてほしいというのがあると思うんですけど、
このギャップって意外とあると思います。
経験値がないし分からないから、
関わらないという態度を取るのは僕は違うと思っていて、
分からないなりにプリミティブな質問をどんどん投げたりとか、
観点でこここうなの?みたいな。
先輩だったり慣れてる人からすると、
もう通った道かもしれないですけど、
分からない人には分からないので、
お互いそういう関係性でしっかりコミュニケーションを取って、
やっていくのがいいんじゃないかなと思ったりはします。
12:02
あとはですね、これもプロジェクト次第だと思うし、
個人開発あるあるではあるんですけど、
やっぱり納期を決めない開発って、
すごいダラダラやっちゃいますよね。
そういう開発してればするほど、
だいたいインプットに時間を使えるんですよね。
結局延々と学習とか学びの方に行って、
開発進まねえなみたいなのがよくあると思います。
お尻がいきなり決まったりする場合ももちろんあるんですけど、
お尻が決まっていくと、
だいたいコーディングのリソースの分散って言ったらいいのかな。
コミット量にしましょうか。
各リポジトリで管理すると思うんですけど、
リポジトリのコミット量ってリリース手前になればなるほど、
急に跳ね上がりますよね。
最後の方になるとみんなうわーっと一気に、
本当はこういう石鹸したいとか、
こういうクリーンなコードを書きたい、
もしくはこういう堅牢なコード、
綺麗なコードを書きたいとか、
いう風に思ってるんですけど、
いざいろんな物事を進めていくと、
外部要因だったり、過去の負の遺産だったり、
環境の問題もあったりするので、
理想のコードと現実のコードが違ったりする。
ただリリース直前になってくると、
そこを諦めるじゃないですけど、
落とし所を決めて妥協して、
あとはもう作るだけーな方向に持っていくと思うんですよね。
そうなってくると一気にコードって書き始めるんですよね。
なのでやっぱり決めることが割と、
本当は大事なんですけど、
なかなかやっていく最初のうちに時間的に余裕があると、
人は理想を追い求めてしまうし、
エンジニアもそういうのよくあると思うので、
理想のコードとか設計をしたい。
のではなかなかコードは進まないんですけど、
割とゴールが目の前に迫ってくると、
いくら何でも妥協しなきゃいけなかったりするのはよくある話なので、
いろいろ諦めた結果、
ゴールまでもう見えてきた。
あとは走るだけみたいなところで、
みんな一気にコードを書くっていうのはよくあったりするんですよね。
ここはですね、
マネージャーやったことある人からすると不安なんですよね。
本当に、
今実際に実装の何パーしかできていませんとか言われると、
でもリリース目の前なんだけどっていうのって不安なんですけど、
でもエンジニアって本当は綺麗な、
良い設計で良いアプリケーションを作りたいっていう意思はあるが、
そのギャップはありますけど、
でもみんなよくやるよなと思ったりしてますし、
僕も何らかんでやります。
まだ時間あるから、
もうちょっと設計やっぱりやりたいとか、
しっかりレビューして、
しっかり綺麗なまま、
将来の自分の拡張性だったり保守性を担保するようなコードにしたいみたいな。
だが、リリース前になってくると諦めて、
とにかく作って動くっていうところまで早く持ってきたいみたいな感じになるので、
終わりになればなるほど、
コミット量が爆増するっていうのはよくある話だなと思ったりしてます。
ただ、Git Brave叩いて、
このクソコードが、
意外と先輩が書いた時とかあったりするんですよ。
先輩、こんな尊敬する人でも、
やー、やるんだなっていうのを見た時は、
エンジニアってやっぱ人なんだなって思う時もありますね。
一応過去の経験上、
ほぼほぼ喋ったことないんですけど、
一緒の会社にいた人で、
1時間か2時間くらいずっとヘッドホンつけて、
一切外部音、社長が話しかけてもガン無視するようなエンジニアさん1人いたんですけど、
その人はちょっとバケモンで、
マジでバグ出さないんですよ。
15:01
絶対にバグが出ない。
いろんな方、ちゃんとシステム連携したりとか、
コアな実装を担当してくださることもよくあったんですけど、
その人だけはなんかちょっとバケモンでしたね。
ただ、ああいうエンジニアになりたいかというと、
僕はちょっと理想ではなかったです。
僕はやっぱりコミュニケーションする方がやっぱり大好きで、
理想ではないんですけど、
ただプロジェクトにいてほしいと思う、
理想のエンジニアってしたらその人に上がりますね。
いやー、びっくりだったな、ほんと。
テスト100%通るしな。
ほんとにいるんだなっていう感じです。
今まで何百人とエンジニアとお会いしてましたけど、
ついその人だけでしたかね。
バグを一回も出さないエンジニアっていうのは。
まあまあ、そういう稀有な例は、
基本的にはほぼいないと思ってますし、
本当に奇跡的な奇跡だったんでね。
あれですけど。
はい、というので、
エンジニアあるあるの話は、
どちらかというと行動確保。
プログラマーのあるあるネタだったかもしれないですね。
エンジニアっていうと。
本当はエンジニアってやっぱりコミュニケーションしたりとか、
設計だったり、
他の人たちとどう連携をするかみたいな話もいっぱいあると思うんで。
まあその辺のあるあるもたくさんあると思うので、
また定期的に喋っていきたいと思いますし、
ネタはほんと尽きないですね。
まだね、一応ガッとリストで上げてるんですけど、
今回は完全にプログラミング要素ばっかりだし、
ネタだったんで。
はい、また他のネタ、
レイヤーの高いところの話とかもできたらなと思ってますので、
興味あれば来てみてくださいと。
またこういうネタもありますよねっていうので、
またネタの提供も募集してます。
まあ僕が経験したネタしかやっぱり僕は思いつかないので、
他の人たちのネタも聞いて、
皆さんで学び合いができたらなと思ってます。
はい、今回はこんなところで終わっていきたいと思います。
いつも聞いてくださり本当にありがとうございます。
ではまた次回の主力でお会いしましょう。
バイバイ。
