がるの健忘録

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

Slimは本当にスリムなのだろうか?

ちょいと気になったり興味があったりしたので、いくつかの「比較的(日本で)ポピュラーと思われる」PHP Web Application Framerowkの、行数とかファイル数とかを調べてみました。
まずインストールですが、本日のタイミングで

composer.phar create-project laravel/laravel laravel
composer.phar create-project cakephp/app cakephp
composer.phar create-project symfony/framework-standard-edition symfony
composer.phar create-project kenjis/codeigniter-composer-installer codeigniter
composer.phar create-project slim/slim-skeleton slim

という感じで一通り入れています。
バージョンとかの細かい違いがあると思うので、その辺は適宜脳内補完をお願いいたします。

また、ファイル数や行数は、基本的には以下のように調べています。

#
find vendor/ -name "*.php" | xargs  wc -l | tail -n 1
find vendor/ -name "*.php" -type f | wc -l
#
find FW本体と思われるディレクトリ -name "*.php" | xargs wc -l | tail -n 1
find FW本体と思われるディレクトリ -name "*.php" -type f | wc -l

ただ、上述だと「ファイル数が多くてうまく合計されない」ものもあるので、その辺は適宜よしなにしております*1

結果。

フレームワーク 全体ファイル数 全体行数 FW本体と思われるディレクト FWファイル数 FW行数
laravel 6161 832270 vendor/laravel/framework/ 857 127125
symfony 6134 739122 vendor/symfony/symfony/ 4055 466309
cakephp 4469 598447 vendor/cakephp/ 872 135415
codeigniter 258 78948 vendor/codeigniter/framework/ 199 68492
slim 1424 145223 vendor/slim/slim/ 47 8564

Laravelが重量級なのは想像通り、cakephpもそれなりに。
symfonyが、思いのほか「フレームワーク本体(と思われる……もしかしたら本体以外が混ざってるのかも)」のファイル数&行数が膨大で、ちょいとびっくり。
codeigniterは「全体としては軽い」んだけど「本体はそこそこの重量」があって。
slimは、「周辺まで含む」と少し行数ファイル数ともあるものの、本体はさすがに貫禄の軽量っぷりw

こうやって見ると、改めて「フレームワーク"を"読む」なら、Slimから、ってのは、割と入門的な位置に行けそうだなぁ、と、改めて感じるところでございます。

*1:findをリダイレクトして「行頭に wc -l」の置換かましたのを実行した結果をリダイレクトたものの0x20をタブに置換してExcelでsum w

この本は外せない

何はなくとも、レベルで必読な書籍

UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学

書いてある内容は割と平坦で「技術素養が薄くても普通に読める」んだけど、そこにあるエッセンスは「業務を二桁年重ねてきたエンジニアでさえも割と失念しがち」な、本当に大事なことが色々と書かれていると思う。

SlimとSlim-Skeleton のindex.php

公式サイト http://www.slimframework.com/ のサンプルだと、index.php

<?php
use Psr\Http\Message\ServerRequestInterface as Request;
use Psr\Http\Message\ResponseInterface as Response;

require 'vendor/autoload.php';

$app = new \Slim\App;
$app->get('/hello/{name}', function (Request $request, Response $response, array $args) {
    $name = $args['name'];
    $response->getBody()->write("Hello, $name");

    return $response;
});
$app->run();

と書かれている一方で、「実際にプロジェクトを起こす時にベースに使うと便利」とされている、公式から出ているSlim-Skeletonのindex.php では、少しばかり、差異があります。
この辺を少し、読み解いていきましょう。

注意
一時期以降、結構ごっそりと書き方が変わっています。
一端 https://github.com/slimphp/Slim-Skeleton/tree/439b6ec6cb1189d0be7fe31f87af4cbeeb801e53 を前提に記述、後で最新用のフォローアップをします。


さて。
とりあえずまずはルーティングの設定です。

$app->get('/hello/{name}', function (Request $request, Response $response, array $args) {
    $name = $args['name'];
    $response->getBody()->write("Hello, $name");

    return $response;
});

このあたり、ですね。
これを、Pageが増える毎にindex.phpに重ねていくと、index.phpがえらいこと長くなってしまうので、ちょいと切り出してみましょう。
そうですねぇpublicにあるのも些か好ましさに欠けるかと思いますので。
publicディレクトリと同じレベルに、srcというディレクトリを切って、その中に routes.php とかいうファイルを作ってみましょう。

そうすると、まず切り出すので、index.php

<?php
require 'vendor/autoload.php';

$app = new \Slim\App;

// Register routes
require __DIR__ . '/../src/routes.php';

$app->run();

こうなり、切り出したroutes.php

<?php
use Psr\Http\Message\ServerRequestInterface as Request;
use Psr\Http\Message\ResponseInterface as Response;
// Routes
$app->get('/[{name}]', function (Request $request, Response $response, array $args) {
    // Sample log message
    $this->logger->info("Slim-Skeleton '/' route");
    // Render index view
    return $this->renderer->render($response, 'index.phtml', $args);
});

こうなります。
use句は、切り出したほうのコードで使ってるので、併せての移動ですね。
ついでに、 Psr\Http\Message\ServerRequestInterface はインタフェース宣言だけなので&Slimは実際にはちゃんとクラスまで切っているので。
implementsしたクラスに、use句を変更しておきましょう。

<?php
use Slim\Http\Request;
use Slim\Http\Response;
// Routes
$app->get('/[{name}]', function (Request $request, Response $response, array $args) {
    // Sample log message
    $this->logger->info("Slim-Skeleton '/' route");
    // Render index view
    return $this->renderer->render($response, 'index.phtml', $args);
});


さて。
index.phpですが。
このままでもよいのですが、実際にアプリケーションを組むのであれば「なにがしかの設定値」は、やはり欲しいところになります。
new \Slim\App でも、コンストラクタに色々と実際には設定を渡す事ができるので。

と言うわけで、設定値をやはり切り出して記載してみましょう。
ファイルは、src/settings.php にしてみます。

index.php

<?php
require 'vendor/autoload.php';

// Instantiate the app
$settings = require __DIR__ . '/../src/settings.php';
$app = new \Slim\App($settings);

// Register routes
require __DIR__ . '/../src/routes.php';

$app->run();


settings.php

<?php
return [
    'settings' => [
        'displayErrorDetails' => true, // set to false in production
        'addContentLengthHeader' => false, // Allow the web server to send the content-length header
        // Renderer settings
        'renderer' => [
            'template_path' => __DIR__ . '/../templates/',
        ],
        // Monolog settings
        'logger' => [
            'name' => 'slim-app',
            'path' => isset($_ENV['docker']) ? 'php://stdout' : __DIR__ . '/../logs/app.log',
            'level' => \Monolog\Logger::DEBUG,
        ],
    ],
];

これで「settings.phpに設定を書く」と「new \Slim\Appの引数として渡される」ので、色々な設定を入れ込む事ができるようになります。

次に。
diコンテナも少し設定をしておきましょう。
とりあえずざっくりと「view用のクラスとしてPhpRenderer」と、最低限の「logger(ログを出力するクラス)」くらいは追加しておきましょう。
追加用の設定は src/dependencies.php にでもいれておくことにします。

index.php

<?php
require 'vendor/autoload.php';

// Instantiate the app
$settings = require __DIR__ . '/../src/settings.php';
$app = new \Slim\App($settings);
// Set up dependencies
require __DIR__ . '/../src/dependencies.php';

// Register routes
require __DIR__ . '/../src/routes.php';

$app->run();


dependencies.php

<?php
// DIC configuration
$container = $app->getContainer();
// view renderer
$container['renderer'] = function ($c) {
    $settings = $c->get('settings')['renderer'];
    return new Slim\Views\PhpRenderer($settings['template_path']);
};
// monolog
$container['logger'] = function ($c) {
    $settings = $c->get('settings')['logger'];
    $logger = new Monolog\Logger($settings['name']);
    $logger->pushProcessor(new Monolog\Processor\UidProcessor());
    $logger->pushHandler(new Monolog\Handler\StreamHandler($settings['path'], $settings['level']));
    return $logger;
};

これで一段落……したいところなのですが。
ついでに、middleware用の設定をいれる場所を作っておきましょう。
一端「場所だけ」を作る感じで、 src/middleware.php に用意をしておきます。

index.php

<?php
require 'vendor/autoload.php';

// Instantiate the app
$settings = require __DIR__ . '/../src/settings.php';
$app = new \Slim\App($settings);
// Set up dependencies
require __DIR__ . '/../src/dependencies.php';
// Register middleware
require __DIR__ . '/../src/middleware.php';

// Register routes
require __DIR__ . '/../src/routes.php';

$app->run();


middleware.php

<?php
// Application middleware
// e.g: $app->add(new \Slim\Csrf\Guard);

こんなところでしょうか。
ちなみに、サンプルで書かれている「\Slim\Csrf\Guard」は、これそのものではなくてもよいので、なにがしかCSRF対策用のものをいれておくのは、大変に好ましいと思われます。

これで、おおよそ「Slim-Skeletonのindex.php」と同じもの、になります。
実際のSlim-Skeletonのindex.php

<?php
if (PHP_SAPI == 'cli-server') {
    // To help the built-in PHP dev server, check if the request was actually for
    // something which should probably be served as a static file
    $url  = parse_url($_SERVER['REQUEST_URI']);
    $file = __DIR__ . $url['path'];
    if (is_file($file)) {
        return false;
    }
}
require __DIR__ . '/../vendor/autoload.php';
session_start();
// Instantiate the app
$settings = require __DIR__ . '/../src/settings.php';
$app = new \Slim\App($settings);
// Set up dependencies
require __DIR__ . '/../src/dependencies.php';
// Register middleware
require __DIR__ . '/../src/middleware.php';
// Register routes
require __DIR__ . '/../src/routes.php';
// Run app
$app->run();

となっていて。
空改行の箇所をのぞくと
・先頭の9行
・session_start();
くらいの差異、ですね。

先頭の9行は大雑把に
・ビルトインウェブサーバーを使っている時に「staticなURI(実在するファイルのURI)がcallされたら、プログラム的な処理をしない」ためのロジック
になります。

session_start()は、そのまま。
まぁセッションを使うことは「極めて多い」ですからねぇ。


と、このような感じで。plainのSlimのindex.phpから、Slim-Skeletonのindex.phpに移り変わりが行われています。

……という感じだったのですが。6 Nov 2018の
https://github.com/slimphp/Slim-Skeleton/tree/8dd2f8469514a43d4180148466a832f8d1683fe4
のタイミングで、ちょいと諸々、がらっと様変わりをしたようなので、少し覗き直してみましょう。

index.phpですが、こんな風になっています。

<?php
if (PHP_SAPI == 'cli-server') {
    // To help the built-in PHP dev server, check if the request was actually for
    // something which should probably be served as a static file
    $url  = parse_url($_SERVER['REQUEST_URI']);
    $file = __DIR__ . $url['path'];
    if (is_file($file)) {
        return false;
    }
}
require __DIR__ . '/../vendor/autoload.php';
session_start();
// Instantiate the app
$settings = require __DIR__ . '/../src/settings.php';
$app = new \Slim\App($settings);
// Set up dependencies
App\Dependencies::init($app);
// Register middleware
App\Middleware::init($app);
// Register routes
App\Routes::init($app);
// Run app
$app->run();

全体的に「クラス名::init($app)」の方法でのcallに変わっている感じですね。
例えばRoutesを見ると

<?php
namespace App;
use Slim\App;
use Slim\Http\Request;
use Slim\Http\Response;
/**
 * Configures the routes
 * @param App $app
 */
class Routes
{
    /**
     * Configures the routes
     * @param App $app
     */
    public static function init(App $app)
    {
        $container = $app->getContainer();
        $app->get('/[{name}]', function (Request $request, Response $response, array $args) use ($container) {
            // Sample log message
            $container->get('logger')->info("Slim-Skeleton '/' route");
            // Render index view
            return $container->get('renderer')->render($response, 'index.phtml', $args);
        });
    }
}

という感じで、全体的に「クラスの中のstaticなメソッドでの定義」に変わっているようです。

で、その状況が、わずか二週間弱、19 Nov 2018 に
https://github.com/slimphp/Slim-Skeleton/tree/15fc5968d9430e67110d82dff3b1b3a2349c9cf6
で、もう一度変わっています。

<?php
if (PHP_SAPI == 'cli-server') {
    // To help the built-in PHP dev server, check if the request was actually for
    // something which should probably be served as a static file
    $url  = parse_url($_SERVER['REQUEST_URI']);
    $file = __DIR__ . $url['path'];
    if (is_file($file)) {
        return false;
    }
}
require __DIR__ . '/../vendor/autoload.php';
session_start();
// Instantiate the app
$settings = require __DIR__ . '/../src/settings.php';
$app = new \Slim\App($settings);
// Set up dependencies
$dependencies = require __DIR__ . '/../src/dependencies.php';
$dependencies($app);
// Register middleware
$middleware = require __DIR__ . '/../src/middleware.php';
$middleware($app);
// Register routes
$routes = require __DIR__ . '/../src/routes.php';
$routes($app);
// Run app
$app->run();

で、routesが

<?php
use Slim\App;
use Slim\Http\Request;
use Slim\Http\Response;
return function (App $app) {
    $container = $app->getContainer();
    $app->get('/[{name}]', function (Request $request, Response $response, array $args) use ($container) {
        // Sample log message
        $container->get('logger')->info("Slim-Skeleton '/' route");
        // Render index view
        return $container->get('renderer')->render($response, 'index.phtml', $args);
    });
};

前回「staticなクラスメソッド」だったのが、今回は「無名関数」に置き換わっている感じですね。

なんか色々と動きがありそうな感じなので、ちょっと興味深く思いました。

明日になったら「明日」になるから、多分、綺麗にならない

なんかつい最近も似たような事を書いたような記憶が、なくもないのですが(
ソレはきっと、ビューティフル・ドリーマー - gallu’s blog )。

今回は(も)、端的には「技術負債を作らないために」的な話でございます。
んと……定期的に耳にするのが
・今は時間がないから、仕方がないから汚くてもまず実装して仕上げる
的なお話。

まぁ「汚い」のレベルにもよるのですが、一旦「そのままにすると負債になるレベル」と仮定します。
「時間が無いから締め切りがあるからやむを得ず一端」というのはわかりますしきっとその気持ちに嘘はないのだろうと思うのですが*1、端的には
・いつまでも負債は支払われず、それは重くのしかかってそのうち自重崩壊する可能性が上がっていく
事が多いかなぁ、と思われます……ってのを、もう少し噛み砕いて。

どこかで何か所かで拝見している、意味合いとしてはこんな内容の文章がありまして。
「綺麗に書ける人は時間をかけなくても大抵綺麗なコードを書くし、汚く書く人は時間を与えても大抵汚いコードを書く」
これを見た時に「あぁ、たしかにある程度そんなもんだろうなぁ」とか思ったりすることが、少なからず。

或いは「一旦忙しいから(ダメかもしれないけど)今までの慣習通りで書いて、しっかりした考察は後回し」ってケースが、時々、見受けられます。
まぁ「締め切り直前」とか、気持ちが「全く完全に1mmも理解できない」とは言いませんが。が。が。

ちぃと違う切り口としましては、曰く
「ベテランは"後で直せる"事を理解しているから、簡単に書く。非ベテランは"後で直せる"事を理解していないから、後で直さなくてすむように複雑に時間をかける(けど、後で直さなくてすむなんてことはあり得ない)」
けだし名言だなぁ、と思うところでございます。

汚く書く人の一番困るのは「後で直しにくいような設計で書く」のが一番の困り者でして……プログラムにしてもデータ設計にしてもテーブル設計にしても。
「綺麗にクラスが切れていて綺麗にメソッドが切れているんだけどメソッドの実装がちぃと泥臭い」であれば「そのメソッドを書き直す」とかで片付くことが多く、ちゃんとテストがかかれていれば「書き直した、テストした、OK」で終わるので、そんなに高い負担にはならないものでございます。
データ設計やテーブル設計だと「後での追加が比較的容易になるように丁寧に設計して、その詳細項目は一旦、欠けのある雑な設計」だと、「足りなくなったら追加しよう」で事足りるので、やはり、そんなに高い負担にはならないものでございます(まぁ「プログラム側が、カラムの追加に対してDRYであること」ってのが追加で入ってきますが)。

つまり、「汚い実装」は、割と多くの場合において「そもそも設計レイヤーでコケている」ケースが多い、というのがまず1点目としてあります。

で、その1点に追加をすると。
「綺麗な実装」ってのは、知っている限りでは「それなりに脳みそで汗をかいてもんどりうった先にある」事が多いように思われるのでございます。
つまり、ある程度の「熟考して立ち止まって3歩すすんで2歩さがってスクラップアンドビルドを繰り返して無理な要求とリファクタで悲鳴を上げながら」スキルが上がってくる側面が、どうも、あるように思われます。
その辺をやらずに「とりあえず汚いコード/テーブル設計を書き散らかす」を繰り返すと。「綺麗な実装」に対する経験値が積めないまま時間が過ぎ去ってしまう、ってのが、どうもちらほらとあちこちで、ごくまれに、例外的に*2見かけられるように思われるのですが、如何でしょうか?

次に「急いでるから一旦汚く書く」ケースで「じゃぁ、いつ、リファクタするの? そのスケジュールは具体的に抑えてるの?」って質問がありまして。
……書いたの最近だなぁ ソレはきっと、ビューティフル・ドリーマー( https://gallu.hatenadiary.jp/entry/2019/02/05/012839 )にある通りなんですが「そのうち」ってのは「いつまでもやってこない」時間軸なんですよねぇ大概。
だって未来は暇じゃなくて「次の作業」が鮨詰めに詰められているんですもの。

で、ってことは「あとで」は来ないので「綺麗に書く経験も苦労も悲鳴も怒号もないまま」に進んでしまうので。
そうすると結果的に「いつまでもコードが綺麗にならない」し「綺麗に設計するための修練を積むことができない」から結果として「汚いままで綺麗にする術がない」んですよね。

勿論「運用で苦労するもの」ではあるんですが、……その辺、認識できないと「他人に運用を押しつけて回避」とか「運用なんてこんなもんだ」くらいで、意識が出来ないまま無駄なコストを食らいまくっていくものでございます。
「極寒の地で全裸で凍えながらなぜ つらいのかわかっていないようなもの これ以上 心身に負担をかけると死にかねないよ」とは、けだし名言だなぁ、と。
「寒いのは当然、凍えるのは当然」とか言っていると、そのうち凍傷になって、場合によっては絶命するんですよねぇ。サービスにしてもエンジニアにしても会社にしても。

勿論案件なので「締め切りがある」ってのは重々承知しているのですが。
とはいえ、どこかで巻き返さないと、なんとなし「ジリ貧にならん?」とか思ったりするんですよ。
「巻き返してそれなりに修練を積むことの重要性」って、なんとなく、割と軽視されているように見えるんですが。

その辺、ど~なんですかねぇ??

*1:「お気持ち」だけなら、ねぇ……

*2:≒大量に、頻繁に

新学期も始まったのでまずは「学び方」

ちょいとラインナップも変更になってきたので、頑張ってこの1年、また備忘録していきたいと思います。

まず初っぱなは「学び方」を学びましょう、ということで、毎度おなじみこちらから。

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

併せて、これも毎年なんですが。

Bjarne Stroustrup: 標準C++を新しい言語として学ぶ
こちらから、この文章も、毎度毎度、使わせていただいております。

プログラムは書きやすく、正確で、保守可能であり、受け入れられる程度に 効率的であることが望ましい。したがって、この理想に最大限に近づけるように C++(そして、その他のプログラミング言語)を使用すべきである。

それではこの1年、頑張って行きましょう!!

Twig チートシート

「あんちょこ」って大分と古くてあんまり使われてない単語なんだなぁ……というあさってな方向からの感想を述べつつ。

単置換

一番の基本だよねぇ。いわゆる「この変数を出力」ってやつ。

{{ variable }}

配列は.(ドット)でつなげる感じ。

{{ array.key }}

フィルタ

いろいろなフィルタがあって、割と便利。

{{ variable|filter }}

filterは、 https://twig.symfony.com/doc/2.x/ とかみるとわかるですが、なんか結構山盛り。
いくつかかいつまんで、使いそうかなぁ、って思えるものを中心にいくつか。

HTMLエスケープ。ただ、単置換でも普通にエスケープしてくれるからなぁ。
「js用のエスケープ」は、もしかしたら、便利、かも。

{{ variable|escape }}
{{ variable|e }}
{{ variable|escape('js') }}
{{ variable|e('js') }}

小文字になぁれ、大文字になぁれ

{{ variable|lower }}
{{ variable|upper }}

「改行をタグに」

{{ variable|nl2br }}

数値のフォーマット変更各種。PHPのnumber_format()関数と一緒

{{ variable|number_format }}

エスケープ無し。気を付けて使わないと危ないけど、とはいえ「必要な時は(稀に)あるよねぇ」というフィルタ。

{{ variable|raw }}

URLエスケープ

{{ variable|url_encode }}

コメント

コメントはこんな風に。

{# コメント #}

ある程度書いておいたほうが、後々、楽だよねぇ。

条件分岐

いわゆる if 文。

{% if variable == 'hoge' %}
    HTML
{% elseif variable == 'bar' %}
    HTML
{% else %}
    HTML
{% endif %}

「厳密な比較( === )」をしたい時に、===と書くとエラーになるので、そゆときは is same as() を使います。

{% if variable is same as('hoge') %}
    HTML
{% else %}
    HTML
{% endif %}

演算子は、andとかorとかを使いましょう。

{% if 18 < variable and variable < 21 %}
    HTML
{% else %}
    HTML
{% endif %}

あと、変数が「あるかないか」とか配列が「あるかないか」とか配列の個数とか、その辺は「length」のフィルタ使ってチェックします。

{% if variable|length  %}

とか

{% if array|length  %}

とか。これは「戻り値が0なら、空文字(空配列)か存在しない変数のどちらかだからfalseになるよねぇ」って感じで使います。

反復

いわゆる「PHPのforeach」は、こんな風に。

{% for key, variable in array %}
  {{ key}}の値は{{ variable }}<br>
{% endfor %}

{% for variable in array %}
  値は{{ variable }}<br>
{% endfor %}

「for文で数値の反復」は、rangeを使います。

{% for i in range(0, 10) %}
  {{ i }}
{% endfor %}

また、ループでは「特別な変数」があって、それを使うと色々なことが出来ます。

loop.index  ループ数 1スタート(1 2 3 4 ...
loop.index0  ループ数 0からスタート(0 1 2 3 ...
loop.first 最初のアイテムならtrue
loop.last  最後のアイテムならtrue

変数の設定

あんまり使わん気もするが……どうしても「テンプレート内で変数を定義したい」場合は、こんな風に。

{% set variable = 'hogeramugera' %}

テンプレートの継承

{% extends 'layout.twig' %}

って書いておくと、継承してくれます。

あとは。継承元のファイルで

{% block XXXXXX %}{% endblock %}

って書いておいて、継承先のファイルで

{% block XXXXXX %}これを出力{% endblock %}

とかってやると変換してくれるので。
よくやるのが、headのtitleとかを

{% block title %}{% endblock %}

で宣言して継承先で

{% block title %}ほにゃららページ{% endblock %}

とかって使ったりします。

includeもあるんだけど、あんまり使わないなぁ。
使いたいときは

{% include "parts/include.twig" %}

とかって書式で。



大体、これくらいかなぁ。
過不足あったら、適宜修正していきまふ。

フレームワークって「マシントレーニング」な側面があるよね

いやまぁ言いたいことはタイトルそのまんま、なのですが。
お題は「フレームワーク」。
見方を変えると「ライブラリとフレームワークの違い」の一端、かもしれない。

元ネタ
http://concierge.diet/column/leader/kawabe20151230

これが自重での筋トレですと、やるごとに負荷がかかる場所がズレたり、疲れてきて余計な動きが出てしまったりと安定しません。
-中略-
あとは安全性が高いのもマシーンのメリットですね。固定されているものなので、変な方向に動くことはないので。

元ネタの記事の趣旨からは結構おおきく大暴投している気がいたしまするが(笑
自重トレーニング、あるいはフリーウェイトと比較しての「マシントレーニング」が、フレームワークなんじゃないかなぁ、と思うのですね。

もうちょいとばかり技術的な側面からの発言だと、この辺が非常に得心のいくところですかね。
http://qiita.com/Jxck_/items/ec8e928f69d099b25764

Rails は、フレームワーク自体が単に機能を提供するだけでなく、Web アプリを開発する上での指針を示している。これは レール と呼ばれ、 Rails が敷いているレールにきちんと沿った開発をすることは、 Rails を使いこなす上では非常に重要になる。

Railsに限らず、基本的に「ほとんどのフレームワークが」このあたりの特徴を持っていると思うのです。
つまり「そのフレームワークが敷いたレールにきちんと沿うことが前提」。

http://concierge.diet/column/leader/kawabe20151230

このマシーンの正しい使い方も、トレーナーに指導してもらうべきですね。

にもある通り、「マシン(フレームワーク)を使ってれば無問題」では絶対になくて、そのマシン(フレームワーク)の「正しい*1使い方」を知り、或いは把握し、チームで共有する必要があるんですね。
後まぁ、そもそもとして「そのマシン(フレームワーク)は何を目指して作られているか、を知る事、とか(足を鍛えるためのマシンで胸筋鍛えても、色々と面倒なだけで効率が悪いものでございます)。

まぁ、フレームワークは「ある程度の、レールから外れた処理への許容度」というのがあるのですが、あんまり自由度が高すぎると「それはマシンいわんで、フリーウェイト言うんちゃうか?」という突っ込みが入ってくるので。
「レールへの強制度が高い」ほど、案件を選びますが、全体の粒度は割合とそろいやすい傾向にあると思います……あくまでも「傾向」程度、ですが。
んで、逆もしかり。「自由度が高い」フレームワークは、フリーウェイトっぽい作りになってたりしますが、その分「ある程度の自力が必要」なので、使う人を選ぶっちゃぁ選ぶ感じでしょうかねぇ*2

まぁ、その辺は以前にも「■[親方]フレームワークの選定の仕方( https://gallu.hatenadiary.jp/entry/20120907/p1 )」で書いているのですが。

後、これ以外にも
http://concierge.diet/column/leader/kawabe20151230

トレーナーをつけることのメリットとして他にも、自分自身のカラダの特徴を客観的に知ることができるという点があります。

なんてお話があって、これなんかは、ソースコードレビューを彷彿とさせるものがあるように思うのは気のせいでしょうか?

「全く違う業界」のお話って、割とどこかで「通じるもの」があって面白いですよねぇ。
……………っつか、いい加減トレーニングしなきゃなぁ、とか思うのですが(……どっちかってぇと、リハビリな気もするが)。

*1:或いは、より好ましい言い方をするのであれば「適切な」

*2:MagicWeaponはもろにその系。Slimも割とそんな系統ですねぇ