ソフトウェア設計の言語化スキルを磨くこと｜qsona

たとえば設計について議論するときや、コードレビューで指摘をするときに、「なぜその設計が良いと思うのか？」について言語化するのが上手だと、確実に良いことがあります。 言語化が上手にできるかが一つの壁なのではないか、と感じることもあります。後輩を育てたりチームをリードするような立場になると、特に必要性を感じるのではないかなと。 自分も、うまく言語化できたことですんなり議論を進められていると感じることは多いですし、逆に直感的な良さを言語化できなかったことで直感に反する方向に進んでしまい、結果よくなかったというような苦い経験もあります。 前提: ソフトウェア設計の良さは静的には決まらない良い設計・良いコードとは何なのか。という質問に一言で答えるなら、「保守性が高い」ことだと思います。つまり、今後の変更・拡張を、高速にバグが少なく行えるような状態が良い設計・良いコードです。(一般的にはこれで70%く

[D_first]

BAD_REQUEST = 400はダメなのか。打ち間違い防止になると思ったんだけど。

[otherworld]

将来的に変わる可能性があるから定数にするのではなく、名前をつけないと意味不明になるからつける。説明なしに42が出てきたら「生命、宇宙、そして万物についての究極の疑問の答え」だと思う新卒がいるかもしれない

[mogami74]

全体的には納得できるんだけど「BAD_REQUEST = 400を定数化するのは残念コード」という事例の説得力が低すぎて全体の説得力を下げている。 可読性の面でBAD_REQUESTを定数化するのはおかしくないでしょ。

[chimerast]

“設計力の高いシニアなエンジニアがスタートアップ最初期に入っても” これ逆(?)で、不確実だからこそ技術的負債の発生を最小限に抑えるために、設計力の高いエンジニアが初めから入るべきだと思ってる。

[jiro68]

コードをぱっと見たとき、400 が http のステータスコードである事が自明とは限らないので定数化しておいて誤解を無くす事は重要。

[marshi]

javaのapacheのhttpclientライブラリには定数定義されてた気がする。ライブラリは別なのかあれも残念コードなのか。定数化するとコードの検索でひっかけやすくなるっていうメリットはあるかな。

[devorgachem]

BAD REQUEST とか番号覚えられないマンなので… なお、テキストがあれば思い出せる。なんというか domain name 書くんじゃなくて IP を書けと言われている気分になる…

[strow0343]

大体同意だけど、保守性や可読性に悪影響を与えないならなるべくコード内の情報を増やした方がいいと思う。自分にとって常識は誰かにとってはそうではないかもしれない

[umai_bow]

Status Code はベタ打ちでもいいけど、多くの言語はネットワークライブラリに組み込みの定数があるので、それを使うべき。でも、ベタ打ちでもいい。パッと見でわからんと言うなら、コメントを添えればいい

[rdrk]

"起こりうる問題などを具体的に説明することで、議論を深める補助とすることができます" ステータスコードの定数化とか、本筋と関係ないブコメが大量にあって、たしかに補助になってる。

[qsona]

https://speakerdeck.com/qsona/bad-request-is-400 続き書いたよ

[yatmsu]

俺もこのスキル高めたい

[qtamaki]

typoを防げるという効果があるけど、vue.jsとか言ってるから動的型付けか。自分も過度の定数化はいらないと思っているけど、たまにtypoでハマるので・・・

[ytRino]

いい話なのだがBAD_REQUESTのくだりでん?となった そしてブコメもそこばっかであった/ ステータスコード並べてswitchするような部分では同意、かなあ

[luccafort]

「マジックナンバーを定数化しろ」と自分がいうときはそのマジックナンバーが自分たちではコントロール出来ないときにいうかな。法律で決まってるけど自分たちでコントロールできないなら定数化する。

[mactkg]

みんな定数のはなししてるなあ…。

[kfujieda]

5280はfeet per mileにきまってるからマジックナンバーでいいと言うアメリカ人

[thatblue]

定数化の話、`if(length(hoge) > 0)` みたいなコードで0をいちいち定数化しない、って話なら理解できるしやってるんだけどな…

[masayoshinym]

“頻繁に変更されるかわからない部分は YAGNI ("You ain't gonna need it", 必要になってからやる) でいく。”賛否あるようだがこれだけは大事にしていきたい。

[light940]

“ステータスコードという概念と値が十分に知られている” これが主観な気がするから、もしこう伝えたいならもうちょっと客観的な意見を言語化して伝えられると良いのかも

[goodstoriez]

“基本的に、いきなり原則を理由にするのではなく、現実の問題に即して理由を説明し、参考として原則を挙げるのが良い姿です。”

[tmtms]

いやいや、そんなことはないじゃろ / “例えば、HTTPのステータスコードについて、 `BAD_REQUEST = 400` みたいな定数を定義して使っているコードは、間違いなく残念なコードです”

[y_maeyama]

"こいつめんどくさいから反論しないほうがいいな、とか、聞いてもあんまり納得できる答えが返ってこないな、とか思われると、わざわざ聞き返してこなくなります。"

[nilab]

ソフトウェア設計の言語化スキルを磨くこと｜qsona｜note

[mt_hodaka]

“周囲や自分のレベルアップへの貢献”のところに深く共感。この記事のブコメもそのことを身をもって我々に教えてくれてはる

[onesplat]

うまく言えないけど君は多分レビューやら言語化やらしてる暇があったらもっとレベルの高い環境でレベルの高い課題を相手にガリガリとコードを書くべきやな。すでに頭打ち感がアリアリと見えてしまってるで

[ka-ka_xyz]

とりあえずのたたき台として「"Effective Hoge"の第XX条に反する」とか「"プログラマが知るべき97のこと"のこの章からすると微妙」みたいな書き方するよ派。初手から言語化するのしんどいので。

[otihateten3510]

概ね同意だなあ、そしてまともに設計できてる人かなり少ない。優秀で真面目な人は大体名前のついた新しい設計に傾倒するが、大体それは保守性が悪く学習コストも高い。そして引き継ぐ俺が死ぬ。

[june29]

共感しました。ソフトウェア設計に限らず、プロダクト開発や、もっと広く「チームで事を成す」ことを願うのなら、言語化は身に付けておきたいスキルですね。

[saiyu99sp]

要件と要件の実現方法をごちゃ混ぜにせずに書く能力の方が重要だと思う

[surume000]

部分的に賛成できない。たとえば405(Method Not Allowed)は400ほど有名ではない。じゃあ405だけ定数化して400は定数化しないまま？おれは両方定数化したほうが良いと思う