[B! 開発][ドキュメント] koma

Androidアプリ開発でAPIのリファレンスを参照する方法【初心者向け】

Androidアプリ開発で【APIのリファレンス】を参照する方法を初心者向けに解説した記事です。「Androidデベロッパーサイト」で確認する方法と「Android Studio」で確認する方法の2つがあるので、1つずつ紹介していきます。テックアカデミーマガジンは受講者数No.1のプログラミングスクール「テックアカデミー」が運営。初心者向けにプロが解説した記事を公開中。現役エンジニアの方はこちらをご覧ください。 ※ アンケートモニター提供元：GMOリサーチ株式会社　調査期間：2021年8月12日～8月16日　調査対象：2020年8月以降にプログラミングスクールを受講した18～80歳の男女1,000名　調査手法：インターネット調査 Androidアプリを開発していると、使用しているAPIの引数や戻り値、対応しているAPIレベルなど、確認が必要な場合あります。そこで、Androidアプ

koma_g 2023/05/11

リンク

安全安心にソフトウェア開発を行うためのDesign Doc導入ガイド｜面川泰明

みなさん、コードを書く前に設計書を書きますか？書くか書かないかは人それぞれだと思いますが、「設計」というプロセス自体は意識的であれ無意識的であれエンジニアであれば全員やっていることだと思います。今回は設計プロセスの改善という文脈で私たちがDesign Docという仕組みを導入したことについて共有しようと思います。もし同じような状況を経験している人がいたら参考になれば幸いです。導入の背景まずは導入するに至った状況からお話します。私たちのサービスは、利用していただくユーザーの数が増加しています。それに伴って品質のハードルも上がってきました。サービスに障害が発生するとユーザーさんに大きな損害を出してしまうことになるからです。そこで今まで以上に安全にサービスを開発できる仕組みづくりが必要になりました。ですが、実現のためには大きく2つの課題がありました。課題1. 開発スピードが徐々に鈍化し

koma_g 2022/09/26

リンク

プログラミングファースト開発の必要性 - ひがやすを技術ブログ

ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。動

koma_g 2022/03/04

リンク

ソフトウェアドキュメント作法 - 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日これらのドキュメントは個人的にわりと良く書けたと思ってますし、

koma_g 2021/08/15

リンク

プログラムの「アーキテクチャに関するドキュメント」は面倒でも書くべき、ではどのように書くべきか？

開発プロジェクトに新しく加わった時は、まずプロジェクトの理解が第一。しかし、全体像を把握できるようなドキュメントがなく、コードから断片的な情報をかき集めるしかない場合もあります。新参の開発者がスムーズにプロジェクトを理解できるよう、大規模なプロジェクトでは「プロジェクト全体のアーキテクチャ」を示した「ARCHITECTURE.md」を添えた方がよいと、エンジニアのAleksey Kladov氏が指摘しています。 ARCHITECTURE.md https://matklad.github.io//2021/02/06/ARCHITECTURE.md.html Kladov氏はオープンソースプロジェクトの開発に携わる中で、「プロジェクトのアーキテクチャに対する知識量」によって開発スピードに大きな差が生じると気づいたとのこと。アーキテクチャに関する知識がない開発者にとって、大量のコードは「バラ

koma_g 2021/02/11

リンク

開発者が考える提案書テンプレート markdown版 - Qiita

概要定型的なシステム開発では以下のような設計書が使われる。システム要件定義システム方式定義ソフトウェア要件定義ソフトウェア方式設計ソフトウェア詳細設計しかしそれ以前に開発者目線、開発者発信で顧客に提案する概要資料を作りたいケースがある。あるいは就職活動時の自身のポートフォリオを採用担当に説明することも同様かもしれません。オードリー・タンがコード書く前にまずreadme.txtを書く話、Yahoo!がプロダクト開発の最初にプレスリリースから作る話、自分が前職で商品企画する際にまず広告から考えていた話、どれも明確なゴールイメージをまず確定させて必要要件を定義していくという意味で全部共通の考え方 — 菅俊一 / Syunichi SUGE (@ssuge) February 2, 2021 なんて話も。技術とマーケティングのちょうど中間、開発者と顧客との意思疎通の橋渡し

koma_g 2021/02/04

リンク

ドキュメントを書くときの「メンタルモデルの原則」 - クックパッド開発者ブログ

こんにちは。クリエイション開発部の丸山@h13i32maruです。みなさんドキュメント書いてますか？私はドキュメントを書くのは結構好きです。最近もプライベートで開発しているJasperというGitHub用Issueリーダーのユーザ向けドキュメント（マニュアル）を書きました。でも良いドキュメントを書くのって難しいですよね。そこで、本記事では「ツールやライブラリなどを対象にしたユーザ向けドキュメント」を書くときに私が考える原則を紹介します。ちなみに私はテクニカルライティングの専門家ではなく、普通のソフトウェアエンジニアです。そのあたりはいい感じに汲み取っていただけると🙏 🕵️メンタルモデルの原則良いドキュメントとはどのようなものなのでしょうか？私は「そのツールやライブラリに対して読者がメンタルモデルを構築できる」のが良いドキュメントだと考えています。これを「メンタルモデルの原則」と呼