ファイルの配置の仕方を平易にするためのLIFT原則
よくプロジェクト等で「アプリケーションに関するコードはapp以下」「データベースに関するコードはdb以下」のような決まりがありますが、その配置の指針としてLIFT原則、というものがあるようです。
まーくんが不定期に更新し続けるブログ
よくプロジェクト等で「アプリケーションに関するコードはapp以下」「データベースに関するコードはdb以下」のような決まりがありますが、その配置の指針としてLIFT原則、というものがあるようです。
プログラミングを生業としていると、人のコードを引き継いで開発するなんてこともままある訳ですが、そういうときに一番困るのは「使われていないコード」だなー、としみじみ感じます。
セルフチェックをしようにも、観点が分からなければセルフチェックのしようがない。技術力がある、とは、セルフチェックの観点が分かっている、ということなのかも知れない。
モバイルアプリのようなスタンドアローンアプリとWebアプリの違いは、ソフトウェアの更新のタイミングを、ユーザーの自由にできるか否かという部分がとても大きい。例えばアップデートによって一部データが不正に書き換えられてしまう…
一見読めないコードでも、「読めない」と言うと何だか負けた気になって、頑張って読んでコメントしようと思ったりしますよね。しませんかね。でも、コードレビューで大事なのは読めないコードを「読めない!」と言える勇気だと思います。
先日9/27に「納品のない受託開発を支える レガシーコードを作らない仕組み」というテーマでレガシーコード改善勉強会にてお話をさせていただきました。
どっちの内部設計方針をとったとしても、ユーザから見える振る舞いは変わらないので、正味どちらでも良い。でも、どちらの方針を取るか決めなければならい、どうしよう? そんな岐路に立たされたこと、あると思います。
「必要最低限の機能をまずリリースする」、と言うとまるで不完全なプロダクトを作るように聞こえてしまうし、プロトタイピングレベルのものをリリースするべき、みたいに聞こえてしまうけど、そうではないんですよね。
よく聞かれることの一つに、「◯◯って、やっておくべきですかね?」「◯◯は読んでおくべきですか?」という質問があります。学んだことがすぐに廃れてしまう技術の分野の話って、やっぱり気になりますよねー。そういうときに答えている…
「何かコードレビューについて、良いネタないですかね」と社内で振ってみたところ、「最近コードレビューされる側の記事を書いているみたいだけど、視点を変えて、する側の視点で考えてみては?」というアドバイスをいただきました。なる…
ニーズ=要望なのだけど、要望をストレートに実現しても、そのまま満足につながらないことがある。
プログラマなので常日頃からコードレビューを相互に行っているのですが、レビューというのはするのもされるのも、学習という面ではとても有効なものだなと感じています。特に「上手いやり方」を共有するという面で、学習に対する効果を感…
尾木ママが批判する武雄市の「反転授業」 子どもの「教育を受ける権利」は大丈夫?という記事で「反転授業」というキーワードをはじめて知ったのですが、その説明に 「反転授業」を受ける児童は、まず授業の前に自宅でiPadなどを使…
先日、リーダブルなコードを保つためには、コードが読まれるような文化をつくらなければならないのではないかというエントリを書いたのですが、こんなことを思ったのもある思い出話があったからでした。
いわゆる「ふりかえり」にKPT(Keep, Problem, Try)というフォーマットを使うことはよくあると思います。KPTって何?という方はこちらの書籍をどうぞ!