mRshly
@mrshly.bsky.social
日本でソフトウェアエンジニアをしています.
仕事で Python と PostgreSQLを使ってます.
仕事で Python と PostgreSQLを使ってます.
2章は最近の自分に刺さることが多い
ドメイン知識を獲得してきて技術力も定着して組織内のテックリードになりつつあるときは特にこの辺りを意識しないと、逆にチームから孤立してしまう
ドメイン知識を獲得してきて技術力も定着して組織内のテックリードになりつつあるときは特にこの辺りを意識しないと、逆にチームから孤立してしまう
July 8, 2025 at 3:53 AM
2章は最近の自分に刺さることが多い
ドメイン知識を獲得してきて技術力も定着して組織内のテックリードになりつつあるときは特にこの辺りを意識しないと、逆にチームから孤立してしまう
ドメイン知識を獲得してきて技術力も定着して組織内のテックリードになりつつあるときは特にこの辺りを意識しないと、逆にチームから孤立してしまう
逆にハイコンテキストなコミュニケーションで成り立ってるチームだと自分はお荷物になるだろうな
March 28, 2025 at 10:36 AM
逆にハイコンテキストなコミュニケーションで成り立ってるチームだと自分はお荷物になるだろうな
ルール9 (4)
共通知識は無料~ のタイトルから, 確かにそうなんだけど, その共通知識がよく分からないメンバーで構成されていたら?
どうやってその共通知識を確かめる?
普段のコードレビューでどういったことに気をつけたら,
あるいはどういったルールを設けたらそれを知る,共有することができるだろうか
これを書いている時点でメンバーとのコミュニケーションが足りていないのだと感じた
共通知識は無料~ のタイトルから, 確かにそうなんだけど, その共通知識がよく分からないメンバーで構成されていたら?
どうやってその共通知識を確かめる?
普段のコードレビューでどういったことに気をつけたら,
あるいはどういったルールを設けたらそれを知る,共有することができるだろうか
これを書いている時点でメンバーとのコミュニケーションが足りていないのだと感じた
March 5, 2025 at 3:52 PM
ルール9 (4)
共通知識は無料~ のタイトルから, 確かにそうなんだけど, その共通知識がよく分からないメンバーで構成されていたら?
どうやってその共通知識を確かめる?
普段のコードレビューでどういったことに気をつけたら,
あるいはどういったルールを設けたらそれを知る,共有することができるだろうか
これを書いている時点でメンバーとのコミュニケーションが足りていないのだと感じた
共通知識は無料~ のタイトルから, 確かにそうなんだけど, その共通知識がよく分からないメンバーで構成されていたら?
どうやってその共通知識を確かめる?
普段のコードレビューでどういったことに気をつけたら,
あるいはどういったルールを設けたらそれを知る,共有することができるだろうか
これを書いている時点でメンバーとのコミュニケーションが足りていないのだと感じた
ルール9 (3)
でも我々はコードを短期記憶だけで読んでいるわけではない
プロジェクトにまつわる知識やこれまでの経験や学習で身に付けた知識を使って読んでいる
例えばその知識にない名前で表現されたメソッドが出てきたらその名前から推測して考える
でもその名前が何の役にもたたないものだったら?
実際に動かしてみるしかない
でも我々はコードを短期記憶だけで読んでいるわけではない
プロジェクトにまつわる知識やこれまでの経験や学習で身に付けた知識を使って読んでいる
例えばその知識にない名前で表現されたメソッドが出てきたらその名前から推測して考える
でもその名前が何の役にもたたないものだったら?
実際に動かしてみるしかない
March 5, 2025 at 3:52 PM
ルール9 (3)
でも我々はコードを短期記憶だけで読んでいるわけではない
プロジェクトにまつわる知識やこれまでの経験や学習で身に付けた知識を使って読んでいる
例えばその知識にない名前で表現されたメソッドが出てきたらその名前から推測して考える
でもその名前が何の役にもたたないものだったら?
実際に動かしてみるしかない
でも我々はコードを短期記憶だけで読んでいるわけではない
プロジェクトにまつわる知識やこれまでの経験や学習で身に付けた知識を使って読んでいる
例えばその知識にない名前で表現されたメソッドが出てきたらその名前から推測して考える
でもその名前が何の役にもたたないものだったら?
実際に動かしてみるしかない
ルール9 (2)
抽象化にはコストが掛かると言う話
ある塊を抽象化して関数に分解するというのはいつでも効果的に働くべきではない
理解しやすくなるか->コードがもっと集約できる様になるかを判断して抽象化するべき
抽象化にはコストが掛かると言う話
ある塊を抽象化して関数に分解するというのはいつでも効果的に働くべきではない
理解しやすくなるか->コードがもっと集約できる様になるかを判断して抽象化するべき
March 5, 2025 at 3:52 PM
ルール9 (2)
抽象化にはコストが掛かると言う話
ある塊を抽象化して関数に分解するというのはいつでも効果的に働くべきではない
理解しやすくなるか->コードがもっと集約できる様になるかを判断して抽象化するべき
抽象化にはコストが掛かると言う話
ある塊を抽象化して関数に分解するというのはいつでも効果的に働くべきではない
理解しやすくなるか->コードがもっと集約できる様になるかを判断して抽象化するべき
ルール9 (1)
短期記憶のトピックで出てくるサンプルコードはどこかで聞いたチャンクの話が実感できるものだった
コメントと名前付けが効果的に機能している好例
短期記憶のトピックで出てくるサンプルコードはどこかで聞いたチャンクの話が実感できるものだった
コメントと名前付けが効果的に機能している好例
March 5, 2025 at 3:52 PM
ルール9 (1)
短期記憶のトピックで出てくるサンプルコードはどこかで聞いたチャンクの話が実感できるものだった
コメントと名前付けが効果的に機能している好例
短期記憶のトピックで出てくるサンプルコードはどこかで聞いたチャンクの話が実感できるものだった
コメントと名前付けが効果的に機能している好例
ツリーにした方が後から読みやすいので,孤立してしまったポストはこっちにつなげておく
bsky.app/profile/mrsh...
bsky.app/profile/mrsh...
ルール7 の文が良い.
自滅ってのが良い表現だね.
> そして, チームにいる他のプログラマーに対し, ある機能を公開したら, やつらはその機能を間違った使い方で使う.必ずだ.
> 自分の設計について, 自問すべき重要な質問項目がある.
「この機能やインターフェイスのユーザーが自滅する(=勝手な使い方をしたせいで好ましくない結果に至る) のを, どれだけ難しくしているか?」だ.
自滅ってのが良い表現だね.
> そして, チームにいる他のプログラマーに対し, ある機能を公開したら, やつらはその機能を間違った使い方で使う.必ずだ.
> 自分の設計について, 自問すべき重要な質問項目がある.
「この機能やインターフェイスのユーザーが自滅する(=勝手な使い方をしたせいで好ましくない結果に至る) のを, どれだけ難しくしているか?」だ.
March 5, 2025 at 3:52 PM
ツリーにした方が後から読みやすいので,孤立してしまったポストはこっちにつなげておく
bsky.app/profile/mrsh...
bsky.app/profile/mrsh...