保守性・可読性の高いPythonコードを実装するためにはどうすればよいか - はてなの金次郎
はじめに コードは理解しやすくなければいけない。 リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) 作者:Dustin Boswell,Trevor Foucher発売日: 2012/06/23メディア: 単行本（ソフトカバー） コードの保守性や可読性を高めるために我々エンジニアはどんなことができるでしょうか？ テストを書く 推奨されているコードスタイルに準拠する コメントを書く DRY原則に則る 変更・拡張しやすく設計する ログを出力する・監視する 適切な命名をする etc... まだまだ意識すべきことはあると思いますが、上記の項目はエンジニアであれば恐らく一度は目にしたことがあるような内容であり、暗黙的に了承されたいルールです。 しかし、これらはただの心構えであり、体現するために実際には以下のような項目に落とし込む必要
普通のチームで立ち向かう - Railsアプリでのテストコードポリシー - - LiBz Tech Blog
皆さん自分たちのプロダクトにテストコードは書いているでしょうか？ LiBzCAREERではRspecやCIなどテストコードを書くための仕組みは割と初期から用意していました。 ただし、テストコードを書くべきかの基準が明確になっておらず、テストコードが書かれているかは実装者に任されていました。 それではテストコードの書く書かないの判断が、実装者のテストコードに対するスキルや志向によってバラけてしまうため、今回の開発チーム再編のタイミングでチーム全員でテストコードを書くという意思決定をし、テストコードポリシーを定めました。 チームやプロダクトの状況 自分が所属する開発チームの体制はこちら エンジニア5人 Ruby on Railsを採用 チームにこれまでもテストコードを書いてきたエンジニアは1名だけ 既存のプロダクトコードにもテストがない箇所が多々ある SPAやJSフレームワークの導入など、フロ
テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita
テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした： 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
