編集可能 編集部イチオシ

プログラミングの時に重視すべき原則やポイントを後輩に伝えるなら

プログラミングの時に重視すべき原則やポイントを後輩に伝えるならなににしますか?という質問をしたらいろんなお声をいただいたのでまとめました。
97
松岡@DDDブログ書いてます @little_hand_s

【ご意見募集】 プログラミングの時に重視すべき原則やポイントを後輩に伝えるなら何にしますか?(最大3つまで) 僕は ・クラスの責務をしっかり定義すること ・高凝集、低結合 色んな話がありますがとにかくこれにつなります。クラスの責務を意識せずに色々盛り込んでるのが悪いことがとても多いです

2019-04-29 10:19:53
yamada yuki @couraeg

場面とか背景が統一できないと何ともだけど。 ・昨日まで最高だから今日も最高だと思うな(逆も) かな。プログラミングうんぬんじゃねーかな。 twitter.com/little_hand_s/…

2019-04-29 10:29:21
やまもん / チャリ走の父🚴 / 本名:山田元康 @MotoyasuYamada

あんまり言われないことだけどまずこの二つができてることが大事 整理整頓w ① 整理 要らないものを捨てる ② 整頓 いつでも誰でも、仕様が修正された時にいじるべきコードにアクセスできるよう秩序だてて配置する twitter.com/little_hand_s/…

2019-04-29 10:30:52
大将 @taisho6339

依存性逆転の原則 + ビジネスロジックを他の関心事から分離することかなー。ビジネスロジックとその他の層にインターフェースで「境界」を作ってその他の変更からビジネスロジックを守るってだけで自然と責務が整理される気がする。 twitter.com/little_hand_s/…

2019-04-29 10:40:55
原幌鰭晴 @P_tan

まずは真っ当な関数を作れるようになること。 ・入力・出力の条件が明確であること。 ・副作用も入出力であることを理解していること。 クラスのメンバ変数はいわばプチグローバル変数なので、真っ当なクラスは真っ当な関数が書けるようになってから…。 twitter.com/little_hand_s/…

2019-04-29 10:45:58
ミノ駆動 @MinoDriven

・影響範囲を局所化最小化すること、そのための設計技法や言語仕様を覚えること ・条件分岐を単純化すること、そのための設計技法やフレームワークを覚えること ・技術駆動な命名を避け、業務概念を表現した命名をすること twitter.com/little_hand_s/…

2019-04-29 11:31:47
松岡@DDDブログ書いてます @little_hand_s

この代表格が ・Util ・Service ・Logic 身近にあるこんな名前のクラス、「このクラスは何をするクラスか」すぐに答えられますか?

2019-04-29 12:01:59
いさお@Webエンジニア @isao_e_dev

@little_hand_s HogeServiceとかいう、Hogeに関する便利(開発者にとって )な機能の盛り合わせって感じの見かけますね。。😢

2019-04-29 12:19:40
fukushiw @fukushiw

・命名第一(クラス、メソッドの責務にも当然影響) ・コードの背景を説明するコメントはこれでもかというくらい書く ・数値などは適切なサイズの型を使用する twitter.com/little_hand_s/…

2019-04-29 12:21:13
かずはる @kz_avant_prtmps

@little_hand_s ・名前を正しく分かりやすくつける ・データの意味は型や名前に持たせ、値そのものに持たせない ・共通関数だからって何でもかんでも一箇所に集めない

2019-04-29 12:29:54
村上昴平@エンジニア @ryuta005

@little_hand_s • 質(保守性、可読性含め) • 完成速度 • ☝️の二つを同時に達成しようとしない事。並行作業は逆に非効率。 完成速度だけに100%集中。 次に質だけに100%集中。 この繰り返しで、段々と完成速度集中時でも質が良いものが書けるようになってくる。 (ついでに炎上案件の時の、手の抜き方も身につく)

2019-04-29 12:30:44
村上昴平@エンジニア @ryuta005

@usu_blog @little_hand_s そうなんです! 質に関して考える5分でモヤモヤすると、あれもこれもどんどん出てきちゃうんですよね(泣)

2019-04-29 13:12:26
suin❄️ Kubernetesエンジニア募集中 @suin

1. Done is better than perfect. 2. 内的品質は外的品質を高める。 twitter.com/little_hand_s/…

2019-04-29 13:35:35
tarosuke @tarosukenet

@little_hand_s かなり重なってるけど「片方向依存」と「抽象度カスケード」の原則かなー。他のことはそこから出てくるものが少なくないし、方法論を導けるというのもポイント。

2019-04-29 14:07:46
cobot_1 @cobot_1

@little_hand_s 名前空間も含めた命名ですね。クラスベースの言語なら Manager、Info、Data といった曖昧な単語を含むクラス名を避ける。メソッド・関数名に三語以上の命名を避けるなどが分かりやすく実践しやすいかと。

2019-04-29 14:24:01
Yasuo Nakanishi @nakanishiyasuo

リファクタリング(相対的にマシにしていくという意味でに)かなー twitter.com/little_hand_s/…

2019-04-29 14:27:12
椿 @mrv_tsubaki

@little_hand_s ・KISS(Keep It Simple, Stupid, シンプルさを保つ) ・DRY(Don't Repeat Yourself, 繰り返し禁止) ・PIE(Program Intently and Expressively, 意図を表現してプログラムする) の3つでしょうか。

2019-04-29 15:13:50
Yuki YOSHIDA @sis_yoshida

責務かなぁ ここを突き詰めていけば自然と他の原則や性質も付いていく気がするので twitter.com/little_hand_s/…

2019-04-29 15:16:45
松岡@DDDブログ書いてます @little_hand_s

いろんな意見ありがとうございます! みなさま見事に全然違うことを言われているので面白いですw あとでトゥギャッターにまとめさせてもらっても良いですかね?NGな方はお手数ですがお声がけいただけるとありがたいですm(_ _)m twitter.com/little_hand_s/…

2019-04-29 15:38:38
44 @44x1carbon

@little_hand_s 僕は、今書こうとしているプログラミングが、いつ何をどうしたいかを言語化する事ですかね

2019-04-29 15:47:17
山地 伸明@5歳×2 @tom_nobu

@little_hand_s 入社してこれからって人ですと2つです - 小さく動かせること - コードが分かりやすいこと(特に名付け) 動くと楽しくなっていくのと、分かりやすく書いておけば先輩からもアドバイスもらいやすいだろうという考えです

2019-04-29 15:55:19
ちょいまけ@引きこもりフルリモート @choimake

@little_hand_s ネストを深くしない コメントなるべく書く 自分が書いたコードは人に説明できるように 当たり前のことのようだけど、できてない人はいる。 自分も気をつけないと❗️ほんとに❗️

2019-04-29 16:20:19
白栁隆司@エンジニアカウンセラー @ShirayanagiRyuj

@little_hand_s ・頭を使わずに読める事 ・DRY ・なぜそう書いたのかを説明できること (なんとなく、のコード禁止) を普段から口を酸っぱくして言ってます オブジェクト指向やコーディングルールなんぞ、これらを実現する為の手段でしか無いですよ、ぐらいの思考です

2019-04-29 17:10:59
残りを読む(22)

コメント

カスタム兆人 @juEsJsX5eMoEbxx 2019年5月1日
一つのロジックに固執するな、意外とシンプルな手段で解決できる、煮詰まったら休憩しろ
3
おろろ @fYe39CoQsPrbZVK 2019年5月1日
思ったように動かない、作った通りに動く。判断は機械、メンテは他人がやるからそのつもりで書くようにする。くらいでねえか。成型ルールなんかはきょうび自動化しとるやろ
3
SAKURA87@多摩丙丁督 @Sakura87_net 2019年5月1日
自分しか見ない予定のプログラムでも、ちゃんとどういう動作をやってどうしてそのコードにしているのかを、書いておくと後々読み返すときに便利。あとは案外今でも容易に置き換えられる割り算(÷2とか÷10とか)は掛け算(×0.5、×0.1)で置き換えると結構早い。
1
澄野一樹@『相互変調とIP3』Kindle版 発売中 @sumikaz 2019年5月1日
伝えることは文書化しろ。 時々更新しろ。 更新は、作成者以外の人にやらせろ。
2
ねや @AriaSub 2019年5月1日
便利な無名関数 便利だけど命名をすっ飛ばして親ロジックに自身の意味を混入させるから 使うべきか分けるべきか悩むんだよなぁ
0
きゃっつ(Kats)⊿ @grayengineer 2019年5月1日
いろんな意味で「依存」しない、かなぁ。最初から選択肢を狭めないという意味でもあり、リスクに強い構造を目指すという意味でもあり
0
ayuzak @ayuzak4318 2019年5月1日
クラスや変数の命名の時は辞書をひくことかなぁ。英単語のスペル間違えたのがずっと残るのは恥ずかしいので。
3
kusano @t_kusano 2019年5月1日
一度書いたところでやめるな。リファクタリングしろ。
1
ゆーき @yuki073 2019年5月1日
linterとスペルチェッカー入れるのはやったほうがいい。 linterの設定は厳し目で。
2
Haruka Oh! @sylphied_ 2019年5月2日
設計意図通りに実装せよ。 リアルタイムで構文解析してくれるIDEを使え。
0
Yeme @yer_meme 2019年5月2日
コードのコピペは良く良く考えてやるっス。良く考えればやらない方が良いのが判るはずっス。
0
AKIRA_TRYSTAR @AKIRA_TRYSTAR 2019年5月2日
・設計書に沿った実装にする。 ・確認作業の前にリフレッシュする。 ・変だと思ったら、有識者に確認する。 原理原則はルール通りでね。(・ω・)
0
× (゚∀゚ ))))∈ @cv45ValleyForge 2019年5月2日
元号の取得は関数化して、値(文字列)はデータベースなり環境ファイルに記述。
0
がらえぽ @glaepo 2019年5月2日
極力、全ての行にコメントを付ける(アセンブラの場合
1
rita_rico @rita_rico 2019年5月2日
・クラス間の関係性は「家族」や「恋人」でなく「職場の同僚」程度に留めよ。 ・バグや不具合は上流工程で見つけるほど修正コストが安くなるので、設計段階から積極的にデバッグせよ。 ・変数が定義されてから役目を終えるまでの範囲を極力短くせよ。
0
すいか @pear00234 2019年5月2日
まずはこういうツイートをする方々自身が「自分の設計やコードを後輩にレビューさせて、質問攻めやなぜなぜ5回に耐えることをやって見せる」のが一番大事なんじゃないかなーと思う。少なくとも一番最初にやるべきは「後輩のコードをレビューする」ことではなく「自分のコードを後輩にとことんまでレビューさせること」なんじゃないか?
1
すいか @pear00234 2019年5月2日
あと、重視すべきポイントや基準ってやつで色々挙げてるのについて「定量的にかつ厳密に、定義と公理によって定理化する」ことは最初にやっておくべきだと思うな、教える立場の人間側が。平たく言うと「クラスの責務をしっかり定義している、とはどういう状態を指すのか」、主観や立場を利用したごり押し抜きでちゃんと定量的に定義したり議論したりできる基準をあらかじめ開示しておくっていうか。
1
すいか @pear00234 2019年5月2日
みんな大好き山本五十六格言でも最初に「やってみせ」って言ってるわけだからね、まずは自分が進んでお手本になり、後輩にガンガン自分のコードを突っ込ませて、自分の設計の理由をきっちり明確に、ふわふわした基準でもごり押しでもない、定義と論理で実証する姿を見せましょうっていう感じですな。
1
Briareos@残弾数はいつも────── @briareos 2019年5月2日
条件逸脱時のハンドリングはちゃんとやらないと、データが中途半端になってしまって以降の処理が死ぬ。チェック漏れしたまま処理に入って例外起こしてデータがぐちゃぐちゃになるってこと、たまにあるんだ・・・
0
harutonatu @harutonatu 2019年5月2日
さまざまな考え方があって、コメント欄含めて眺めるのが楽しい。
0
ひこゆさ @mbMCcefiR2YQYpl 2019年5月2日
レビューは人格批判じゃない。ソースコードは個人批判に使うものじゃない。当たり前のはずのこれが徹底できないと心の弱い人から辞める。実力じゃなくメンタル勝負になる。
2
かつのり @k5n6 2019年5月2日
すぐクラスの話になるのは何でだろう。 クラス設計なんてプログラムの表現方法の1つでしかないのに。 OS資源の使い方が適切かとか、そういうのを教えたいな。 ログ出しまくってDiskFullを起こして障害になるなんて良くあるケース。 なのにプログラムは正しいと逆ギレする人もいるんだよ。
1