あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ - Qiita

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに この記事は数百万行の動的型付き言語のWebアプリケーションのリファ

[hidari-yori]

これ会社に投げつけたい

[Appakun]

“この制約はサービス間の連携が本当に粗結合であるときに有効です。 連携が密結合な場合、内部的なAPIリクエストの数が爆発したり、障害点が増えたりとレスポンスの悪化を招いたり、障害検知が複雑化しがちです。”

[sylvan_l]

あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ

[yh1126]

“理解可能性(Understandability) ”

[canon4444]

“鶏が先か卵が先かの議論になりがちですが、鶏を生み出してしまえば、卵は生まれます。”

[ko-ya-ma]

力作

[kikeda1104]

仕組み化は重要"「守らないプログラマがいる」ことではなく、「守らずにコミットできること」「守っていない箇所を検知できないこと」「守っていない箇所をコントロールできていないこと」にあります。"

[saisa6153]

プロジェクト始めるときにひと通り用意できれば理想なのかな 後からの導入はコストかかるし

[y0sh1-nek0]

あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ この記事は数百万行の動的型付き言語のWebアプリケーションのリファクタリング、アプリケーションアーキテクチャの再設計の経験を基に、有効だ

[shimobayashi]

bugspotsはとりあえず使ってみようかな。Perlで静的解析楽にやる方法知りたい

[igrep]

“複数人で複数回にわたって編集されたファイルは複数の目的でコードが編集されている訳ですから、「単一責務原則」を違反している可能性が高く、潜在的にバグを内在していそうだということ”

[satzz]

7/18

[msfukui]

大抵のトピックが網羅されていてとても参考になります。記事に書かれている通り、少しずつ..ですね。

[waniji]

"問題は、「守らないプログラマがいる」ことではなく、「守らずにコミットできること」～" 同意見

[masayoshinym]

[プログラマ[プログラミング系読み][チーム開発]

[tkmoteki]

ふむふむ "あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ - Qiita"

[decoy2004]

『コードチャーン Code Churn. 複数人で複数回にわたって編集されたファイルは複数の目的でコードが編集されている訳ですから「単一責務原則」を違反している可能性が高く、潜在的にバグを内在していそうだ。』

[root]

bugspotsは使ってみたいな．

[kyab]

まじナニモンなのこの人

[hatest]

PGのソースコードに対する意識のスパゲッティ化を防ぐ方法

[lEDfm4UE]

「暗黙知」による評価は避けましょう

[poppun1940]

はじめに この記事は数百万行の動的型付き言語のWebアプリケーションのリファクタリング、アプリケーションアーキテクチャの再設計の経験を基に、有効だと思われる考え方やアプローチを抜粋して紹介するものです。言