Spring Bootアプリケーションのコードレビューポイント - Qiita
リクエストの入り口になるのはControllerになるため，初めてSpringを触る開発者の方も馴染みに深いと思うのですが，何も考えずにアプリを作っていくと，ついついControllerにビジネスロジックを実装してしまいがちです。そうすると，所謂保守性や可読性が低いFat Controllerが出来上がってしまうので，ビジネスロジックの隔離は強く意識したいポイントだと思います。 個人的にはそれぞれ以下の内容に徹するのが良いのでは？という考えです。 Controller リクエストの受付 リクエストパラメータのValidation Serviceの実行 例外処理 レスポンスの作成 Service ビジネスロジックの実行 外部サービスとの連携 Repositoryを介したデータ操作 トランザクション管理 Repository データ操作 Controllerの中で複数種類のServiceを呼び
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム（16年の歴史があります）の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
Androidソースコードレビューで指摘する事が多い項目まとめ2 - こやまカニ大好き
去年Androidソースコードレビューで指摘する事が多い項目まとめという記事を書いた時はアプリ全体を一度に見るような機会が多かったため、内容も大きめのものばかり書いていましたが、最近はプルリクエスト単位でレビューする機会が増えたので細かい項目についてまとめてみようと思います。 ミリ秒で時間を指定する時に自前で計算している 1000L * 60L * 60L * 24Lのようなコード。 TimeUnitを使いましょう。 24時間の場合は以下のように書けます。 TimeUnit.DAYS.toMillis(1L) ある文字列がhttp/httpsで始まるかチェック URLUtil.isNetworkUrl()を使いましょう。 ただしequalsIgnoreCaseで判定してます。 ベースURLにパラメータを付与していってURLを生成したい StringBuilder#append("&key=
Androidソースコードレビューで指摘する事が多い項目まとめ - こやまカニ大好き
業務でソースコードレビューを行う機会が増えたので、複数回指摘した項目や気になった実装などをまとめてみました。 こういう観点をできる人と共有できるといいなあ…。 2014/09/29 23:00 一部修正しました。 業務上ソースコードレビューの名目で仕様・デザインまで見ることになっていたためこれらを先頭に書いていましたが、わかりづらかったため最後にまとめました。 Fragment関連 FragmentとActivityの密結合 Fragmentが特定のActivityから呼ばれることを想定して書かれている場合、そのFragmentとActivityは密結合である場合が多いです。 具体的には、以下の様な実装です。 ActivityのViewを参照する Activityのメソッドを直接呼び出す なぜダメか Fragmentの利点のひとつは優れた再利用性にあります。 Fragmentが特定のAct
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
一つのメソッドに上から下にずらっと全部書いてしまう現象の考察 - basyura's blog
とある機能を実装するとする。例えば外から Excecute が呼ばれてその結果を返すような場合。多いのが Execute メソッドの中に全部書いてしまって、何 10 行を超えて何回スクロールするんだろうになっているパターン。その際はレビューで以下のようにアドバイスする。 Execute にはシナリオを書いて、中身は別に書くと良いですと。僕の経験的にこの方が良かった、という深い根拠のないものではある。けど、間違った考えとも思わない。自然だろうと。private なメソッドではインスタンス変数を直接扱うのはやめて、public なめそっどから引数で渡したほうがいいとか細かいところもあるけど、そのへんはすっ飛ばしてまずは上記のようにいう。 そんな考えを持っているので、レビュー依頼されたものやコミット済みの資源をなにかの機会で見たときに、上記に反するものを見かけると気になってしまう。 もうちょっと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - SecureSkyTechnology/study-struts2-s2-054_055-jackson-cve-2017-7525_cve-2017-15095: Struts2の脆弱性S2-045, S2-055 および Jackson の脆弱性 CVE-2017-7525, CVE-2017-15095 の調査報告
https://blog.ik.am/entries/138