Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
こんにちは、クライアントエンジニアの@kobakeiです。元々KyashのAndroidアプリを立ち上げから担当しており、昨年末よりiOSアプリを開発しています。 Kyashは3/5 (月)に初のメジャーバージョンアップとなる2.0.0をリリースし、大幅にデザインをリニューアルしました。実はiOSチームはそれよりも前、昨年末から大幅なアーキテクチャの見直しとリファクタリングを並行して行っていました。今日は皆様にその裏側をご紹介したいと思います。 当時のiOSアプリが抱えていた課題 KyashのiOSアプリは2017年の4月にリリースされましたが、開発期間は意外に長く2016年2月に最初のコミットがGitHubに入りました。そこから様々なスクラップ&ビルドやiOSチームのメンバーの増減を経てリリース、そして現在に至るのですが、その結果「品質が安定しない」、「普段の開発効率が上がらない」という
ピクスタ開発部で毎日ヒィヒィ言いながらエンジニアをやっております @muramurasan です。 今回はPIXTAのとあるリポジトリにおいて、未使用のメソッドを削除しようとした際、gemを組み合わせることで、効率的かつ安全に削除することができたという話をしたいと思います。 よくやる方式 外部の勉強会などで、「未使用のメソッドを削除する際にどうしているか?」ということを聞いた際、よく聞くのが「未使用らしきコードを見つけ次第、ロギングを行うメソッド呼び出しを挟み込んでいく」というものでした。 この方式は、動的なメソッド呼び出しにも当然対応できますし、お手軽なので、一般的に好まれているようです。 問題点 ただし、この方式では以下の問題点があると私は考えています。 そもそも、未使用らしいメソッドを見つけるのが大変 プロダクションコードを汚してしまう これらの問題を解決するために、PIXTAでは
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
アプリケーションエンジニアの id:funnelbit(北村) です。先日 DroidKaigi 2017 で「大規模アプリのリノベーション」というタイトルで発表させていただきました。 speakerdeck.com 大まかな内容としましては以下のようなものです。 1. ドメイン知識を得る まずは現状のアプリケーションの解析からスタートします。実装済みの画面を洗い出し、現状を把握します。各画面や View に正しい名前付けを行います。 2. ライブラリと設計を決定する 次にライブラリ、設計を決定します。はてなブックマークの Android 版では MVVM を採用しています。また Repository, Interactor, ViewModel, View といったレイヤー分けを行っています。この設計につきましては様々な議論があるところかと思います。これが唯一無二のものであると主張するつ
Sansan tech meetup #1 モバイルアプリ編 https://sansan.connpass.com/event/48510/ 発表資料Read less
現在絶賛開発中のkirimoriですが、なんとGolang界隈で有名なmattnさんにリファクタリングをして頂くという、とても嬉しい事態がありました✨ kirimoriについてはこちら↓ syossan.hateblo.jp リファクタリング前提でかなり雑に書いていたのですが、めちゃくちゃ良い感じにコードを直して頂けたので自分の勉強のために読み解いてみます👏 リファクタリング前 kirimoriは以下の機能を有しています。 initコマンドでkirimoriの設定ファイル(toml形式)を作成します addコマンドでコマンドライン引数に指定したプラグインを追加します removeコマンドでコマンドライン引数に指定したプラグインを削除します listコマンドでプラグインの一覧を表示します で、構成的には kirimori.go に全てのコマンドの処理をベタ書きにしてある感じになっております
メリークリスマス!!この記事は、はてなエンジニアアドベントカレンダー2016の25日目の記事です。昨日は id:tarao による 開発速度と品質のトレードオフの判断基準の合意 でした。 僕は id:funnelbit と言う者です。はてなでは Android アプリを担当しています。 突然ですが、ソフトウェアというものは腐ります。腐るというのは、メンテナンス性が失われたり、機能追加が困難になってくることを指します。原因は複雑なコードが絡み合ってしまったり、ライブラリのバージョンが古すぎたり、もはや世間では時代遅れのライブラリをつかっていたり等です。特に長期間問題を放置すれば腐りやすくなります。 こうなってくるとエンジニアとしてはリファクタリングを考えるようになります。リファクタリングには規模の大小があり、リネームやモデルの修正程度で済むものから、アプリ全体の設計を変更せざるを得ないケース
みなさんもきっとそうだと確信いたしておりますが、プログラマというのは、どういうわけか実装のちょろまかしには頭がまわるもので、今や丁寧なコードを書く人の鏡とまで言われるワタクシも、それはそれは手抜き方法ばかりうかんだものでした。 技術的投資のいくつかは、不本意ながら技術的負債になりまして、いろいろと世間様にもご迷惑をおかけした次第です。みなさんもきっとそうだと思いますが。 この話は、そんな「誰にでもある」小さな事件のひとつです。1 この記事は CrowdWorks Advent Calendar 21 日目の記事です。 昨日は @tmknom さんの 「アプリケーションアーキテクチャに関するポエム」 でした。 設計に関するトピックは幅広く、かなり広範な知識が求められますよね!早く DDD を読まねばという気分になりました(笑)。 さて、この記事は、著者がここ1年ほど携わった簡単なデータ構造の
Webアプリケーションのコードも歴史的経緯から歪な形へとなっていくもの。 私の担当しているサービスでは同じPEARライブラリが重複を気にせずたくさん入れられ、 一筋縄では解けないほどの複雑なファイル依存関係が出来上がりました。 一度ハマってしまえば二度と抜け出せない底なし沼のような依存関係を解…
はじめに 先日、とある知りあいのRubyプログラマからこんな相談を受けました。(内容はちょっとボカしてます) 社内のコードレビューでもっときれいなコードを書けるようになった方がいい、と言われました。 「きれいなコードを書けるようになれ」と言われても、具体的にどうすればいいかわかりません。 伊藤さんのアドバイスを聞きたいです。 この内容だけだとどんな問題があるのかわからないので、実際に指摘を受けたRailsアプリのコードを見せてもらいましたが、確かに「もうちょっと頑張りましょう」と思うような点がチラホラありました。 ただ、具体的にどうすればいいの、という答えは一言では言えません。 というわけで、今回のエントリではこの悩みを解決するのに参考になりそうな話をあれこれ書いてみようと思います。 (その前に)もくじ かなり長い記事になってしまったので、先に目次を載せておきます。 はじめに (その前に)
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #経緯 casyというインターネットを使って手軽に家事代行を頼むことができるサービスのプログラマをしています。 Webだけでなく、スマホアプリも出すことにあたり、Webアプリサーバ(Rails)から機能を切り出し、APIサーバ(Rails)を別途作成し、Webアプリの場合はWebアプリサーバからAPIサーバを呼び出し、アプリからは直接APIサーバを呼び出すような仕組みにしました。 ただ、全部の機能をAPIサーバに移すのは容易なことではなかったため、いくつかの機能はまだWebアプリサーバに残っていて、アプリよりもWebのほうが機能が多い状
こんにちは。Airシリーズ開発チームでiOSの開発リードを担当している永井です。 この度、Airレジから予約台帳機能を切り出して、Airレジとレストランボードの2つのアプリとして新たに5/10にリリースしました。 iPad版・iPhone版合わせて181,175行あったAirレジですが、今回内部的にもObjective-CからSwiftに全面的に書き換えています。 まだまだリファクタリングしていきたい課題はありますが、コード行数は70%も減り(つまり元々の行数から30%になりました)、SonarQubeで示される技術的負債も500dから21dに減り、かなり成功したと言って良いのではないかと思っています。 今回の取り組みの中で、良かったこと・再検討したいことがいろいろ発見できました。それらについてまとめてみるので、これからSwift採用を検討している方々の参考になれば幸いです。 取り組みのポ
ステップ数で評価が決まる現場では全く役に立たないテクニックではありますが、ソースコードの減らし方について紹介したいと思います。 開発Div. エンジニアのayasudaです。 2014年の夏にジョインし、会社名と同じサービス、クラウドワークス の開発に携わっています。 ご覧の通り、消したソースコードの方が多いので、ステップ数換算だとマイナスの働きしかしてませんね! 本記事では、特に Ruby on Rails の運用されているプロダクトコードにおける、ソースコードの減らし方について紹介していこうと思います。 基本的な考え方 ソースコードを減らすときの大原則は「ボーイスカウト・ルール - プログラマが知るべき97のこと」です。 普段、ソースコードを触るときに、一つでも良いので簡単な改善を入れる。これを積み重ねるのが大事です。 一度に一気に直そうとするのはあまり良くありません。大抵の場合、デグ
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、ヤフーでiOSアプリを開発している林です。 私が関わっているYahoo!ショッピングでは、iOSアプリをObjective-CとSwiftの混在状態で開発しています。今年の6月末からこのスタイルに切り替え、新規で書くコードは原則Swiftを使い、徐々にObjective-Cで書かれたコードを減らしている状況です。一方で完全にObjective-Cのコードを捨てることは現実的でないとも考えており、混在状態がこの先もしばらく続く想定でいます。 Yahoo! JAPANのアドベントカレンダー14日目は、この形に至った経緯・開発の進め方・そこから得られた知見を共有したいと思います。 プロジェクトが動き出すまでの経緯 Yahoo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く