(新人)エンジニアが開発しやすいREADMEの書き方2023年6月28日に開催された「Findy×freee」さんのコラボイベントに登壇した「新人エンジニアが入っているプロジェクトにおけるREADMEの書き方」の登壇スライドです エ…
ドキュメントを残さない
普段仕事をしてるとき、いろいろなことに気を使いながら仕事をしてると思う。たとえばissueには、その背景、やりたいことや期待する効果、制限事項、認識している副作用やリスクの情報等などを書くような運用ルールを作っているチームは多いらしい。しかし、私たちのチームではそういうルールはない。それでうまくいくんだっけっていう話をよく質問されるので、考えてみた。 コードの品質をカバーするためのコメント私たちは、常にわかりやすいコードを書けるとは限らない。解説として、コメントが役立つ場面はある。 ちょっと待ってよ「よし、Why notを書こう！」と言って上手く書けるのは、そうとうに経験を積んだ人だ。そして、経験を積んだ人は大体問題ない。悪いコードほどコメントが必要だが、良いコメントが書けるくらいならコードはもっと良くなってる。鶏と卵じゃん。 コメントについて議論する暇があったら、コードについて議論したほ
Ruby on Railsを使った開発で参照してもよいドキュメント - Qiita
記事中のURLや内容、特にRailsやRubyのバージョンについて古くなっていることに気づいた方はぜひ編集リクエストください。 この記事はOkinawa.rbのAdventCalendar 5日目の記事です。 YassLabの業務時間中にQiita:Teamに書き溜めたものを編集して公開します。 4日目は @siman さんの「今年作った gem の紹介 (2017)」でした。 明日は @fullkawa さんのFinOpsのはなしです。 背景 人数が増えたり参加プロジェクトが増えるにつれ以下のような変化がおきました。 同じソフトウェアのさまざまなバージョンを扱うようになった コードレビューをする人・される人が増えた 同じソフトウェアでもバージョンによってAPIや使い方が異なる場合があります。 また、人によっては参考にする情報源がバラバラになってしまい、ソフトウェアの開発者が提供しているド
Redmine で技術仕様書を書こう
はじめまして！ 株式会社 Aiming の土井です！ エンジニアをやっております！ 今回の開発者ブログでは、情報共有ツールとしての UML の活用方法について、現場での取り組みをご紹介させていただければと思います！ 技術仕様書の“図” どうやって書いてますか？ 株式会社 Aiming では、プロジェクトの Wiki やバグトラッキングに Redmine をメインに使っています。みなさんも既にご存知だったり、実際にバリバリ活用されていることとおもいます。 また、企画仕様書、技術仕様書などは Redmine の Wiki やエクセルに代表されるオフィススイート等を活用して作成しますが… 図の表現を求められるような仕様書を作る時に、どうやって作成しようか悩んだことはありませんか？ 標準ペイントソフトで頑張って作成 オフィススイートに含まれる、ドローツールを使って図を作成、画像吐き出し というケー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
