回答編集履歴
3
git blame
answer
CHANGED
@@ -19,4 +19,10 @@
|
|
19
19
|
- githubなどに上げて公開する
|
20
20
|
- ブログに紹介記事を書くようにする
|
21
21
|
- パッケージ管理がある言語ならそれに公開する
|
22
|
-
- サンプルを書く
|
22
|
+
- サンプルを書く
|
23
|
+
|
24
|
+
---
|
25
|
+
|
26
|
+
さらに追記
|
27
|
+
|
28
|
+
gitでソースコードを管理してかつコミットは粒度を細かくしておいてかつコミットメッセージをWHYがわかるように書くと、**git blame**をみて「なんでこんな実装にしたんだっけ」というのがわかって良さそう。他人が書いたコードを見るときにもgit blameはそれなりに見ているのでコミットが適切にされていないとすごく困る。
|
2
友人曰く
answer
CHANGED
@@ -10,4 +10,13 @@
|
|
10
10
|
追記
|
11
11
|
|
12
12
|
- 標準ライブラリのクラス/関数群をよく知る(普段使ってないもので有用なものはきっとたくさんある)
|
13
|
-
- デファクトスタンダードとなっているライブラリがあればそれもよく知る(C++ならboostとかEigenとかとか)
|
13
|
+
- デファクトスタンダードとなっているライブラリがあればそれもよく知る(C++ならboostとかEigenとかとか)
|
14
|
+
|
15
|
+
---
|
16
|
+
|
17
|
+
友人曰く
|
18
|
+
|
19
|
+
- githubなどに上げて公開する
|
20
|
+
- ブログに紹介記事を書くようにする
|
21
|
+
- パッケージ管理がある言語ならそれに公開する
|
22
|
+
- サンプルを書く
|
1
m
answer
CHANGED
@@ -3,4 +3,11 @@
|
|
3
3
|
- 標準ライブラリの作法になるべく合わせる
|
4
4
|
- 標準ライブラリの今後の動向を把握し、それに沿う関数/クラスを作る
|
5
5
|
- **そもそも自分で書かない**、すでにあるライブラリを使う
|
6
|
-
- **テストを書く**
|
6
|
+
- **テストを書く**
|
7
|
+
|
8
|
+
---
|
9
|
+
|
10
|
+
追記
|
11
|
+
|
12
|
+
- 標準ライブラリのクラス/関数群をよく知る(普段使ってないもので有用なものはきっとたくさんある)
|
13
|
+
- デファクトスタンダードとなっているライブラリがあればそれもよく知る(C++ならboostとかEigenとかとか)
|