Производительный код тоже может быть качественным, если его писать "по уму" и снабжать комментариями по мере необходимости.
Вот как раз качественный код комментариев не требует, их необходимость указывает на то, что код сам по себе нечитабельный, приходится подпорки ставить в виде комментариев.
Производительный код может быть качественным, но это большая редкость. Чаще всего для того, чтобы сделать код производительным, приходится сознательно ухудшать такие его характеристики, как читабельность, расширяемость, сопровождаемость и т.д., в т.ч. избегать использования шаблонов и идти на сознательное нарушение принципов (SOLID, GRASP, KISS и т.д.).
А наворачиванием шаблонов качество можно только ухудшить.
Конечно, можно. В кривых руках даже при отличном инструменте результат будет кривой. И точно так же качество можно ухудшить, всячески избегая использования шаблонов. Как применение, так и неприменение чего бы то ни было требует осознанности :).
Тогда эти рекомендации не для Вас :) Качественный код (читабельный, сопровождаемый и т.д.) и производительный код -- понятия чаще всего взаимоисключающие. Если Вы пишите код для встраиваемых систем и экономите байты -- о каком полиморфизме может идти речь?
Из этой статьи, конечно, непонятно -- потому что это только первый этап преобразования, дальнейшие улучшения здесь отсутствуют:
Важно отметить, что большинство методов is являются временными и существуют недолго — в примере мы избавимся от некоторых из них в текущей главе и от многих других в главе 5.
Но вообще есть такой рефакторинг -- "замена условия полиморфизмом", смысл его в следующем. Вот у вас есть enum, и вы обрабатываете его с помощью switch -- при этом при добавлении нового элемента перечисления вам нужно найти все свитчи и внести в них изменения. Это явное нарушение OCP. Если же у вас вместо енума набор классов и для принятия решений вместо свитча используется полиморфизм, то при добавлении нового элемента вы просто пишите новый класс, клиентский код при этом не затрагивается. OCP радуется :).
Ну нет. Бизнес требует весьма специфических навыков, и отличный специалист в своей области (слесарь, менеджер по продажам, упомянутые врач и учитель, и т.д.) может вообще не уметь вот это вот. Даже не "может", а скорее всего не умеет. Иначе вокруг были бы тыщи и тыщи бизнесменов.
Тогда любой код с точки зрения этой конкретно команды является качественным (чистым). Поэтому любая нормальная команда начинает вырабатывать свои подходы к обеспечению качества кода.
Или наоборот, есть несколько команд, у каждой из которых свой набор гайдлайнов?
Понятие "качество кода" определяется строго на уровне команды, не ниже, не выше.
Скажем, грамотного техписателя, который умеет внятно формулировать свои мысли, да еще и понимает подноготную (не обязательно веб), — это надо еще поискать.
Ну да.
_Один мой друг_, сеньор-разработчик, откликнулся на вакансию техписа в СберТехе (зачем – обсуждать не будем). Так вот сразу прислали отказ (без объяснений) и даже не стали проверять, насколько внятно он умеет формулировать свои мысли.
Наш любимый заказчик (20 лет взаимодействуем) выдал как-то «Надо было делать не то, что написано в согласованном ТЗ, а то, что мы имели в виду».
Ну т.е. из-за того, что попадаются неадекватные заказчики (а они, конечно же, есть) Вы предлагаете всегда изменение требований постфактум считать проблемой исполнителя?
потом выкатит миллионную неустойку
Мы ведь говорим о требованиях, которые были заказчиком утверждены и подписаны, так? Поэтому юридически неа, он бессилен.
в стоимость всех работ сразу закладывать расходы на доработки
Как вариант – почему бы и нет? Но и в этом подходе есть минусы:
Из-за изначально более высоких цен теряем часть потенциальных заказчиков.
Т.к. речь идёт о предсказании будущего, мы будем регулярно промахиваться. И работать в таких ситуациях себе в убыток.
Когда аналитик ставит задачу - дизайнер знает, что есть ширина стопы и что размерная таблица параметрами, которые нужно свести в таблицу, например.
Так вот и я о том, что это аналитик должен знать и учитывать скрытую логику, и вообще бизнес-логику и бизнес-данные. Это он знает, для чего эта задача, какую проблему закрывает и т.д.
Разработчики получают задание в уже очень рафинированном виде, им всё это знать совершенно не нужно. У разработчиков есть свой, огромный пласт знаний – внутреннее устройство системы, и аналитик нужен, в том числе, чтобы разработке не требовалось глубокое погружение в предметную область и бизнес-процессы. Иначе перегрузка и взрыв головного мозга :).
Значит, я неправильно понял, у меня после прочтения сложилось впечатление, что "изменение требований в процессе (или тем более после) разработки – это не проблема заказчика, а проблема исполнителя".
Был неправ, вспылил. Но теперь считаю своё предложение безобразной ошибкой, раскаиваюсь, прошу дать возможность загладить, искупить. Всё, ушел.
Дизайнеры получают подробно выявленные требования. Они понимают, для чего эта задача, какую проблему она закрывает, какие данные необходимы и как всё должно функционировать.
Без такого анализа дизайнер может не учесть скрытую логику или понять её некорректно.
Вот здесь непонятно. Если речь идёт про дизайнеров пользовательского интерфейса, то зачем им знать про данные и скрытую логику?
Когда я кодю, в наушниках всегда играет медленный блюз.
КДПВ: после этого фильма я всей душой полюбил блюзы... Крайне рекомендую к просмотру!
Простите, не могу удержаться ??????
Хм, я думал, что нажимающие кнопки на процессоре уже все давно естественным образом вымерли. Ан нет! :D
Вот как раз качественный код комментариев не требует, их необходимость указывает на то, что код сам по себе нечитабельный, приходится подпорки ставить в виде комментариев.
Производительный код может быть качественным, но это большая редкость. Чаще всего для того, чтобы сделать код производительным, приходится сознательно ухудшать такие его характеристики, как читабельность, расширяемость, сопровождаемость и т.д., в т.ч. избегать использования шаблонов и идти на сознательное нарушение принципов (SOLID, GRASP, KISS и т.д.).
Конечно, можно. В кривых руках даже при отличном инструменте результат будет кривой.
И точно так же качество можно ухудшить, всячески избегая использования шаблонов.
Как применение, так и неприменение чего бы то ни было требует осознанности :).
Тогда эти рекомендации не для Вас :)
Качественный код (читабельный, сопровождаемый и т.д.) и производительный код -- понятия чаще всего взаимоисключающие. Если Вы пишите код для встраиваемых систем и экономите байты -- о каком полиморфизме может идти речь?
Из этой статьи, конечно, непонятно -- потому что это только первый этап преобразования, дальнейшие улучшения здесь отсутствуют:
Но вообще есть такой рефакторинг -- "замена условия полиморфизмом", смысл его в следующем.
Вот у вас есть
enum, и вы обрабатываете его с помощьюswitch-- при этом при добавлении нового элемента перечисления вам нужно найти все свитчи и внести в них изменения. Это явное нарушение OCP.Если же у вас вместо енума набор классов и для принятия решений вместо свитча используется полиморфизм, то при добавлении нового элемента вы просто пишите новый класс, клиентский код при этом не затрагивается. OCP радуется :).
Сейчас попробовал зайти – не пускает :(
Ну нет. Бизнес требует весьма специфических навыков, и отличный специалист в своей области (слесарь, менеджер по продажам, упомянутые врач и учитель, и т.д.) может вообще не уметь вот это вот. Даже не "может", а скорее всего не умеет. Иначе вокруг были бы тыщи и тыщи бизнесменов.
Хм, а зачем нужно предсказывать будущее? Зачем чего-то ожидать?
В процессе дальнейшего чтения я увижу, какие методы вызываются.
Вот для этого точное знание типов вообще не нужно. Достаточно понимать бизнес-смысл происходящего.
Явное указание типов при чтении мешает.
В коде
прекрасно видно бизнес-смысл переменной -- список сотрудников. Какая мне разница, что там за тип:
List<Employee>,Employee[]или вообщеDictionary?Вот если потребуется глубокое погружение в код с целью его модификации (что уже не чтение, а изучение), то тип подскажет IDE.
Тогда любой код с точки зрения этой конкретно команды является качественным (чистым). Поэтому любая нормальная команда начинает вырабатывать свои подходы к обеспечению качества кода.
Понятие "качество кода" определяется строго на уровне команды, не ниже, не выше.
Вы вообще не привели никакой выборки, но при этом сделали глобальный вывод о всей сфере.
Но неадекватен при этом я, да.
Ну да.
_Один мой друг_, сеньор-разработчик, откликнулся на вакансию техписа в СберТехе (зачем – обсуждать не будем). Так вот сразу прислали отказ (без объяснений) и даже не стали проверять, насколько внятно он умеет формулировать свои мысли.
А ничего, что Git и GitHub – это разные вещи?
Ну т.е. из-за того, что попадаются неадекватные заказчики (а они, конечно же, есть) Вы предлагаете всегда изменение требований постфактум считать проблемой исполнителя?
Мы ведь говорим о требованиях, которые были заказчиком утверждены и подписаны, так? Поэтому юридически неа, он бессилен.
Как вариант – почему бы и нет? Но и в этом подходе есть минусы:
Из-за изначально более высоких цен теряем часть потенциальных заказчиков.
Т.к. речь идёт о предсказании будущего, мы будем регулярно промахиваться. И работать в таких ситуациях себе в убыток.
Так вот и я о том, что это аналитик должен знать и учитывать скрытую логику, и вообще бизнес-логику и бизнес-данные. Это он знает, для чего эта задача, какую проблему закрывает и т.д.
Разработчики получают задание в уже очень рафинированном виде, им всё это знать совершенно не нужно. У разработчиков есть свой, огромный пласт знаний – внутреннее устройство системы, и аналитик нужен, в том числе, чтобы разработке не требовалось глубокое погружение в предметную область и бизнес-процессы. Иначе перегрузка и взрыв головного мозга :).
Значит, я неправильно понял, у меня после прочтения сложилось впечатление, что "изменение требований в процессе (или тем более после) разработки – это не проблема заказчика, а проблема исполнителя".
:)
Причём очень большие, ибо предсказывают будущее люди ну оооочень плохо.
Вот здесь непонятно. Если речь идёт про дизайнеров пользовательского интерфейса, то зачем им знать про данные и скрытую логику?
Может быть подразумеваются проектировщики ПО?