ソフトウェアドキュメント作法 - maru source
こんにちは丸山@h13i32maruです。つい先日、devchat.fmというポッドキャストに出演して、「ドキュメント」というお題について話しました。なぜこんなニッチなお題について話したかというと、Ubie Discoveryに入社して5ヶ月の間にいくつか*1まとまったソフトウェアドキュメントを書いたので、自分の中でホットな話題だったからです。 #devchatfm 33回目は、Ubie DiscoveryのSWE @h13i32maru にドキュメントを書くことで得られるメリットや、ポイント・工夫などを聞きました！ #33 チームの生産性を上げるドキュメントのすすめ with@h13i32maruhttps://t.co/TrmZd13D91— 久保 恒太 / Ubie CEO (@quvo_ubie) 2021年8月12日 これらのドキュメントは個人的にわりと良く書けたと思ってますし、
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
ソースコードは設計書であり、コーディングは設計作業である - Qiita
だから意味のない旧来の「詳細設計書」は消えてほしい、というお話。 前提 現場によって、いろいろと粒度や定義が異なるとは思いますが、この記事における旧来の「詳細設計書」とは、ソースコードに書くべき内容を日本語に書き下したものであったり、その「設計書」通りにソースコードを書けば正しいプログラムになることを前提にしている何か、のことを指します。 標記の件について 今さら私が主張するまでもなく昔から言われ続けていることではあります。 ささっとぐぐれば、いろいろな記事が出てきますし（以下は一例） 詳細設計書という名のゴミ | Gm7add9 「コーディングは設計か製造か」という考え方の違い - 人生は長い暇つぶし。 古くて著名なところでは、たとえばマーティン・ファウラーとか。 主張 なぜそのようなものが生まれるのか？ 経験上からは、やはりソフトウェア開発を「モノづくり」に当てはめている現場ほど「詳細
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
