サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
DX: Developer Experience （開発体験）とは、あるシステムを「気持ちよく開発・保守できるかどうか」を示すもの 開発者は開発・保守という行為を通じたそのシステムのユーザーであり、DXはUXの一種であるDXがよいと日々の開発を楽しめるようになり、気持ちに余裕ができる 気持ちの余裕がでるとコードの品質があがり保守時のデグレも減らせる また、DXがよい事自体がDXを高める動機になり、正のスパイラルを見込める つまり、「定められたタスク」（＝義務）以上のことを行うようになるDXが悪いと開発を楽しめず、「定められたタスク」以外のことをしたくなくなるDXは放置すると悪化するので、「DXがよくも悪くもない」プロダクトは時間が経つに連れ「DXが悪い」になる なので積極的にDXを良くしていく活動を奨励していくのがよい いくつか興味深いフィードバックがあったので記しておきます。DX
昔、本項で比較したかったのは、要するに「For Next と For Each って、どっちが速いの？」ってことです。1995年にMicrosoftから出版されたVBAに関する公式本に「For Each の方が速いよ～理由はね～」って書いてあったからです。その頃調べた結果では、確かに For Each の方が速かったです。でも、時代は変わりました。と同時に、パソコンの性能も飛躍的に向上しています。理論的に速くても、体感速度として、あるいは計測結果としては、どうなんでしょう。 まず、For Next と For Each で比較してみましょう。 Sub Test1() Dim i As Long For i = 1 To 10000 Cells(i, 1) = 100 Next i End Sub Sub Test2() Dim c As Range For Each c In Range(
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
これは人それぞれのコードの書き方に依存するので必ずしも筋悪というわけではない。むしろそういう風に書いてしまえる人もいるだろう、くらいの話。 何が言いたいかというと、自分の場合、ある程度は頭の中でまとめつつとりあえず手を動かして書いてみる→気に入らなかったり、後から「これではあかん」と思ったらインタフェース変える、みたいなことを繰り返しながら、要は同時にリファクタリングしながらコードを書いていくので、初めから厳密すぎるテストを書いてしまうと手戻りが多くなって非効率的なのである。 例えば、とあるJavaScriptのメソッドの返り値がこんな感じだったとしねえ。 { valid: true, foo: 10, bar: 0 } で、"valid"の部分はほぼ間違いなくこれで行くけど、"foo"と"bar"の部分は後から無くすかもしれない。あるいはkey名を変えるかもしれない。あるいは何か別のke
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
