アプリで作成

「分かりやすく美しいソースコードは業務の現場ではあまり求められません」に総ツッコミ「コメントはきちんと書こう」「保守性を考えると…」

まずは実行まで動かすことからってことなのかな
141
まっつん総研@図書館プログラミング実習室 @matsun_research

小学生向けプログラミングの本でしれっと有害な嘘を書くの、やめてくれませんかね…。前後は正しいから尚更厄介だ。 pic.twitter.com/xgbotOSi86

2019-04-25 00:42:35
拡大
まっつん総研@図書館プログラミング実習室 @matsun_research

他の制御文で書いた方が簡潔なのに「便利だから」という理由でGOTO使ってるし…僕も初心者向けにGOTOを進めたことがあるけど、本当にGOTOが一番簡潔に書けるシチュエーションだったからだし、20年以上前のことで相手は大学生だった。

2019-04-25 00:49:01
まっつん総研@図書館プログラミング実習室 @matsun_research

元SE、現在は小学校プログラミング教育のことをいろいろ調べ中の図書館員(not司書)。※発言内容は個人の見解です

https://t.co/ldn2Vq9zel

クマノテツ @kumanotetu

業務では求められます が、学習では色々と試行錯誤することを優先して気楽に書きましょう!が自分の思う正解です わかりづらいコードなんて書いた本人ですら3日でわからなくなるので、それでは効率良く働けないよ!って事を声を大にして言いたい twitter.com/matsun_researc…

2019-04-25 10:11:04
MA @MitsuakiAadachi

@cloche019 @matsun_research まずは気軽に体験してほしいって意図なのかも知れませんが、保守性を完全に無視してますよね。教科書としてはRASISの重要性を踏まえて構成して欲しいとこですね。

2019-04-25 09:25:35
かわいち @waverideraction

@matsun_research 基本的に現場ではマクロでチェックされるため綺麗なコードを書くよう求められるからね、あと必ずコメントも書こうね!3日経ったら忘れるから!(経験者

2019-04-25 08:30:03
りゅーすい(とおぴさく) @flwater_generic

@matsun_research これはひどいw求めてるけど余裕がなくて美しくなくなってるだけだよ><

2019-04-25 00:45:56
Keisuke S@SugarAddict @F_N_K_Gino

@matsun_research @MIBkai 「求められていない」、ではなく「見られない」とか「発見されることは極めて稀」とかにしてほしいですね。「動けばいい」「書いた人がわかればいい」ってクソコードは撲滅していかないと。。。

2019-04-25 08:49:42
n-kiduki @nkiduki

「美しさ」はどうでもいいけど、インデントだけはしっかりしてw あと、意味がある変数にAとかBとか適当につけるのヤメテw twitter.com/matsun_researc…

2019-04-25 10:26:21
Mill=O=Wisp @millowisp

@matsun_research プログラムの「美しい」って、「見た目の簡潔さ」「文字数の少なさ」「処理の目視での追いやすさ」あたりの概念が混在してる印象。

2019-04-25 09:05:02
やまもん🚴チャリ走&HTML5カジュゲー社長/株式会社Liberapp📢りべらぷ/本名:山田元康 @MotoyasuYamada

美しいソースコードって言葉キラーイ!! コメント書いて綺麗に装飾することが綺麗なコードじゃねえゾ 責務分担、重複なく混在もなく、堅く動くが、仕様の変更に柔軟なソースコードが一番や なんと呼べばいいのか? 質実剛健? 数学風にエレガント? twitter.com/matsun_researc…

2019-04-25 10:08:41
千代田数理セミナー @BZM10005

日本語って難しいですね 文意の解釈問題かな 玄人が 後からみてわからないレベルの スマートすぎるコードは歓迎されませんし “わかりにくく 美しい スマートすぎる コード” とするなら正しいのかな 素人目線のチェックも入れた方がいいですね twitter.com/matsun_researc…

2019-04-25 10:05:52
@cloche019

@matsun_research 「動けばOK」的な作り方をされた結果、「これ直すなら最初からやり直したほうがいいんじゃないか?」と思われるものが出来ることに…。

2019-04-25 09:13:11
Kenji Otsuka @_kjot

@matsun_research これはおかしい。 ソースコードは人それぞれで変わってくるからコーディング規約というものができたりしているのだが。

2019-04-25 09:15:42
ohNussy@個人開発者 @ohNussy

「美しいソースコードは求められてません、動けばOK♪」ってのは、「私は掃除しないし二度とこの部屋来ないから汚してもOK♪」とほぼ同義 twitter.com/matsun_researc…

2019-04-25 10:11:33
Alpha Lead @alphalead

@matsun_research これは酷い。 こうやってスパゲティご量産されていくのですね…。

2019-04-25 09:32:07
アルター8の蟹漁師(元) @RiscStorage

@matsun_research スパゲッティ~スパゲッティ~ 混ぜ混ぜグチャグチャ何処へ飛ぶ~ スパゲッティ~スパゲッティ~ やったの誰だ~居ない人~···

2019-04-25 09:32:42
alf @alf361

@matsun_research @sek_mnt 言語何なんだろう… gotoもあるのか… 生徒達にVBAが書けるようにしてるのかな?

2019-04-25 10:09:36
kbwave @kbirwave

実際に求められるのは納期までに対応を終わらせること。 ソースの美しさよりは速度を求められるのがITの現場なので間違ってはない。 けど、そのせいで保守が死ぬことも書いて欲しいな・・・ twitter.com/matsun_researc…

2019-04-25 10:15:05
くにあつ(本人) @kuniatsu

わかりやすいは求めるね。気取った書き方をしたくなっても、ダサい可読性の高いコードを書くのが大事だと思ってる。それによって後々の進捗が変わっていくのだ。 逆にワンポイントで配属されたSESだった時は「食らいやがれ」って気持ちで新しい書き方とか美しい書き方を書いてたな、その方が楽しいから twitter.com/matsun_researc…

2019-04-25 10:07:51
BattleWolf359 @wolf359battle

まず「わかりやすい」と「美しい」はちがうし「実行速度が速い」ともちがう。 まあそういう職業に就くんならコーディング規約とかソフトウェア工学の勉強はほぼ0からやる羽目になるし、BASICなんかどうせ使わない。 一般に教えるなら重要なのはデータ構造とアリゴリズムだと思うな。 twitter.com/matsun_researc…

2019-04-25 10:03:48

コメント

rambda @rambda2 2019年4月25日
変数に「日本語」は使えません。も間違ってるような…… 言語にもよるけど、最近の言語は大体識別子に多バイト文字が使えるはず。これは見たところVBのようだけど、VBなら日本語は使えるだろう。
25
まさご叔父さん @masago53 2019年4月25日
そりゃ、動かんコードよりは動くコードやけど、綺麗な(というか分かりやすい)コードを書かなくていいってわけやないぞ。それに始めのうちから綺麗に書く癖付けとかんと、後で癖付けるのは大変やぞ
76
ちょちょまる @sakuya_little 2019年4月25日
プログラミング教えるなら、コードレビューもさせたほうがいい。 書くより読むほうが最初は大事だぞ。
39
yamadataichinokiseki @yamadataichino1 2019年4月25日
開発環境とフレームワークを延々といじって実質何もやってないくせにドヤるプログラマーにならないよう教育してほしい。
4
HasHeadache @HasHeadache 2019年4月25日
なぜ「わかりやすく」の語句を入れてしまったのか…たとえそのコードに触るのは自分一人でも、自分にもわかりづらいコードなんて書いたら後で泣くのは自分なのに…「3ヶ月後の自分は他人」とはよく言った物よ…
67
あいしー★ @aicm2 2019年4月25日
凝ったLINQで一行で処理してるコードを他の人が読むのに手間がかかるとかはよくあること。
8
うめいじ🏰 🍠📕🥕🎋 @da_sth 2019年4月25日
わかりにくいコードとか、2日見なかったら読めなくなるぞ
52
ふぁむ氏 @phantom0730 2019年4月25日
まぁキレイなコードの「キレイ」がどのような状態かが判別できない相手に可読性向上の話をしてもしょうがないというのは解らんでもない
8
Calucifer🌲💉💘🐕🍵 @Chigami 2019年4月25日
主題は美しいなんだろうがわかりやすくの意図がよくわからない 日本語難しい
1
kusano @t_kusano 2019年4月25日
aicm2 (たいていの場合は)それは余計な情報がない良いコードでは?
1
saku @sakuuuuuuune 2019年4月25日
これ、作った人の働いた環境がそういうところだったんやろなぁ 業務では可読性が高いコードは重要、3日後、あるいは3ヶ月後、あるいは1年後に読む日が来るから
0
dcyan @hash008b8b 2019年4月25日
バカは可読性も保守性も理解できないので両方とも台無しにしても気づかない。 残業を成果に昇進したバカが上司になってそいつの成果物のメンテを丸投げされたときは辛かった。 1年経って全部捨てて作り直して工数もバグも激減させたのに逆恨みされて昇級に不都合が出たので転職した
30
reesia @reesia_T 2019年4月25日
わかりにくいコードは担当者が辞めた途端にブラックボックス化して、ユーザーからは求められている機能なのにメンテ出来ないからと削除されたりするから困る。
0
fai into VR @faifx 2019年4月25日
KISS(Keep It Simple and Stupid )。他人に読まれるコードは、バカでも分かるように単純な書き方をしよう。
38
村雨カマンベールまみ @murasame753 2019年4月25日
マナー講師()の亜種の様なものか。
4
優希(ゆき) @ulbvbdkp23409 2019年4月25日
rambda2 使えなくはないけど使う意味は正直…
1
優希(ゆき) @ulbvbdkp23409 2019年4月25日
これが俗にいう【スパゲッティコード】になるんですね。
2
優希(ゆき) @ulbvbdkp23409 2019年4月25日
そもそも「書いたコードは 自分以外が 読んでも理解るの 基本のき」って感じだよね
6
机ひとつ @msyk_hmns 2019年4月25日
この人は自分が書いたコードを後で保守する経験がなかったんだろうか?業務用のコードって、書いて動いたら終わり、じゃないよ?
24
rambda @rambda2 2019年4月25日
ulbvbdkp23409 俺も自分のコードで使うことはまずないけど、使えるか使えないかで言えば「使えない」ってのは単にウソなので。
6
spin_out @spin_over 2019年4月25日
正直小学生にプログラミングさせる意義がわかんない。
6
toq-mitz @toqmitz 2019年4月25日
コメントは放置されがちなので、なるべくコメントはコードに書くなというプロジェクトもある。 (コメントは書いてもチケット番号だけ。なにか言いたいことあるならチケットかコミットメッセージでカバーせよという思想)
0
trycatch777 @trycatch777 2019年4月25日
仮に、小学生なんで複雑なこと教えたくないのであれば、「業務では~」の部分は要らないし、書くのであれば逆に「業務では、自分が書いたプログラムを他人が改造することもあるので、わかりやすいコードを書くよう心がけるべし」でしょ。
7
ポン酢太郎 @ponzoo2you 2019年4月25日
ちゃんと教えられる人もいない状況で年少期にコーディングの癖をつけるとそれはもう業務の段階でヤバイことになりそうなもんだけどなぁ
1
ムー @mu_50yen 2019年4月25日
改修案件で汚いコードに当たると「◯ね…◯ね…これ組んだやつ◯ね…」と呪詛のように頭の中で唱えながら仕事してる。
39
けやき あきひと(としあき @zelkovatreefolk 2019年4月25日
草書ではなく楷書で書きましょうみたいな感じかな
0
Yeme @yer_meme 2019年4月25日
趣味なら好きにすれば良いっスけど、仕事で書くなら読みやすさ優先スよ。レビューでボコられること請け合いっス。
5
ikazuchiboy @ikazuchizoku 2019年4月25日
こんな教育してたら将来GOTO文を多用するプログラマになるぞ
0
お見積り @kai_grayshblue 2019年4月25日
「そういうネタ」として敢えて難読化してたりするので意味はちょっと違うし大変極端な例になるけど #シェル芸 には震える。最近見たフィボナッチ数列のやつはヤバかった。
1
takatakattata @takatakattata1 2019年4月25日
小学生向けなのにわざわざ「業務」と書いてるあたり言い訳効かないけど、本音だとしたら迷惑プログラマーとしか言えない。
16
飛鷹隼 @junhiyoh 2019年4月25日
取り敢えず先ずは動く事が最優先だが、動いた時点で改行と空白と字下げとコメントチェックして清書するに限るぞ そうしないとなにより後で弄る時に自分が死ぬw
3
たかつき @taka4tsuki 2019年4月25日
プログラミングは本質的に文書を介したコンピュータとの会話であり、後任者とのコミュニケーションなので、背景、主語、述語、目的語が揃っているか自明であることが重要。一段落が適切な規模であることも重要。要は「意味の分かる文書」であることが重要なのよ。ゆえに子供にプログラミング教育すると論理的思考が身に付くとか言われる。
3
犬エンジニア @tada_suzu 2019年4月25日
どっちかというとテーブル名やカラム名、プログラムのファイル名の方を丁寧に考えてくれ。そこさえちゃんとしてれば中のコードが多少汚くてもどうにか追える。
5
Game_you @game_yanyan 2019年4月25日
業務でって所がミソよね。 自分の範疇なら好きにすればいいけど、業務でなら流石に後から読み直せる程度には整然としてないと…。
7
佐渡災炎 @sadscient 2019年4月25日
「コメントはきちんと書こう」みたいなふわっとした指導だと「//aに100を代入する」のような情報量ゼロのコメントが全行にかかれることになる。
27
hajime_z0 @hike1096 2019年4月25日
美しいコードが何か定義を明確にしないと始まらないのでは。
0
Yeme @yer_meme 2019年4月25日
あー、「変数名は思いつき」ってのがどうしても気になるっス……命名は重要っスよ。
11
低浮上monolith@フォロー外から失礼します @se_monolith 2019年4月25日
一行にテクニック駆使して処理を詰め込むコード、かっこいいっつーて持ち上げる人いるけど、可読性は最悪だよな。しかも理解に時間かかってると「これ読めないのはお前のレベルが低いから」みたいなマウンティングが始まるし。
4
_ @readonly6582 2019年4月25日
大半のIT屋にとって、なにが「美しいコード」かは客が決めることだからなぁ
0
ポッカ @pokka80 2019年4月25日
美さ必要はさほど必要ない、何がしたいコードが重要だな
0
Hacchi @2mocccck 2019年4月25日
自分一人で書く時だって数ヶ月単位でコード書くなら汚く書く癖ついてると後が大変じゃない? リファクタリングの時に追うのが大変だと思うんだけどな。
3
dcyan @hash008b8b 2019年4月25日
クソコードしかかけない人は人間への指示も満足にできない。
0
rambda @rambda2 2019年4月25日
readonly6582 いや、客は普通コードなんて読まんが。
30
クリスセドン @sedooooooon 2019年4月25日
美しいコードを求めるなんて当たり前ですよ… なお自分は書かない模様
0
yuki🌾㊗️5さい🎉⚔ @yuki_obana 2019年4月25日
美しくなくていいので例えばブラウザなら類似する窓30個へぼいPCで開いても落ちない設計にしようとかそういうとこでは(´・ω・`)
0
たかつき @taka4tsuki 2019年4月25日
「わかりやすい」「美しい」コードとは具体的にどんなものか言語化できる人少ない問題。
2
John KOD Nollen @katsusinz 2019年4月25日
(お前が辞めさえしなければ)が抜けている
0
Live long & prosper @titan3xFnfxte 2019年4月25日
rambda2 「三角形の内角の和は180度」みたいなもので、数学としては間違っていても、算数の初心者に教える方法としては正解。
2
鹿 @a_hind 2019年4月25日
最初になんでもいいから動けばいいんだよ!って思考でやり遂げるとそれが原体験となってその後ずーっとグダグダになるよ。悪い癖つける前に最初から綺麗に書く習慣付けておいた方がいい。 大人になるころまだプログラミングあるんかどうか知らんけど。
14
むう @nyal1999 2019年4月25日
「業務では求められてない」のではなく「求めたいが時間も金も上司の頭も足りない」だけである
4
SAKURA87@多摩丙丁督 @Sakura87_net 2019年4月25日
まぁでもVSだとある程度整形してくれるから。勝手にある程度読みやすいコードにはなるから、まぁ。
0
たかつき @taka4tsuki 2019年4月25日
ソースコードにもCCとかMIとかあるいはテストカバレッジ等の品質指標があるの知らなさそう。だから「ぼくのかんがえたさいきょうのぷろぐらむ」みたいなフワッとしたこと言っちゃう。可読性が低くてバグのないコードなんてクロスチェックテストできないも同義なので矛盾してるんだよ。エアプだろ。
18
むう @nyal1999 2019年4月25日
クソコードで苦労する時には、たいてい書いた本人は偉くなってるか死んでるかだからな… あとまあ、コードが残ってるだけマシってことも多々あるしな…
0
低浮上monolith@フォロー外から失礼します @se_monolith 2019年4月25日
てか美しいソースと高可読性ソースって同じようで違うよな?
2
F @hehe3000 2019年4月25日
yeldだっけ?とかを使うと短い文で住むけどあれは可読性が上がったと言えるのですけ?
0
Yeme @yer_meme 2019年4月25日
hehe3000 yieldっスね。書き方次第っス。便利ではあるっスけど用途は限られるっスかねぇ……
3
@ @KareidoMegane 2019年4月25日
[c6219942] 「現場では」と「ブラックな現場では」を同じと思うような国語力でよくこの手の話にクチ挟めますね。スゴイナー( ̄▽ ̄;)
0
@ @KareidoMegane 2019年4月25日
se_monolith 高可読性は「わかりやすい」の方で担保されてるんでは?
0
lonngfa @lonngfa 2019年4月25日
今までどんな現場を経験してきたかが如実にわかるコメント欄ですね。メンテナンスとか機能拡張とか、既存の第三者が作ったコードを修正するようなことをしてきた人ほど、「わかりやすさ」を重視するんですかね。
1
Yeme @yer_meme 2019年4月25日
lonngfa どっちかと言うと、「作って終わり」って古き良き案件が無くなってきたって話だと思うっスよ。後から誰かが改修する前提っス。半年後の自分は他人と一緒っスし。
6
lion5557 @lion55571 2019年4月25日
「業務の現場」って書かなかったらよかったのかもしれん……
0
lion5557 @lion55571 2019年4月25日
今は(僕の周りでは)派生開発多くなってきてるから、可読性はそれなりに求められるよね。ただまぁ、設計の良し悪しの話をしてるわけではないから、これはこれでアリなのかなぁ……いや、コード1行でも設計だろっていわれたらそうなんだけど。
0
BABA Motoharu @calc3 2019年4月25日
「学校で教えるときに言うべき建前」ってのはあるよね。法律を教えるときに「実際には法律はあまり守られていません」なんてのを法律を守らない人を肯定する文脈で言うべきではない。相手が小学生ならなおさら。
0
皇深廉 @M_O_Sumeragi 2019年4月25日
「動けばいい」と作られたコードにバグがあって他人が補修するとさらに可読性が下がって、それが繰り返されることで「代々伝わる熟成された秘伝のソースコード」が出来上がり、元の基幹部分に手が付けられなくなります。
2
K3@FGO残6.5 @K3flick 2019年4月25日
美しいコードよりわかりやすいコードで頼む
2
lion5557 @lion55571 2019年4月25日
あ、これはsmall basicってやつなのか。変数名に日本語使えないんだ……小学生向けなら日本語の変数名使えた方が嬉しい気がするんだけどなぁ。
0
すいか @pear00234 2019年4月25日
たとえば「while(*++p = *++q); 」みたいなコードは要らないって意味だと思う。
0
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx 2019年4月25日
これは真実だった。ただし真実となったPJは須らく納期に追われていた。わかるな?デスマーチだ!
0
山下 @6wc2D732p08gevM 2019年4月25日
こんなソースたまに混ざってるよね。 for(i=1;i!=403;i++){} // これ追加したら動いたので暫定対応
1
Gothicgaze @Gothicgaze 2019年4月25日
先生「はい、それじゃ二人組になってコードを交換して互いにデバッグしてください」
7
すいか @pear00234 2019年4月25日
「分かりやすい」「可読性が高い」ってのも落とし穴でね、例えばaを2倍するって処理で「a*=2;」と書くか「a+=a;」と書くか「a<<=1;」と書くか。どれも意味と解釈次第では「分かりやすい」「可読性が高い」と言えるし、さすがに同一人物ではないけど、3パターン全部経験したなぁ。
1
すいか @pear00234 2019年4月25日
6wc2D732p08gevM これ確か比較的新しい目のコンパイラでそこそこ以上の最適化掛けると、この処理全部削られるとか聞いた。
0
北斗柄@生涯六壬者.多分 @hokutohei 2019年4月25日
プログラミングなんて作りたいものができてから勉強したって間に合うもんだよ。
1
すいか @pear00234 2019年4月25日
横内威至氏(グランツーリスモのビジュアルエフェクト担当メインプログラマー)いわく「動くコードはすべて美しい」
0
ビーフジャーキー @_beafJerky 2019年4月25日
LL書き捨て系ジョブホッパーのとっさのやっつけはフェーズによっては理解できるけど、関数満たす仕事だけずっとやってきた中途氏はシンプルに人生で一番ヤバかった...
0
ビールクズ猫 @WAKUWAKUTAKKU 2019年4月25日
美しい汚いというか、第三者によるメンテナンスや改良が不可能なスパゲッティ納品されるのはいろんな意味で論外なんだがなぁ…… リアルの機械だと歯車剥き出しでそもそも日々のメンテナンスにすら困るレベルでやむなくサポート呼んだら「担当者が異動したんで分かりません」とかそういう次元だぞ。
0
じゃこうねこ @Jakoneko2 2019年4月25日
機械語+メモリが少なかった時代には可読性無視して1バイト削るのに血道をあげてたなぁ・・・ XOR AX,AXとか。
0
むう @nyal1999 2019年4月26日
6wc2D732p08gevM //このコメント消したらバグります (実話
6
むう @nyal1999 2019年4月26日
PGに限らず技術屋の仕事の矜持ってのは「自分がいなけりゃできないものを、自分がいなくなっても大丈夫なように作り上げる」ことだと思う…自分はそんな仕事をいくつできたか…
4
nbtnk @nbtnk 2019年4月26日
難読化が必要な現場の人間はいないのか?
0
哺乳類型爬虫類 @harunotokage 2019年4月26日
「何をどうやってるか」分からなきゃリファクタリングもクソもないですよ(愚痴交じり)
0
むう @nyal1999 2019年4月26日
nbtnk 殺人幇助はしたくないなあ…
0
むう @nyal1999 2019年4月26日
いつもの逆張りおばさん筆頭に「美しいコード」をPGの「自己満足」かのように言ってるやつがいるけど、可読性の追求ってのはメンテナンス性の向上や引継ぎのしやすさとかの「実利面」の話だぞ。デスマーチ中盤以降の地獄ってのはコードの可読性が低下した結果、不具合やバグの原因探しや実装漏れ(という名の機能追加要求)の穴埋めがまともにできなくなってさらに問題起こすっていうスパイラルにはまる、そういう泥沼だぞ。「とにかく動けばいい=いつまでたってもまともに動かない」だぞ
31
オッカナイ剃刀 @okka_RazorBlade 2019年4月26日
「ホラね、簡単なんだよ〜☆」としたいがために先人の叡智の結晶をゴミ箱にブチ込んでも、ほどなくして踏襲したほうが自分も周りも楽だと気が付き、戻って拾い直す羽目になりますね
4
そでのした @sodenoshita 2019年4月26日
3日後の自分は他人だから、分かりやすく美しいコードを心掛けて書かないと自分が死にます。
13
哺乳類型爬虫類 @harunotokage 2019年4月26日
可読性を無視したら実行速度が上がるわけじゃないし、可読性を上げれば実行速度が落ちるとも限らない。 この2つは何の関係もないんだがどういう思考回路でごっちゃにしてるんだろう
1
哺乳類型爬虫類 @harunotokage 2019年4月26日
もしかして「作業時間」と「実行速度」が何時の間にかごっちゃになってる…?
5
むう @nyal1999 2019年4月26日
sodenoshita 1年後くらいに改修案件来て「誰だこのクソコード書いたの!俺だ!」はだいたいみんな通る道…
8
akiran @akiran32748624 2019年4月26日
まずは考え悩むより、ひたすら書け! やれ! 試せ! ってのを、あんまり業界のことしらない人が代筆したらこうなった、って感じ
0
飛鷹隼 @junhiyoh 2019年4月26日
se_monolith 昔々のベーマガだと、可読性は二の次三の次でとにかく一行255文字縛りでゲームとして成立する限界プログラムがジャンルとして存在して割とみんな一度は挑戦したけどな(2本ほど載った
0
優希(ゆき) @ulbvbdkp23409 2019年4月26日
junhiyoh それと今回は違くない? やらなくていいところでプログラムの圧縮とかやらなくない ??
0
ぷほるず @homerunutuyo 2019年4月26日
綺麗に書くことって「長々と処理一つ一つがすぐわかるコードを書くこと」じゃなくて「なんの処理をしてるか見てわかるように書く」だと思って仕事してたけどちがうんすかね?
12
ぷほるず @homerunutuyo 2019年4月26日
あとお客さんが欲しいのは軽くてバグがなくて保守性の高いシステムなんだよなぁ
0
dcyan @hash008b8b 2019年4月26日
空白を開けるのも大事だしデータの流れと出入り口が分かるように処理を書くのも大事。いきなりキーボードをいじらないでまず絵に描いてほしい。
0
節穴 @fsansn 2019年4月26日
自分にしか読めないように書いて人質に取るんじゃ
0
むう @nyal1999 2019年4月26日
junhiyoh 個々人のテクニックを求めつつ、チームや業務として円滑に回す「仕組み」としてのコードを書くのがお仕事です
0
ナスカ(Nazka) @Chiether 2019年4月26日
コメントフルvsコメントレスの宗教戦争が見られると思ったら、みんな大人なのでそんなことはなかった。 > タイトルの「コメントはきちんと書こう」
0
m_shige1979 @m_shige1979 2019年4月26日
可読性は重要と思います
0
ひこゆさ @mbMCcefiR2YQYpl 2019年4月26日
ありがたいことに文法の規定はlintのおかげでだいぶ揃ったよね。誰が書いても同じような形式になる言語が至高ということですよ。
0
spin_out @spin_over 2019年4月26日
うーん。リファレンスはその機能単位で何をしてるかは確認できるけど、実際に中でデータをどう回してるかとか、そういうのが読み取りにくいコードになってるのが問題なんで、そうならないように「なるべく短く機能単位でサブルーチン(function、関数)を作り」「意味のある変数名・機能名で何を操作してるかわかりやすく」「共有ロジックを多用して車輪の埼葛をしない」が求められてるんだけど。汚いコードはえてしてこういう基礎ができてない。
4
Yeme @yer_meme 2019年4月26日
GoogleはC++のスタイルガイドで「読みやすさを重視すること。必要なら最適化すること」って言ってるんで、どうも知らない世界と交信出来る人が紛れ込んでるみたいっスね。
11
spin_out @spin_over 2019年4月26日
そもそも、現代では、javadocしかり、ソース内のヘッダでリファレンスや変数の定義書くのが普通なのだが。
1
spin_out @spin_over 2019年4月26日
spin_over 車輪の埼葛→車輪の再開発 どういう誤字だ。
0
ラヌ @25ranai 2019年4月26日
美しさにカギカッコがついてるんだから、分かりやすさは必要と言ってると思うけど。まあつまり日本語がおかしい
0
諏訪真 @liarsuwa 2019年4月26日
ところで君達、リーダブルコード読んでるよね?
2
ざおーが @zaooga 2019年4月26日
小学生向けの問題に業務の話持ち込むの?プログラミング初めて触るなら「ダメ出し減らして興味を持たせる」が優先されそうだけどなあ。
0
むう @nyal1999 2019年4月26日
zaooga 逆です。業務(というかアカン現場)の話持ちだしてきたから突っ込まれてるんです
4
むう @nyal1999 2019年4月26日
出羽守の話はむしろ「コモディティ化の問題」とかの範疇だよなあ。コードの可読性や保守性の担保が「あたりまえ」になってるので、「(今更)そんなとこ重要視しないよ」っていう界隈の話を、いまだに汚いコード書いてる連中が「はなっから重要視しなくていいんだ!」っつってありがたがって改善放り投げてる構図
0
せんたく @senn_taku 2019年4月26日
とりあえず法律は可決させておき、あとから内容を詰めていくと言い換えたらヤバさは伝わるかな?
2
yukinoda_jp @yukinoda_jp 2019年4月26日
言っても無駄なウンコーダーだから業務で求められなくなった、という過去があるのかもなw
2
phantive @phantive 2019年4月26日
「小学生向けプログラミングの本」ならば、わざわざ「業務の現場」に触れなくてもいいのに。 現場でのピアレビューなんて、ほとんどこの観点。そもそも理解されなければレビューにならない。
1
ねや @AriaSub 2019年4月26日
この手の本って、業務経験が無いがっこうのせんせいか、若しくは業務経験があっても能力不足で2,3年で会社辞めたドロップアウト組が書いてるんだよね・・・ そういう人たちは、最後には(もうお前には何も期待してないから)とにかく最低限動く物を出せと言われる
1
yukinoda_jp @yukinoda_jp 2019年4月26日
反論になってない独自理論を展開する人は、エクセルの関数が書かれたセルを勝手に上書きしてぶっ壊す犯人、で想像するとだいたい合ってると思う。
3
yukinoda_jp @yukinoda_jp 2019年4月26日
今この瞬間はこの値でないと困るんだ、とかなんとか言ってw
0
yukinoda_jp @yukinoda_jp 2019年4月26日
知らずにぶっ壊すほうがまだマシ
0
yukinoda_jp @yukinoda_jp 2019年4月26日
自分でアプリやITサービス作って、リリースして、運用して、ちょっとづつ顧客増やして、っていうスモールビジネスのサイクルでもコードの美しさは極めて大事。
1
yukinoda_jp @yukinoda_jp 2019年4月26日
もちろん大人数のプロジェクトではもっと大事。試しにGitHubで何かOSSにウンコードでプルリクだしてみ? 見向きもされんよw
0
yukinoda_jp @yukinoda_jp 2019年4月26日
美しく作れば効率もよくなって軽くなる。当たり前だね。単に可読性あげただけじゃ美しいとは言わない。良いプログラムは「美しい」じゃなく「エレガント」と言うんだ。全部備わっての「エレガント」だよ。それが不要なわけ無いだろ。
2
セマフォ @NoMoreLivesOne 2019年4月26日
確かに美しさなど求めない。 分かりやすさだ。読みやすさだ。 プログラミング「言語」なのだから、読めるように書いてくれ。 ワンライナーで圧縮したかったなら、そう「注釈」を入れてくれ。 C#は、Switch-case したって、JITされたらIFの分岐だ。 効率を謳うなら、最終レイヤーまで意識しろ。そしてそれを意識するくらいなら、CPUの特性を学べ。 絶対的な目標は「誰でも修正できる処理能力に問題が無いソースコード」だ。
6
undo(俺の花だよ月見草) @tolucky774 2019年4月26日
コードがクソでリファレンスドキュメントがまともなプロジェクトって床上手な処女みたいなものって存在するの?私は知らないけど
1
Yeme @yer_meme 2019年4月26日
まさに今「重たくて作法決まってる言語」が大人気なんスよね。Pythonて言うんスけど
4
yukinoda_jp @yukinoda_jp 2019年4月26日
うーむ。「可読性」の定義にも誤解があるなこれは。少なくとも「突き詰めると馬鹿でも読める」は違うね。複雑なアルゴリズムは使うな、みんなが知らないイディオムは書くな、とかの話では全く無い。「初学者でも読めること」とか誰も目指してない。
1
むう @nyal1999 2019年4月26日
yukinoda_jp どこにでも現れて知ったか逆張りする構ってオバチャンなので、まともに取り合うだけバカ見ますよ
1
Yeme @yer_meme 2019年4月26日
nyal1999 「否定的な事を書くと勝手に情報が集まるメソッド」の体現者っスよね。便利っス
3
spin_out @spin_over 2019年4月26日
今どきコメントなり変数名長で処理速度が変わるコンパイラがあったらソッチのほうがびっくりだ。なんか大手銀行のCOBOL時代のことでも想定してるんだろうか。30年ほど時代遅れだよ。
0
Yeme @yer_meme 2019年4月26日
[c6224670] そうなんスか。まさに「お好きな宗教を信仰してください」っスね。
3
undo(俺の花だよ月見草) @tolucky774 2019年4月26日
でかいプロジェクトほど共有情報もドキュメントもコーティングもしっかりしないと座礁しまっせ。業務用プログラマーで他人が仕様の確認をしてメンテできないと困るので。スーパープログラマーがすごいコーティング笑をして他人が何をやってるのかわからない時代は20年位前に終わってる
2
spin_out @spin_over 2019年4月26日
可読性無視し、処理の効率性からほぼすべてのデータ処理がbit演算のみ、変数はa01~z99、関数名はf_a_01,f_a_02で記述されコメントが全く書いてないプログラムの改修案件を納期までに仕上げてから「可読性なんてどうでもいい」と言って欲しい。リファレンスは紙と、取り込んだPDFのみとする。
3
せんたく @senn_taku 2019年4月26日
極端すぎるのはどっちも良くないのは言わずもがな。美しさと効率の両方を求めつつ落とし所を見つけるもんでは?DB正規化しろって言われてどんな案件だろうと第五までやる人はあんまいないだろう?
0
せんたく @senn_taku 2019年4月26日
可読性を保持しつつ効率を保つのなんて、大前提じゃないか。モノによっては効率を重視して可読性を下げることもあるが、目的が違うんだよ
3
せんたく @senn_taku 2019年4月26日
ぶっちゃけどんなコード書いてもいいよ好きにしな。ただし自分で面倒見てくれよな!面倒見れないなら見てやるよ金払いな!私も大したコード書けてる訳じゃないが、スパゲッティがあるお陰で成り立つ案件もないではないらしいしね!
3
せんたく @senn_taku 2019年4月26日
[c6224706] 重たいコードをAWSに乗せてスケール地獄突入して会社飛ぶレベルなら問題はコーダーじゃないだろw
6
むう @nyal1999 2019年4月26日
spin_over 人それを「現物(ROM)合わせ」と言う…(吐血
0
哺乳類型爬虫類 @harunotokage 2019年4月26日
可読性の高いコードがクソ重いんだよと繰り返し主張している人に対しては、「何が原因で」クソ重くなるのかの説明が一切ないということからすべてを察するべきなんだろうか
8
机ひとつ @msyk_hmns 2019年4月26日
処理が重たい、読みにくいコードはそもそもロジックが間違ってる場合が多くて、適切なロジックに沿って書かれたものは理解しやすく読みやすい。プログラミング教育がロジックを学ばせるのが目的なら、誰にも理解しやすいコードを書く事を推奨するべきでしょう。
1
ビーフジャーキー @_beafJerky 2019年4月26日
青さん若干泥臭い業界と世代の人だったんだなぁ...
0
もくざい @mokuzai_tig 2019年4月26日
関わってきた案件やその他環境の差なのかわかりませんが、 碧さんのコメント半分わかるけど半分わかりません。 [c6221194] テストコードなどで確実に動作を担保できなければ、 「動いてるサービスのコード」は一行たりとも変更したくありません。 むしろ、そこの工数とれない中であとからリファクタする時間が取れるとも思いません。 後からリファクタはできないものと思って書いたほうが効率的かと。
0
もくざい @mokuzai_tig 2019年4月26日
[c6223803] [c6224595] 碧さんの言う通り"超軽快に動く言語もだいぶ増えてきた"ので、 最近はひとつ処理の効率より、読みやすさ・テストしやすさ、を重視される案件が多いと感じています。 ご自分でも軽さ・可読性etcトレードオフって言ってるじゃないですか。 "品質"って何を指してますか?指標なんていくつもあって、そのなかにテストしやすさも、改修しやすさも入りますよね? 若輩者につき、釈迦に説法かもしれませんね。失礼しました。
1
齊藤明紀 @a_saitoh 2019年4月26日
可読性無視の現場「もある」のが、事実だとしても、一般的に可読性無視だと子供に教えるのがダメななのは変わらない。
2
ぷほるず @homerunutuyo 2019年4月26日
可読性を初心者でもわかるコードで書くことだと思ってるのはちょっと…
1
ぷほるず @homerunutuyo 2019年4月26日
逆に言うと可読性が高い=初心者が最初に覚えるようなサンプルコードみたいに書くことだと思ってコード書いてるのはそれはそれですごくヤバい
1
ぷほるず @homerunutuyo 2019年4月26日
汚いコードって極端な話「ループが幾重にもネストしてる」とか「一つのメソッドにすべての処理を詰め込んだ」みたいなことだと思ってるんですけど、ひょっとしてそういう話ではない感じ?
1
ぷほるず @homerunutuyo 2019年4月27日
後、早くてバクが無いものがベストなのはそうなんだけどひとつのシステムが役割を終えるまでに改修や性能改善が入らないのか?ってことを考えると、コードを書き直す上で可読性は求められるのでは?と思う次第です。
0
murasame @murasame51 2019年4月27日
コード書いた本人にリファクタリングの機会が与えられるとか、余裕のある会社で羨ましい話だなぁと、かろうじて動いてるクソコード改修してる者は思いました。
2
アセローラ社 @KizunaEYE 2019年4月27日
他人が見てもわかりやすく書くのは必要だけど、「芸術的な美しさ」は必要ないよな。お客様の金で趣味のプログラミングをやるな。
1
むう @nyal1999 2019年4月27日
harunotokage 保守性の話を保守契約と取り違えてる時点で、実務やったことねえでしょ
1
哺乳類型爬虫類 @harunotokage 2019年4月27日
nyal1999 「保守性」の下りもそうですが、全体的に知ってる単語を並べてるだけの支離滅裂な文章ですな…。
1
すいか @pear00234 2019年4月27日
ひょっとして:×「分かりやすく かつ 美しい」 〇「分かりやすく美しい(パッと見は綺麗に見えるし実装ロジックは分かりやすいが、仕様との適合性が分かりづらい)」だったりは・・・。しないかやっぱ。
0
spin_out @spin_over 2019年4月27日
可読性という場合、「短い(無駄な処理をしない・機能を分割する)」「理解しやすい(意味の通る単語での変数名関数名)」「読みやすい(インデントの徹底、ネストのサブルーチン化)」が基本で、後は言語特性で変わってくる。人によっては英語的に正しい記述も含めたりするが、それは少数派だろう。
1
jpnemp @jpnemp 2019年4月27日
AレジスタをXOR Aでクリアするようなコードはやめましょうって話です
2
spin_out @spin_over 2019年4月27日
それこそ機械語やアセンブラの開発でもしてない限り、ソースからの実行速度は無駄な処理やらループやらの有無とDB接続の回数及びデータ取得のスピードが影響し、適切な記述をした場合速度差はコンパイラの性能が主であり、組み込み開発ですら高級言語に移行している現代、世界の99.99%の開発環境に適応しない特殊例を持ってきて一般的にそうであるような言説は迷惑だからやめてくれませんかね。
9
spin_out @spin_over 2019年4月27日
ましてや、「初心者」に対してであれば全く的はずれな言説でしかない。
4
哺乳類型爬虫類 @harunotokage 2019年4月27日
最近はWebページもパーフォーマンスを考えて作ろう…という話はありますけど。曲芸的な手法を使ってでも速度を稼げなんて話じゃないですよ、8ビット時代のゲームじゃないんだから
1
たかつき @taka4tsuki 2019年4月27日
何度でも言うがプログラムは文書だよ。モノを適切に表現=説明できているか、内容を検証できるか、引用=再利用できるか、といった視点が重要。「馬鹿は高等なプログラムが読めない」という視点は不適切で「馬鹿は他人に読ませる文書が書けない」という要素の方が効く。前者だと思っているなら騙されているよ。
1
ぷほるず @homerunutuyo 2019年4月27日
spin_over それこそ並列で処理する、ストアド、データのキャッシュを保持する、みたいな感じでパッと思い付くので、処理を早くするとこをコードの書き方だけしかないように書くのはなぁ…と
0
spin_out @spin_over 2019年4月27日
homerunutuyo DB接続の回数って書いてるし、並列処理の場合は、プロセッサと言語の特性次第な部分が多いので、大量データを扱う場合にプロセス分け(スレッド処理)するよりもサーバーの性能を上げて処理を依存させるほうが早い場合があるので、そこを1コーダーの責務にするのもちょっと違うと思うんですがどう考えます? ちなみにストアドは、処理内容に寄っては(特にデータ加工をストアド内でしようとする思想は)むしろ処理速度の劣化に繋がる場合があるので注意が必要です。
1
むう @nyal1999 2019年4月27日
spin_over たぶん homerunutuyo でおっしゃられてるのはサーバーサイドの「並列(物理)」なのでは…お二人ともおんなじこと言ってるような
1
むう @nyal1999 2019年4月27日
ネットワークやDB周りのクライアントサイドなんて、そもそもの基礎設計がタコだったらどうしようもねえもん。コードで物理層変えられるやつがいたら文字通りのウィザードだぜ
1
alan smithy @alansmithy2010 2019年4月27日
taka4tsuki ロジックに対応した処理の可読性が高い(読みづらくない)/メンテナンス性が高い(設定やロジック変更に苦労しない)が綺麗なソースだが、逆に汚いソースがどういうものか見たほうが早い。右は駄目なソースを例題として挙げている| Cプログラミング診断室 http://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.intro.html
2
Yeme @yer_meme 2019年4月27日
nyal1999 ある程度まともに書いてあるコードを最適化で倍速くするのはクッソ大変スけど、マシンを倍に増やすのは単に予算の問題で済むっスからねー。
0
たかつき @taka4tsuki 2019年4月28日
alansmithy2010 1990年…古い…。こちらは良い側の例ですが、こういうのとか「プログラマーって どんな人? -- 牛乳と卵で理解するプログラマーという人種」 https://speakerdeck.com/tanakahisateru/puroguramatute-donnaren-niu-ru-toluan-deli-jie-surupuroguramatoiuren-zhong?slide=37
0
ぷほるず @homerunutuyo 2019年4月28日
spin_over 確かにハード側の性能上げるのが一番手っ取り早いんですよね~。そこに予算の都合だったりが挟まってくるのでスケールアップもスケールアウトも無理とかだと「とりあえずこういう改修で多少は早くできるよ」みたいな提案をする感じかなぁと。
0
むう @nyal1999 2019年4月28日
[c6230743] 初学者に対して「最初は自由に」を否定してるわけじゃないですよ。「業務だと気にされない」といういらん嘘をわざわざ挟むから突っ込まれてるだけで
7
ザッキー🚙🍤 @zakky_san7 2019年4月28日
美しいというか、可読性のあるコードは 現場で求められてる気がする、というか求めている。 書き方が汚いコードは、解析する気を無くして ほぼ一から作り直す事もあるし(リソースの無駄)、美し過ぎるコードは逆に、 改修が困難なケースもある。 要はバランスかな。
1
Hacchi @2mocccck 2019年4月28日
Pythonは普通の文だと重いけどNumpyとか使う大規模な数列計算だと他言語と比べてそこまで遅くないんじゃなかったっけ?(クソリプ)
0
Wolkenbruch729 @wolkenbruch729 2019年4月29日
社会に出た時のためとして学校で指導される、上級生には絶対服従・下級生には理不尽な命令をしていいという部活の上下関係も、危険を冒すのが偉いという組体操の価値観も、社会に出たら根本的に否定されて正される。 プログラミングの基本もそれらと同じか。 わざと間違いを植え付け、後で就職先が時間と労力をかけて教え直す過程が必要だなんて、教育関係者はなぜ思った?
0
Shin Saito @shinsa82 2019年4月29日
指摘には同意なんだけどなんでこんな攻撃的な書き方をするのか
0
むう @nyal1999 2019年5月2日
shinsa82 親はともかく同僚は殺されたりしてますからねえ…
1
シロネコ @straypas 2019年5月19日
shinsa82 プログラマの生産性は出来る人と出来ない人の間で一桁違うってのがありまして、 優秀なプログラマはそこそこプログラマの10倍の量の仕事が出来る。コードが汚いせいで、10分で終わりそうな仕事が1日かかるとかが当たり前にある業界なわけで、汚いコードは最終的に損失しか生まない
4
mokyuxtu @mokyuxtu 2020年2月21日
ulbvbdkp23409 どんな業務でも、「他人にも分かり易く」は基本にしなきゃいけないね。(自戒)
0
touyamochi @touyamochi1 2020年2月22日
まあ仕事じゃ納期に間に合わせんのが一番大事だからな。綺麗なコード書くやつより汚くても早く実装する奴の方が評価されるのが現実ですわ。リファクタリングするんなら別にそれで良いと思うけど、大抵そのままだしなぁ。プログラムなんて趣味でやるのが一番だわ。
1
なちゃ @nachakey 2020年3月14日
よく新しい機能を使わずにどれでも分かるようにベタにみたいなのあるんだけど、例えばLINQみたいのとか(いやもうこんなもん新しくも何ともないんだけど)、そういうの使わずにべたに書くよりも、明らかにやる内容が明確にシンプルに読みやすく、ノイズが減って意図するところだけを明確に書けるので、むしろ分かりやすくべたに書くというのはこっちが正解だろと思ったり。
0
なちゃ @nachakey 2020年3月14日
うまく書いたりきわめてシンプルに明確に意図するところだけを表現して短くかけるのに、ベタベタにごちゃごちゃと長ったらしいコード書かれたら、どう考えてもそっちの方が読みにくいし何やってんのか分からないしバグ入りやすいし、どう考えてもそっちのがマイナスだよなーと思ってしまう…
0
なちゃ @nachakey 2020年3月14日
あと、納期の話もあるけど、大体シンプルに書く方が早いんだよね、当たり前だけど。 よけいなこと書かなくていいし考えなくて良いしやりたいことだけ書けばいいんだから。
0