2022年11月9日

駆け出しのITエンジニアがやりがちな失敗。先輩から「自分の書いたコードでも1年経てば他人のコード。だからコメントはしっかり書いてね」と指導されるも…

50
えび@プログラマー @ebiebi_pg

ITエンジニア1年目 先輩「自分の書いたコードでも1年経てば他人のコード。だからコメントはしっかり書いてね」 🦐(お前の自論だろ?上から押し付けるな「綺麗に書けばソース読めるやつならちゃんと解るだろが!読めないヤツ乙」) ITエンジニア2年目 🦐(ゴメンナサイ、ゴメンナサイ、ゴメンナサイ)

2022-11-07 23:44:59
えび@プログラマー @ebiebi_pg

エンジニア1年目でモリモリとスキルが伸びて きちんとソース書けるようになったころに 「コメント書け」 なんて言われるとこういうシーンに出会います

2022-11-07 23:45:46

みんなの反応

遊©️ 2022 @4023vqad

@ebiebi_pg コメント書けって言われる環境なのちょっと羨ましい 僕の今の所属、コメント書いてないしコメント書いてプッシュするなとまでいわれる異常な環境なので・・・

2022-11-08 05:47:54
Yamachan @twowho

@ebiebi_pg 昔、COBOLやってたころは、詳細設計書・プログラム設計書どおりにコードを書くってルールだったので、 コメントはほとんど書かなかったですね。

2022-11-08 07:50:07
炊きあがれ!機動炊飯器ガン略 @shino65536

@ebiebi_pg コメントが実装と食い違ってると殺意を覚えるよね。 /** ユーザを登録する */ public function delete(User $user) {...}

2022-11-08 08:47:22
アスランの父 @dad_aslan

@ebiebi_pg コメントやドキュメントは自分も含めた将来、このソースを見た人への手紙だと思っている。

2022-11-08 09:51:32
ゴンノス @g2zZ

@ebiebi_pg 昔の風潮では「コンピュータの進化は早いので 同じプログラムを10年後も使っているなんてないよな」 それなのに現実では 20年前のソース読むはめになったりして。 #なんでこうなった

2022-11-08 09:53:59
人面犬じょり @mekenjyori

@g2zZ @ebiebi_pg 本来なら新ハード規格で互換がない筈が 機器を駆使してデータの移送を行えてしまうから大変な事(管理や様々な面)になってる ポケモンのルビサファがまもなく20年、かがくのちからってすげー 20年前のデータを最新ハードで使えるゲームはオカシイ

2022-11-08 15:51:47
ゆっくりドットコム @ch62547763

@ebiebi_pg ゴメンナサイ、ゴメンナサイ、ゴメンナサイ、ゴメンナサイ、ゴメンナサイ、ゴメンナサイ、ゴメンナサイ、ゴメンナサイ、ゴメンナサイ、ゴメンナサイ、ゴメンナサイ、ゴメンナサイ、ゴメンナサイ、ゴメンナサイ、ゴメンナサイ、ゴメンナサイ、ゴメンナサイ、ゴメンナサイ、ゴメンナサイ、ゴメンナサイ!

2022-11-08 10:04:03
ciro @_ciro_sa

@ebiebi_pg コメント書くのは、特記事項だけで良いと思いますよ。 ※1: ベースのコードが変数名、メソッド名などで説明できてる場合のみ ※2: 説明できてるコードを書ける人は一握り

2022-11-08 10:57:18
daigoro.tsv @daigoro021

@ebiebi_pg 意味不明なコードは、処理の内容がわかっても意図が通じない場合がほとんどです(難読化されたコードもありますが)。 コメントはあくまで「実装者がこのコードを書いた意図」を示すべきな気がします。

2022-11-08 11:49:12
わなごなwannagonna🧲 @TDlMfYJgeZCKao3

@ebiebi_pg 自慢か?3日の時点で他人のコードになる俺は記憶力悪いと言いたいんか!

2022-11-08 12:41:07
th0x0472 @th0x0472

@ebiebi_pg 作業手順書なんかも近いものがありそうですねぇ。 私は「その業務を離れて半年か1年たって業務固有のことをすっかり忘れた自分」でも問題なく作業できる、を目標に手順書を書いてます。

2022-11-08 13:36:44
しろつつじー@プログラムの話題なら極力一緒に悩み〼 @white_azalea

@ebiebi_pg 長く保守されて来たコードだと、メソッド名以上の処理が行われている事もしばしば… リファクタさせてもらえるならまだしも、NGされたらコメントだけが最後の砦になる…。

2022-11-08 18:30:22
molaris @molarisun

@ebiebi_pg うん十年前からソースコードにコメント書いたことがない。困ったことはあんまりない。エレガントすぎるコードは書かないし。一回切りしか使わないプログラムのときしか。

2022-11-08 20:17:10
kumapress @kumapress1

@ebiebi_pg 正しいコメントはお金になりましたし。。 今はどうなんだろ??

2022-11-08 20:34:03
蒼眼鏡👓 @yt93c

@ebiebi_pg ゴードン・アルジャーノン効果っちゅうて、「はあー?なんでこんなコード書けたんや?→昔の俺」って自分のソースコードを見ながら思うことがありますんや。

2022-11-09 00:18:30
ブラックジャックなエンジニア @TOkyaku

@ebiebi_pg 若い時代は、自分で書いたコードはいつまでも忘れずに理解できるかもしれないが歳をとるにつれて段々と忘れてくるようになる。必然的にコメントを自ら書くようになる。コメントのやたら多いコードは歳とったエンジニアかもしれない。

2022-11-09 09:05:34
Instance@VRChat / 原神 @Instance_Main

@ebiebi_pg 「何をしたいか」「そのために何をするか」「このパーツは何か」「このパーツは何に繋がるか」「何故この処理なのか」を書かないと概ね死ぬ

2022-11-08 20:14:35

コメント

sigmarsphere @sigmarsphere 2022年11月9日
情報保証の一種さね。経緯追跡可能な情報化。
1
おろろ @fYe39CoQsPrbZVK 2022年11月9日
コメントは単体テスト通らないので、正しさを保証しない。仕様変更や機能追加で書いてある事と動作が違う事なんてザラにあるので不要。コメント書くならテストコードを書け
2
棘垢 @eU3oSlnSHuAO49c 2022年11月9日
ダニングクルーガー効果の最初の山を下り始めたところやな
0
たるたる @heporap 2022年11月9日
関数をコピペしてコメントの修正を忘れるあるある。<コメントと実装の食い違い
6
早川慶次 @keiji_hayakawa 2022年11月9日
3日経てば他人のコードに激しく同意
38
SAKURA87🌸 @Sakura87_net 2022年11月9日
まとめにも似たような話があるけど、特に初心者は自分の思ってることとやってることが違う事があるので、確認のためにもどういうコードなのかコメントを、出来れば1行単位、なるべく処理単位で遺すようにしたらハマったときの間違いを見つけやすくなるからコメントは絶対残しておいた方が良い。
18
trycatch777 @trycatch777 2022年11月9日
20代の時に当時の師匠に言われた言葉がまんまこれ。プログラム書いた人と保守する人は別だからコメントちゃんと書けと。当時はソースコードレビューやってるプロジェクトに居たので、曖昧だったり間違いのコメントは全部直させられた。
9
aa @aa60006342 2022年11月9日
ドキュメント、コメント、テストとどれも開発の補助になるものだけど主張すべきものが違うってのを理解してない人は多い
9
prad_bitt @pradbitt42 2022年11月9日
3日で分からなくなるって言ってるのはPerl使いではないな。Perlは3時間で分からなくなる。
14
辛いマン @tsurai_man 2022年11月9日
関数名と引数でどう言う処理か伝わるように書けるまではコメントちゃんと書いてくれ
0
kusano @t_kusano 2022年11月9日
たったの一年も働いたことがない分際で「お前の自論だろ?上から押し付けるな」とかクソ生意気な反抗するようなガキは要らん。
9
岸本慎介 @tamago915 2022年11月9日
処理はコードを読み解けばわかるので、その処理を行う意図をコメントに書いてほしい
26
さとうあきひろ @akihirosato1975 2022年11月9日
trycatch777 今どきはweb業界だとDevOpsが普通なので、自分が書いたコードを自分で保守する展開になる。昨日も社内のmtgで、7年前に自分が書いたコードの意図を聞かれて、さすがに覚えてないわと返事した。
2
neat @neat2103 2022年11月9日
/* この行を消すと落ちます */
1
Metallis(へたれ) @c7R1S0tU 2022年11月9日
テキストベースのプログラムはまだいいよ・・・しっちゃかめっちゃかに制御の絡み合ったラダー言語なんかもう最悪だぞ
3
かぶ @kabu0404 2022年11月10日
コメントに「仕変番号ここから」と「仕変番号 ここまで」って書けって言われるプロジェクトはやめとこうね
1
お断りします @oktwrshmth 2022年11月10日
一年もいらんよ。週末の自分と週明けの自分ですでに意思疎通ができてない……
17
しまの @shimanonno 2022年11月10日
エンジニアではないけど、FileMakerのスクリプトでさえ1年たったらよくわからなくなってた。 自分と自分がわかり合えないなんて驚き。
0
moxid @moxidoxide 2022年11月10日
毎日やらんことはな、分からなくなるねんな…
1
クロックル @clock10_10 2022年11月10日
大規模でやってると何十年も使われてきたものに今でも手を入れることはあるし、その時に頼れるのは設計書とコメントだけなので、処理ごとに網羅的に入れておかないとマジで後(に触る人)が辛くなる
1
伍長 @gotyou_H 2022年11月10日
ゲームでもちょっとプレー期間空いたりしただけでどういう意図で編成したのか思い出せなくなる事例がよくあるのでな。。。  なので「マイセット1」「マイセット2」の部分の名前変えれるやつは「対○○」とか「△△待ち」とかなんとかちゃんと変えとかないとダメだぞ
5
あごにー @Agony_01 2022年11月10日
組んだプログラムが一人でもこれなんだから、いろんな人の手が入るような環境下だとまずコメントで処理書いてから実際のコード書くぐらいでちょうどいいっていうね。
1
ディアリーン@アークス @amatuki314 2022年11月10日
コメントの内容はあてにならなくても、日付はあてになるで
0
MSどす🌤️TL49 @msdos148 2022年11月10日
某銀行PJの受け入れ検査で、プログラム中にコメントが一切入ってないぞと指摘した事がある。オフショアのひ孫受けの書いた文字コードが表示できないので、孫請けの韓国人がぜんぶ消していたという事が発覚した。オフショアが一体どこなのか不明のまま終わった。
0
ひげぶくろウエストゲートパーク @jrskigogo 2022年11月10日
誰やこのクソ仕事!って数年前の自分だった事なんか多々ある
4
navyfox @navyfox 2022年11月10日
テストコードも所詮はプログラムなので「テストコードの意図を読み解く」プロセスがどうしても介在する。どれか一者が正しいというよりはコード、コメント、テストの三者をクロスチェックすることでおかしい箇所があぶり出される。
5
ポップ @bottlefoam 2022年11月10日
1ヶ月前のコードで無理。
1
VRAM01K @VRAM01K 2022年11月10日
確かにコード読んだらどう動くのかは読み取れても、何のためにやってるのかとか何を意図してのコードかが分かんなくなるのよね。そしておまじない化してしまう…
1
Calucifer🌲 @Chigami 2022年11月10日
「Aって書いてあるけどBが正しそう」的なコードがあった場合、どんな意図で書いたかのコメントが無いと「書いた時からあるミス」「書いた時はAが正しかった」「深淵な意図があって実はAが正しい」などの可能性を検証するために変更履歴の奥地に旅立つ必要があるから…
12
S @SAKU030907 2022年11月10日
あれってどこにしまったっけ?!(見つからない)に通じるものがある
0
tibigame @tibigame 2022年11月10日
コメントだけを見て何をやっているかがわからないといけない。特に多人数で変更頻度が高いものは。コードを見れば処理はわかると言うが、コード解読するコストよりもコメント読むコストのほうがはるかに低いので、そのコストを他人(未来の自分)に押し付けてはいけない。コードを読むのは実際にコードを変更しようと思った時だけでいい。
3
掛居明彦 @KakeiAkihiko 2022年11月10日
コメントは正しさを保証するっていうよりブックマーク用途だな。メソッド名とか引数リストとかを見るよりは、探そうとしてるフィールド・メソッドが早く分かる。
0
かばなり @kabanari 2022年11月10日
誰が読むかわからないドキュメントを小奇麗に長々と書くよりも、ほぼ間違いなく未来の自分も見るであろうコメントを書くほうが心理的負担が少ないと思ってます。個人の資質や会社の社風にもよるでしょうが。ただ、わかりやすいコメントって結構難しいんですよね…。
0
fukken @fukken 2022年11月10日
コードには How テストコードには What コミットログには Why コードコメントには Why not を書こう、という名言があってな https://twitter.com/t_wada/status/904916106153828352 「それはコメントじゃなくて〜に書け」という主張は正当だが、それを以てコメントが不要になるということはない
5
M.Abe @abe_m 2022年11月10日
コメントをどうするかは議論の余地があり得るが、反論もせずに指示を無視するのは100%有害。
0
星山 等(TA-ZZW30) @H_Hoshiyama 2022年11月10日
oktwrshmth 3連休以上はほんとヤバい。連休突入前の退勤間際、毎回時間をとって備忘録を作ってる。それでも絶対???になるけど、備忘録の有無で悩む時間が段違いだからな…。作成にかかった時間なんて余裕でペイする。
1
LCO @f_lco 2022年11月10日
3~4年目になると「メモに11/10って書いてあるけど、去年(2021)と2年前(2020)どっちだ…orz」ってなって、年月日をちゃんと書くようになる
3
M.Abe @abe_m 2022年11月10日
コードは頭使うのでまだ記憶に残るが、ソフトの設定をなぜそうしたかなんてまず憶えていない。
2
mar @rammmmmmmmmmm 2022年11月10日
// iに1を代入する int i = 1;
0
blossom @blossom53884378 2022年11月11日
rammmmmmmmmmm i++; /* iをインクリメントする */ に通じるものが
0
kartis56 @kartis56 2022年11月11日
新人には新規ソース書かせるより、他人のバグ修正やらせるのがいいよ
0
マグロ @maguroyanen 2022年12月3日
これどんな仕事でも言えるなあ。 昨日の自分も明日の自分も他人だから信用するな、昨日の仕事は再度チェック、明日の仕事は明日の自分ならちゃんとやるとは思わない。
0
のみりん @nomirin 2022年12月7日
「○月○日までは削除しないこと」ってコメントがあって、年が書いてないので、削除されずに何年も放置されてるコードを見かけることがあるので、コメントを書いても誤解などが生じないようにしないとダメだったりする。バグでも無いのに動いてるコードをわざわざ変更するリスクなんて誰も取りたくないし。
0