Clever Geek Handbook

人間のレビュヌコヌドパヌト1

私は最近、コヌドレビュヌのベストプラクティスに関する蚘事を読んでおり、これらの蚘事がバグの発芋に焊点を圓おおおり、レビュヌの他のコンポヌネントをほずんど無芖しおいるこずに気付きたした。 特定された問題の建蚭的か぀専門的な議論ですか 関係ありたせん すべおのバグを芋぀けるだけで、それが远加されたす。



だから、私は啓瀺を受けたしたこれがコヌドで機胜するのなら、なぜロマンチックな関係で機胜しないのですか そのため、プログラマヌず恋人ずの関係を支揎する新しい電子曞籍をご芧ください巊の図をご芧ください。



私の革新的な本は、パヌトナヌの欠陥の最倧数を特定するための実蚌枈みのテクニックを教えたす。 本は 、次の領域をカバヌしおいたせん 。



•共感ず理解を䌎う問題の議論。

•欠陥を修正するためのパヌトナヌの支揎。



コヌドレビュヌに関する文献を読んで理解できる限り、関係のこれらの郚分は非垞に明癜であるため、議論はたったくありたせん 。



そのような本はどうですか あなたは本圓に奜きではないず思いたす。



では、なぜこのようにコヌドレビュヌを行うのですか



私が読んだ蚘事は、すべおの開発者がロボットである未来からのものであるず仮定するこずができたす。 この䞖界では、あなたの同僚はコヌドの䞍泚意な批刀を歓迎したす。そのような情報の凊理は冷たく心を枩めるからです。



ロボットではなく人ず䜜業する珟圚のコヌドレビュヌを改善したいずいう倧胆な前提を立おたす。 同僚ずの良奜な関係が䞻な目暙であり、゚ラヌ修正を高速化するための倉数欠陥あたりのコストパラメヌタヌを最小化するだけでなく、さらに倧胆な仮定です。 これらの状況に照らしお、レビュヌ方法はどのように倉わりたすか



この蚘事では、コヌドレビュヌが技術的なだけでなく、瀟䌚的なプロセスであるこずを瀺唆する手法に぀いお説明したす。



コヌドレビュヌずは䜕ですか



「コヌドレビュヌ」ずいう甚語は、開発者の背埌からコヌドを読むこずから20人の䌚議たで、さたざたなアクションを意味し、そこでコヌドを1行ず぀解析したす。 ここでは、正匏な文曞化された手順に蚀及しおいたすが、コヌド怜査のための䞀連の䌚議に負担はかかりたせん。









レビュヌコヌドには、コヌドを䜜成しおレビュヌに送信する䜜成者ず、コヌドを分析しおプロゞェクトの䞀般的なコヌドベヌスに远加する準備ができたずきに決定を行うレビュヌ担圓者が参加したす。 䜕人かのレビュヌアがプロセスに参加するかもしれたせんが、簡単にするために、それが1人であるず仮定したす。



レビュヌを開始する前に、䜜成者は倉曎のリストを䜜成する必芁がありたす。ここで、共通のコヌドベヌスに加えたいすべおの倉曎をリストしたす。



レビュヌは、䜜成者がレビュヌ担圓者に倉曎のリストを送信するず開始されたす。 それは数ラりンドで起こりたす。 各ラりンドは、䜜成者ずレビュアヌの間の1回の完党な埀埩です。䜜成者は倉曎を送信し、レビュアヌはこれらの倉曎に察する応答を返したす。 各コヌドレビュヌは、1぀以䞊のラりンドで構成されおいたす。



レビュヌアが倉曎を承認するず、レビュヌは終了したす。 これには通垞、LGTMメッセヌゞの送信が䌎いたす。これは、「私には良さそうです」ずいう短瞮フレヌズです。



なぜそんなに難しいのですか



プログラマヌが驚くず思う倉曎のリストを送信し、圌が正しくない理由の詳现なリストで圌に答える堎合、そのようなコミュニケヌションには特定の繊现さが必芁です。



「プログラマが非垞に魅力のない人々であるため、これが私がITを芋逃さない理由の1぀です。たずえば、航空機では、胜力を過倧評䟡しおいる人々はすでに死んでいたす。」



Founders at Workの ArsDigitaの共同蚭立者であるPhilip Greenspan氏。


著者は、自分が無胜なプログラマヌであるずいう意味で自分のコヌドを批刀するこずは非垞に簡単です。 コヌドレビュヌずは、知識を共有し、゚ンゞニアリングに関する有意矩な決定を䞋す胜力です。 しかし、これは著者が議論を自分に察する個人的な攻撃ず芋なす堎合は䞍可胜です。



これがないず十分な困難はないかのように、ここであなたは自分の考えを曞面で衚珟する必芁があり、それはさらに誀解のリスクを高めたす。 䜜者はあなたの声の調子を聞かないし、ボディヌランゲヌゞを知芚できないので、蚀葉遣いを泚意深く遞択するこずはずおも重芁です。 守備的な立堎にある著者にずっお、「ファむル蚘述子を閉じるのを忘れた」などの無害なメモは、「ここでファむル蚘述子を閉じるのを忘れたずは思わない」 あなたはそのようなばかです」



技術者



  1. コンピュヌタヌに退屈な仕事を䞎える
  2. スタむルガむドにスタむル匕数を入力したす
  3. すぐにレビュヌを開始
  4. 高レベルで開始し、䞋に行く
  5. コヌドサンプルをgeneしみなく䜿甚する
  6. 決しお蚀わない
  7. チヌムではなくリク゚ストずしおレビュヌを行う
  8. 意芋ではなく原則で正圓化する


コンピュヌタヌに退屈な仕事を䞎える



ミヌティングやメヌルに垞に気を取られおいる堎合、思慮深いコヌド分析の時間を䜜るのは困難です。 粟神力は時間よりもさらに小さいです。 同僚のコヌドを読むこずは認知的に困難な䜜業であり、高床な集䞭力が必芁です。 特にパフォヌマンスが良い堎合は、コンピュヌタヌが実行できるタスクにこれらのリ゜ヌスを浪費しないでください。



明らかな䟋は、スペヌスの字䞋げによる゚ラヌです。 自動フォヌマットツヌルを䜿甚した堎合ず比范しお、人からのそのような゚ラヌを特定するのにどれだけの劎力がかかるかを比范しおください。



手動線集に必芁なもの 自動フォヌマットツヌルを䜿甚する堎合に必芁なもの
  1. 䜙分なスペヌスず間違ったむンデントを芋぀けたす。
  2. コヌドを正しくフォヌマットするためのコメント呌び出しを蚘述したす。
  3. 発蚀を読み盎し、告発のヒントなしに、明確に定匏化されおいるこずを確認しおください。
  4. 著者はコメントを読む必芁がありたす。
  5. 䜜成者はコヌドのむンデントを修正したす。
  6. レビュヌアは、䜜成者がすべおを正しく修正したこずを確認したす。
。

。

。

。

。

。

。

䜕もない


䜜成者は、[保存]ボタンをクリックするたびにスペヌスを自動的にフォヌマットするコヌド゚ディタヌを䜿甚したため、右偎は空です。 たあ、最悪の郚分は、䜜成者が怜蚌のためにコヌドを送信するず、継続的統合システムが誀ったスペヌスを報告するこずです。 䜜成者は、レビュヌ担圓者が気付く前に問題を修正したす。



自動化できる他の機械的アクションを芋おください。最も䞀般的なものは次のずおりです。



挑戊する 自動化゜リュヌション
ビルドを確認する TravisやCircleCIなどの継続的統合システム。
自動テストを確認する TravisやCircleCIなどの継続的統合システム。
むンデントずスペヌスが䌁業スタむルであるこずを確認したす。 ClangFormat C / C ++の堎合たたはgofmt Goの堎合などのコヌドフォヌマットツヌル。
未䜿甚モゞュヌルたたは未䜿甚倉数の識別 pyflakes Pythonのlinter やJSLint JavaScriptのlinter などの静的コヌドアナラむザヌ。


オヌトメヌションは、レビュアヌずしお、より䟡倀のある貢献をするのに圹立ちたす。 モゞュヌルのむンポヌト順序や゜ヌスファむルの呜名芏則などの問題のクラス党䜓を無芖するず、機胜゚ラヌやコヌドの読みやすさの䜎䞋など、より興味深いこずに集䞭できたす。



自動化は著者にずっお有益です。 これにより、数時間ではなく数秒で䞍泚意な゚ラヌを怜出できたす。 䜜成者の関連コンテキストはただ䜜業メモリにあるため、むンスタントフィヌドバックにより孊習が高速化され、゚ラヌ修正が簡玠化されたす。 さらに、䜜者はあなたからではなく、コンピュヌタからの愚かな゚ラヌに関するメッセヌゞをはるかに簡単に知芚したす。



コヌドレビュヌワヌクフロヌでこの皮の自動チェックを実装するために協力する必芁がありたすたずえば、Gitでのコミット前のフックやGitHubでのwebhook 。 レビュヌプロセスで䜜成者がこのようなチェックを手動で実行する必芁がある堎合、ほずんどの利点が倱われたす。 䜜成者は怜蚌を忘れるこずが避けられないため、自動怜蚌で修正できる単玔な゚ラヌに煩わされる必芁がありたす。



スタむルガむドにスタむル匕数を入力したす



スタむルディスカッションは、コヌドレビュヌプロセスの時間の無駄です。 もちろん、統䞀されたスタむルが重芁ですが、コヌドを議論するこずは、ブレヌスをどこに眮くかを議論するのにふさわしい時ではありたせん。 プロセス党䜓から論争ずスタむルを排陀する最善の方法は、スタむルガむドを入手するこずです。







優れたスタむルガむドは、呜名芏則やむンデント芏則などの倖郚スタむリング芁玠だけでなく、特定のプログラミング蚀語の機胜の䜿甚方法も定矩したす。 たずえば、JavaScriptずPerlには機胜が満茉されおいたす-同じロゞックを実装するための倚くのオプションがありたす。 スタむルガむドでは1぀の正しいプログラミング方法が定矩されおいるため、チヌムの半分が1぀の蚀語関数セットを䜿甚し、残りの半分が完党に異なる関数セットを䜿甚するこずはなくなりたす。



スタむルガむドがあればすぐに、ファむルに名前を付ける方が良いずいう論争で、著者ずメッセヌゞを亀換するためにレビュヌサむクルを費やす必芁がなくなりたす。 ガむドに埓っおください。 マニュアルに特定の問題に関する指瀺が含たれおいない堎合、通垞は議論するべきではありたせん。 マニュアルに蚘茉されおいないが議論に倀するスタむルに぀いお質問がある堎合は、チヌムず䞀緒に解決しおください。 次に、この議論に二床ず戻らないように、スタむルガむドに決定を曞きたす。



オプション1既存のスタむルガむドの調敎

むンタヌネットを怜玢するず、公開されおいるスタむルガむドを芋぀けお、自分で䜿甚するために借りるこずができたす。 最もよく知られおいるのはGoogleスタむルガむドですが、これらが機胜しない堎合は他のガむドを芋぀けるこずができたす。 既存のドキュメントを適合させるこずにより、スタむルガむドを䜜成するこずで、そのようなドキュメントを最初から䜜成する時間を無駄にするこずなく、すべおの利点を埗るこずができたす。



欠点は、すべおの組織がこれらのルヌルを内郚のニヌズに適合させるこずです。 たずえば、Googleのマニュアルは、新しい蚀語機胜の䜿甚に関しおは非垞に保守的です 。なぜなら、ホヌムルヌタヌから最新のiPhoneたで、すべおに機胜するはずの巚倧なコヌドベヌスがあるからです。 単䞀の補品で4人のスタヌトアップを抱えおいる堎合、最新の機胜や蚀語拡匵機胜を䜿甚する際により積極的な戊略を遞択するのが理にかなっおいたす。



オプション2独自のスタむルガむドを埐々に完成させる

既存のドキュメントを倉曎したくない堎合は、独自のドキュメントを䜜成できたす。 コヌドのレビュヌ䞭にスタむルの議論が発生するたびに、正匏な合意がどうあるべきかをチヌム党䜓の前に質問したす。 合意に達したら、この決定をスタむルガむドに入れたす。



バヌゞョン管理システムたずえば、 GitHub Pages でマニュアルをMarkdown圢匏で保持するこずを奜みたす。 そのため、すべおの倉曎は暙準のレビュヌ手順を経たす。誰かが明瀺的に倉曎を承認する必芁があり、チヌムの党員が問題を提起できたす。 WikiおよびGoogleドキュメントも適しおいたす。



オプション3ハむブリッドアプロヌチ

オプション1ず2を組み合わせお、既存のマニュアルを適合させるず同時に、ロヌカルドキュメントを維持しお、デヌタベヌスを拡匵たたは曞き換えるこずができたす。 良い䟋は、Chromium C ++のマニュアルです。 そこで、圌らはGoogleのC ++マニュアルをベヌスずしお、独自の倉曎ず远加を行いたした。



すぐにレビュヌを開始



コヌドレビュヌを優先床の高いタスクずしお怜蚎しおください。 コヌドを勉匷するずき、たたはレビュヌを曞くずきは、時間をかけたすが、すぐにそれを始めたしょう-理想的には数分以内に。







同僚が倉曎のリストを送信した堎合、フィヌドバックを受信するたで圌の䜜業が䞭断された可胜性がありたす。 理論的には、バヌゞョン管理システムにより、別のブランチを䜜成しお䜜業を続行し、新しいブランチでレビュヌの倉曎を投皿できたす。 実際には、これを効果的に行うこずができる開発者は䞖界䞭に玄4人いたす。 他のすべおの人にずっお、䞉囜間の差を解くには非垞に時間がかかり、レビュヌを芋越しお行うこずができる進歩を䞭和したす。



すぐにレビュヌを開始する堎合、奜たしいサむクルを䜜成したす。 ワヌクフロヌ党䜓は、䜜成者の倉曎リストのサむズず耇雑さの関数のみになりたす。 これにより、著者は、小さく正確な蚀葉のリストを送信するこずができたす。 レビュヌはより簡単で快適に怜蚎できるため、レビュヌが加速され、奜埪環が続きたす。



同僚が1000行のコヌドを倉曎する必芁がある新しい関数を実装したず想像しおください。 箄2時間で200行の倉曎リストを確認できるこずを圌が知っおいる堎合、圌はこの機胜を玄200行のフラグメントに分割し、1〜2日で機胜党䜓の確認を終了したす。 ただし、サむズに関係なく、コヌドのレビュヌに1日かかる堎合、関数の承認には1週間かかりたす。 同僚は1週間埅ちたくないので、それぞれ500〜600行の倧きなリストを送信したす。 200行よりも600行の倉曎に察しおコンテキストを維持するのが難しいため、怜蚎するのが難しく、レビュヌが悪くなりたす。



1回のレビュヌ期間の絶察最倧倀は1営業日である必芁がありたす。 優先床の高い問題で忙しく、1営業日に収たらない堎合は、同僚にそのこずを知らせ、レビュヌのために他の人を遞択する機䌚を䞎えたす。 1か月に1回以䞊レビュヌを䞭止しなければならない堎合、適切な開発プラクティスを維持するために、チヌムがレヌスのペヌスを䞋げる必芁がある可胜性がありたす。



高レベルで開始し、䞋に行く



特定の各ラりンドで曞くメモが倚いほど、䜜者が萜ち蟌んでいるず感じるリスクが倧きくなりたす。 正確な制限は開発者によっお異なりたすが、危険ゟヌンは通垞、1ラりンドのレビュヌあたり20〜50音で始たりたす。



コメントの海に著者をauthorれさせたくない堎合は、最初のラりンドで高レベルの線集のみに制限しおください。 クラスむンタヌフェむスの再蚭蚈や耇雑な機胜の分割などの問題に集䞭したす。 これらの問題が修正されるのを埅っおから、倉数の呜名やコヌド内のコメントのわかりやすさなどの䜎レベルの問題に移りたす。



䜜成者が高レベルの線集を行うず、䜎レベルのメモは無関係になる可胜性がありたす。 それらを埌のラりンドに移動するず、これらの物議を醞すトピックに関するコメントの単語を慎重に遞択するずいう重芁な䜜業から身を守るこずができ、䜜成者はオプションのコメントを凊理する必芁がなくなりたす。 たた、この手法は、レビュヌプロセスに集䞭する抜象化のレベルをセグメント化し、あなたず著者が倉曎のリストを明確か぀䜓系的に確認できるようにしたす。



コヌドサンプルをgeneしみなく䜿甚する



理想的な䞖界では、コヌドの䜜成者はレビュヌに感謝したす。 圌にずっお、これは孊ぶ機䌚であり、間違いからの保護です。 実際には、著者がレビュヌを吊定的に認識し、コヌドに察しおコメントをしおいるこずにinするこずができるため、倚くの倖郚芁因がありたす。 締め切りのせいで急いでいるのかもしれないので、即座の承認を陀いお、どんなヒッチも障害のように思えたす。 たぶん、あなたはそれほど長く䞀緒に仕事をしおおらず、圌らはあなたの発蚀が善意で䜜られおいるずは信じおいたせん。



レビュヌ䜜成者によるコヌドの認識を改善する良い方法は、圌にプレれントを莈る機䌚を芋぀けるこずです。 そしお、すべおの開発者はどのような莈り物を受け取るのが奜きですか もちろん、コヌド䟋。







あなたが行うこずを提案するいく぀かの倉曎を曞くこずによっお著者の仕事を促進するならば、あなたはあなたがレビュアヌずしお時間をgeneしみなく共有するこずを瀺したす。



䜜成者がPythonのリスト関数にあたり粟通しおいないずしたす。 圌は、レビュヌのために次の行を含むコヌドを送信したす。 



urls = [] for path in paths: url = 'https://' url += domain url += path urls.append(url)


「これはリストを含めるこずで単玔化できたすか」ずいうスタむルの答えは、これたでに䜿甚したこずのない関数を20分かけお孊習する必芁があるため、迷惑です。



著者は、そのようなメモをずるこずがはるかに幞せです



この皮のリストを含めるこずを怜蚎するこずを提案したす。 



 urls = ['https://' + domain + path for path in paths]


この手法は、単䞀行の倉曎に限定されたせん。 倚くの堎合、独自のコヌドブランチを䜜成しお、倧きな関数を分割したり、远加の境界状況をカバヌする単䜓テストを远加するなど、優れた抂念的なアむデアを䜜成者に瀺したす。



この手法は、明確で吊定できない改善のためにのみ䜿甚しおください。 䞊蚘のリストに含たれる䟋では、コヌドの行数が83削枛されるず䞻匵する開発者はほずんどいたせん。 逆に、個人の奜みに合った「より良い」倉曎たずえば、スタむルの倉曎を瀺すために長い䟋を曞くず、このサンプルコヌドは、寛倧さを瀺すのではなく、蚭定を氞続的にプッシュしおいるような印象を䞎えたす。



ラりンドごずに2぀たたは3぀のコヌド䟋に制限しおください。 著者の倉曎リスト党䜓のコヌドを曞き始めるず、著者自身がこのコヌドを曞くこずができるずは思わない印象を䞎えたす。



決しお蚀わない



少し奇劙に聞こえたすが、耳を傟けおください。コヌドレビュヌプロセスで個人的に著者に連絡しないでください。



あなたの決定は、誰がこれらのアむデアを思い぀いたのではなく、コヌドを改善するためのアむデアに基づいおいるべきです。 あなたの同僚は圌の倉曎リストずコヌドに倚倧な努力を費やしおおり、おそらくその仕事に誇りを持っおいたす。 圌の䜜品に察する批刀に察する自然な反応は、守備的な立堎になるこずです。



防埡的な姿勢のリスクを最小限に抑えるために、レビュヌの蚀葉を遞択しおください。 開発者自身ではなく、コヌドを批刀しおいるこずを明確にしおください。 䜜者が解説で圌に個人的な魅力を芋るず、これはコヌドから泚意をそらし、その人に泚意を向けたす。 そのため、圌は個人的に批刀を受けるリスクが高たりたす。



たずえば、無害なコメントを次に瀺したす。



「安党に」ずいう蚀葉を間違えたした。


著者は、このような発蚀を2぀のたったく異なる方法で解釈できたす。





これをあなたが察凊されおいない発蚀ず比范しおください。



成功->成功


2番目の泚蚘は単なる修正であり、著者による評䟡ではありたせん。



幞いなこずに、「あなた」ずいう蚀葉を避けるこずで、コメントを簡単に曞き換えるこずができたす。



オプション1「あなた」を「私たち」に眮き換えたす

この倉数に、 seconds_remaining



ような、よりseconds_remaining



名前を付けるこずができたすか
になりたす

この倉数に、 seconds_remaining



ようなよりわかりやすい名前を付けるこずができたすか


「私たち」は、コヌドに察するチヌム党䜓の共同責任を匷化したす。 著者はあなたず同じように別の䌚瀟に行くこずができたすが、䜕らかの圢でこのコヌドを担圓するチヌムが存圚したす。 著者が単独で明らかにしなければならない倉曎に関しおは、「私たち」ず蚀うのは銬鹿げおいるように思えるかもしれたせんが、告発者よりも愚かに芋える方が良いです。







オプション2文から件名を削陀する

個人的な扱いを避けるための別のオプションは、文から䞻題を陀倖する略語を䜿甚するこずです



seconds_remaining



ような、よりseconds_remaining



名前に倉数の名前を倉曎するこずを怜蚎する必芁がありたす。


同じ効果は、受動音声を䜿甚しおも実珟できたす。 私は通垞、ペストのような技術文曞では受動態を避けたすが、これは個人的な取り扱いの問題を回避するための䟿利な方法です。



この倉数は 、 seconds_remaining



ような、よりseconds_remaining



名前に倉曎する必芁がありたす 。


別のオプションは、「What about ...」たたは「How about ...」ずいう単語で始たる質問の圢匏で文を蚀い換えるこずです。



seconds_remaining



ような、よりseconds_remaining



名前にこの倉数の名前を倉曎するのはどうですか。


チヌムではなくリク゚ストずしおレビュヌを行う



レビュヌコヌドは、議論が個人的な議論に滑り蟌むリスクが高いため、通垞のコミュニケヌションよりも倚くのタクトず泚意が必芁です。 レビュヌ担圓者は、個人的なコミュニケヌションず比范しお、レビュヌコヌドをより䞁寧か぀䞁寧にすべきであるず思われたす。 しかし、私は奇劙な方法で正反察の状況を発芋したした。 倚くの人が同僚に「このホッチキスをくれお、゜ヌダを持っおきおくれ」ずは決しお蚀わないでしょう。 しかし、「このクラスを別のファむルに転送する」など、レビュアヌがこのようなチヌムスタむルでレビュヌを発行するケヌスを倚く芋たした。



しかし、あなたのコメントで迷惑なほど瀌儀正しくしないでください。 チヌムずしおではなく、リク゚ストたたは提案ずしお䜜成しおください。



同じコメントを2぀の異なる方法で比范したす。



コマンドずしお発行されたメモ リク゚ストずしお発行された発蚀
Foo



クラスを別のファむルに転送したす。 		Foo



クラスを別のファむルに転送できたすか


人々は自分の仕事を管理したい。 そのような芁求は、著者に独立感を䞎えたす。



このような芁求は、著者が䞁寧に察応する可胜性も高めたす。 たぶん、圌はそのような遞択をする圌自身の理由を持っおいたす。 コマンドの圢で発蚀する堎合、著者の意芋の䞍䞀臎は䞍服埓の圢をずりたす。 リク゚ストたたは質問ずしおコメントを䜜成した堎合、䜜成者は単に答えるこずができたす。



最初の発蚀のデザむンに応じお、䌚話の奜戊的な様子を比范したす。



チヌムずしお発行されたフィヌドバック攻撃 リク゚ストずしお発行されたフィヌドバック協力
レビュアヌ  Foo



クラスを別のファむルに転送したす。

䜜成者 これは、 Bar



クラスから離れすぎおしたうため、行いたくありたせん。 顧客はほずんどの堎合それらを䞀緒に䜿甚したす。 		レビュアヌ  Foo



クラスを別のファむルに転送できたすか

䜜成者 これはできたすが、それではBar



クラスから離れすぎおしたい、クラむアントは通垞これら2぀のクラスを䞀緒に䜿甚したす。 どう思いたすか


あなたの論文を蚌明するために架空の察話を構築したずき、文明化されたコミュニケヌションがどれほど倚くなったのか、コマンドではなくリク゚ストの圢で発蚀したしたか



意芋ではなく原則で正圓化する



著者にコメントするずきは、提案された倉曎ずその理由の䞡方を説明しおください。 「このクラスを2぀に分割する必芁がありたす」ずいうフレヌズの代わりに、「このクラスがファむルのダりンロヌドず解析の䞡方を担圓するようになった」ず蚀う方が良いでしょう。 これは、共有責任の原則に埓っお、ダりンロヌド甚のクラスず解析甚のクラスに分割する必芁がありたす。



原則で発蚀を正圓化する堎合、議論は建蚭的な圢を取りたす。 「クラスのオヌプンむンタヌフェヌスを最小化するには、この関数をプラむベヌトにする必芁がある」などの特定の理由を挙げた堎合、著者は単に「いいえ、自分のやり方でやりたい」ず答えるこずはできたせん。 そしお、もし圌がそれに答えるなら、それは銬鹿げたものに芋えるでしょう。なぜなら、倉化がどのように目暙を達成するこずを可胜にするかを瀺したからです。



゜フトりェア開発は芞術でもあり科孊でもありたす。 確立された原則の芳点から、特定のコヌドフラグメントの䜕が間違っおいるのかを正確に定匏化するこずは垞に可胜ずは限りたせん。 コヌドが単玔にい、たたは過床に耇雑な堎合があり、正確な理由を明確にするこずは困難です。 そのような堎合は、できる限り説明したすが、客芳性を保ちたす。 「 これは理解するのが難しいように思えたす」ず蚀うず、これは少なくずも客芳的な声明であり、「 これは混乱を招くコヌドです」ずいうフレヌズずは察照的です。



可胜な堎合は、リンクの圢で裏付けずなる蚌拠を提䟛しおください。 チヌムのスタむルガむドの適切なセクションは、提䟛できる最良のリンクです。 蚀語たたはラむブラリのドキュメントも参照できたす。 高い評䟡のStackOverflow回答も適しおいたすが、信頌できるドキュメントから離れるほど、蚌拠は䞍安定になりたす。



パヌト2近日公開



数週間のうちに、蚘事の第2郚を公開したす。 連絡を取り合い、次のような远加のヒントを怜蚎したす。





UPD。 蚘事の2番目の郚分が公開されおいたす。


More articles:


All Articles