「技術的負債」への処方箋と「２つのDX」 - Qiita
はじめに 本稿は、日経クロステックにて筆者が昨年連載していた3回分の記事一部変更して1つにまとめたものです。 https://xtech.nikkei.com/atcl/nxt/column/18/01394/ 有料記事として配信されておりますが、無料でも閲覧できるようにということで日経クロステック様に許可を得てQiitaにも掲載しています。 第1回：技術的負債はなぜ生じるか。 第2回：ソフトウエア開発を「制御」する意外な処方箋 第3回：技術的負債への取り組みはなぜ「２つのDX」につながるのか。 第1回：技術的負債はなぜ生じるか。 年間12兆円ものマイナスの影響をもたらす技術的負債（あるいはレガシーシステム）はどのように生まれるのでしょうか。それを防ぐ方法はあるのでしょうか。第1回は、技術的負債をとりまく歴史をたどりながら、ソフトウェアエンジニアではない人にも理解できるようにその正体に迫り
可読性を高める2つの大きな方向性 - 脳内メモリに優しいコードを書く -
TL;DR 「可読性が高い」とは、「理解するために使う脳内メモリの量が少ない」ということである。 理解するために使う脳内メモリの量 = コードを理解するのに必要な情報量 - コードについての予備知識 「そのコード 1 行を単独で理解するのに必要な、追加の情報を意識する。その追加で必要な情報が減るようなコードにする」というのが可読性を高めるための一つの大きなの指針としてアリなのではないか。 はじめに 可読性についての細かい Tips は様々ありますが、「結局」何をどうすればいいのか？という漠然とした問いには答えられていない気がします。細かい Tips を包括する大きな指針をがないかと考え、まとめたのがこの記事です。 可読性の高いコードとは？ 脳内メモリの消費を抑える 可読性とは、コードが頭に入ってくる時のスムーズさと言えると思います。すなわち、いかに直感的に、余計なことを考えず、脳内メモリの
昔は苦手だったモブプロを今は推進する側になっていた - yasuhisa's blog
3~4年前はモブプロにめちゃくちゃ苦手意識があったんだけど、最近はなぜか(?)モブプロを推進していく旗振りをしている。モブプロの取り組み自体については今度会社のTech Blogに書く予定だけど、このエントリでは自分の心境の変化にフォーカスを当てる。人間、数年すると割と変わるもんだなぁと思って面白かったので、記録に残しておく。 モブプロが苦手だった頃 なぜモブプロしようとなったか 今はどうモブプロしているか 所感 モブプロが苦手だった頃 前職の開発チームにいた頃(3年前くらい)で、状況はこんな感じ。 7~8人くらいの規模の開発チーム 京都と東京でそれぞれメンバーは分かれているが、まだ物理出社している時期だったので、大きなディスプレイに写された自分の画面をみんなが見るスタイル 時間は60~90分くらいだったかな タイピストはガンガン交代するスタイルではなく、1回を1~2人のタイピストで回して
モブプログラミングに向いてない私の話 - 誰かの役に立てばいいブログ
新型コロナウィルスの影響も長引いてますが、皆さま無事お過ごしでしょうか。私は幸い無事です。 日ごろチームでソフトウェア開発をしているのですが、近年社内ではペアプログラミングやモブプログラミングが流行しています。 私のいるチームでもここ二年ほどモブプログラミング（ないし類似のプラクティス）に取り組んできました。 モブプログラミングについて正確にどのようなものかは以下の記事などをご参照いただければと思います。 簡単にまとめると、要求分析やコーディング等幅広い開発作業を、同じ場所に集まったチームの共同作業でこなしていくというものです。 このご時世ですので、最近はオンラインのミーティングルームに集合する形式でしたけど。 www.agilealliance.org ここから先は、非常にパーソナルな、私に限定された体験になります。 どの人・チームにも適用できる話ではありません。ではありますが、どの人・
実務でどんな git コマンドを使っているか振り返ってみる - Qiita
gitコマンドって実務でどう使うんだろう？ 独学の git コマンドを実務で使いまくり、最近やっとうまく運用できているように感じます。 そのうえで、git コマンドを勉強し始めた頃、「コマンドの説明はいっぱいあるけど、実務でどうコマンドを使うんだろう？」 と感じていたのを思い出しました。 そんな想いから、よく使う git コマンドを実務テイストで振り返ってみました。 本記事に書いていないもの 実務では使うのですが、諸事情により以下は省いています。 submodule 本当はこの記事に含めようかと思ったのですが、長くなりすぎてしまったので、需要がありそうだったら次回作に書こうかと思います。 プルリク コマンドの説明をしたいため、省きます。 Git Flow やら GitHub Flow やらの Flow 系の考え 説明がややこしくなってしまうので省きます。 developブランチ、maste
コードレビューで気をつけているいくつかのこと | Recruit Tech Blog
はじめに タブやスペースの数（インデント）とか変数名のセンスだけを指摘してコードレビューしたぜ！となっていいのは小学生までと言われています[要出典]。このエントリでは主にScalaをターゲットにして、どういうところに気をつけると効果的にレビューできるのか？について僕の個人的な経験に基づきつつ紹介しようと思います。 こういうコードがでてきたら、これは慎重に見るべきポイントだな！というのを紹介していきます。コードの全てのを見ていくのは非常に大変なので、こういう気になるところだけ見るような形にしています。また、このエントリではサンプルコードとしてScalaを利用してます。 型Aをとって型Bを返す関数 こう言われるとやや謎かもしれないですが、たとえば次のような関数です。 def toInt(str: String): Int = ??? // 実装があるとする こういう関数があったら、僕は脳死で次
保守性・可読性の高いPythonコードを実装するためにはどうすればよいか - はてなの金次郎
はじめに コードは理解しやすくなければいけない。 リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) 作者:Dustin Boswell,Trevor Foucher発売日: 2012/06/23メディア: 単行本（ソフトカバー） コードの保守性や可読性を高めるために我々エンジニアはどんなことができるでしょうか？ テストを書く 推奨されているコードスタイルに準拠する コメントを書く DRY原則に則る 変更・拡張しやすく設計する ログを出力する・監視する 適切な命名をする etc... まだまだ意識すべきことはあると思いますが、上記の項目はエンジニアであれば恐らく一度は目にしたことがあるような内容であり、暗黙的に了承されたいルールです。 しかし、これらはただの心構えであり、体現するために実際には以下のような項目に落とし込む必要
チームで成長！ 〜モブプロはじめました〜 - SmartHR Tech Blog
こんにちは、エンジニアのりさきゃんです！ 最近、開発チームでモブプログラミングという開発手法を取り入れました。この記事では、モブプログラミングをすることになった経緯と実際やってみて感じたメリットを紹介したいと思います。 モブプログラミングのきっかけ おかげさまでエンジニアの採用もうまくいきはじめ、下半期は合わせて7名のエンジニアが開発にジョインしました。🎉🎉🎉 (※ まだまだ募集中です! ) 様々なレベルのメンバーが入社する中、安定的に機能開発をしていくためには Rails のレールに乗った開発を続けていくことが大切です。 SmartHR では Ruby on Rails プロダクトの開発を望ましい状態のまま続けていくことを目的として、2018年7月に技術顧問の willnet さんをお招きしました。willnet さんにはペアプログラミングを通じてRuby on Rails 開発の
Angular中〜大規模アプリ設計 // Speaker Deck
All slide content and descriptions are owned by their creators.
Androidアプリを長く開発し続けるために気をつけている9個のルール - ZOZO TECH BLOG
Androidエンジニアの @nissiy です。Androidが発表されてからもうすぐ10年になろうとしています。長いですね。 実はAndroid版IQON、今年の4月でリリースしてから丸5年を迎えます。ここまで長くサービスを続けられて、かつ3年連続でベストアプリをいただけたのは、使ってくれているユーザーの方々のおかげであると日々感謝しています。 この5年で様々な追加機能の開発を行ってきました。新機能を1つ追加する度に、古い機能を1つ削除することを徹底して開発を進めてきたものの、長く開発を続けているのでそれなりに巨大なアプリになっています。 今回はAndroid版IQONを長く開発し続けるためにチーム内で徹底しているルールをいくつか紹介したいと思います。 当たり前な話ばかりですが、大きくOSのアップデートを繰り返すAndroidのアプリ開発に取っては大事な話ばかりですので、少しでも参考に
フロントエンドエンジニアがサーバーサイドエンジニアとペアを組む話 - Qiita
この記事は freee Engineers Advent Calendar の1日目です。 こんにちは。freee株式会社でフロントエンドエンジニアをしている @ymrl です。freeeでは給与計算freeeの開発をしています。 僕はフロントエンドエンジニアを名乗っていますが、実際はサーバーサイドの開発もしています（freeeではフロントエンドとサーバーサイドの担当に線引きをしていません）。しかし自分としてはフロントエンドのほうが得意だし、UIを作るのが心底楽しいし、サーバーサイドに比較的苦手意識を持っています。 今日はそういう状態の僕が、どういうふうに開発しているかという話をします。 技術に自信がないのでペアを組んだ 給与計算freeeの開発チームでは、ひとつの機能を開発するときに エンジニアのペア制 というのをとっています。 かつて僕が給与計算freeeのチームに異動してすぐの頃、僕
マイクロサービスで不可欠、作業効率化ツールを使い倒せ
システムを「小さく」作る設計手法であるマイクロサービスを企業システム分野で採用する機運が高まっている。前回（業務分野でマイクロサービス採用の機運高まる、狙いは「変更の速さ」）は、マイクロサービスの利点と課題を中心に解説した。 マイクロサービスを採用すると、システム変更の影響が小さくなり、改修しやすくなるメリットが得られる一方、小さなアプリ（サービス）の集まりとしてシステムを実現するので、そのぶん運用の手間がかかる。 業務システムをマイクロサービス型で実現する場合は、運用を効率化するためにツールを使い倒す姿勢が欠かせない。今回は、作業効率化ツールと使い方を中心に見ていく。 CIツールは「共有」が前提 作業効率化ツールとして、まずCI（継続的インテグレーション）ツールが挙げられる。CIはアプリの構築とテストを繰り返す開発手法のことで、CIツールはこれらの作業を自動化するものだ。OSS（オープン
プログラマーの強い味方！国内で代表的なソースコード共有サービス5選
プログラミングをしていて、「なぜ動かないんだろう」「同じことをしたくてもコードが分からない」ということはプログラマーなら一度は経験しているのではないでしょうか。 そんな疑問を解決するサービスが「ソースコード共有サービス」です。国内外のプログラマーが様々な言語のソースコードをインターネット上に共有し、協力して開発していくこともできます。 これによって開発者同士の協業を可能にし、開発のスピードアップや完成物のクオリティの向上にも繋げることが可能です。 今回は実際の開発現場の問題・課題を解決する手段としてソースコード共有サービスがいかに有効か、そしてサービスにはどのようなものがあるのかをご説明します。 このニュースを読んだあなたにオススメ baseタグ、styleタグ、linkタグの使い方 知らなきゃ損！パソコン上でホームページのモバイルでの見え方を爆速でチェックする方法 本当に使えるコーディン
デザイナーが書くコードについて思うこと（1） | ツクロア - DESIGN LAB
あらためてなるほどな、と思えるいい記事でした。 【これからのスキル】デザイナーとエンジニアの境界線がどんどん無くなる | freshtrax | btrax スタッフブログ 自分にも重なる部分があると思って経験と雑感込みで書いてみた、毎週水曜更新のデザインラボbyツクロア、今週私のターンではデザイナーがコードを書く意味についてです。 一枚絵では通用しないアプリデザイン 某携帯電話メーカーからAndroidアプリデザインの依頼があったときの話です。 電話着信画面や起動直後の待受ロック解除のデザインを含め、使い心地や操作感から画面構成まで一緒に考えてもらえるデザイナーを探しているということでした。 担当者いわく「静止画だけではアプリデザインの良し悪しが決められないんですよ」という話から始まり、では「実際うごくデザインモックを作りながら一緒に考えましょう」という作業の流れを提案して検証からリリー
やさしいPHPコーディング規約の導入・完全版 - コネヒト開発者ブログ
はじめに こんにちは、社内でコーディング規約おじさんと呼ばれ始めて久しい高野(@fortkle)です！ ここ2ヶ月間ほどに渡って通常の開発業務とは別に社内のアプリケーションにコーディング規約を導入する試みをしており、PHP7 Casual Talks や PHP BLT などのPHP関連の勉強会で都度共有してきました。 今回はそれらをまとめ、共有したいと思います。興味のある方の参考になれば幸いです。 開発効率を阻害するもの 弊社が運営している ママリjp、ママリQといったサービスが順調に成長していっている中、その成長を支える開発チームの人数も少しずつ拡大しています。今後もこの流れは続くと思いますが、エンジニアたるものそういった場合でも「コードの質」は落とさずに成長させたいものです。 弊社では非常に丁寧にコードレビューを実施していますが、質の高いコードを維持し続けるためにはコードレビューをよ
ちょっとしたペアプログラミングに便利そうな『Code Coach』 | 100SHIKI
シンプルでいいかも。 Code Coachではちょっとしたペアプログラミングに使えそうなツールを提供している。 使い方は簡単で、URLの後ろに適当な文字列をくっつけてそれを共有すればいい。 ビデオチャットとも連動しているので話ながら指導ができていいのではなかろうか。 なお普通のエディターばりにショートカットが用意されているのも好感がもてる。 実行環境がないのが微妙ではあるが、知っておいてもいいかもですね。
プログラミングスタイルガイドのスタイルガイド - Qiita
本文書は、プログラミング言語向けのスタイルガイドに向けたスタイルガイドである。 本文書へのフィードバックはQiita上のコメントにて受け付ける。 構造 対象を明確にする そのスタイルガイドがどのような状況のどのような対象に向けたスタイルガイドであるか規定すること。 状況や対象は広すぎてはならない。 理由: 対象はスタイルガイド記述者には自明かもしれないが、似て非なる言語に誤用されたり、特定分野のアプリケーション向けスタイルガイドが他分野のアプリケーションを理不尽に拘束したりすることがある。これを防ぐべきである。 良い例: 「本文書はRuby on Railsアプリケーション向けのスタイルガイドである」 「本スタイルガイドはX社におけるRubyプロジェクトに適用すべきスタイルを規定する」 悪い例: (何も書かない) 「本文書はX社におけるすべての開発に適用される ... 述語メソッドや述語関
チームにとってのリーダブルコード - pixiv inside [archive]
株式会社クリアコードさんにご協力いただき「リーダブルコードワークショップ」が行われました。 ピクシブ株式会社からは7名、永和システムマネジメントさんからは1名が参加した合同ワークショップです。 このワークショップを通して、 通常のレビューでは良くない部分ばかり見てるけど、良い部分も共有しよう。 コミットメールを受信して、push式でコードを読む習慣をつけよう。 といった、チームにとって読みやすいコードを書くための方法を実践形式で学びました。 その詳細についてご紹介します。 ワークショップ開催までの経緯 SEゼミにてクリアコード須藤さんから弊社リードエンジニアedvakfにワークショップについてのお話をいただき、人数や構成などが対象として適しているチームが弊社にあったため話が進んでいきました。 そのチーム(BOOTH&pixivFACTORYチーム)では 開発メンバーの入れ替わりによってベテ
![チームにとってのリーダブルコード - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/25ec32188ad8eb3043bc5cb87cb9e23fc5409184/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fm%2Fmoyashipan%2F20150811%2F20150811174853.png)
技術的負債について考えた - 考えた。
技術的負債についての自分の考えをまとめます。 言いたいこと 最初から綺麗なコード・設計を書ける状態を目指せ。 そうもいかないものは天秤だが、勝手に背負うな。 技術的負債とは？ 技術的負債は事業リスクです。放置することによって事業が失速したり損害が発生したりするため、適切に取り扱う必要があります。 負債の種類と対応は、以下の三つに別けられると自分は考えています。 1. 新規で書く末端機能のクソコード・クソ設計 最初から綺麗なコード・設計を書けるを目指すべきですが、時間がかかるのであればスピード重視でよいでしょう。 「もっと良いように書けるべきだけど、どうすればよいか？」とコメントでも添えて、さっさとプルリを投げてしまうべきです。 末端機能で、あとで上に乗っかる物がないのであればコードの品質はそれほど問題ではありません。テストを整備しておけば、後でレベルが上がったときに綺麗にできるでしょう。
ソーシャルコーディングの時代に置いてはエンジニア以外もレポジトリ（GitHub等）を見るべき : D-7 <altijd in beweging>
ソーシャルコーディング時代の非技術者と技術者の関わり方についてちょっと考えをまとめたい。なお、これは「技術によって実現されるなにかをベースに商売をしている団体」という前提のもとで書く。たまたまインフラの一部にGitHubを使っているとかそういうのはここに含めない。また、大きめの企業・団体では数の利をいかしてなんとかこのあたりを解決できてしまったりするので、それもここでは含めない。 昔々、自分がメーカー系の会社に勤めていた頃バグトラッカーやレポジトリ（Perforceだった）などにエンジニア以外の人を入れるのは御法度だった。技術者側からの「わけのわからん注文をされる」「話がかみ合わない」など、納得の理由もある。なにより技術的な素養をもたない人達にとってはこれらのツールを使いこなすことが難しく、閲覧することさえなかなかかなわなかった。こちらもごもっとも。 が、21世紀に入って10年以上過ぎてい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
