Не вижу ничего плохого в классах с одним методом. Количество методов не очень важно (если их не 100). Важно, чтобы у класса была одна ответственность.
Плохо — когда при добавлении новой фичи изменяют существующий класс (подобные классы часто называются *Manager, *Controller, *Service и т.д.).
Существует набор принципов SOLID, следуя которому вы получите множество небольших классов, которые очень удобно интегрировать. При добавлении новых фич вы будете создавать новые классы, расширяющие функционал существующих, не меняя их. Таким образом вы сильно уменьшите шанс внесения регрессионного бага в код.
Я тоже начинал с интернет-магазинов и практически не развивался профессионально. Тоже своя «CMS», тоже много магазинов на ней. Длилось это четыре года.
Но когда я опомнился и начал читать хорошие книги (начал с самых признанных программистами), то я понял насколько можно стать лучше и эффективнее. Причем я хорошо понимаю эти книги, так как уже имеется немалый опыт работы (без опыта я не понял бы многого). В итоге я расширил границы незнания, увидел огромные перспективы развития и больше не могу стоять на месте.
Есть фреймворки, позволяющие делать моки на статические классы. Например, TypeMock Isolator или Moles.
Но они провоцируют плохой дизайн, потому их надо использовать осторожно.
Помочь человеку найти что-то конкретное — задача фильтров, а не переключателя страниц. Если я хочу найти товар с определенной ценой, то я ставлю ограничение и сортировку по цене и сразу получаю то, что мне нужно.
А если хочется смотреть все подряд, то «бесконечный» скролл удобнее.
Не вижу большого смысла в переключателе страниц.
Соглашусь, что читать комментарии проще, если плохо понимаешь язык синтаксически. Но в высокоуровневых языках сам код может выглядеть как повествование. Описательные имена переменных и методов, небольшой размер метода и соблюдение одного уровня абстракции в его пределах — все это способствует тому, чтоб код читался, как книга.
Например, если мы видим строчку кода:
var pageHtml = downloadWebPageHtml(pageUrl);
Нужен ли нам комментарий, чтобы понять что здесь происходит? Я думаю, что нет. Комментарий только создаст лишний шум.
Читабельность — одно из самых важных свойств хорошего кода. Если не самое важное. Мы тратим на чтение кода гораздо больше времени, чем на его написание. Потому лучше посидеть чуть подольше и написать читабельный код, зато потом гораздо больше времени уйдет на его чтение.
Кстати, комментарии на французском — не проблема. Проблема — комментарии вообще. Если их много, значит сам код, скорее всего, не читабельный.
Кеш материализованных объектов на EF придется написать самостоятельно, но это не так сложно. С ручной инвалидацией так вообще элементарно.
Насчет CQRS. Это вопрос терминологии. Сейчас простое разделение Query и Command на уровне API чаще называют CQS, когда CQRS подразумевает раздельные хранилища. Но, имея первое, проще будет прийти ко второму, если это понадобится. Только переписав Query Handler'ы и добавив денормализаторы.
По моему опыту, все реальные проблемы с производительностью EF были вызваны неправильным его использованием. EF нарушает принцип наименьшего удивления. В своих недрах он может производить лишние операции и тормозить тогда, когда от него этого никак не ждешь. Но все решаемо, если знать с чем имеешь дело.
Кстати, существует решение для EF для автоматического кеширования/инвалидации на уровне result set`ов.
Для горизонтального масштабирования нагруженного проекта все равно придется прийти к денормализованному хранилищу для чтения (CQRS). Но для работы с нормализованной БД EF неплохо подходит.
Стив Макконнелл писал, что, согласно исследованиям, юнит-тесты помогают избежать меньшего числа ошибок, чем обзоры и инспекции кода. Так что, если вы думаете о том, что внедрить в вашей команде в первую очередь, подумайте о code review.
Плохо — когда при добавлении новой фичи изменяют существующий класс (подобные классы часто называются *Manager, *Controller, *Service и т.д.).
Существует набор принципов SOLID, следуя которому вы получите множество небольших классов, которые очень удобно интегрировать. При добавлении новых фич вы будете создавать новые классы, расширяющие функционал существующих, не меняя их. Таким образом вы сильно уменьшите шанс внесения регрессионного бага в код.
Читайте, осознавайте, применяйте.
P.S. еще можно подписаться на профильные блоги, чтобы быть актуальным. Но сперва надо «догнать», а потом уже поддерживать актуальность знаний в сфере.
Но когда я опомнился и начал читать хорошие книги (начал с самых признанных программистами), то я понял насколько можно стать лучше и эффективнее. Причем я хорошо понимаю эти книги, так как уже имеется немалый опыт работы (без опыта я не понял бы многого). В итоге я расширил границы незнания, увидел огромные перспективы развития и больше не могу стоять на месте.
Мой совет — читайте книги.
Но они провоцируют плохой дизайн, потому их надо использовать осторожно.
А если хочется смотреть все подряд, то «бесконечный» скролл удобнее.
Не вижу большого смысла в переключателе страниц.
Например, если мы видим строчку кода:
var pageHtml = downloadWebPageHtml(pageUrl);
Нужен ли нам комментарий, чтобы понять что здесь происходит? Я думаю, что нет. Комментарий только создаст лишний шум.
Кстати, комментарии на французском — не проблема. Проблема — комментарии вообще. Если их много, значит сам код, скорее всего, не читабельный.
www.fidelitydesign.net/?p=375
Насчет CQRS. Это вопрос терминологии. Сейчас простое разделение Query и Command на уровне API чаще называют CQS, когда CQRS подразумевает раздельные хранилища. Но, имея первое, проще будет прийти ко второму, если это понадобится. Только переписав Query Handler'ы и добавив денормализаторы.
Кстати, существует решение для EF для автоматического кеширования/инвалидации на уровне result set`ов.
Для горизонтального масштабирования нагруженного проекта все равно придется прийти к денормализованному хранилищу для чтения (CQRS). Но для работы с нормализованной БД EF неплохо подходит.
Жду заголовок «Искусственный интеллект на CSS3, без скриптов» ;)