[ウトコ]1週目のバックエンドフィードバック

名前で君の意図を表す

変数、関数(メソッド)、クラスの名前を付けるのに時間がかかります.
変数の役割、関数の役割、クラスの役割の意図を名前で明らかにしようと努力します.
連続数字(a 1、a 2、...)、非用語(Info、Data、a、an、the)を追加する方法は適切ではありません.

足を引っ込まないで

意図が表れるなら名前が伸びても大丈夫です.
誰もがクラス、メソッド、変数名を減らしたいという流行に夢中になっています.その誘惑を振り切ろう.
略語は混乱を引き起こし、より大きな問題を隠す傾向がある.
クラス名とメソッド名を1つまたは2つの単語に維持し、コンテキスト名の重複を回避するように努力します.
クラス名がOrderの場合、shipOrderの名前付け方法は必要ありません.
短いship()ならクライアントでorderです.ship()と呼ばれ、簡潔に呼び出される表現です.
:対象向けの生活体操原則5:省略しない(省略禁止)

空白もコード会議

if,for,whileゲート間の空白も符号化会議である.

空白線を有意義に使う

空白行を意味的に使用するのはよく見えますが、コンテキストの部分を分離するのに最適です.
過剰な空白は他の開発者に疑問を与える.

繰り返さないで

重複はソフトウェア内のすべての悪意の根源です.

space vs tab混用

スペースとtabをインデントに混用しません.両者の中で一つしか使われていない.
不確実であれば、pull requestを送信してインデントを確認する習慣をつけましょう.

無意味な注釈をしない

変数名、関数(メソッド)名で意図を示す場合は、コメントする必要はありません.
すべての変数や関数を注釈するよりも、できれば名前で意図を表す練習をし、意図を表現しにくい場合は注釈を練習します.

有意義なコミットメッセージの作成

コミットメッセージには、コミットで行われた作業を理解できるように記述されます.

機能リストの更新

README.mdファイルに作成された機能リストは、機能の実装に伴って変更される場合があります.最初は、すべての機能を完全にリストするよりも、機能を実装しながらドキュメントの更新を継続します.死んだドキュメントではなく、生きたドキュメントを作るように努力します.

機能リストの再確認

クラス設計と実装、関数(メソッド)設計と実装など、機能リストはあまり詳しくありません.クラス名、関数(メソッド)の初期値、戻り値はいつでも変更できます.
あまり細かい部分を整理するよりも、実現すべき機能リストを整理することに集中します.
通常は重要ですが、例外も機能リストに整理されます.
特に,例外は開始段階ではなかなか見つからないため,機能を実現しながら追加を継続する.

README.詳しくmdを記入する

タスク・リポジトリのREADME.mdは、ソースコードの前に、プロジェクトをプロジェクトとしてマークするドキュメントです.このプロジェクトがどのようなプロジェクトであり、どのような機能を持っているかを説明するために、ダウンスケール構文を検索して学習し、適用します.

IDEによるコード自動ソート機能

IDEのコード自動ソート機能を使用すると、よりクリーンなコードが表示されます.

IntelliJ IDEA : option++ command + L,

Eclipse : control + command + F

数字は使わない

magic numberは意味を表す定数(static final)に変換され、コードの可読性が向上する.

インプリメンテーションプログラムもエンコード会議

クラスは定数、メンバー変数、作成者、メソッドの順に作成されます.

class A {
  상수(static final) 또는 클래스 변수
  
  인스턴스 변수
  
  생성자
  
  메서드
}