よくプロジェクト等で「アプリケーションに関するコードはapp以下」「データベースに関するコードはdb以下」のような決まりがありますが、その配置の指針としてLIFT原則、というものがあるようです。

プログラミングを生業としていると、人のコードを引き継いで開発するなんてこともままある訳ですが、そういうときに一番困るのは「使われていないコード」だなー、としみじみ感じます。

セルフチェックをしようにも、観点が分からなければセルフチェックのしようがない。技術力がある、とは、セルフチェックの観点が分かっている、ということなのかも知れない。

モバイルアプリのようなスタンドアローンアプリとWebアプリの違いは、ソフトウェアの更新のタイミングを、ユーザーの自由にできるか否かという部分がとても大きい。例えばアップデートによって一部データが不正に書き換えられてしまう…

一見読めないコードでも、「読めない」と言うと何だか負けた気になって、頑張って読んでコメントしようと思ったりしますよね。しませんかね。でも、コードレビューで大事なのは読めないコードを「読めない！」と言える勇気だと思います。

先日9/27に「納品のない受託開発を支える レガシーコードを作らない仕組み」というテーマでレガシーコード改善勉強会にてお話をさせていただきました。

どっちの内部設計方針をとったとしても、ユーザから見える振る舞いは変わらないので、正味どちらでも良い。でも、どちらの方針を取るか決めなければならい、どうしよう？ そんな岐路に立たされたこと、あると思います。

よく聞かれることの一つに、「◯◯って、やっておくべきですかね？」「◯◯は読んでおくべきですか？」という質問があります。学んだことがすぐに廃れてしまう技術の分野の話って、やっぱり気になりますよねー。そういうときに答えている…

「何かコードレビューについて、良いネタないですかね」と社内で振ってみたところ、「最近コードレビューされる側の記事を書いているみたいだけど、視点を変えて、する側の視点で考えてみては？」というアドバイスをいただきました。なる…

プログラマなので常日頃からコードレビューを相互に行っているのですが、レビューというのはするのもされるのも、学習という面ではとても有効なものだなと感じています。特に「上手いやり方」を共有するという面で、学習に対する効果を感…