Эта статья — один из многих постов в блоге автора. Блог в целом посвящен гибкости, open mind и подобным вещам. Примеры подогнаны для иллюстрации основных идей блога, поэтому технически не всегда удачны.
изменения действительно трудно предсказать, если вообще возможно
Изменения чего? Если представить приложение, речь пойдет о некоей бизнес-логике, которая оперирует бизнес-сущностями (моделями).
Изменение моделей, над которыми на этапе проектирования хорошо подумали (вникли в доменную область заказчика и увидели, что в реальности стоит за описанным в user stories видом со стороны пользователя), происходит достаточно редко. Как правило, это добавление нужных новых полей; пометка deprecated, перевод в опциональные и последующее удаление более ненужных. Здравый смысл и опыт позволяют программисту избегать крайностей (как слишком больших моделей, которые описывают несколько сущностей вместо одной, так и излишне мелких, описывающих малую часть доменной области). И тут нарушенные принципы SOLID — источник вопросов к самому себе, некие флаги, подсказывающие, что что-то с моделью не так, и возможно она требует уточнения или декомпозиции.
Изменение же бизнес-логики при нормально написанных моделях не требует переписывания большого количества кода и не нуждается в предсказании изменений. Если наши сущности адекватно соотносятся с реальностью — ничего не рухнет от изменения порядка вызовов публичных методов или передачи в них других значений в заданных для их параметров рамках.
в будущем кто-то может просто захотеть выполнить операцию сложения без необходимости использовать класс Calculate. Тогда код выше нужно изменить!
С чего такой однозначный вывод? Возможно, этому кому-то для начала стоит доказать коллегам необходимость выполнения операции в обход существующего класса. И в случае успеха — написать новый код.
речь, конечно же, не о C-level managers, их нет в моем комментарии. Это на основе общения в профильных группах — собственный опыт это всегда одна точка, по которой экстраполировать нельзя.
Качество важно, пока оно находится на приемлемом уровне, не важно именно высокое качество. Приемлемое качество все еще может обеспечиваться при продаже джуниора (по хардскиллам) как мидла, а мидла как синьора (разумеется, речь не идет о полном отсутствии у оных софтскиллов).
Рост количества нетехнических сотрудников в индустрии приводит к двум вещам:
они меняют правила игры в первую очередь для повышения ценности собственной работы в глазах бизнеса, большей ее видимости, а не для повышения качества продукта. Думаю, все видели рекламу различных семинаров о том, как правильно убеждать заказчика, зачем ему нужен HR и скрам-мастер на постоянной основе. Кроме того, пропагандируется набор людей независимо от квалификации для соблюдения принципов diversity. Это не приводит к краху даже при низкой квалификации этих людей и малом их вкладе в результат, т.к. в большинстве случаев софт заказывается у аутстафф компаний. А если компания — аутстафер, чем больше людей в проданной команде, тем больше ее доход, независимо от результата конкретного члена команды. Т.е. если на пару разработчиков, производящих продукт (и прошедших полноценное техническое интервью, продемонстрировавших опыт работы), заказчику будет продан SPM, линейный менеджер, скрам мастер, HR, а также приходящие рекрутер и аджайл коуч — компания только выиграет.
они нанимают удобных людей на технические должности выше мидла (т.е. те, с которыми им предстоит работать, и на фоне которых им предстоит выступать перед заказчиком). Принцип социального взаимодействия "кто тут начальник, а кто тут дурак" в современном мире маскируется чуть лучше, но сути не меняет. Синьор должен быть гибким.
Качество продукта и требуемые для него технические знания для синьор+ важны лишь в мелких продуктовых компаниях. Там, где без технической экспертизы не выжить, а на раздувание иерархии из удобных людей нет денег.
Как выход — центральный (он же встроенный) пылесос, правда это больше актуально для домов. Хотя и в квартире можно его выход вывести на улицу через просверленное отверстие в стене. Ну и пневморозетки развести по комнате трубкой внутри гипсокартонной стены, за мебелью, или за плинтусом проштробить, чтобы хотя бы пара точек подключения была, иначе шланг нужен слишком длинный, неудобно.
Считали они процент уничтоженных клеток после воздействия черным фосфором для бактерий E. coli, P. aeruginosa, MRSA, S. typhimurium, B. Cereus, грибков C. albicans, C. auris, C. neoformans (Sensitive), C. neoformans (FR), C. neoformans (AR).
Хуже всего убивались B. cereus — 82.5% ± 6.2%, лучше всего C. albicans 99.9% ± 1.1%, выжившим двух часов экспозиции для уничтожения не хватило.
За те же два часа в контрольной группе P. aeruginosa умерло 20.2% ± 7.3% без всякого фосфора. В обзоре этого очень не хватает, откуда взялась цифра 99% — тем более непонятно.
На Кикстартере собрали в разы больше планируемого проекты Jammy Evo (складная электрогитара, поддерживающая эффекты обычной электрогитары) и Fretlight (электрогитара с подсветкой мест, куда нужно нажимать в режиме обучения игре). Использовали ли что-то из их опыта?
Для Хрома и FF есть плагин Tunable Image Block, который блокирует загрузку только больших по трафику картинок, причем максимальный размер картинки, которую он будет пропускать, можно настроить — это позволит решить проблему на всех сайтах, а не только на Хабре.
Есть babel-preset-php, который синтаксис PHP7, кроме деструкторов, ссылок, die(), суперглобальных массивов с данными запроса и еще некоторых моментов транспилирует в JS, который можно обернуть в Cordova/PhoneGap и получить десктопное или мобильное приложение.
Реальных проектов не видел.
Каким образом наличие опытных программистов, следующих сложным принципам на сложных проектах, мешает новичкам решать свои задачи просто на простых? У PHP замечательная обратная совместимость, можно при желании по старым книжкам писать, если проект позволяет. А вот отсутствие новых фич и интересного в плане структуры кода, понятного и близкого переходящим из других технологий, ведет к неприятию и тому самому мнению, что PHP не умеет то, что могут современные языки, и негде применить свои скиллы, некуда расти.
Есть несколько DIY кофемолок (кофеварки и прочие кофемашины, само собой, не в счет) на Raspberry Pi, на котором Linux. Малинка с линуксом используется для простой интеграции весов, запоминания настроек помола, порции и прочих и отображения UI на экране без необходимости программирования контроллера и пайки.
Моим глазам свет галогенок приятнее LED-ламп, поэтому вместо одной диммируемой ШИМом умной LED лампы стоят группы маломощных галогенных на 220 вольт, каждая группа коммутируется микроконтроллером с оптосимисторами. При ремонте прокладывался сетевой UTP кабель везде, где возможна хоть какая-то автоматизация, поэтому с питанием микроконтроллеров групп проблем не возникало. При возобновлении электричества хаб шлет в МК последнее состояние, присланное в него выключателем той или иной группы перед пропаданием электричества, и сохраненное в нем. Можно при желании на хабе поменять поведение на отправку "выключено", но это неактуально, т.к. свет пропадает редко и ненадолго.
Если однострочная функция возвращает bool, это не значит, что она будет использована в if. Она может быть предназначена для использования в качестве колбэка в функции сортировки или фильтрации, в т.ч. находясь при этом в другом классе или неймспейсе.
Войцеховский Я. Радиоэлектронные игрушки (электроника дома, на работе, в школе) 1978 года — несмотря на игрушки в названии, "Книга содержит сведения о многих электронных устройствах, которые могут найти применение в домашнем хозяйстве, в учебе, при занятиях спортом, музыкой, фотографией и в других сферах, украшающих быт и досуг человека. Книга предназначена для читателей всех возрастов"
Содержание
Для начинающих хороша, покрывает очень много принципов, используемых в различных устройствах. Плюс название каждой схемы и описание отвечает на вопрос "Зачем это?", даже содержание разгруппировано по отраслям. Нравится такой подход.
У любой фичи есть видимая (бизнес-логика, которую видно в UI приложения, если человек пишет фронтенд, или в UI Postman/Swagger, если бэкенд) и невидимая для бизнеса часть (исследование, рефакторинг, построение или изменение абстракций).
Когда фичу делает один человек (ну или два, три человека, мержа код в один фича-бранч), поработать и над видимой, и над невидимой частью достается всем, а в конце майлстоуна видно, кто, каких и сколько фич сделал.
В предлагаемом же варианте человек может делать исключительно невидимую для бизнеса работу, и несет все риски, связанные с этим (хотя в целом команда работает быстрее).
Это удобно для приложений, где много разнородного контента (настолько, что заворачивать в SPA не имеет смысла) и бизнес-правил на сервере. Разные микроприложения находятся на разных страницах сайта. Где шаблонизатор также серверсайд, но при этом нужна и быстрая валидация пользовательского ввода на фронтенде для лучшего UX, поэтому в чистом виде использование серверсайд фреймворков недостаточно. Где валидация пользовательского ввода происходит на сервере по четкой схеме, где скорее будет REST или CQRS, чем GraphQL, а данные для инициализации микроприложения могут приходить прямо при загрузке страницы, в ее коде.
Фронтенд-либы и общий код для разных страниц с микроприложениями доступны по общему пути (и кэшируются в браузере). Код, специфический для каждого микроприложения имеет свои папки.
Из плюсов — быстрый билд, простота отладки, модульность, отсутствие необходимости использования тяжелых frontend-first фреймворков там, где приоритетом является безопасность, гарантируемая логикой на сервере, но при этом нужен современный UX без перезагрузки страницы.
Из минусов — большая связность с бэкендом, роутинг не только на фронтенде (хотя это может быть единственным вариантом для лучшего SEO, если server-side rendering использовать нельзя из-за того, что бэкенд не на NodeJS).
class Season extends Enum {
public const WINTER = 'winter';
public const SPRING = 'spring';
public const SUMMER = 'summer';
public const AUTUMN = 'autumn';
}
$now = Season::AUTUMN(); // Autocomplete works as Season::AUTUMN exists
var_export($now->is(Season::AUTUMN)); // true
var_export("$now" === Season::AUTUMN); // true
var_export($now == Season::AUTUMN); // true
var_export($now == Season::SPRING); // false
echo "$now"; // autumn
class Enum {
protected string $_value;
protected function __construct(string $value) {
$this->_value = $value;
}
public function is($key)
{
return $this->_value === $key;
}
public static function __callStatic($name, $params) {
$value = constant("static::$name");
if (!$value) {
throw new \InvalidArgumentException(static::class . " can't be $name");
}
return new static($value);
}
public function __toString() {
return $this->_value;
}
}
Можно еще таким примером продолжить ряд. IDE это нравится (начав писать Season видим список возможных значений), стринговые ключи можно придумать те, которые нужны (например, чтобы согласовать Snake case и Camel case в стиле кода и там, где используется строковая составляющая), плюс макросы IDE позволяют писать одновременно имя и значение константы. Плюс этим можно пользоваться без создания объекта там, где он не нужен и достаточно лишь строковой константы.
В христианстве это ключевая идея изначально: люди, делайте что хотите, и с вами будут делать, что хотят, вы временно в сендбоксе, который будет свёрнут, когда между вами прекратятся войны, а те, кто покажет за время пребывания в нем способность жить любя ближних — будут сохранены в продакшн и продолжат это делать вечно с теми кто там есть, остальных в топку.
Т.е. это не то чтобы реинкарнация идеи — она живет как минимум две тысячи лет, возможно больше, если она встречалась где-то еще до н.э.
Эта статья — один из многих постов в блоге автора. Блог в целом посвящен гибкости, open mind и подобным вещам. Примеры подогнаны для иллюстрации основных идей блога, поэтому технически не всегда удачны.
Изменения чего? Если представить приложение, речь пойдет о некоей бизнес-логике, которая оперирует бизнес-сущностями (моделями).
Изменение моделей, над которыми на этапе проектирования хорошо подумали (вникли в доменную область заказчика и увидели, что в реальности стоит за описанным в user stories видом со стороны пользователя), происходит достаточно редко. Как правило, это добавление нужных новых полей; пометка deprecated, перевод в опциональные и последующее удаление более ненужных. Здравый смысл и опыт позволяют программисту избегать крайностей (как слишком больших моделей, которые описывают несколько сущностей вместо одной, так и излишне мелких, описывающих малую часть доменной области). И тут нарушенные принципы SOLID — источник вопросов к самому себе, некие флаги, подсказывающие, что что-то с моделью не так, и возможно она требует уточнения или декомпозиции.
Изменение же бизнес-логики при нормально написанных моделях не требует переписывания большого количества кода и не нуждается в предсказании изменений. Если наши сущности адекватно соотносятся с реальностью — ничего не рухнет от изменения порядка вызовов публичных методов или передачи в них других значений в заданных для их параметров рамках.
С чего такой однозначный вывод? Возможно, этому кому-то для начала стоит доказать коллегам необходимость выполнения операции в обход существующего класса. И в случае успеха — написать новый код.
while (a--) b-=-1;
речь, конечно же, не о C-level managers, их нет в моем комментарии. Это на основе общения в профильных группах — собственный опыт это всегда одна точка, по которой экстраполировать нельзя.
Качество важно, пока оно находится на приемлемом уровне, не важно именно высокое качество. Приемлемое качество все еще может обеспечиваться при продаже джуниора (по хардскиллам) как мидла, а мидла как синьора (разумеется, речь не идет о полном отсутствии у оных софтскиллов).
Рост количества нетехнических сотрудников в индустрии приводит к двум вещам:
Качество продукта и требуемые для него технические знания для синьор+ важны лишь в мелких продуктовых компаниях. Там, где без технической экспертизы не выжить, а на раздувание иерархии из удобных людей нет денег.
Как выход — центральный (он же встроенный) пылесос, правда это больше актуально для домов. Хотя и в квартире можно его выход вывести на улицу через просверленное отверстие в стене. Ну и пневморозетки развести по комнате трубкой внутри гипсокартонной стены, за мебелью, или за плинтусом проштробить, чтобы хотя бы пара точек подключения была, иначе шланг нужен слишком длинный, неудобно.
DRM — слишком громкое название. Там всего лишь счетчик остатка в EEPROM, 1 байт, лежащий по постоянному адресу 0xA1, без какой-либо защиты, в который прописывается значение как у новой кассеты.
Считали они процент уничтоженных клеток после воздействия черным фосфором для бактерий E. coli, P. aeruginosa, MRSA, S. typhimurium, B. Cereus, грибков C. albicans, C. auris, C. neoformans (Sensitive), C. neoformans (FR), C. neoformans (AR).
Хуже всего убивались B. cereus — 82.5% ± 6.2%, лучше всего C. albicans 99.9% ± 1.1%, выжившим двух часов экспозиции для уничтожения не хватило.
За те же два часа в контрольной группе P. aeruginosa умерло 20.2% ± 7.3% без всякого фосфора. В обзоре этого очень не хватает, откуда взялась цифра 99% — тем более непонятно.
На Кикстартере собрали в разы больше планируемого проекты Jammy Evo (складная электрогитара, поддерживающая эффекты обычной электрогитары) и Fretlight (электрогитара с подсветкой мест, куда нужно нажимать в режиме обучения игре). Использовали ли что-то из их опыта?
Для Хрома и FF есть плагин Tunable Image Block, который блокирует загрузку только больших по трафику картинок, причем максимальный размер картинки, которую он будет пропускать, можно настроить — это позволит решить проблему на всех сайтах, а не только на Хабре.
Есть babel-preset-php, который синтаксис PHP7, кроме деструкторов, ссылок, die(), суперглобальных массивов с данными запроса и еще некоторых моментов транспилирует в JS, который можно обернуть в Cordova/PhoneGap и получить десктопное или мобильное приложение.
Реальных проектов не видел.
Каким образом наличие опытных программистов, следующих сложным принципам на сложных проектах, мешает новичкам решать свои задачи просто на простых? У PHP замечательная обратная совместимость, можно при желании по старым книжкам писать, если проект позволяет. А вот отсутствие новых фич и интересного в плане структуры кода, понятного и близкого переходящим из других технологий, ведет к неприятию и тому самому мнению, что PHP не умеет то, что могут современные языки, и негде применить свои скиллы, некуда расти.
Есть несколько DIY кофемолок (кофеварки и прочие кофемашины, само собой, не в счет) на Raspberry Pi, на котором Linux. Малинка с линуксом используется для простой интеграции весов, запоминания настроек помола, порции и прочих и отображения UI на экране без необходимости программирования контроллера и пайки.
Моим глазам свет галогенок приятнее LED-ламп, поэтому вместо одной диммируемой ШИМом умной LED лампы стоят группы маломощных галогенных на 220 вольт, каждая группа коммутируется микроконтроллером с оптосимисторами. При ремонте прокладывался сетевой UTP кабель везде, где возможна хоть какая-то автоматизация, поэтому с питанием микроконтроллеров групп проблем не возникало. При возобновлении электричества хаб шлет в МК последнее состояние, присланное в него выключателем той или иной группы перед пропаданием электричества, и сохраненное в нем. Можно при желании на хабе поменять поведение на отправку "выключено", но это неактуально, т.к. свет пропадает редко и ненадолго.
google "медведи (субкультура)"
Если однострочная функция возвращает bool, это не значит, что она будет использована в if. Она может быть предназначена для использования в качестве колбэка в функции сортировки или фильтрации, в т.ч. находясь при этом в другом классе или неймспейсе.
Войцеховский Я. Радиоэлектронные игрушки (электроника дома, на работе, в школе) 1978 года — несмотря на игрушки в названии, "Книга содержит сведения о многих электронных устройствах, которые могут найти применение в домашнем хозяйстве, в учебе, при занятиях спортом, музыкой, фотографией и в других сферах, украшающих быт и досуг человека. Книга предназначена для читателей всех возрастов"
Для начинающих хороша, покрывает очень много принципов, используемых в различных устройствах. Плюс название каждой схемы и описание отвечает на вопрос "Зачем это?", даже содержание разгруппировано по отраслям. Нравится такой подход.
Когда фичу делает один человек (ну или два, три человека, мержа код в один фича-бранч), поработать и над видимой, и над невидимой частью достается всем, а в конце майлстоуна видно, кто, каких и сколько фич сделал.
В предлагаемом же варианте человек может делать исключительно невидимую для бизнеса работу, и несет все риски, связанные с этим (хотя в целом команда работает быстрее).
Фронтенд-либы и общий код для разных страниц с микроприложениями доступны по общему пути (и кэшируются в браузере). Код, специфический для каждого микроприложения имеет свои папки.
Из плюсов — быстрый билд, простота отладки, модульность, отсутствие необходимости использования тяжелых frontend-first фреймворков там, где приоритетом является безопасность, гарантируемая логикой на сервере, но при этом нужен современный UX без перезагрузки страницы.
Из минусов — большая связность с бэкендом, роутинг не только на фронтенде (хотя это может быть единственным вариантом для лучшего SEO, если server-side rendering использовать нельзя из-за того, что бэкенд не на NodeJS).
Можно еще таким примером продолжить ряд. IDE это нравится (начав писать Season видим список возможных значений), стринговые ключи можно придумать те, которые нужны (например, чтобы согласовать Snake case и Camel case в стиле кода и там, где используется строковая составляющая), плюс макросы IDE позволяют писать одновременно имя и значение константы. Плюс этим можно пользоваться без создания объекта там, где он не нужен и достаточно лишь строковой константы.
Т.е. это не то чтобы реинкарнация идеи — она живет как минимум две тысячи лет, возможно больше, если она встречалась где-то еще до н.э.