タグ

developmentとdocumentationに関するkenjiro_nのブックマーク (5)

  • ノーコードでアプリ内製進めるLIXIL、2万個超えでも「野良」を生まない仕組み

    LIXILはDX(デジタルトランスフォーメーション)を推進するため、米Googleグーグル)のノーコード開発ツール「AppSheet(アップシート)」を採用した。2022年7月29日時点で、2万個を超えるアプリケーションを内製し、このうち839個を番運用している。AppSheet活用の狙いについて、同社の岩﨑磨常務役員デジタル部門システム開発運用統括部リーダーは「(情報システム部門に該当する)デジタル部門が開発すべきシステムやアプリにフォーカスできるようにする」と語る。 LIXILがAppSheetを導入した背景には、デジタル部門の負荷増大があるという。「社内でデジタル技術の活用が進んだことにより、デジタル部門が社内の全ての案件に対応するのが難しくなってきている」(岩﨑常務役員)。そこで経営レベルで費用対効果の大きいシステムやアプリをデジタル部門が開発し、小さいものは現場が自ら開発する

    ノーコードでアプリ内製進めるLIXIL、2万個超えでも「野良」を生まない仕組み
  • 我々はいかにシステム開発におけるドキュメント腐る問題と戦えば良いのか

    フューチャーアーキテクト Advent Calendar 2017 の2日目です。 システム設計が大好きで大嫌いな皆さん、こんにちは。 突然ですが、皆さんはどのようにシステム設計における ドキュメント腐る問題 に立ち向かっていますか? … ドキュメント腐る問題とは、設計時に作成した各種ドキュメントがGoogle Driveやファイルサーバ上で陳腐化してしまい、現状の正しい状態を指していないことです。せっかく新規参画者がキャッチアップしようとしてもドキュメントが真実を示していないという怖いやつですよね。 今まで出会った一番辛いドキュメントは、PJ初期に作成したホワイトボードに書かれたラフスケッチの画像しか無かったところですね。まず字が汚いし、内容も最新版と微妙に異なっていました。新規参画者殺しにもほどがあると、ほんのちょっとだけ恨みました。 いやいや、ちゃんとサボらず整合性を取れよって?サボ

    我々はいかにシステム開発におけるドキュメント腐る問題と戦えば良いのか
  • 最近コード中のTODOコメントの書き方を工夫している - $shibayu36->blog;

    コード中に後でやろうと思って以下の様なTODOコメントを書くことがあります。TODOコメントというのは # TODO: 後でリファクタリングしたい ... # TODO: 投稿機能ができたら置き換えること ... みたいなやつです。 コード中にTODOコメントを気軽に書いてしまいがちですが、よくTODOコメントが放置されて気づいたらプロジェクト中に大量のTODOコメントが書かれたりすることがあります。直せる量を超えてくると、直すモチベーションも下がってきて、結局ただのコメントと同じ状態になります。 最近いろいろ工夫して、TODOコメントの書き方を変えたところ、そこそこうまく回ったのでメモしておきます。 TODOコメントの問題点 問題点として次のものがあると考えました。 (1) 書く人によって形式がバラバラ TODO, XXX, FIXMEなどバラバラだったりする (2) TODOコメントの

    最近コード中のTODOコメントの書き方を工夫している - $shibayu36->blog;
  • Makefileを自己文書化する | POSTD

    私たちのプロジェクトではいつも、非常に長い Makefile を使用して、インストールやビルド、テスト、デプロイメントの処理を自動化しています。ターゲット名はほとんど標準化されていますが( make install 、 make deploy )、中には説明が必要なものもあります( make run-dev 、 make restart-api )。そして、詳細なmakeターゲットを追加するほど、それらの処理内容をテキスト形式で大量に記載しなければなりません。私たちのプロジェクトでは通常、このような文書を README ファイルに書いています。 しかしCLI(コマンドラインインタフェース)を用いる場合は、主に自己文書化ツールを使っています。 make と打つだけで、利用可能なコマンドとその説明が一覧表示されたら便利だと思いませんか? それを実現するのは、実はとても簡単です。まずは各ターゲッ

    Makefileを自己文書化する | POSTD
    kenjiro_n
    kenjiro_n 2016/03/29
    makeのタグがなかった。
  • 保守開発に開発者として入って困ることのまとめ(実体験) - Qiita

    このページについて 保守開発にほぼ縁がなかったのですが、最近保守開発に携わわることも増えたので、そのまとめです。 普段のシステム保守に関わりはなく、業務知識がないエンジニアが、ある程度まとまった保守開発の案件発足時に開発専門でスポット対応したときに困ったことが書いてあります。 ここに書く困った事案について対応しておくと、スポット対応や保守PJで増員or要員入れ替えで新参者を迎え入れた場合に、新しく入った人が困ることは少なくなると思います。 ※保守開発の経験が増えて困った事案があれば、(愚痴にならないようにときにはネタを仕込んで面白おかしく)ここに書き足します。 ドキュメント周りで困ること 単語集がない 新規開発も同じですが、新参者に取ってPJへの途中参加は、日語以外が飛び交う海外に行くのと同じです。新参者は業務用語が判らないので、業務用語の単語集があると喜びます。 単語集の整備は軽視され

    保守開発に開発者として入って困ることのまとめ(実体験) - Qiita
  • 1