並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 15 件 / 15件

新着順 人気順

リーダブルコードの検索結果1 - 15 件 / 15件

  • テストコードにはテストの意図を込めよう #vstat

    リーダブルなテストコードについて考えよう~VeriServe Test Automation Talk No.3~で発表した資料です。 【発表資料中のURL】 ※複数ページで出てくる場合は、初出のページ数に掲載 ◆P7 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03 ◆P17 リーダブルテストコード / #vstat ◆P43 見てわかるテスト駆動開発 ◆P46 JaSSTレポート(過去のJaSSTの講演資料などが載っています) ◆P47 Agile Testing Condensed Japanese Edition ◆P48 A Practical Guide to Testing in DevOps Japanese Edition ◆P49 The BDD Books - Discovery (Japa

      テストコードにはテストの意図を込めよう #vstat
    • リーダブルコード by DDD / Readable Code by DDD

      リーダブルコード by DDD モデリングを起点に可読性の高いコードを実現する

        リーダブルコード by DDD / Readable Code by DDD
      • 「コメントは書くな」 - Qiita

        同僚だったロシア人のMはとにかくすごいエンジニアで、給料について社長ともめていたかと思えば、スーパーデプロイシステムを一人で作り上げていたり、Python推しの会社の中で、各所を説き伏せてTypeScript on node.jsの導入を進めたりしていた。 皮肉屋で、だれかれかまわず議論をふっかけていたが、とにかく仕事が速くて品質がよいので絶大に信頼されていた。 私は開発者としてMから様々な教えを授けられた。当時私はPHPerあがりのひよっこで、日々ダメコードを生産していた。 ある日Mにコードレビューを依頼すると、こんなことを言われた。 「堀さん!ソースコードにコメントを書いてはいけない!」 // connect to the database named "mysql" on the localhost val driver = "com.mysql.jdbc.Driver" val u

          「コメントは書くな」 - Qiita
        • 複雑さに立ち向かうためのコードリーディング入門

          iOSDC Japan 2023登壇資料

            複雑さに立ち向かうためのコードリーディング入門
          • 仕様の変更に強いコードを書きたいよねって話 - Qiita

            この記事は NIJIBOX Advent Calendar2019の13日目の投稿です。 背景 何かしらのロジックを作る際に、仕様変更に強いコードを書きたいぞい!ってエンジニアだったら思いませんか。今の仕様なら動くけど、もし仕様が変わり、そのために関数全書き直しとかしんどみが深すぎます。今回はこのしんどみを少しでも回避できるように柔軟なコードを書くぞい!って記事です。 ページネーションコンポーネントを例にしますが、なぜページネーションなのかというと僕が最近業務でページネーションを作り、かつ仕様の変更に強いコードの大切さを実感したからです。 そもそもページネーションとは ページネーション(pagination)とは、日本語で丁付け、ページ割りという意味で、Web制作においては、検索結果一覧など、内容の多いページを複数のWebページに分割し、各ページへのリンクを並べてアクセスしやすくするために

              仕様の変更に強いコードを書きたいよねって話 - Qiita
            • リーダブルコードを読んで重要だと感じたルールを抜粋 - Qiita

              はじめに 業務で開発をしていて、Pull Requestを送るたびに命名について厳しいレビューをもらうので、業務で特に重要だと感じた部分のみまとめてみました! 最初は「動けばいいじゃん!」と思っていたのですが、チーム開発、仕事となるとそうはいきません。 品質も含めて評価されるため、読みやすいコードを書くということは非常に重要です。 レビューで毎回のように 「ちゃんとリーダブルコードを読みましたか?」 と厳しい指摘を受けるので、できるだけその回数を減らしていきたいです。 毎日レビューで厳しい指摘を受けるのは(おそらく上司も仕事のためとしてコードに対しての指摘をしていると思われるが)とても辛いです。 レビューは あくまでもコードの指摘をしているだけ で、自分自身の人間性や仕事に対するダメ出しをもらっているということではない!と思うようにしてます。 とはいえできるだけレビューで受ける指摘は減らし

                リーダブルコードを読んで重要だと感じたルールを抜粋 - Qiita
              • 書店の音楽コーナーで「リーダブルコード」を発見するプログラマ

                Kazushi @vr_kzsh 今日は書籍部に行きました。 『リーダブルコード』が音楽のところに置いてありました。 そっちのコードじゃねえからな!!!!! pic.twitter.com/Vqb6zjZwpX 2021-04-08 21:27:42

                  書店の音楽コーナーで「リーダブルコード」を発見するプログラマ
                • 『良いコード/悪いコードで学ぶ設計入門』を読んで気になったことのメモ

                  はじめに 話題となっている『良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方』 (出版社のページ) を読みました。 全体的には「うんうん、そうだよね」と同意できることが多かったです。 もちろん、初めて目にするような考え方, アイディア, テクニックもありました。 一方、気になったことやちょっと引っかかったこともありましたので、メモしておきます。 あくまでもメモなので結論のようなことはありません。 p.55: HitPoint.isZero HitPoint クラスに isZero メソッドがあります。 「ヒットポイントがゼロであれば true」という仕様で、実装は次のようになっています。

                    『良いコード/悪いコードで学ぶ設計入門』を読んで気になったことのメモ
                  • Go言語の記述の迷いどころについて

                    この記事はGoのコードをいくらか書いていてもっとGoらしい書き方に興味を持ってからみてね!(Go初見で読んでも響かない内容です) Goは「シンプルで迷いなく書ける」というのが売りではあるのですが、 実際書き始めると、「あれ?これどうやって書くほうがいいの?」ってポイントにちょくちょく巡り合います。そのようなポイントを思い出しながら今思うベターな書き方を紹介しようと思う。 err変数束縛について err変数の受け取りを複数回繰り返していると「:=」だけで書けないという状況に出会うでしょう。 err := funcA() if err != nil { ... } err := funcB() // <- コンパイルエラー: "no new variables on left side of :=" if err != nil { ... }

                      Go言語の記述の迷いどころについて
                    • 【forが嫌い!可読性を上げたい!】楽するために学ぶ配列の高階関数(map, filter, reduce等) - Qiita

                      【forが嫌い!可読性を上げたい!】楽するために学ぶ配列の高階関数(map, filter, reduce等)JavaScriptリーダブルコード高階関数 複雑すぎるforの処理に悩まされたことはありませんか? プログラミング習いたての頃、forに悩まされた記憶はありませんか? また、業務で複雑すぎるfor文を見て、これくらい理解できないとやっていけないのか…と悩んだ記憶はありませんか? 実はそのfor…もっと読みやすい書き方が出来て、簡単に読めるとしたら楽じゃないですか? いやいや、単にもっと楽したくありませんか? 今回は個人的に「苦手なfor文」の書き換え(map, filter, reduce等)について、短くなるだけじゃないところを紹介したいと思います。 コードを読む事に神経をとがらせて疲弊したくない人には、オススメしています。(頭を使う労力が減ってると信じたい...) 本記事につ

                        【forが嫌い!可読性を上げたい!】楽するために学ぶ配列の高階関数(map, filter, reduce等) - Qiita
                      • 可読性と変更容易性のため、気をつけていること - Qiita

                        コメント頂いた件について追記しました。 2020/02/24 22:17 パイプライン演算子について追記しました。 2020/02/26 1:59 コメントの返信は終了しました。 2020/02/26 11:46 タイトルを変更しました。旧タイトル「可読性のためなら改行してくれ」 2020/02/27 09:38 この記事の内容は可読性と変更容易性の向上のための 1つの方法を記載しています。 可読性の感じ方には個人差があります。 ソースコードで一番大事なのは、 速度よりも可読性 です。 少しくらい速度が上がるからといって、可読性を損なうのは基本的には避けるべきで、 止む得ない事情がある時のみであると、自分は思ってます。 ・可読性を損なわない高速化は行う ・可読性を損なう高速化の場合は正しいクラス設計で開発し、動きが保証されてから最適化する 例 特定の文字列をもらった後に、決まった文字列を後

                          可読性と変更容易性のため、気をつけていること - Qiita
                        • 『リーダブルコード』の要点&活用方法

                          はじめに 今回の記事では『リーダブルコード』の要点と、実務で活用する方法を徹底解説する。この記事を読むことで、『リーダブルコード』の重要な部分と実務での活用方法を学べるだろう。 本記事で使うプログラムの言語はPythonを採用した。Pythonは文法がシンプルなので初心者でも学習コストが低く、プログラミングの入門としては最も相応しいからである。今回の記事の内容は良いプログラムを格上での重要な基本事項なので、どの言語でも役立つだろう。 1部:表面上の改善 名前に情報を詰め込む プログラムに使われる名前は、主に次の5つの鉄則を守る必要がある。 明確な単語を選ぶ 例えば、getは具体的に何をしているのかがわからない。 この場合だと、画像をダウンロードするのか、あるいはWebサイト上に表示されている画像のすべてを取得するのかまったくわからない。 インターネット経由で画像を取得するなら、Downlo

                            『リーダブルコード』の要点&活用方法
                          • リーダブルコードの要点整理と活用法をまとめた - Qiita

                            はじめに 2022年で新卒エンジニア2年目になりコードレビューの機会が増えてきたので、1年振りに「リーダブルコード」を読み直しました。 リーダブルコードを読んでいく中で要点を整理し、実務の現場でコードを書いたりレビューをする際にどのように活用していけば良いのかを自分なりにまとめてみました。 この記事を読むことで、リーダブルコードの要点と初級者から中級者目線で実際の現場でどのように活用すればよいのかが学べます。 この記事の主な対象者 リーダブルコードの要点をサクッと知りたい人 初級~中級者(実務歴1~3年目)の人 コードレビューの機会が増えてきた人 これまで我流でコードを書いてきた人 リーダブルコードについて リーダブルコードはあくまで「こう書きなさい」と押し付け口調ではなく「こう書いた方がもっとよくなるよ」といった丁寧な語り口で書かれています。 それを踏まえた上で要点や活用方法をまとめてい

                              リーダブルコードの要点整理と活用法をまとめた - Qiita
                            • 【変数を笑う者は変数に泣くぞ】20分で学ぶ!読みやすくバグを生まないローカル変数を書く方法 - Qiita

                              変数に泣かされた事ありますか? 変数はいい大人でも泣かしにかかってきます。 リリース直前であろうと、某ジャ〇アンのようにギッタンギッタンにしてきます。 大抵は意図していないタイミングで書き換えられ、その結果が他のロジックに引き継がれ 結果、微妙にズレた結果となり…テスト結果は プログラミングの初歩中の初歩である変数で、泣かされるなんて馬鹿らしくないですか? 良い機会なので復習してみませんか? 本記事について 読み方 重要なことだけ教えろって方は、大項目と強調文字だけ読んでください。 対象者 駆け出しエンジニア、2-3年目のエンジニア リーダブルコードを書きたい方 目的 変数の書き方について復習する。 より良い変数の書き方を理解する。 注意点 サンプルコードはJavaScriptで書いています。 すべての言語に適用可能でない可能性があります。 業務でコーディングする際は、プロジェクトのコーデ

                                【変数を笑う者は変数に泣くぞ】20分で学ぶ!読みやすくバグを生まないローカル変数を書く方法 - Qiita
                              • 年齢と共に理想は変わっちゃった - POTTIRI'S AUTOBIOGRAPHY

                                お疲れさまです。POTTIRIです。 毎日毎日プログラムを書いてますが、 自分の理想とするプログラムが年齢と共に変わってくのを感じます。 今日はそんな話です。 今日のステージ 格子模様つけてみました 20代の頃の理想 30代の頃の理想 現在の理想 今日のステージ 今日はこちらです。 昨日作ったステージを嫁に見せたところ、 もっともーーーーっとシンプルな面いいということなので、 こんな感じにしてみました。 こ・これでいいのかなあ? (ていうか爆風が重なりすぎて処理オチしてる・・・) 長男にやらせてみよう。 どんな反応するかな? 他の面はこちらにあるので、万が一興味を持たれたらサイトを訪れてください。 blast.pottiri.tech 格子模様つけてみました 今までステージのマス目が真っ白だったので、 ちょーっと寂しいかなーっていうことで格子模様にしてみました。 爆弾パズルはマス目を一定に

                                  年齢と共に理想は変わっちゃった - POTTIRI'S AUTOBIOGRAPHY
                                1