Комментарии 331
О, наконец то нормальный программист, а не выращенная маркетологами макака на стероидах. Спасибо!
"Макака, позиционирующая себя крутым программистом". Освоила стримы и реактивку, но еще не умеет их НЕ применять.
Я всегда пишу огромные мануалы по проделанной работе, указывая все мелочи, вплоть до версий пакетов, если эту работу предстоит делать в будущем, снова, потомкам. И, как правило, я и есть этот потомок ;) А так-же оставляю в коде ссылки на свой git\linkedin для вопросов тех, кто будет продолжать работу.
Автор не тупой, а заботливый.
Просто эталон программистского благочестия. Сам себя не похвалишь - никто не похвалит.
О! Интересно. А как к принципам "Чистого кода" Мартина относишься? Для меня наоборот, это сильно упрощает понимание и работу с кодом (если пишу свой, конечно). Наследование имхо слишком сложно.
Это перевод, под заголовком есть ссылка на сайт автора.
Вот к этому самому "Чистому коду" надо на самом деле относиться с опаской. Бездумное применение его практик может приводить к внушительным потерям в производительности программ - именно из-за следования советам этой книги.
Подробнее в статье на английском: https://www.computerenhance.com/p/clean-code-horrible-performance
Эту "статью на английском" тут уже не раз переводили и разбирали в комментариях, она чуть более чем наполовину состоит из откровенного натягивания совы на глобус и выдачи желаемого за действительное.
"Чистого кода" Мартина слегка устарел, т.к. был написан под Java 5 и за пределами этой самой Java выглядит многословно.
Ну и ряд тейков в книге у него было откровенно вредительских - типа функции которые в идеале не принимают аргументов и многопоточка не дает прироста по перфу. Самое смешное, это там где он привел листинг кода на 7 страниц книги с ремаркой внизу, что ~"реализовал тоже самое на питоне в 5 раз короче, а все потому-что Java многословный язык"
Из прикольного, читал про Domain Driven Development, который выглядит адекватно и на самом деле это адекватный чисто-код с понятными плюсами и минусами.
А "Чистокодить" за пределами Java, например в плюсах, это моветон
Все зависит от нефункциональных требований к приложению
Если вам хватает (а почему бы и нет) - от ок. Но с какого-то уровня может не хватить
И с течением лет пришел к осознанию, что я не очень умный.
Не наговаривайте на себя. "Не очень умный" - это, например, программист, который в системе бронирования авиабилетов не может различить двух пассажиров с одинаковыми именами (см. соседнюю новость на Хабре).
У меня есть сомнения, что именно разработчик лично решил сравнивать пассажиров именно так. Возможно программист таки рвался сделать всё правильно, но ТЗ есть ТЗ, и порой переубедить заказчика, что фигня получится - не так уж просто...)
Из личной практики:
— Вы хотите написать систему управления многоквартирным домом и хотите запретить регистрироваться в нём пользователю, если человек с таким же ФИО уже зарегистрировался в системе. Но вот смотрите, в моём доме живёт три человека с совпадающим ФИО...
— Ну какая вероятность, что такое произойдёт вообще? Меньше одного процента? Мы пренебрежём этой возможностью совпадения.
Полгода переговоров параллельно с разработкой ТЗ ни к чему не привели, требование ушло в работу :)
— Ну какая вероятность, что такое произойдёт вообще? Меньше одного процента? Мы пренебрежём этой возможностью совпадения.
О да! Классический шаг в бездну потенциального секса с проектом через полгода год. И каждый раз одна и та же картинка. Как только произносятся ключевые слова про "вероятностью в 1% надо пренебречь" можно смело планировать время на глубокий рефакторинг спустя полгода. И про "1% пронебречь" уже никто не вспомнит, а зачем нужен рефакторинг придется обосновывать.
Немножко подушню, а чем тут поможет глубокий рефакторинг, если это по определению "процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения" (с), а тут клюнул жареный процент и внешнее поведение не устраивает? Можно смело планировать время на переписывание проекта.
глубокий рефакторинг != рефакторинг ... ну как то так)
Если говорить серьезно, бизнесу же не важно, что там внутри. Может там совсем новая версия будет. Или старая, но теперь она (как в примере выше) умеет рассылать письма менеджерам с уведомлениями, что "вау! редкое событие таки наступило, чините парни руками прямо в бэдэшечке".
В программировании 1% - это ведь буквально овердохрена. Это значит, что столкнёшься с этим явлением а) обязательно; б) скоро; в) неоднократно. Если, допустим, запрограммировать Псалтырь, чтобы, в результате бага, произвольное слово с вероятностью 1% подменялось матерным ругательством - матерных ругательств там будет в среднем по одному-два на страницу, а не "спустя полгода пренебречь". Чтобы хоть в каком-то приближении можно было "пренебречь" (читай: "спихнуть, пока не заметили") - это какие-то сотые-тысячные доли процента должны быть, а не единицы.
Оооо да, я для менеджеров сразу открываю карькулявтор и ввожу цифры "от 200 (заказов в день) * 365 дней в году / 100 = 730 раз в год эта канистра будет фигачить тебя по голове, занимать по 30 минут объяснений CX клиенту и час разбирательств тебя и любимого начальника". Довольно быстро доходит, что + 3-5 дней на поработку выходят дешевле.
про "1% пронебречь" уже никто не вспомнит
а вы записывайте
Лет пятнадцать назад читал одну историю (к сожалению, сейчас найти не могу). Смысл такой: программист бодался с менеджером (или постановщиком, или ключевым пользователем) по поводу ТЗ (какое-то деловое ПО ), и в алгоритме одна из ветвей "вела в никуда". Менеджер доказывал, что "такое сочетание событий не то, чтоб крайне маловероятно, но вообще никогда не может быть". Ну, договорились, что в этом случае будет приходить письмо на электронную почту этого менеджера. В общем, за неделю там накопилось несколько сотен писем...
Поэтому я если слышу слова "никогда" или "маловероятно" - я знаю, что это наверняка случится. И чем меньше заявляют вероятность, тем скорее это произойдет...
Похоже на закон Мёрфи.
Может, и Закон Мерфи. Но скорее всего, эта ситуация была регулярна, как-то обрабатывалась исполнителями (линейными сотрудниками), а менеджер был "не в курсе". поэтому я частенько контактирую не только с постановщиками, но и с исполнителями... "чтоб сто раз не переделывать".
Да, ими и надо руководствоваться в разработке. :-)
Ну, договорились, что в этом случае будет приходить письмо на электронную почту этого менеджера. В общем, за неделю там накопилось несколько сотен писем...
А ведь это гениальная идея)
конец нулевых, самописаный сервис деск на пыхе, ловим странное исключение в логе... нахожу его в коде, а там после обработки пачки кейсов, которые по задумке покрывают все случаи, стоит выброс исключения с комментарием - этого никогда не должно случится
А какая альтернатива решающая проблему была предложена заказчику и почему он отказался?
Не вводить это ограничение, как избыточное :) И относящееся к проблеме, которой нет. Полные тёзки в этой системе никаких проблем друг другу не создавали.
Но тогда получается, что можно одному человеку 100 раз регистрироваться, разве это нормально?
Вводятся дополнительные критерии - огграничители, к примеру "номер телефона", "год рождения", ИМЕИ и пр. данные конфигурации железки - источника запроса. Это просто "навскидку", там много можно чем дополнять ФИО.
Но тогда получается, что можно одному человеку 100 раз регистрироваться, разве это нормально?
Конечно нормально. Что мешает одному человеку выкупить несколько квартир в одном доме для сдачи внаем / инвестирования ?
Если речь про регистрацию, которая "прописка", то кажется что номер паспорта неплохое ограничение. Не идеальное, но неплохое.
Речь о "системе управления многоквартирным домом". Тут всё еще проще: номер квартиры.
И тут внезапно отец и сын, полные тёзки, в пролёте.
Квартира может потом после развода разделиться на разные доли и даже коммуналка будет приходить на разные условные комнаты
и тут была большая и сложная проблема, поскольку клиент просил нормализацию номеров квартир до простого числа, а я отбивался жизненными примерами такого вида:
И даже в некоторой элитной недвижимости бывают номера квартир, условно, «кв. 305,311» — потому что двухуровневая, на двух этажах
Ага, чтобы так сразу в 152ФЗ с головой нырнуть и не вынырнуть...
А еще паспорта могут менять...
Увы - плохое. регистрация вообще в другом месте может быть. Владелец он такой - может быть зарегистрирован где угодно )). А номер паспорта - не слишком ли круто? эти данные еще и защищать придется. а паспорта еще и меняют..
Тут странности со стороны менеджера. Обычно наоборот бывает, В данном случае, добавление такого условия, это очевидное добавление ефортов, так как надо отдельно обрабатывать ситуацию с одинаковыми именами.
Т. е для заказчика это доп. траты. Заказчик обычно не тупой, и такие вещи спецом добавляет, типа вы такой ему, да зачем это делать, заказчик соглашается, убирается пункт из ТЗ и уменьшается стоимость. Ну вам же меньше делать.
Наоборот такие вещи надо делать без обсуждения, а уже потом за отдельную плату удалять.
Год назад, работая в сфере ЖКУ я уже слышал такое. Ушел раньше начала написания по ТЗ .. нахер. Не одно ли это место, случаем? ;)
Даже в пределах одной квартиры, не то что дома, ФИО могут повторяться
Это ТЗ не значит ведь, что вы будете хранить пользователей в базе по уникальному ФИО? Ведь не значит?
[падме.жпг]
Забавно, хабр выдал это по вашей ссылке на новость.
Буквально вчера видел this.messages is null вместо ленты статей )))
Да что-т глючит Хабр в последнее время, навигация по "F" через раз работает, ошибки сыплет и помечает все комменты прочитанными. @Boomburum что-то неладное творится, уровень счастья пользователей Хабра падает.
У меня была другая история. Вылетал из Схипхол (Амстердам), было два рейса одновременно на Прагу. Мало того, что кто-то додумался их поставить в одно и то же время, так они были в разных гейтах и на табло был отображен только один. Попался на этот косяк не только я - в итоге еле успел. Теперь всегда помимо времени вылета проверяю на табло еще и номер рейса.
Удивительно, как можно не смотреть на номер рейса?
Это происходит так: бежишь глазами по табло по отсортированному времени, зная время и город назначения. Находишь нужную строчку и идешь в гейт. Там перепроверяешь время вылета и город на экране (ведь типа весь такой предусмотрительный). Но не номер рейса, т.к. интуитивно не предполагаешь (не предполагал раньше) такой подставы. И спокойно ждешь до последнего момента.
Билет корпоративный, поэтому на такие детали как авиакомпания и прочее почти не обращаешь внимания.
В каком-то смысле это и есть вершина эволюции отдельного человека — познать ограничения и адаптироваться к ним. И да, если вам хватило возможностей разума работать с кодом, то вы умнее 95% людей. Многим не по силам даже в арифметику и прогнозирование собственных действий на 2 шага вперёд.
И да, если вам хватило возможностей разума работать с кодом, то вы умнее 95% людей.
Нет.
он вместо того, чтобы разобраться.натренироваться - занимается избеганием и придумывает себе оправдания в виде тупости, хотя я уверен, что он совсем не разбирается в тупости
Потенциально существует интеллект, для которого самые умные программисты - просто муравьи барахтающиеся в банке. Все люди разные. Самое главное: не переставать учиться и развиваться. Статья и ее резонанс не о чем.
Гениально! Я смотрю тут многие не поняли про что написано и давай хейт разводить. А смысл прост - писать просто настолько насколько можно. Выкинуть всё ненужное настолько - что бы программа выполняла только то что от неё требуют.
До этой мысли приходишь только спустя годы или даже десятилетия программирования.
А всё от того что написав свой код, спустя месяц ты на него смотришь, и что бы понять что там происходит тратишь день, а не 10 минут. Я не говорю про чужой код.
В 99% случаях сложная иерархия классов на старте никому в последствии ненужна. А только будет доставлять неимоверный гимор в разработке. Опять же если проект растёт - то гораздо проще переписать уже устоявшуюся архитектуру с нуля, чем писать очередной костыль который будет бороться с изначально неправильной архитектурой.
И такой подход имеет свою особенность. Код становится выглядеть "примитивным". Отсутствуют наследования, инъекции, полиморфизм - да вообще всё. Любой новичок посмотрев на такой код сразу понимает как он работает.
Но как написали в статье: в "Гуглах" будут воротить нос.
Вполне нормальный подход. Недавно где-то глаз зацепился: после jquery пошел бурный рост и развитие разных framewors: react, node, angular, vue, svelte - а все равно 77% сайтов на настоящий момент используют jquery :) Не близко к тексту - но посыл был примерно такой.
Кстати добавлю как у меня получается писать "просто".
Многие наверно подумаю что это же "просто"! А вот нифига. Написать "просто" - сложнее чем просто написать ))) Извините за каламбур.
Короче я это делаю в 2 или в 3 подхода. Сначала пишешь как есть. Когда код работает - даёшь ему отлежатся. Плюс со временем в него добавляются новые фичи.
Потом когда код перестаёт интенсивно расти - возвращаешься к нему и выкидываешь, склеиваешь функции по максимуму, упрощаешь логику.
И да я описал банальный рефакторинг. Который в современном бизнесе совсем не ценится.
3 итерация это возвращение к коду спустя продолжительное время - когда поменялась архитектура. И причёсываешь код под новую архитектуру. при этом не забывая выкидывать и упрощать.
Может показаться что это бесконечный процесс - но как показала практика, такое выкидывание и упрощение всегда приближается к какому то максимуму и останавливается. Это похоже на ёмкость заполненную разными фигурами. Сначала все они лежат в разнобок. Но со временем все фигуры укладываются упорядоченно одна за другой. Что то типа тетриса. В результате все фигуры претёрты друг к другу.
Положительный момент - отлавливаются много упущенных багов.
Отрицательный - бизнесу такое нафиг не нужно.
P.S. И забыл добавить. Итерация 2 и 3 не привязаны ко времени. Они привязаны к ситуации. Т.е. происходят тогда когда они нужны. Тогда при рефакторинге ты находишься максимально в мейнстриме. И рефакторинг происходит максимально безболезненно. Имеется виду безболезненно для психики программиста. Никто же не хочет разгребать этот поганый легаси )))
"усложнять - просто. Упрощать - сложно!"©Законы Мэрфи
Многие наверно подумаю что это же "просто"! А вот нифига. Написать "просто" - сложнее чем просто написать
Еще у Паскаля было: "Письмо это вышло более длинным только потому, что у меня не было времени написать короче". В общем, это просто проблема оптимизации, которая обычно не решается за 2-3 итерации. За это время можно даже не успеть понять, что конкретно следует оптимизировать и в ущерб чему.
У меня попроще - второй этап как третий, спустя полгода :D
Вот сейчас как раз занимаюсь переписыванием того, что было реализовано год назад - половина кода стёрта окончательно (а не закомментирована, как до этого обычно делали), большая часть конструкций упростилась, entity framework пошёл лесом - SqlConnection хватает за глаза. Спасибо M$ за Minimal API - громоздкие контроллеры
заменены несколькими строками
Через какое-то время может быть ещё где-то можно будет упростить, но пока что мне кажется, что проще не сделать. Опыта всего ничего)
Через какое-то время может быть ещё где-то можно будет упростить
Уберите префикс "Map.." из всех этих MapGroup, MapGet и тд
Не убрать, это стандартная реализация https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis
Удачи вам в ваших упрощениях. Уверен, придет время и вам придется все возвращать назад. Не зря ведь говорят, что простота она часто хуже воровства :) Все эти "minimal bla-bla-bla" они обычно только для примеров масштаба "Hello world" хороши.
Уверен, что не придёт. Яне в кровавом энтерпрайзе работаю)
Так я и не говорю, что всем срочно надо всё бросать и переходить на такие упрощения в виде minimal api 🤔 Для каждой задачи свой инструмент. Нам такой очень даже подходит для небольших бекендов.
Вместо методов громоздкого контроллера у вас вызываются такие же методы некоего сервиса. Разница только в том что у вас еще и все эти Map... вручную прописаны. Где тут упрощение?
Отож. Причем код специфичный для web наверняка смешивается с кодом БЛ - ведь SRP и слоенную архитектуру придумали для "выращенных маркетологами макак на стероидах".
Мы говорим о Minimal API в контексте .NET. Здесь упрощение в том, что нет лишних файлов (по одному на каждый контроллер) и соответственно нет лишних методов. Для написания микросервисов очень даже подходит.
Представьте, что MapGroup в примере это отдельный файл, а все анонимные методы из MapGet, MapPost итд самостоятельные методы. Это будет стандартный вид проекта. Если нам надо только жсоны перекладывать, зачем же писать весь этот код ради дёрганья методов из сервиса? Так и появился Minimal API, где всю маршрутизацию можно формить в таком виде. Оно и раньше было в виде отдельных опенсурсных пакетов, теперь официально поддерживается Microsoft.
jQuery будет жить до тех пор, пока в CSS наконец не завезут возможность анимировать height от 0 до auto. Все остальные функции легко заменяются нативным кодом.
В 99% случаях сложная иерархия классов на старте никому в последствии ненужна.
Почти каждый раз, когда мне приходилось переписывать готовый код, я ругался на себя из-за того, что поленился сразу нашарашить класссов и вообще поработать с архитектурой. Потому что все равно приходится. Важно на этапе начала понимать - может ли возникнуть ситуация дописывания с необходимостью усложнять и переструктурировать код или нет. Потому что было и обратное - заложил пользовательские объекты под развитие, а развития никому нафиг не надо, хотя напрашивается.
Опять же если проект растёт - то гораздо проще переписать уже устоявшуюся архитектуру с нуля, чем писать очередной костыль который будет бороться с изначально неправильной архитектурой.
Времени переписывать уже устоявшуюся архитектуру с нуля могут и не дать. Помню, как я переписывал эту "устоявшуюся архитектуру", а меня в спину пихали, что "устоявшаяся архитектура" плохо работает на заказах с объемом отгрузок более 32 чертовых паллет, а все потому, что изначально исходил из того, что все объекты в интерфейсе влезают в одно пользовательское окно, потому что больше 32 паллет в еврофуру не загрузишь, и тут появился заказчик, который грузил вагонами. И приходилось по каждому сообщению об ошибке у пользователей(благо они были не часты) прерываться, залезать в заказ, ручками через графический интерфейс делать то, что должен делать код, ставить костыль там где можно его поставить и дальше - переписывать все и вся. Потому лучше изначально было закладывать бесконечное количество паллет в заказе и делать некоторые избыточные решения посложней, чтобы не мучиться
В целом никто не закладывается на рефакторинг, надеяться на то, что "потом переделаем" вообще не стоит. Я как-то для себя сделал автоматизацию отчета на коленке, формировался он достаточно долго, в файл записывал кучу лишнего, ничего, думал я, потому почищу, перепишу по-человечески. 4 года после этого я проработал в этой компании, 4 года ежедневно у меня отсылался этот отчет. 4 года над монитором провисела бумажка о том. что надо переписать отчет. 4 года я ругался за то, что меня ждут 15 человек в маршрутке, а отчет еще формируется. Я не только для себя его не переписал, но к концу 4-го года скинул на коллегу, с твердым намерением переписать в первый же день, когда в офисе буду пробку на МКАДе пережидать. Нет, не переписал.
Почти каждый раз, когда мне приходилось переписывать готовый код, я ругаюсь на себя из-за того, что поленился нашарашить класссов и вообще поработать с архитектурой.
Смотрите в чём фундаментальная проблема. На старте вы не знаете какая архитектура будет в конце. Если вы знаете это - то вам выгоднее в казино ходить. Но будем исходить из того что не знаете.
Отсюда вывод на старте вы закладываете неправильную архитектуру. И в конце вы будите героически бороться с этой неправильной архитектурой.
Если на старте вы закладываете минимальную архитектуру. Либо наращиваете архитектуру по мере разработки, конечно придётся постоянно рефакторить, то ситуация в конце будет выглядеть скажем так "по приятнее".
Ваша же конкретная проблема архитектуры которая пила из вас соки, конечно если бы вы заложились на старте её решение - то и проблемы бы не было. Но где вероятность того что вы бы угадали на старте про именно эту проблему?
Кстати я тут ничего от себя не придумываю. Краеугольный камень всей современной разработки - аджайл, как раз исходит из того что ничего не известно. Через неделю всё может поменяться на противоположное. Поэтому всё делим на спритны, и каждый спринт всё перосмысливаем.
А история которую вы описали про программу - это "база" ))) У каждого программера есть такая программа написанная на коленки чисто на сегодня поюзать и выкинуть. Но что то пошло не так... )))
И это верно. Не реально на старте заложить все верно. Так как слишком много неизвестных.
Но продумать заранее возможные варианты, зная предметную область - вполне возможно.
Вот конкретный пример:
ТЗ: "для определенного клиента определенная номенклатура должна отгружаться с остаточным сроком годности 70%, остальным клиентам - 50%". условие "для остальных" уже сделано. Самое простое и тупое решение - "захардкодить" (точно так же, как сделано с "50%"). Чуть сложнее - таблица с клиентом, номенклатурой и сроком. Учитывая, что клиенты могут меняться (добавились такие же привередливые клиенты), ассортимент может меняться (появился скоропорт), да и срок тоже (изменилось качество сервиса) - была сделана таблица "клиент/группа клиентов" - "номенклатура/группа номенклатуры" - ОСГ. Из которой выбирается "последовательным уточнением" нужный срок.
Вместо условного "часа" - "там всего-то строчку добавить" - было затрачено пара дней. Зато управлять "исключениями из правил" могут сами ответственные пользователи. И этих "строк исключений" уже с полтысячи...
Если бы с самого начала "не усложнять", то сколько бы было "рефакторингов" - не берусь сказать...
Не работайте с такими постановщиками!!!
Как только вы это напишите, залетит желание на 72 и 52,5 процента, причем для каждого клиента индивидуально...
Однозначно!
Любые конкретные значения стараюсь всегда делать в доступных пользователям настройках.
С какими именно?
поясните, плз...
Выше Вам ответили.
Любые параметры бизнеса, не должны быть прописаны в коде. Если бизнес говорит "есть исключение", для Вас это означает, что вводимый как чье-то конкретное исключение параметр, в дальнейшем будет применяться как типовой для всех.
Аналитики, проектировщики почему-то не понимают, что пока нет инструмента, бизнес хочет чтобы он появился побыстрее и поэтому не думает над тем, какие у него появятся хотелки, когда первая версия инструмента заработает.
Ответили столь же невнятно, как и вы.
Повторюсь еще раз: "бизнес" хотел "обработать возникшую ситуацию". Поставил задачу так, как ее увидел. Это для определенных условий (устоявшихся процессов, и уровня мышления определенной части персонала) вполне нормально.
То, что я изменил и постановку, и реализацию задачи (еще и объяснил, утвердил у руководства и научил пользователей) - всего лишь отражение моего опыта. Которое и позволило реализовать "желание на 72 и 52,5 процента, причем для каждого клиента индивидуально..." без необходимости кодинга, параметрическими настройками. Потому, что предусмотрел именно возникновение таких потребностей в дальнейшем.
Выносить все настройки в параметрические - тоже глупость. Ибо бОльшее количество параметрических настроек вызывает излишний рост сложности везде - и в данных, и в коде, и в управлении данными, и в рефакторинге в дальнейшем. Везде нужен баланс
Я бы с самого начала эту логику засунул в отдельный абстрактный компонент по принципу паттерна "стратегия", исходную его реализацию сделал бы с константами, как написано, а потом, когда выяснилось бы, что в константы логика не укладывается, то сделал бы другую (скорее всего даже параллельную) реализацию с отдельными значениями по клиентам/номенклатурам и проч. Но меня бы тут, наверное, за такое сразу назвали бы "энтерпрайзной макакой" :))
А в одном не любимом многими продукте, любой начинающий, создал бы регистр сведений состоящий из измерений "контрагент", "номенклатура" и ресурса "срок годности". Сам отбор номенклатуры для отгрузки конкретному контрагенту формировал бы с учетом этого регистра. А о том, что там юзеры конкретного бизнеса занесут в этот регистр, даже бы не парился...
А если окажется что это еще должно зависеть не от (или не только от) "что там юзеры конкретного бизнеса занесут в этот регистр", а от фазы Луны и високосного года? Вот смотрите, допустим я вообще в душе не знаю всех этих слов "номенклатура", "остаточный срок" и прочее - мне вот это просто аналитики прислали на реализацию. Но я при этом, исходя из опыта, сразу вижу, что речь идет о вычислении какой-то величины в соответствии с какой-то политикой, а следовательно, эта политика может просто со временем взять и измениться. А это уже явный сигнал к выносу этого в отдельный и легко в случае надобности заменяемый компонент, что и есть паттерн "стратегия".
Чуть выше, в другой ветке, я написал «не работайте с такими постановщиками задач». Проблема для Вас заключается в том, что, если постановщик недалекий и неумный, то, как бы качественно вы не выполнили свою работу, результат будет один — бизнес будет недоволен работой такой команды.
А это уже явный сигнал к выносу этого в отдельный и легко в случае надобности заменяемый компонент, что и есть паттерн "стратегия"
Вот!!! Это понимание того, что для того чтобы писать для бизнеса, нужны соответствующие бизнес ориентированные библиотеки и наборы метаданных. Причем желательно заточенных под конкретную отрасль бизнеса. Но кто же будет тратить время на их написание, ведь за это бизнес не заплатит.
Проще ругать "не уважаемый продукт", но в нем вы можете не знать, что такое "номенклатура" и ее характеристики, но глянув описание этих метаданных вы поймете и будете использовать в своей доработке не сломав остальной работающий код.
Я специально так завернул "доработке", дело в том, что любая программа это инструмент за который платит бизнес. И естественно бизнес хочет, чтобы его инструмент жил и развивался вместе с ним. Но большинство разработчиков, относится к результату своего труда, как к одноразовой работе - сделал и забыл...
...а от фазы Луны и високосного года?
будет добавлено еще одно измерение в этом же регистре "фаза луны" и простая функция расчета фазы для конкретного дня текущего (или любого другого) года. А високосный год или нет об этом знает сама платформа.
будет добавлено еще одно измерение в этом же регистре "фаза луны" и простая функция расчета фазы для конкретного дня текущего (или любого другого) года. А високосный год или нет об этом знает сама платформа.
И со временем получаем код увешанный мильоном if-ов и switch-ей, которые из своих веток еще и выполняют SQL-запросы вбитые в код текстом (мы же за простоту и ORM принципиально с самого начала не используем :))
мы же за простоту и ORM принципиально с самого начала не используем...
Это подход разработчика.
А я пишу со стороны заказчика. Поставленная задача должна быть решена и желательно не так чтобы на следующем этапе ее надо будет переписывать заново.
Если честно, то мне не понятно и не интересно, почему сами разработчики усложнили себе жизнь написав кучи однотипных/различных фрэймворков, придумав стопитсот разных технологий якобы для облегчения своего труда, не придумали ни чего стандартизированного для решения конкретных "бизнесовых задач" за исключением одного, неуважаемого в определенных кругах продукта.
Почему разработчики считают, что бизнес должен ставить им задачу познав дзен и предсказав как она будет выглядеть через несколько лет. Что впрочем всё равно не даст бизнесу сто процентную гарантию, что его задача будет решена, а не утонет в метаниях разработчика применять ORM или нет, использовать фрэймворк ХХХ или YYY, и т.д и т.п.
Возможно я кого-то из программистов обижу, но если простейшее, понятное, обоснованное требование сделать дневной и ночной режим для пользовательского экрана, превратилось в серьезную проблему, на решение которой требуются месяцы а то и годы, то это значит программирование как отрасль производства, где свернуло не в ту сторону.
Если честно, то мне не понятно и не интересно, почему сами разработчики усложнили себе жизнь написав кучи однотипных/различных фрэймворков, придумав стопитсот разных технологий якобы для облегчения своего труда, не придумали ни чего стандартизированного для решения конкретных "бизнесовых задач" за исключением одного, неуважаемого в определенных кругах продукта.
А что есть "бизнесовая задача" в вашем понимании?
Ну вот мы используем специализированный инструмент для решения "бизнесовых задач". Специально для этого заточенный "от и до" - железо, операционка, язык. Высоконадежный, высокопроизводительный.
А теперь вопрос к бизнесу - вы готовы закупить недешевую, вендер-лок платформу, заточенную под "решение бизнесовых задач"? Или вам надо чтобы подешевле да попроще, да без вендерлоков, да чтобы купить в соседнем магазине можно было?
Если второй вариант, то получите то, что получите. Покупаете что подешевле, потом на это начинаете городить сборную солянку - БД, языки и все прочее.
Если первое - получаете все в одной коробке - сервер с системой, интегрированной БД, интегрированными средствами разработки и вообще всем, что нужно для работы. Но дорого.
Ну вот мы используем специализированный инструмент для решения "бизнесовых задач". Специально для этого заточенный "от и до" - железо, операционка, язык. Высоконадежный, высокопроизводительный.
Я заранее прошу прощения и не имею желания Вас обидеть или задеть! Но именно примерно такие слова я слышал когда несколько лет назад заказал разработку продукта который открыт у меня на соседнем экране. С этими разработчиками ни чего не произошло, они в добром здравии, приятные в общении и хорошие по жизни люди, но это теперь не область интересов их коллектива. Они теперь работают на совершенно другими задачами.
Поэтому:
А теперь вопрос к бизнесу - вы готовы закупить недешевую, вендер-лок платформу, заточенную под "решение бизнесовых задач"?
Не готов...
Пока ваше решение не станет массовым, пока не будет понятна фактическая стоимость его сопровождения и доработки под новые требования, пока на сайте не исчезнет строка "Вам надо ХХХ рабочих мест - звоните мы рассчитаем", и еще много чего...
Простите, но не готов даже вникать в чем фишка вашего решения, ибо время мое не резиновое.
И еще одно замечание. Решения "вендер-лок" помимо несомненных плюсов имеет как минимум два очень больших минуса для заказчика.
1. Постоянно ощущение себя в роли подопытного кролика.
2. Меня, как заказчика, сажают на иглу.
И даже если на практике мне это не выказывают, но я то все равно понимаю, что у меня нет альтернативы. За каждым чихом, мне обращаться только к одному вендору. А сколько чихов мне завтра подбросит правительство, налоговая, роструд и прочие ведомства ни я, ни вендор даже не представляем. Ну а если вендор бросил свой проект как экономически не выгодный, то для заказчика это просто выброшенные деньги, такой проект уж точно никто не подхватит.
Брать на себя эти риски сейчас мало найдется желающих.
Еще раз повторюсь, ни кого не хочу обидеть или задеть. Я просто высказываю точку зрения с другой стороны.
Опять же, без желания обидеть - если вы не готовы платить за специализированные решения, то вам придется пользоваться тем, что вам предложат. А это будут универсальные решения, как-то притянутые к вашей задаче. С той или иной степенью успешности и эффективности.
Так что тут обоюдно все. Вы не готовы платить, вам не готовы что-то узкоспециальное делать.
заказчик не хочет автомобиль, он хочет даже не более быструю лошадь, он хочет быстрее перемещать товар из точки А в точку Б.
Порой даже не "перемещать", а "переместить". И уже задача стоит - определить, часто ли будет перемещаться товар, только ли в точку Б (или даже в точки Б,В, Г и Д), или количество точек будет произвольно изменяться. Ну и т.п. И уже в зависимости от этого решать - ускорять ли лошадь, изобретать ли автомобиль, или может можно обойтись конвейером или гравитационным стеллажом.
А о том, что там юзеры конкретного бизнеса занесут в этот регистр, даже бы не парился...
И так медленно и неотвратимо скатываемся к тому, что приложение становится интерпретатором медленного, кривого и проектируемого 'как получится' DSL языка, живущего где-то внутри баз данных и конфигов. И для программирования на этом DSL тоже в конце концов человек понадобиться. Или много. И умение это делать становится тайным знанием.
Оно надо? Может, во многих случаях логику все-таки прямо на основном языке писать и пересобирать/переустанавливать приложение при изменениях?
что приложение становится интерпретатором медленного, кривого и проектируемого 'как получится' DSL языка, живущего где-то внутри баз данных и конфигов...
Ну да, оракал, посгресс и прочие им подобные (большие) БД смотрят на вас с удивлением... Они от своего рождения (лек так 30+) поддерживали классическую двухуровневую клиент-серверную архитектуру. Просто в какой-то момент, стало не модно писать бизнес логику в БД. Но есть продукты которые до сих пор именно так в них работают и решают свои задачи.
Просто Вы указываете недостатки фактически единственного российского бизнес ориентрованного продукта. А других-то таких массовых нет.
ИМХО развитие ЭДО красноречиво показывает направление автоматизации учета в бизнесе. Лет через несколько, налоговая разродится облачным налоговым компилятором, которому на вход будут скармливать типизированные файлики электронных документов, а на выходе получать учетный и налоговый баланс предприятия. А из всех нынешних задач на локальном рабочем месте, останется только правильное отображение этих документов для конкретного юзера, да связь с этим компилятором...
А вот кривые и косые интернет магазины продолжат плодиться как грибы после дождя еще долгое время, пока кто-нибудь в Гостехе не реализует типовой конструктор...
Просто Вы указываете недостатки фактически единственного российского бизнес ориентрованного продукта.
Да нет, тут как раз язык попытались нормально сделать.
Я больше про то, что все как-то постепенно движется к условной мысли вида 'а давайте формулы вычисления тарифов хранить в базе и конфигах, а то пока программисты напишут наши желания и протащат через все через тестирование - сто лет проходит. А так можно будет просто базу быстренько поправить да переконфигурировать'.
Но поскольку все происходит медленно и постепенно, задачи написать нормальный язык для всего этого ни в какой момент не ставится - получается страшный монстр, состоящий премущественно из костылей. И в какой-то момент получается кривой косой и корявый интерпретатор миллиона флажков и строк со странным синтаксисом. Который нещадно тормозит.
Я больше про то, что все как-то постепенно движется к условной мысли вида 'а давайте формулы вычисления тарифов хранить в базе и конфигах, а то пока программисты напишут наши желания и протащат через все через тестирование - сто лет проходит. А так можно будет просто базу быстренько поправить да переконфигурировать'.
А ведь именно так и происходит. Именно по этой причине родился миф про могущество SAP а энтерпрайз автоматизации. А на самом деле сложность доработки собранных модулей заставила пойти их по пути - мы не автоматизируем ваши требования, мы учим вас работать в нашем продукте.
задачи написать нормальный язык для всего этого ни в какой момент не ставится
Ну хоть подходы к описанию предметных областей стали вырисовываться, посмотрите на доменную архитектуру платформы Гостех. Правда под капотом там все с ног на голову поставлено и родовые травмы видны уже сейчас. Но доменный подход к предметной области, ее систематизация целей, задач, наборов данных это реально серьезнейший шаг в сторону переориентации программирования ради программирования на программирование ради решения задач заказчика.
Лучшей систематизации "бизнес требований" или другого подхода к этой задаче, я еще не видел.
Я все же не про это. А про то, что вот есть какая-то система. Умеренно сложная, написанная прямо на какой-нибудь Java или даже скриптовом языке.. И по мере ее развития - если этому не сопротивляться, ее конфиги и базы данных превращаются в программы, а сама система - и интерпретатор.
Мой тезис - что весьма часто это - совершенно зря.
Результат только хуже выходит. Не нужно пытаться выносить максимум логики в конфигурации и данные, надеясь, что программисты не понадобиться. Ибо понадобятся, но программирующие на этом получившемся языке, к которому никаких IDE и отладчиков и вообще инструментария нет.
Не нужно так сильно бояться перекомпиляции и переустановки. А очень часто нужно вот прямо в коде все нужное и написать. Возможно - хорошо организовав код. И потом стандартными инструментами сделав тесты и код-ревью.
И потому человек 'с улицы' быстрее освоит вот весь этот код, но на стандартном языке, чем тот код, что из на химере из кучи хитро интерпретируемых данных и конфигов написан.
А всяким желаниям сделать 'если поле в таблице начинается с "$", то там не значение имени пользователя стоит, а формула, по которой оно вычисляется, что делается....' - лучше сопротивляться.
Или делать сразу полноценно - воспользовавшись существующими полноценными языками, а не сооружая собственный интерпретатор.
Это, все, понятное дело, про системы, которые внутренние и в единственном экземпляре, а не про те, что как-то потом тиражируются.
Мне минусов наставили, не знаю получится ответить или нет.
...
Не нужно так сильно бояться перекомпиляции и переустановки.
Всё написанное Вами, я понимаю и даже частично согласен. Но прямо сейчас, на соседнем экране, у меня открыт пример того о чем вы пишите, написанный несколько лет назад. Мне надо добавить в него, с моей точки зрения мелочи, обусловленные текущим законодательством. И даже его исходники разработчики предоставили, но теперь это не их профиль. В результате другой разработчик написал мне пятистраничное и даже понятное не специалисту обоснование, почему этого нельзя сделать (библиотеки, фрэймворки, зависимости, конфликт версий и ядер и т.п.) и проще все переписать заново. Ладно говорю, а данные будут перелиты в новый продукт? О-о-о это отдельная тема и перелить так просто их нельзя потому, что на первых этапах еще не будет того функционала, что создал эти данные в старом продукте...
Честно, находясь в этой ситуации я бы предпочел решение описанное вами в цитате:
А всяким желаниям сделать 'если поле в таблице начинается с "$", то там не значение имени пользователя стоит, а формула, по которой оно вычисляется, что делается....' - лучше сопротивляться.
И самое интересное, я не обвиняю ни предыдущих, ни новых разработчиков и понимаю почему так произошло в принципе. Самое страшное для меня то, что если я продолжу с новыми разработчиками, то через некоторое время неминуемо окажусь в точно такой же ситуации.
Знакомство с внутренностями неуважаемого продукта, поразило меня тем, что там разработчик работает с понятиями номенклатура и ее характеристики, что есть объекты типа справочник и документ, что данные хранятся в регистрах сведений, остатков, движения и т.п. Я стал "понимать" (ну или точнее то представлять) как можно реализовать имеющийся функционал в этих объектах. Самое интересное и меня не грузят "библиотеками", а уточняют деталями то, что я себе на бумажечке нарисовал в этих объектах.
Вывод: Используемый для автоматизации бизнеса программный стэк, должен быть заточен под решение прикладных задач, иметь готовые объекты и модули реализующие типовые атомарные задачи и т.п. Тогда разработчик не будет тратить свое время и деньги заказчика на кописпаст обвязки каждой таблицы кучей тригеров и функций, тратя время в ущерб решению специфичных и уникальных для заказчика задач.
А ведь есть еще общие для бизнеса задачи, ну например обмен ЭДО между контрагентами, маркировки, ЭТД, электронная отчетность и т.п. И надо сказать это очень неудобное и непродуктивное занятие, прыгать между скомпилированными разными разработчиками модулями или между разными экранами браузера походу разбираясь в несовместимости версий и библиотек...
Вывод: Используемый для автоматизации бизнеса программный стэк, должен быть заточен под решение прикладных задач, иметь готовые объекты и модули реализующие типовые атомарные задачи и т.п. Тогда разработчик не будет тратить свое время и деньги заказчика на кописпаст обвязки каждой таблицы кучей тригеров и функций, тратя время в ущерб решению специфичных и уникальных для заказчика задач.
Вот это то, что я давно пытаюсь продвигать. Поскольку сам последние 6+ лет работаю именно на таком стеке. Самодостаточный для решения поставленных задач язык, не требующий никаких внешних зависимостей. И при этом позволяющий эти задачи решать максимально эффективно и с минимальными затратами.
В ответ основные возражения - "зачем мне это осваивать, это нерелевантный опыт, что мне потом с этим делать".
В результате другой разработчик написал мне пятистраничное и даже понятное не специалисту обоснование, почему этого нельзя сделать (библиотеки, фрэймворки, зависимости, конфликт версий и ядер и т.п.) и проще все переписать заново.
Ничего из этого не должно мешать изменить алгоритм расчёта чего бы то ни было. Если проект уже работал - значит, все эти зависимости и конфликты имеют решение, фреймворки же к бизнес-логике не относятся никаким боком.
Возможно, ваш проект просто кусок говнокода, за который разработчики не хотят браться, вот и ставят условия по поводу переписывания. Однако, описанные в той цитате костыли - это не решение проблемы говнокода. Вы сравниваете свою ситуацию "сейчас" с ситуацией "сейчас + костыли", но правда в том, что ваш проект никогда бы не достиг ситуации "сейчас + костыли" - эти костыли ему бы помешали. К примеру, прошлая команда разработчиков разбежалась бы раньше.
Возможно, ваш проект просто кусок говнокода, за который разработчики не хотят браться, вот и ставят условия по поводу переписывания.
Вот!!! Вы сформулировали главную проблему. Кусок это или не кусок но:
1. Я заплатил за него не малые деньги, а не говнофантики.
2. Тогда, да и сейчас я не являюсь экспертом чтобы понять ..вно.. это или не ..вно...
Жизнь научила что любой софт написанный не тем у кого спрашиваешь мнение - это говнокод. Так уж устроено сообщество программистов.
Вы сравниваете свою ситуацию "сейчас" с ситуацией "сейчас + костыли", но правда в том, что ваш проект никогда бы не достиг ситуации "сейчас + костыли" - эти костыли ему бы помешали.
я не покупал проект, я покупал инструмент для решения своих задач. Хотел и хочу пользоваться этим инструментом, но не могу.
К примеру, прошлая команда разработчиков разбежалась бы раньше.
Вот поэтому, ни на какой самый мега пупер революционный, суперсовременный "вендер-лок" продукт, я даже смотреть не буду, какие бы коврижки мне не обещали продаваны этого продукта.
Обидно, что ситуация с разработкой для бизнеса не только не разрешается, а еще более усугубляется...
Жизнь научила что любой софт написанный не тем у кого спрашиваешь мнение - это говнокод. Так уж устроено сообщество программистов.
Не всё так плохо, хороший код всё-таки существует, я в это верю...
любой софт написанный не тем у кого спрашиваешь мнение - это говнокод. Так уж устроено сообщество программистов.
это называется "фатальный недостаток"®
Впрочем, иногда свой старый код выглядит так же.
Вот поэтому, ни на какой самый мега пупер революционный, суперсовременный "вендер-лок" продукт, я даже смотреть не буду, какие бы коврижки мне не обещали продаваны этого продукта.
Но вы все равно его купите. В той иной степени любой заточенный под ваши задачи продукт будет вендорлоком и слезть с него будет достаточно дорого. Если вы этого не хотите - будте любезны всю документацию и все бизнес-процессы вести по единому стандарту. И вот тогда под этот стандарт можно будет сделать единый для всех продукт без вендорлоков. Об этом вам уже тут написали.
Когда я говорил про наш "вендорлок", то имел ввиду вот это: https://programmers.io/blog/everything-to-know-about-ibmi-as400-i-series/
Серверы на процессорах PowerS (у нас сейчас Power9), сразу установлена система с интегрированной БД, компиляторами языков, средствами администрирования и всем, что нужно для работы. Поверх этого стоит АБС от MiSys, но там выкуплены все исходники и дальше мы ее сами уже развиваем под свои процессы.
Понятно, что соскочить со всего этого уже не получится, но и нужды особой нет - все это очень надежно и по производительности вполне достаточно. Но... дорого.
Но прямо сейчас, на соседнем экране, у меня открыт пример того о чем вы пишите, написанный несколько лет назад. Мне надо добавить в него, с моей точки зрения мелочи, обусловленные текущим законодательством. И даже его исходники разработчики предоставили, но теперь это не их профиль. В результате другой разработчик написал мне пятистраничное и даже понятное не специалисту обоснование, почему этого нельзя сделать (библиотеки, фрэймворки, зависимости, конфликт версий и ядер и т.п.) и проще все переписать заново.
...
Честно, находясь в этой ситуации я бы предпочел решение описанное вами в цитате:
А теперь представим ситуацию, когда логика описана не в коде приложения, а в конфигах. И тогда изменения нужно будет вносить тоже в конфиги. И объяснение будет 'язык и способы конфигурирования желаемое не поддерживают'.
И в результате сначала придется делать, чтобы он стал поддерживать, а потом уже - вписывать и отлаживать конфигурацию.
Как-то мне не кажется, что ситуация сильно лучше. Скорее наоборот.
нет простого ответа на проблему поставленную Вами в каментах.
ИМХО это должна быть "бизнес" ориентированная среда разработки. Что я под этим понимаю, попробую объяснить утрированном примере.
В жизни каждый из нас сталкивается с разными документами, а программисты которые каждый день манипулируют разного уровня абстракциями, до сих пор не разработали библиотеку с абстрактным классом документ и производными от него типами и видами документов, которые можно использовать и дописывать в разных проектах?
Почему на описание, я не говорю про хранение, одного вида документа определенного типа, аналитик, проектант и кодировщик должны потратить по Х часов, вместо одной декларации "создать документ вида Приказ о приеме на работу типа приказ" или "создать документ вида Транспортная накладная типа накладная".
При этом я ожидаю, что среда разработки сама знает какие таблицы в БД надо создать и в общем виде, что этот документ должен делать в системе и какие ему данные надо подпихнуть на вход, а что получить на выходе.
Разве это я придумал, разве не законодательство страны в которой мы живем определило и законодательно закрепило функции и требования к этим документам?
Вот вы обсуждаете сложность использования всяких всяких зависимостей, классов, библиотек, а это всё пустое с точки зрения бизнеса это ваша внутренняя кухня. Вы же в серьез не обсуждаете проблемы технологов выбиравших материал для коленвала вашего личного автомобиля.
Бизнесу важно, чтобы приказ по кадрам манипулировал объектом сотрудник, а накладная манипулировала позицией номенклатуры в разрезе объекта хранения и не наоборот.
Когда говоришь позиция номенклатуры содержит наименование товара и его характеристики, на тебя смотрят круглые недоуменные глаза и становящиеся еще более круглыми, когда вдруг внезапно до них доходит что это не просто текстовая переменная, а набор значений разного типа уникальный для каждого типа номенклатуры. А вы что ни кода не покупали туфли ХХ размера, черные, на шнурках или бензин АИ-95 не заливали в бак?
Что непонятного и сверхъестественного я произнес и почему это очень сложные требования и требуют много времени на проектирование структуры данных и методов их обработки?
Скажите где есть такая среда разработки, где не просто объявляются документы "счет" и "накладная", но еще и описывается их поведение в зависимости от порядка их создания и не путайте его с порядком в несения в учетную систему...
Продолжать можно бесконечно.
Каждый из тех кто осилит этот камент, не сможет сказать, а я не знаю, что такое счет, да и накладной ни разу в глаза не видел потому, что для этого надо быть конем в сферическом вакууме. Так почему же тогда, ни одна из причастных к области автоматизации учета фирм, не создала ни какого инструментария содержащего в себе метаданные абстрактных объектов описывающих любую отрасль бизнеса?
Ответ прост это дорого, в режиме "вендер-лок" такие затраты без сиюминутной отдачи, никто не потянет. А вот для себя, для облегчения программирования, отладки, тестирования, сколько опенсорс инструментария написано, пишется и будет написано. Но упростит это решение задач бизнеса и соответственно увеличит прибыль разработчика, я например сильно сомневаюсь.
Уже дело дошло до того, что задания для тестировщика (!!!) выдаются - протестировать смену темы день/ночь. Скажите вот почему за эту чушь и неспособность решать такие мелочи, в итоге должен заплатить бизнес?
до сих пор не разработали библиотеку с абстрактным классом документ и производными от него типами и видами документов, которые можно использовать и дописывать в разных проектах?
Разработали, и пользуются, и дописывают. И даже несколько таких библиотек и систем.
Вот это "дописывают" - и называют программированием.
почему это очень сложные требования и требуют много времени на проектирование структуры данных и методов их обработки?
Потому что вы и ваши контрагенты меняете формы документов по зову сердца, желанию левой пятки и согласно фазе луны.
Приведите весь документооборот к строгой, четкой, единообразной, формализованной ГОСТированной форме, и обяжите ВСЕХ контрагентов привести к такой же, не меняйте вообще никогда, ни при каких обстоятельствах, введите нормоконтроль на предприятии, штрафуйте за несоблюдение, и тогда вам быстро и дёшево всё автоматизируют, сделают это один раз, и доработок никогда не потребуется.
среда разработки сама знает
Компьютер - это машина не умная, а исполнительная. Ничего он "сам" не знает. Только то, что туда заложили руками живые люди, и не параметром больше.
Бизнесу важно, чтобы приказ по кадрам манипулировал объектом сотрудник, а накладная манипулировала позицией номенклатуры в разрезе объекта хранения и не наоборот.
Вы описываете только интерфейс управления, а не всю систему автоматизации.
Руль и педали =/= вся машина. Вся машина - она больше и сложнее, чем руль и педали.
Так почему же тогда, ни одна из причастных к области автоматизации учета фирм, не создала ни какого инструментария содержащего в себе метаданные абстрактных объектов описывающих любую отрасль бизнеса?
Потому что, прежде чем перевести описание бизнес-процессов на формальный язык алгоритмов, нужно это описание подробно составить и строго формализовать на языке человеческом.
Кто это должен делать, представитель бизнеса или автоматизатор - вопрос открытый.
А вот для себя, для облегчения программирования, отладки, тестирования, сколько опенсорс инструментария написано, пишется и будет написано
Особенности опенсорса в том, что он тиражируется и "накапливается", т.е. количество полезных наработок только растёт. В том числе и потому, что он не интересен в чистом виде никакому бизнесу, зачастую это просто инструмент.
А вот бизнес-логика - это "ноу-хау", коммерческая тайна и вообще NDA. Бизнес такими вещами не делится с конкурентами. Все пилят одинаковые велосипеды и не дают друг другу списывать. Как вы себе представляете, чтобы такие наработки попали в опенсорс? (иногда попадают - когда компании банкротятся или перепродаются)
Скажите вот почему за эту чушь и неспособность решать такие мелочи, в итоге должен заплатить бизнес?
Не почему. Не должен. Не платите. Вас кто-то заставляет?
Потому что вы и ваши контрагенты меняете формы документов по зову сердца, желанию левой пятки и согласно фазе луны.
Секундочку, про формы я не слова не сказал. А сами документы, правильней сказать их наполнение данными обязательными и необязательными, определяют наши органы власти. Надо их печатать или просто отправлять по ЭДО это уже дело третье.
А вот дело первое это как их хранить и желательно чтобы не рожать это хранение каждый раз заново.
В моей фразе я говорю про среду разработки, а вот их разрабатывают люди и затачивают под определённые цели и задачи.
Возможно я не правильно выразился, но я написал "манипулировал объектом" имея ввиду, что любой документ управляет какими то объектами проектируемой системы и это не произвольные объекты, определенные на стадии объявления типа документа.
А вот бизнес-логика - это "ноу-хау", коммерческая тайна и вообще NDA. Бизнес такими вещами не делится с конкурентами.
Вот тут Вы сформулировали самое главное непонимание различие в наших взглядах. То что вы написали это правильно, но все эти "ноу-хау" коммерческие тайны и т.п. существуют внутри общей среды состоящей из общих государственных классификатором, законов, требований, условий, должно взаимодействовать (отдавать и получать данные) с различными ГИС, и т.п. Говоря о среде разработки я и имею ввиду что она должна поддерживать это общее окружение. А вот внутри его должны разрабатываться уже всякие там ноу-хау и NDA...
Другими словами, не нужен вам код ОКПД" ну и не используйте его, а если понадобился, то не надо лезть в интернеты искать что это, прочитав взрывать себе мозг как с этим гов... работать. Среда разработки должна знать что такое ОКПД2 или честный знак или Аршин или что-то еще из государственных сервисов и справочников.
В моей фразе я говорю про среду разработки, а вот их разрабатывают люди и затачивают под определённые цели и задачи.
Люди разрабатывают прежде всего то, за что им платят. Если вы готовы оплатить нужную вам среду разработки - вам ее разработают. Но это будет дороже чем покупать готовое.
Вы же понимаете, что разработчикам надо платить. За идею никто работать не станет.
Согласно вашего утверждения, ни одной новой автомашины после Форд-Т появиться не должно было.
Я думаю это называется по другому - зрелость разработчика.
Тоесть когда он понимает, что ходит по кругу с разными заказчиками, он начинает делать инструментарий для повышения своей эффективности и с другой стороны для повышения качества своей работы.
Почему-то считается, что самое сложное это написать программный продукт, а ведь на самом деле, самое сложное это поддерживать его в актуальном состоянии.
Вы путаете разработку с решением бизнес-задач. Разработчик не настолько глубоко погружен в предметную область чтобы самостоятельно создавать что-то для бизнеса. На это есть аналитики. Строго говоря, максимальная эффективность достигается когда процесс построен по цепочке BRD -> FSD -> Код. Где BRD - бизнес-требования, формулируются заказчиком. FSD - ТЗ, пишется аналитиком по утвержденным BRD. А разработчик уже по ТЗ работает.
И учитывайте, что такая система очень сильно завязана на внутренние бизнес-процессы. Которые везде разные. В одно месте где работал была своя система, написанная под свои бизнес-процессы. Потом объединились с другой конторой и пришлось переходить на 1С. Потому что у них процессы все другие. В нашу систему они не лезли. А наши не лезли в 1С (точнее, залезли, но с большим трудом и не полностью).
Т.е. если кто-то что-то сделает "универсальное", то вам это все равно окажется неудобно. Потому что оно не под вас сделано, а "вообще", усредненно.
Тоесть когда он понимает, что ходит по кругу с разными заказчиками, он начинает делать инструментарий для повышения своей эффективности и с другой стороны для повышения качества своей работы.
Не так. Пришел заказчик - "хочу это, плачу столько". Это делается. В том объеме, сколько оплачено. А делать что-то такое, что непонятно выстрелит или нет, продастся потом или нет, отобьет затраты или нет - это надо иметь очень мощную финансовую подушку. Не все на это способны и готовы.
Вы вот сами лично - много вкладываетесь проекты, которые начнут приносить хоть какие-то деньги (даже не прибыль еще) через 3-5 лет? Готовы часть прибыли на финансирование такого пускать?
Уж поверьте, я не один год такую тему тянул. Та были периоды когда на зарплату денег не было, приходилось на стороне что-то такое подрабатывать на еду. Такое могут только идеалисты тянуть, а их исчезающе мало. В основном же - ты платишь, я делаю. Ровно столько, сколько платишь.
Ну и об "эффективности разработчика" у вас превратное понятие. Для разработчика "эффективность" это прежде всего скорость выдачи продукта. Написания, отладки, тестирования. Причем, сегодня один продукт, завтра другой. И нет единого универсального решения для любого бизнеса. В ритейле одно, на производстве - другое, финансы - третье.
Вы вот сами лично - много вкладываетесь проекты, которые начнут приносить хоть какие-то деньги (даже не прибыль еще) через 3-5 лет?
Заводик строю.
Ну и об "эффективности разработчика" у вас превратное понятие. Для разработчика "эффективность" это прежде всего скорость выдачи продукта
Вот после этого, работники боинга нервно покуривают за углом.
Я вас прекрасно понимаю, то что вы пишите, справедливо для не больших коллективов.
Мое же "возмущение" больше относится к крупным игрокам этого рынка и даже отчасти к пассивности Минцифры в этом вопросе...
Я вас прекрасно понимаю, то что вы пишите, справедливо для не больших коллективов.
Посмотрите где я работаю. Только на уровне разработки для центральных серверов (под тут самую IBM i) более сотни разработчиков. А всего IT подразделение оценивается как > 5000 сотрудников.
Строго говоря, мы - как "продуктовая компания". Занимаемся разработкой и поддержкой вполне конкретного продукта С той разницей, что у нас есть один постоянных заказчик - бизнес-подразделения. И не мы бегаем за ними "а давайте мы вам...", а они приходят к нам с бизнес-требованиями по автоматизации того или иного процесса.
Вот конкретно я работаю по линии автоматизации процессов комплаенс-контроля. И да, там есть четкие стандарты от регулятора что и как должно быть. Но вот конкретика реализации всего этого зависит от 100500 внутренних факторов и плотно увязана со всеми остальными процессами. Например, мы работает (в числе прочего) с командой Системы Расчетов (по линии комплаенс-контроля платежей). У них свои процессы, у на свои, но все это приходится стыковать и увязывать между собой.
И сделать универсальную систему, которая будет работать везде, тут физически невозможно. По крайне мере до тех пор, пока все не перейдут на одну платформу и одну АБС с едиными структурами данных и одинаковыми внутренними процессами. Что нереально и чего нигде в мире нет.
беда "универсальных решений" в том, что они [как минимум] либо работают медленно, либо сложны в поддержке, либо неполны. (ну а как максимум - 2 из 3, а то и все 3 варианта).
Именно так. Ибо "нельзя объять необъятное, понять непонятное и впихнуть невпихуемое". Как только начинается "универсализация на все случаи жизни", получается либо неподъемный монстр (где для каждого конкретного случая будет куча лишнего), либо что-то такое, которое в полной степени никому не подходит.
И все равно - любые бизнес-процессы в реальной жизни не идеальны. Каждый все равно так или иначе "скругляет углы" (главное, чтобы отчетность правильная была в итоге). А как только все начать делать строго по стандартам, все просто взвоют что "работать невозможно".
Ну вот к примеру, сидит у вас человек на сдельной оплате. Счет фактура есть. Смета есть. Работа выполнена, но заказчик задержался с подписанием акта приемки (у него кто-то там в командировку уехал, будет через три дня). И все. Вам зарплату начислять исполнителю, а акта нет - заказ не закрывается, материалы не списываются со склада, деньги не начисляются... Система не позволяет... Да, через три дня все будет. Но з/п надо сегодня начислить, а завтра выдать...
И такого полно в реальной жизни...
Потому что раньше всех отправляли на производственные практики. И студенты видели реальные станки, конвейерные линии, участвовали в производственных процессах. А сейчас большинство программистов тяжелее ... ничего в руках никогда не держали.
Знакомство с внутренностями неуважаемого продукта
Так не зря же позиционируется как "предматно-ориентированная система", а вовсе не универсальный ЯП, думая про который, все тут её ругают и плюются.
Да, частично так и получается - начиналось с "Доступно и всерьез"©Нуралиев, а закончилось "мордой и в навоз"©пит. Хотели сделать систему, в которой любой бухгалтер может написать запрос, а получился клан 1с-ников. (на следующем этапе развития это же произошло с СКД). Но с другой стороны, язык SQL тоже задумывался (емнип, Коддом) как "описание запросов для домохозяек", а выродился тоже в специализацию программистов.
Со срезом последних ?
У меня уже 10 лет как все еще лампочка ильича в прихожей после того, как в день заезда плафон разбил... А вы тут про переписывание кода ))
До этой мысли приходишь только спустя годы или даже десятилетия программирования.
Или когда встречаешь цитаты типа «Совершенство достигается не тогда, когда нечего добавить, а когда нечего убрать», А.Д.Сент-Экзюпери
Отличный совет. Так и делаем. Но есть опасение, что когда наступит момент "сделайте шардирование/round robin балансировщик/распределённый кэш/очередь сообщений" мы нихрена из этого не сделаем , потому что экспертизы нет и лучших практик, т.к. "мы же за простоту".
Что за момент такой когда вам так говорят?
Обычно ж говорят - сделайте чтобы работало, а если работает - сделайте чтоьы работало лучше. А каким образом - добавлением кеша, очереди, шардирования или просто заменой сортировки пузырьком на вызов ORDER BY - это уже технические нюансы
и вы и @alan008оба правы, знать конечно надо, но применять четко от необходимости, чтобы не получилось, с одной стороны, преждевременных оптимизаций, усложняющих код и приводящих к багам. А с другой велосипедов, героического решения проблем, которые уже давно решены людьми поумнее. Но чтобы балансировать на этой грани, мне понадобилось >15 лет
KISS? А если DRY добавить — это будет KISS?
Это и называется осознанность. Обычный программист наоборот, считает себя умным, таковым не являсь. Минутка психологии. Что отрицается, то вытесняется и определяет и управляет человеком. Говоря честно о себе "я плох, грешен, каюсь" вытесняются положительные качества, что полезно и позитивно. Текст статьи отражает скорее мудрость и опыт, а не тупость.
Ум и мудрость, все-же несколько разные вещи на мой взгляд, ум - способность анализировать, делать выводы, постигать новое, а мудрость - способность умело пользоваться накопленным опытом и багажом знаний, так что вполне можно быть не супер умным и относительно медленно накапливать знания, но более удачно применять их на практике
Кто где кого вытесняет и управляет? Я тупой, плохой и грешен, можете для таких пояснить?
Я уже много раз говорил об этом. По моему мнению, программисты делятся на два типа: те, кто зарабатывает деньги и на программистов. Первые тупо пишут код (хороший, прекрасный код, как и говорится в статье), вторые горят духом исследования и двигают индустрию вперёд.
Собственно, каждый выбирает для себя, что ему нужно больше. Если просто денег заработать - то нафиг не нужны распределённые кэши, абстракции и другие совершенства инженерной мысли. А если цель именно стать программистом (т.е. поставить перед собой цель бесконечного совершенствования), то придётся сильно расширять кругозор.
Мне кажется что немного наоборот. Безнесу вообще пофиг что у вас там за код. Пусть будет хоть самый страшный и ужасный и вызывающий ктулухту в эксепшенах.
Бизнесу важно главное. Код должен быть написан вчера. Код должен не падать в эксепшен сразу после старта (а дальше похер). И желательно код должен быть бесплатен.
И поэтому "эксперименты" в программировании бизнесу очень не нравятся - потому как противоречат пункту 1. Т.е. вам не дадут времени на эти эксперименты.
Собственно, для этого бизнесу и нужны люди, которые будут просто писать код. Это должен быть максимально простой код, который написан максимально быстро и эффективно, что бы потратить как можно меньше денег. По этому я и говорю о людях первого типа, которые просто зарабатывают деньги и пишут такой код.
Люди второго типа, для которых важен сам процесс программирования, как самоцель, очень часто вообще никакой прибыли за свой код не получают. Есть компании, которые в них вкладываются, т.к. одна идея из тысячи может выстрелить. Но это меньшинство.
Я думаю путаница возникла в термине "простой". Под простым я имел в виду понятный, отрефакторенный код. Вы же имеете ввиду: лапшакод накиданный максимально быстро.
Такой код не будет простым. Для дальнейшей разработки он будет максимально сложным. Что бы его понять новому разработчику нужно будет тратить уйму времени. Такой код будет сотостоять из 100500 очень сложных сторонних библиотек. А сами библиотеки будут при этом использоваться на 0.001% Типа 1 функция из сотен тысяч. В коде будут куча не очевидных багов - которые хрен найдёшь в этой лапше зависимостей.
Короче простой он только в момент создания. Сразу после - становится максимально сложным для разработки.
Главный перевешивающий плюс такого кода для бизнеса - его можно написать быстро и выкатить показать потребителям быстро. А всё остальное уже не важно. И потребление памяти. процессора. И баги.
И да я вообще не говорю какой подход более правильный. Тут всё зависит от вашего мировоззрения. Если вы бизнесмен - то один. Если инженер - то противоположный.
Просто у бизнеса есть деньги. А вот у инженеров нет. Вот и вся реальность.
Вы же имеете ввиду: лапшакод накиданный максимально быстро.
Эмм, что? Я же буквально написал
Первые тупо пишут код (хороший, прекрасный код, как и говорится в статье)
В целом я говорю не о бизнесе, а о базовом целеполагании. Т.е. первый тип именно обучается и продвигается в сторону получения прибыли. А пути второго более направлены в сторону исследований.
К примеру, если взять онлайн школы программирования, либо простые уроки с ютуба, то там, с большей вероятностью, будет направление для подготовки людей первого типа. Т.е. там не будут подробно изучать всю компьютерную отрасль от принципов работы микропроцессоров и литургии до смежных отраслей, типа экономики и ведения бизнеса или углубленной математики. А что там будет, так это принципы написания чистого кода, софт скиллы для прохождения собеседования, правила оформления портфолио и прочее.
И вот, человек, который закончил подобные курсы, либо отринул ненужные ему области, затем 15 лет писал код и довёл до совершенства свои главные навыки, пишет на хабре ироничную статью, где намекает на ненужность модных и современных Rust, Go и прочего.
Со вторым типом непонятка. Ну, хорошо, если эти люди (не получая типа денег) пишут сложный умный код для себя. Исследуют. Подразумевается, что они двигают компьютерную отрасль. Но. Куда они ее двигают, если комментарии под статьёй почти единогласно одобряют код без всех этих продвинутых фишек?
Обычно наибольшего успеха добивается тот, кто не следует всеобщему мнению....
Типовой демагогический прием. Что значит "обычно"? Кто это проверил? доказал?
Мне казалось, это очевидно. Базовым логическим суждениям и влиянию на них общества учат ещё в школе. Можете ознакомиться, например с этим фильмом.
Тут другой демагогический прием. А именно подтасовка из серии "чаще ходят пустые автобусы, или переполненные" одни опросили водителей, другие пассажиров.
Наибольший успех - очевидно экстраординарный. Вполне естественно предположить, что и путь к нему не шаблонный. Так как шаблонному пути следует большинство, и результат будет очевидно средний, скорее медианный, чем арифметический.
А вот вроде такая же (почти) фраза
Обычно тот, кто не следует всеобщему мнению добивается наибольшего успеха....
уже почти столь же очевидно не верна. Так как большинство не следующих всеобщему мнению уйдут в тупик. А тот, кто добьется суперуспеха просто породит новый шаблон.
Автор не намекает на ненужность модных и современных штук, а на Go так и сам пишет. Он лишь указывает, что не хватило, якобы, ума на это. На мой взгляд всё-таки усидчивости, ну да не важно, главное, что он осознал и принял свое положение, а не стал метаться в бесполезных попытках ухватиться за всё и сразу.
Всё-таки нельзя всех программистов (как и практически любые другие группы людей) делить вот так на "черное/белое". Те же самые люди, которые пишут код "для заработка", создают технологии, которые упрощают эту самую разработку "для заработка". Разве ж это не движение отрасли? А бывает и так, как вы написали, одни двигают, другие пользуют и зарабатывают на этом. Но чаще, подозреваю, что и те, и другие что-то зарабатывают на своём коде, и так же каким-либо образом двигают отрасль (тут тоже надо определиться, с откуда начинает "движение", если совсем опускаться, то даже рефакторинг внутреннего проекта можно так назвать, ведь он хоть чуть-чуть, но улучшает суммарное общее состояние кодовой базы).
Соответственно, считаю неверным такую простую дихотомию
Я не делю на чёрное и белое. Я говорю о двух видах целей, которые преследуют программисты в той или иной мере. Первые приходят за деньгами и пишут простой код. Второй программируют потому, что им интересно программировать в больше мере, чем зарабатывать деньги. Для первой категории характерны более простые и прямолинейные подходы в написании кода, вторые используют более сложные конструкции и знания из смежных отраслей.
Вторые, если это хорошие вторые, тоже не будут переусложнить код и добавлять "концептуальность ради концептуальности".
Насколько я понимаю, тут речь не о том, чтобы писать только примитивный код, но о том, чтобы не плодить сущностей сверх необходимого. И всегда искать наиболее простое и эффективное (именно И) решение. Всегда подумать по уже написанному - а нельзя ли это же сделать проще без потери эффективности? А где тут можно что-то улучшить?
вы статью читали? Он пишет на Go.
А какие, интересно, программисты ради программирования создали продукты? Все продукты создавались исключительно под практические цели - и линукс, и гит, и квадратный корень без деления Джон Кармак создавал для оптимизации цикла рендеринга, а не абстрактно в вакууме.
Самолет красивый не потому что его делают красивым, а потому что ему летать, на мой взгляд вы не верно делите когорты.
Есть места работы, где документооборот, 1С, предприятия, финтех и прочее - там и работают в основном программисты "за деньги". А если хочется программировать что-то новое и на острие - есть стартапы, но и там вы делаете конечный продукт для пользователя, какая-то абстрактная красота и технологичность в вакууме вообще никому не нужна, все в конечном счете служит прикладному, даже наука
все в конечном счете служит прикладному, даже наука
Ну, мы живём в физическом мире. По другому и быть не может.
Я говорю о самоцели. Есть люди, для которых цель - заработать денег, а есть - кто программирует ради самого процесса программирования. Это две очень большие группы, которые различаются, как по характеру обучения и подготовки, так и способом реализации своих навыков.
Люди второго типа, для которых важен сам процесс программирования, как самоцель, очень часто вообще никакой прибыли за свой код не получают
Я практически уверен, что все такие программисты квазипараллельно просто пишут код - потому что надо на что то жить.
Тут можно перефразировать поговорку про бекапы. Бизнес делится на тех, кому нужен просто код, который работает вот прям щас и тут и на тех, которые уже решали дилемму, что выбрать "еще N вакансий открыть, чтобы доработать предыдущий код и тогда экономика проекта перестает быть положительной или заново переписать, то что никак не может быть расширено и допилено"
Нету однозначного ответа. Иначе бы все просто выбирали правильный путь.
Очень много "бизнесов" прогорали выпустив сырой, баганутый продукт. Много бизнесов не взлетело - не выпустив ничего, т.к. старт бюджет закончился.
Легко скатываться в крайности. И как бы банально не звучало - истина в середине. Это как шар на верхушке параболы - трудно удержать и не скатится на край.
Но бизнесу еще и важно, чтобы новые "хотелки" добавлялись быстро и без глобального рефакторинга. А это почти всегда требует определенного "усложнения" уже на старте.
Код исполняет компьютер, но читают его люди...
Ох уж этот "Бизнес". Единственно важный бизнес для разработчика - это собственный бизнес по сдаче в аренду собственных мозгов. Ваша задача - сдать подороже, а какой именно маркетинг вы примените для этого - это уже вопрос отдельный. Часто "Бизнес" вообще понятия не имеет, что такое хорошо и что такое плохо, в техническом плане. И он готов купить вашу "экспертизу", как страховку, для собственного спокойствия. В этот момент, сразу становится "не пофиг" на то, как вы способны зажечь аудиторию на тематической конференции. Не стоит абсолютизировать "Бизнес", за этим словом всегда стоят конкретные люди, иногда очень толковые, но часто и профаны, которые ведутся на любые "умные слова" сказанные "человеком в белом халате".
Я как представитель партии "Инженеров" скажу что самое важно для меня это проект. Он должен быть интересен для меня. А деньги... Это второстепенно. Чем меньше про них думаю - тем лучше себя чувствую. От этого и страдаю.
Когда я писал что бизнесу не важны баги в проекте - это просто литературный приём гипертрафации сути бизнеса. Как впрочем и фраза про то что код нужен вчера.
Просто если на одной чаше весов лежат баги, а на второй продать продукт сегодня. Понятно что выберет бизнес.
Я бизнес не выделяю в какой то отдельно живущий объект. Бизнес это те же самые люди. Просто у этих людей мировоззрение противоположно тому кто собственно и пишет код. Даже задачи разные. Бизнесу не важно что подорвать. Инженеру как раз очень даже важно что он созидает.
Что бы написанное не выглядело бессмысленным надо привести какой то умный вывод )))
Пусть вывод будет такой - если вам кажется что ваши босы идиоты, не переживайте. Вы своим босам тоже кажетесь дармоедами ))) Вселенское равновесие "Ра" востановленно )))
Весьма спорное мнение. Раз уж вы сдали свои мозги в аренду, именно это и есть работа по найму, то будьте любезны соответствовать. "Бизнес", это не только выгодополучатели, но и потребители. Ваша забота - потребители. "Сдать подороже" - это аналог "кидалова", ведь у всего на свете, есть справедливая рыночная цена.
Поставьте себя на место нанимателя и вы поймёте как вы не правы. Судя по всему, вы имеете доступ к информации о валовой прибыли и не понимаете какие бизнес имеет расходы, кроме расходов на ваш уникальный и незаменимый труд.
Если вы не помогли бизнесу заработать, когда была такая возможность, вы кинули людей на бабки.
Бизнесу важно главное. Код должен быть написан вчера. Код должен не падать в эксепшен сразу после старта (а дальше похер).
Увы, но не всегда. Если оно работает, в потом вдруг встает колом потому что количество клиентов увеличилось - бизнесу это не нравится. Бизнес от этого денежку терять начинает.
Тогда вторых программистов лучше писать с большой буквы, чтобы не путаться.
программисты делятся на два типа
Кажется, что терминологию, которую вы тут ищете, придумали давно: есть прикладные инженеры и есть инженеры-исследователи. Прикладной инженер применяет имеющиеся в его распоряжении инструменты и знания для решения конкретной прикладной задачи. Исследователи анализируют существующие инструменты и придумывают новые.
Если просто денег заработать - то нафиг не нужны распределённые кэши, абстракции и другие совершенства инженерной мысли
Не вижу связи, если честно. Необходимость высокоуровневых инструментов обычно диктуется сложностью задачи. Если ваша работа - разработать приложение на 100 человек (условно), но вы запихиваете туда все известные примочки просто из любви к профессии - вы действуете нерационально.
И не надо, пожалуйста, никого никому противопоставлять и рассказывать, кто лучше: все профессии нужны, все профессии важны. Ваш чудесный инженер-исследователь, который двигает всю индустрию, может помереть на месте от рутинных задач, которые решает обычный прикладной инженер. А прикладной инженер, в свою очередь, раз в жизни может и написать что-то общественно полезное. Это роли, которые мы примеряем на себя в жизни, они меняются.
есть прикладные инженеры и есть инженеры-исследователи
Ни разу не слышал о подобной терминологии. Возможно есть ссылка на исследование/законопроект? Единственное деление, которое встречал по специальности - это техник-программист и инженер-программист. Но я говорю о другом.
Если уже давать имена, то первый тип я назвал бы программисты-корпораты, а второй программисты-авантюристы. Авантюрист - это такой исследователь, который ради собственного интереса открывает и создаёт новые технологии или новые области в информатике. А корпораты закладывают фундамент на открытиях авантюристов, строят там систему, что бы получать прибыль.
В целом, изначально передо мной стояла задача сформулировать ответ на вопрос: Нужны ли программисту математика и прочие смежные с программированием науки. И я для себя вывел ответ так, что обязательно нужны авантюристам, т.к. информатика часто тесно взаимодействует со всеми другими науками. Но, почти не нужна корпоратам, (кроме ситуаций требующих непосредственного применения прикладной математики) т.к. для построения системы нужны только знания того, как работает система, её правил и принципов для извления прибыли.
Под эту же концепцию попадают онлайн-курсы, где готовят исключительно корпоратов. Если вы почитаете программу любых курсов, то увидите предметы и напрвления, направленные только на получение прибыли.
Необходимость высокоуровневых инструментов обычно диктуется сложностью задачи.
Это совсем не так, если подходить к проблеме с точки зрения бизнеса. В бизнесе не инженер выбирает инструмент для решения задачи, а сам бизнес выбирает инженера, способного решить ту или иную задачу.
Проще говоря, если в компании сменился стек, то компания нанимает новых сотрудников, а не переобучает старых.
А если человек запихивает в приложение на 100 человек кучу лишнего, то это просчёт бизнеса, который его нанял. Очевидно, что данный человек предназначен совершенно для другой работы.
Прикладники и академики.
И это не только у программистов, а вообще у всех инженеров.
Не сказал бы, что у всех. Единственная область, где это на столько ярко выражено - это информатика.
А в каких ещё инженерных отраслях вы работали?
Я ещё в электроэнергетике и в связи, и со строителями много пересекался. По своим могу сказать, что у всех.
А у вас какой опыт?
У меня опыт в юридической сфере, сфере образования, а сейчас вот в телекоммуникациях. Но, я не слышал терминологии "прикладники" и "академики".
Если имеете в виду, что есть инженера, ответственные за продукцию, а есть за разработки - это да. Но, ещё есть инженера, которые занимаются обеспечением, инфраструктурой и т.п. Мне кажется, это не то, о чём я говорил ранее.
У меня опыт в юридической сфере, сфере образования
Это не инженеры.
сейчас вот в телекоммуникациях
А это инженеры.
Если имеете в виду, что есть инженера, ответственные за продукцию, а есть за разработки - это да. Но, ещё есть инженера, которые занимаются обеспечением, инфраструктурой и т.п. Мне кажется, это не то, о чём я говорил ранее
Я имею в виду, что помимо инженеров-программистов бывают ещё:
инженеры-электрики
инженеры-теплотехники
инженеры-строители
инженеры-механики
инженеры-химики
инженеры-нефтяники
инженеры-связисты
и т.д.
Во всех этих тусовках бывают "академики" и "прикладники". Задачи и подходы к ним, соответственно, академические и прикладные. И лучше их не смешивать, на мой взгляд.
Забавно, что не так давно ребенок на мой вопрос "чем в вашем вузе это направление отличается от другого с почти таким же названием?", ответил, что его направление - программная инженерия, практики, а вот то "с почти таким же названием" это больше теоретики-академики.
У меня опыт в юридической сфере, сфере образования, а сейчас вот в
Как раз хотел написать что описанное характерно не только для инженеров, но например и юристов. Странно что вы такое деление пропустили с этим опытом, на конференциях юристов, например, о делении "практики" и "теоретики" говорится прямо как о факте.
Есть ученые кот. двигают юр. науку и читают гражданское право в универе, а есть те у кого есть реальный опыт ведения дел. И зачастую академику не стоит идти в суд, а практику залезать в академию.
Ни разу не слышал о подобной терминологии.
Это совсем не так, если подходить к проблеме с точки зрения бизнеса.
Проще говоря, если в компании сменился стек, то компания нанимает новых сотрудников, а не переобучает старых.
Что-то очень много категоричных заявлений на единицу текста, простите. Вы уверены, что не выдаёте свои мироощущения за непреложную истину?
передо мной стояла задача сформулировать ответ на вопрос: Нужны ли программисту математика и прочие смежные с программированием науки.
Это не тот вопрос, на который отвечает в своей заметке автор. Кажется, вы отвечаете в своём контексте, но многие поняли статью по-другому.
Да, весь приведённый текст - это моё мнение и опыт.
Кажется, вы отвечаете в своём контексте, но многие поняли статью по-другому.
Если нужен ответ по контексту: Автор иронизирует над другими стеками технологий, которыми не пользуется. Однако, он находится в своей корпоративной структуре и не видит других структур, которые существуют параллельно, где точно такие же люди точно так же пишут программы в своей структуре.
Кроме того, я говорю об "Авантюристах", которые вообще не следуют корпоративной канве и могут сильно выбиваться по части используемых технологий.
Автор иронизирует над другими стеками технологий, которыми не пользуется.
Не увидел этого)
Автор иронизирует - это верно. Но я воспринял текст автора как иронию над культом сложности: мол, любая инженерная задача - это вызов и возможность применить весь набор инструментов, доступных человечеству на данном этапе эволюции, нагородить тысячи абстракций и декомпозировать код на миллионы методов, каждый из которых содержит одну строку кода (для читаемости).
Конечно же, это не так)
Во-первых, есть пресловутый закон Парето, который в том числе можно интерпретировать так, что 80% задач требуют самых простых и тривиальных решений. "Авантюризм", про который вы говорите, применим в остальных 20% случаев. Да, они принесут 80% пользы, но это не означает, что простые и тривиальные решения не нужны. Это всё ещё большая часть работы любого из нас.
Во-вторых, просто - не означает легко. Как верно заметили в других комментах - автор говорит про простоту восприятия написанного кода (тут невольно вспоминается "цикломатическая сложность"). Писать понятный код - это отдельное искусство: им действительно не похвастаешься в Google, но этот навык делает программиста ценнее. Проблема "авантюристов" в том, что они могут выдать рабочее (даже гениальное) решение, но если в нём никто не может разобраться - полезность этого решения снижается при необходимости внести в него правки.
Ни разу не слышал о подобной терминологии.
Вы, видимо, не инженер?
Инженер-исследователь это то, что у инженеров вместо "магистра". Инженер - это специалитет, а инженер-исследователь - магистратура.
Я занимался предпроектными обследованиями на промышленных объектах, профессионально (мне за это деньги платили), а из образования у меня только бакалавриат.
Что я делал не так?
Вы делали всё так. Только звания "инженер" Вам не присваивали. Звание и должность - не всегда совпадают.
Открыл трудовую, проверил - "Инженер 1 категории".
Получается, присваивали?
Так в трудовой должность.
Точно, да, должность. Простите мне мою невнимательность.
Так, а звание где?
В дипломе, очевидно.
Да, это было до бакалавров)
(Осознал свой возраст, приуныл)
Так я ж говорю, у меня диплом бакалаврский. Слово "инженер" там нигде не написано. Фальшивый, что ли?
Что делать-то?
А что же там у вас написано?
Что делать-то?
Расслабиться и жить дальше? :D
Так бакалавр это неполное высшее, откуда там инженеру взяться?
Так бакалавр это неполное высшее, откуда там инженеру взяться?
В трудовой же, ну.
Мы ж, вроде выяснили, что инженер - это должность, а не звание.
Или нет? Или что?
Я запутался.
Есть должность (в трудовой) есть звание (точнее квалификация, в дипломе). Это омонимы. Как, я не знаю, какой-нибудь доктор. Может быть в поликлинике просто доктор, может быть кандидат наук доктор, а может даже доктор наук доктор.
Как, я не знаю, какой-нибудь доктор. Может быть в поликлинике просто доктор.
Нет, не может. "Просто в поликлинике доктор" это "просто врач". "Доктор" это всегда человек с докторской степенью. Называть всех врачей "докторами" это издавна прижившаяся ошибка, которая, видимо, возникла и пошла от уважения к этой профессии в старые времена.
Ну вот с инженерами и менеджерами та же фигня.
5 лет менеджерского опыта на должности менеджера по клинингу и тп.
А вот у меня квалификации по диалому нет, он бакалаврский. Там просто другая форма записи. Я "бакалавр по направлению...“
И огромное количество наших соотечественников тоже. И не соотечественников в европах и Америках - тоже. Ибо мы у них и скопировали болонскую систему.
Это тоже всё неправильные инженеры?
Правильные - это только советские, потому что специалитет? Или что? Или как?
А если так, то что делать с неправильными - всех с работы выгонять? Или зарплату резать? Как быть?
Честно скажу, учился давно, еще до болонской системы. По болонской младшая дочка училась (дошла до бакалавра, ушла в другой профиль потом).
Так вот, сложилось впечатление, что бакалавр сейчас - это то, что у нас называлось "неполное высшее образование". Т.е. только общая часть, без спецкурсов по конкретной специальности.
У нас так было - первые три года - базовая подготовка. Математика (очень много и не просто высшая, а по разделам - отдельно матанализ, отдельно дифисчисление, отдельно функции комплексных переменных, матстатистика, уравнения матфизики и т.п.), физика (немного общей и потом вся теорфизика по разделам - аналитическая механика, квантовая механика, механика сплошных сред - "полное собрание сочинений Ландау-Лифшица"). Немножко химии (у нас был физический профиль, так что химия так, ознакомительно). Это то, что сейчас назвали бы физмат бакалавриатом.
А потом еще 2.5 года спецкурсов (преимущественно "закрытых" т.к. физтех наш готовил кадры для минсредмаша и курировался им). Там уже конкретные специальности.
Кстати, наш факультет (сейчас он имеет статус института в составе университета) на болонскую систему так и не перешел. Только специалитет (по крайней мере по тем специальностям, что раньше были минсредмашевские, а сейчас относятся к росатому).
Так вот, сложилось впечатление, что бакалавр сейчас - это то, что у нас называлось "неполное высшее образование". Т.е. только общая часть, без спецкурсов по конкретной специальности.
Странно. У меня было 2 года общего, 2 года спецкурсов.
Может дело не в бакалавриатах, а в том, что в образовании тоже проблема с кадрами и в вузе нет преподов, которые хотят/могут вести спецкурсы?
Да ну, нет, бред какой-то, не может такого быть.
У нас так было - первые три года...
Простите, но звучит как "я в свои годы в школе стометровку бегал..."
Какое отношение это имеет к инженерной профессии - мне не очень понятно.
Ну, или "инженер" - это не профессия, а статус, который дают только избранным. Если так, то понятно, о чём вы тут, всё сходится.
Может дело не в бакалавриатах, а в том, что в образовании тоже проблема с кадрами и в вузе нет преподов, которые хотят/могут вести спецкурсы?
имхо, вряд ли - иначе ВУЗ лишили бы аккредитации. Просто "так истерически слежалось" И во всяких учебных заведениях, относящихся к "странным министерствам" (МОМ, МСМ,МРП), была традиция - давать спецдисциплины только на старших курсах, ибо 1)к их восприятию уже подготовлена база (все эти "вышки", "физики", "химии", "ТОЭ") 2)все случайно зашедшие и неспособные - уже отчислены. Вероятность утечки "спецзнаний" уменьшается.
Необходимость высокоуровневых инструментов обычно диктуется сложностью задачи
Как оценить сложность задачи без квалификации "исследователя"?
Понимание что в проекте можно обойтись без очередного совершенства инженерной мысли - это как раз и есть вершина бесконечного совершенствования.
Чтобы понять что распределенный кеш здесь не надо - надо с ним достаточно натрахаться ранее. А не просто статью прочитать о том какой он хороший и надо пихать его везде
так абзацы 4-5 показывают крутого сеньора, который осознал Дзен.
Проектирую модули с понятными API (и не употребляю слово «понятный» в том значении, которое ему придает Роберт Мартин)
А какое значение ему придаёт дядюшка Боб?
Ха, автор использует Docker, значит уже стильный, модный, молодежный и примкнуть к "по настоящему тупым" не вышло. ))
Начало любопытное.
"У меня плохо получается отслеживать сложные зависимости в кодовой базе".
Писал как-то развесистую программу и понял, что именно вот это самое сложное - в какой-то момент перестал понимать вообще, что у меня где и как это всё работает. Возникло нестерпимое желание переписать всё с нуля. Подавил его и ничего страшного не случилось. Продукт и так работает.
Вообще наверное можно на этой идее придумать IQ-тест, чтоб было много данных со сложными зависимостями.
Выглядит как описание прекрасного коллеги, с которым одно удовольствие работать.
Программы, которые я создаю, вроде бы работают нормально. На программиста из Google они большого впечатления, конечно, не произведут
Парадокс в том, что подобные программы не произведут впечатления при собеседовании в Google. А вот окажись такой человек внутри - есть вероятность, что его бы ценили за качество и предсказуемость результата.
Тем не менее, автору лично я бы посоветовал не вешать на себя ярлыки и таки прощёлкать задачки с LeetCode, или освоить Rust, или ещё как-то расшевелить свой мозг - не столько для профессионального развития, сколько для личной пользы. Просто, чтобы не утратить гибкость мышления - тяжело, больно (с возрастом образование новых нейронных связей - всё более неприятный процесс), но полезно.
Гугл притянут за уши. Кто будет оценивать ранее написанные программы?
Будут задавать вопросы, на которые у человека будут ответы. Потому что писать просто можно научиться только после того как научился писать сложно.
У меня аж экран замироточил. Делать просто - очень непросто. Это касается любых сфер применения инженерных навыков. Для этого нужен и неслабый интеллект и куча опыта. Автор какбэ говорит нам: - я не только очень умный, но и очень скромный.
точно так. Код джуна обычно запутан в бездумном применении паттернов и новомодных практик, которым на самом деле 100 лет (ФП если не старше ООП, то ровесники, например). И чрезвычайно сложен. Код же синьора с легкостью читается и джуном, и синьором.
Но вот не все становятся синьорами даже спустя 15-20-25 лет. Видел я и взрослых дядек типа меня, которые очень долго в индустрии, но все равно пишут обертки над обертками библиотечных функций, REDUX там где хватит за глаза MVC и тянут в проект 5 либ в день ради одной функции. Иногда с годами приходит мудрость, а иногда только одна старость, как сказал великий...
Максимальное одобрение автору. Но распределенный кэш типа редиса всё же стоит юзать. Если контейнер с сервисом падает и каждый раз при факапе теряются данные in-memory кэша, то беда.
А если падает распределенный кеш? А редис в неэнтерпрайс версии всегда SPoF.
Ну сходу ощущение, что самописное приложение с большим шансом упадет в эксепшн, чем протестированный миллионами юзеров редис. Плюс, при деплое контейнер рестартует и in-memory кэш пропадает. Плюс, у редиса можно сделать персистентность и даже если он по какой-то магии факапнется, то основная часть кэша будет жива. Еще я бы поспорил, что кэш можно считать "точкой отказа", так как в нем по определению лежат данные, которые оптимизируют работу приложения, но в случае его отказа ("контейнер упал по OOM и рестартанул") апп будет работать медленнее, но не сломается.
"Скучно, девочки" (с)
Должна быть мечта, размах. Лучше придумать 100 абстракций и ни одной не сделать, чем байты с места на место перекладывать по указке.
И на заметку, "наиболее легкий мейнстрим-язык программирования " в РФ это 1С :)
Язык простой, а вот инфрасртуктура вокруг него - тяжелеет.
Вы пробовали программировать современные конфигурации на 1С ?
"программировать на 1с" - легко. А вот "современные конфигурации" - это уже то, что на нём "легко напрограммировали".
У меня в работе их с десяток очень разных, от лохматых легаси до самых современных
Мне не скучно все это интегрировать.
Но каждую неделю я захожу на codeforces.com и чувствую себя "тупым" :) При этом на codingame я в принципе в топе. А на работе вот 1С. В принципе сочетание хорошее, рекомендую.
Я считаю надо стремиться все-таки к высотам, постоянно, а то руки опустятся и какое-нибудь выгорание случится.
Мой коментарий на оригинальную статью Антона:
I even more stupid than Anton, I use C instead of Go and Perl instead of Python. I do not use Docker. I distrubute my code with Makefiles. I do not use CMake.
Да вы люди все тупые. Ведь предназначение человечества - полоть картошку и пасти гусей, а не вот это всё.
Это не глупость, это мудрость
Пока нагрузка влезает в рамки одной машины и есть понимание, что оно так и будет в будущем, то да это мудрое решение. Но вот делать с таким подходом систему, которая ожидает реально большую нагрузку, я бы не стал - на этом месте простые решения перестают работать.
Почитайте “big data is dead”, автор работал в Google и как раз ее родную продвигал. Компаний типа Google -1-3 в мире. И ваша явно не из их числа.
Дальше закон Мура гласит что производительность компьютеров удваивается каждые сколько-там лет.
Вы сей час за разумные деньги можете взять instance на Амазоне где все ваши данные просто вылезут в оперативную память.
Так что у вас лично нет проблемы с производительностью и большими данными.
Ну как бы я не стал делать голословные предположения насчёт моей компании. Это во первых.
Во вторых, все же прекрасно считается и планируется. И легко можно посчитать влезет ли твой сервис в одну машину или нет. Если есть риск, что не влезет, то горизонтальное масштабирование даёт большее пространство для маневра.
Закон Мура давно уже не про производительность ядра, а про производительность множества ядер. Производительность на ядро растет на жалкие десятки процентов с каждым новым поколением. А вот нагрузка то как раз часто растет по экспоненте.
Не знаю что там продвигал автор из Гугла, но можно хотя бы базовые тезисы из книги пересказать?
Эй, полегче там. Я тоже весьма хорош во всех отношениях. Я даже носки в тон подбираю.
Достоинство и всепоглощающая скромность.
Всегда считал себя не программистом, а алгоритмистом.
Дайте задачу и скажите на каком языке написать.
Не знаю этот язык? Пофигу. Просто буду писать в 5 раз дольше.
В прошлом году настрочил на питоне несколько огромных скриптов. Заодно и разобрался что там к чему. До этого так же было с QLua. Когда то давно - с PL/1.
Уже много лет в беседах говорю что мне пофиг какой язык использовать. Собственно на почти всех кодил. От разных ассемблеров до weba, мобильных платформ, PC софт от бейсика с дельфой, до C# и всякого новомодного, SQL и прочего. Да собственно и схемотехника тоже, хотя это не по теме.
Так вот - все языки одинаковые в основе своей. Потому как все работают на одних процессорах которые работают по законам булевой алгебры. Грубо говоря все языки состоят из if,for,var.
Различия же не в языках - а в библиотеках и абстракциях которые приходится строить.
плюсую, но уточню - императивные языки примерно одинаковы. (насчет функциональных не скажу, ибо не знаю). но между императивщиной и функциональщиной есть разница. Даже между императивными языками и SQL (который ближе к функциональным).
Ну и изучать приходится "систему вокруг языка"
"На любом языке можно написать Фортран-программу"?
Если язык полон по Тьюрингу то на нём можно написать что угодно в пределах булевой алгебры. Вопрос удобства.
А что такого особенного в фортране? Приведите пример. Язык просто принципиально не может предложить возможности выше чем предлагает процессор на котором выполняется программа написанная на этом языке.
Это просто мем со времен когда слова мем ещё не было.
Вопрос удобства.
Именно. Удобства.
Вот представьте - у вас есть БД. Вы из нее читаете запись. И там есть какие-то типы данных, которые языком не поддерживаются. И тогда вам придется тянуть какие-то зависимости, воздавать из этих данных объекты дополнительные. Только для того, чтобы с ним как-то работать.
А елси это какой-то специализированный язык, в котором нативно есть все типы данных, что есть в БД, вам всего этого не нужно. Вам что int, что какой-нибудь numeric или date - все это есть в языке и вам все равно - что с int работать, что с numeric...
Или один язык при переполнении вызывает UB, а другой - бросает исключение...
Тут много нюансов которые делают тот или иной язык более или менее удобным для решения тех или иных задач...
Честно говоря не вижу предмета спора. Я не противоречу вам. А вы собственно мне. По крайней мере я так вижу.
Достаточно взрослые языки имеют полный комплект инструментов для удобства. И примерно равны друг другу.
На brainfak конечно писать можно всё.... Но это вопрос скорее в плоскости психиатрии.
Вы привели пример с типами данных. Вот я сейчас в основном мейню С#. Так вообще нету с этим проблем. Написание структуры либо класса - пара минут. А дальше используй этот тип точно также как и любой другой нативный. Честно говоря с точки зрения С# там вообще нету как таковых нативных типов. Всё либо классы либо структуры.
Даже далеко ходить не надо. У меня в текущем проекте есть кастомные типы. Так я написал структуру - что бы данные в стеке хранились(как у настоящей "тру" неуправляемой переменной), плюс переопределил нужные мне операции.
Теперь я с переменной этой структуры в любом математическом выражении просто участвую. Складываю, умножаю, сравниваю. Да вообще всё. Также инициализация переменной. Написал нативное присваивание всех нужные мне типов . Теперь переменная инициализируется от массива, поинтера, набора int, long. Да вообще всё что мне надо то и будет жрать. Собственно что мне прописные истины описывать. Повторяю - современные развитые языки это умеют. Ну или должны уметь. Если они развиваются то такой функционал точно подъедит.
Ах да забыл. Про неопределённое поведение. Скажем так - это вообще не то ради чего надо выбирать язык. Разумеется в разумных пределах конечно же. Тот же С++ косячно относятся в некоторых моментах. Да - это написано в документации. Но есть одно но!
Пример - есть такие дороги где происходят постоянно аварии, хоть все знаки и есть в наличии. И дорожники изменяют такие дороги. Или есть мост глупости. Там стоит знак. но люди попадали в аварию и будут попадать. Хоть ты тресни. Несмотря ни на какие знаки.
Короче такие вещи просто надо запомнить для каждого языка. Их на самом деле единицы. И в основном связаны с адресной арифметикой.
Честно говоря не вижу предмета спора. Я не противоречу вам. А вы собственно мне. По крайней мере я так вижу.
Да нет, конечно. Это не то что бы какой-то предмет для спора. Вопрос удобства.
Вы привели пример с типами данных. Вот я сейчас в основном мейню С#. Так вообще нету с этим проблем. Написание структуры либо класса - пара минут. А дальше используй этот тип точно также как и любой другой нативный.
Ну... Наверное... Но тут вопрос "ситаксического сахара". Вот есть в БД табличка. В ней 20 полей. Среди них есть поля date, time, timestamp.
Чтобы со всей этой радостью работать что придется? Сначала описать структуру, соответствующую структуре записи этой таблицы (куда будете читать запись). Когда табличка одна - да и бог бы с ним. А когда их десятки тысяч? И неизвестно с какой из них придется завтра работать...
Дальше - что делать с этими датами, временем и т.п.? Придется написать свой класс где будет реализована вся арифметика - представление даты в виде числа или строки в десятке разных форматов. Конвертация строки или числа в дату. Разность дат, увеличение/уменьшение даты на заданное количество дней/месяцев/лет. И т.д. и т.п. Аналогично для времени, таймштампов, типов с фиксированной точкой (decimal, numeric).
Затем вы прочитаете запись в буфер. И надо как-то сделать так, чтобы из этого буфера создались объекты нужных типов с которыми далее уже нужно работать. Т.е. байты с 1-го по 8-й - это объект типа дата, с 9-го по 15-й - объект типа numeric.
Это все реально, но это все время. А теперь представьте, что структуру, соответствующую структуре записи можно описывать просто ссылкой на нужную таблицу. Одной строкой. "Такая же как структура записи в таблице ...". Что вам не надо создавать никаких дополнительных объектов для дат, времени, чисел с фиксированной точкой - это просто типы данных. Прочитали запись из БД в объявленную "как запись" структуру и сразу работаете с ее полями.
Такой вот "синтаксический сахар". Когда вся работа заключается в том, что нужно что-то прочитать из БД, как-то обработать и положить обратно в БД, когда количество таблиц и индексов в БД десятки, если не сотни, тысяч все это уже чувствуется.
Дальше. Скорее всего у вас единственный способ работы с БД - какая-то библиотека, позволяющая выполнять SQL запросы. А теперь представьте что не нужно библиотеки. Вы можете прямо в код вставить exec sql и дальше запрос практически любой сложности (хоть на три страницы с 5-7-ю подзапросами и т.п.). А если вас не устраивает sql по какой-то причине, можно использовать прямой доступ к БД средствами языка - позиционирование индексе, чтение/добавление/изменение/удаление записи и т.п. Чтобы прочитать запись по известному значению ключа не нужно раскручивать sql движок, можно просто сделать это одной строкой в коде.
Сейчас, кстати, в работе задачка где или очень сложный SQL запрос, или прямая работа с БД. Так вот напhямую с БД работает на 25% быстрее чем через SQL. Потому что там можно реализовать алгоритм, использующий возможности языка и минимизирующий количество обращений к БД. Возможностей SQL на такую логику не хватает уже.
Я не говорю что на любом другом языке это невозможно. Возможно. Если найдете подходящие библиотеки. Но тут все уже есть. Он специально на это заточено. Меньше зависимостей, меньше строк кода.
Теперь я с переменной этой структуры в любом математическом выражении просто участвую. Складываю, умножаю, сравниваю. Да вообще всё. Также инициализация переменной. Написал нативное присваивание всех нужные мне типов . Теперь переменная инициализируется от массива, поинтера, набора int, long. Да вообще всё что мне надо то и будет жрать. Собственно что мне прописные истины описывать. Повторяю - современные развитые языки это умеют. Ну или должны уметь. Если они развиваются то такой функционал точно подъедит.
Несомненно. Я не говорю что на любом другом языке это невозможно. Возможно. Если найдете подходящие библиотеки. Но тут все уже есть. Он специально на это заточено. Меньше зависимостей, меньше строк кода. Или вы некий буфер читаете в структуру (одной строкой кода) где расписаны поля нужных типов, или вы инициализируете нужные переменные кусочками этого буфера. Каждую переменную отдельным куском и отдельной строкой.
При этом, если мне потребуется решать иные задачи (а это иногда приходится - что-то низкоуровневое делать) - я выберу С как более подходящий и удобный язык (слава богу, С и немного С++ были для меня основными в течении 25+ лет пока занимался другими задачами). Тут аналогия - если вам нужно вырезать сложный криволинейный профиль, вы берете лобзик. Если ровно раскроить прямоугольные листы - циркулярку. Пилить дрова - цепная пила.
Ах да забыл. Про неопределённое поведение. Скажем так - это вообще не то ради чего надо выбирать язык. Разумеется в разумных пределах конечно же. Тот же С++ косячно относятся в некоторых моментах. Да - это написано в документации. Но есть одно но!
Вот именно. Есть нюансы. Если вы не выучите наизусть 100500 страниц стандарта (особенно весело с учетом того, что стандарты постоянно меняются, а компиляторы не всегда успевают за последними версиями стандарта и нужно держать в голове - а какую версию стандарта поддерживает компилятор, а вот поменяли компилятор - что там перестало быть UB, а что, наоборот, стало UB...), вы рискуете нарваться на UB. В реальной жизни UB может вылиться в то, что ваш код продолжает тихо работать, но делать совсем не то, что от него ждут. Утрируя - 100 000 000 денег крупного корпоративного клиента ушли куда-то не туда. И узнаете вы об это только когда вам выкатят претензию "где мои деньги?". До этого будете считать все хорошо.
Более правильно в такой ситуации просто остановиться (с указанием где остановились и почему) и ничего не делать. Что сразу привлечет внимание. Но при этом не будет совершено никаких непредусмотренных логикой работы действий. Иными словами - или работаем так, как прописано логикой, или не работаем вообще. Т.е. ваш код на 146% предсказуем.
Все это не претензии к чему-то. Просто описание альтернативных подходов, которые тоже имеют право быть. Ну а выбор подхода в каждом конкретном случае за вами.
"Любая достаточно сложная программа на Си или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp." (Десятое правило Гринспена) :)
Так вот - все языки одинаковые в основе своей
Грубо говоря все языки состоят из if,for,var.
все мультипарадигменные языки, на функциональном явно с ходу, что то серьезное не начнешь писать
Ах, если бы. У меня такое впечатление, что "не важно, на каком языке писать" обычно тем, кто ни один язык не знает глубоко, поэтому не представляет, сколько подводных камней и особенностей могут скрывать другие языки и мир вокруг них. Этакий синдром Даннинга-Крюгера.
Я в своем C++ мире насмотрелся на таких свитчеров с Java/Delphi/Python/etc. (больно уж у нас предметная область интересная была, многие хотели поучаствовать). Да, они писали код, но делали это так, как привыкли это делать в своих прошлых языках. И ладно если бы у них получался просто кривой код (когда то, что просто и понятно можно уложить в 3 строчки, люди укладывали громоздкие в 15, потому что были не в курсе про доступные им возможности), так обычно код получался глючный и падающий в сегфолт в зависимости от фаз Луны. Понятное дело, что у нас в пайплайнах были и компиляторы с -Wall -Wpedantic -Werror, и анализаторы, и на код-ревью опытные коллеги высматривали код очень внимательно, и объясняли, как делать нельзя и почему - но без всего этого была бы беда.
С сишниками ещё интереснее. Казалось бы, более родственных в плане синтаксиса чем Си и Си++ не найти. Но я недавно тут на Хабре лично демонстрировал в комментариях "опытным сишникам" из мира эмбеддеда кейсы, когда абсолютно корректный в Си и логично выглядящий код являлся некорректным в C++ и вызывал неопределенное поведение. Потому что - да - специфика языка, о которой написано мелким шрифтом в одном абзаце стандарта на тысячу страниц. Для них это было близко к шоку. Да что там говорить, опытные сишники-эмбеддеры очень сильно удивлялись, когда я им доказывал, что абсолютно логичный код, который они пишут у себя каждый день, по факту с точки зрения стандарта языка тоже некорректный и может привести к неопределенное поведению, а они об этом даже не догадывались :) Это не знали люди, которые писали на языке десяток лет и делали вполне рабочие проекты - а откуда о таком узнать тем, кто "с наскоку" решил что-то написать на языке впервые?
У жены в фирме так ещё веселее, у них часть компонентов проекте написана на C#, а часть на F#. Люди, бившие себя пяткой в грудь на собеседовании про "я смогу писать на любом языке", когда доходило дело до F# или с воем исчезали, или отчаянно матерились и страдали :) Потому что парадигма другая. Между парадигмами переключаться сложнее, особенно когда до этого ты не имел никакого опыта с другими подобными языками.
Я в юности много писал на Паскале и Delphi (упокой господь его душу), потом полтора десятка лет на C++ и на C#. Я могу смогу написать код на других языках - Java, Go, Python, JavaScript, и так далее, но я прекрасно понимаю, что профессионал а них, в отличие от меня, будет писать код не только в 5 раз быстрее, но и гораздо качественнее, идиоматичнее и с меньшим количеством ошибок. Потому что важно знать именно специфику и нюансы. Но понимание этой важности приходит только с годами, опытом и набитыми шишками.
Я так же отношусь с подозрением к тем, кто знает и кодил на 100500 ЯП. Обычно это у них занимает 1, максимум 2 года. И в итоге получается что все и ничего не знает. Чтобы изучить тонкости ЯП нужно время.
А можно ссылку на эти обсуждения с сишниками эмбедерами? Интересно посмотреть эти кейсы.
Вот тут и дальше вглубь комментариев
На С++ надо с детства начинать писать, потом уже поздно переходить.
Два экземпляра "Совершенного кода" этому джентльмену.
Соглашаюсь на 146%
Начально-базовые вещи обычно просты, а знание языка - это именно знание нюансов и возможностей. И лень никто не отменял - узнали про var и for - и достаточно.
Один мой коллега написал на Си очень громоздкую систему управления расчетами, потому что ему было лениво углубляться во все возможности расчетной программы которые были доступны почти из коробки. А Си он и знал.
я тоже думал, что освоил питон за несколько лет решения алгоритмических задач
А потом был AOC 2023 и я понял, что не знаю я питон. Потому что вот
advent-of-code/py/2023 at master · oliver-ni/advent-of-code · GitHub
Огромный скрипт на питоне это нонсенс какой-то
Зато джунам надо это всё учить! Чтобы войти.
всегда предпочту композицию наследованию
Хорошо быть тупым — у тебя сразу появляется выбор ))) Ладно, я этого не говорил. Я тоже не лобачевский. Тем не менее…
Агрегирование, которое автор зачем-то называет композицией, нужно, чтобы показать, что А это часть Б.
Наследование нужно, чтобы показать, что А это частный случай Б.
Поскольку это ситуации, прямо скажем, очень разные, то как можно иметь по этому поводу какие-то предпочтения? Как говорили Спиноза, Аристотель, Гегель, Маркс, Энгельс и Джейсон Стэтхем, «Свобода есть осознанная необходимость».
Как хорошо, что в моём детстве программисты, на чьих библиотеках и фреймворках я учился, не были тупыми и использовали в библиотеках и то, и другое, в зависимости от ситуации.
Наверное, имелось в виду "плохое" наследование - когда наследование делается только для того, чтобы повторно использовать код базового класса в производном и "А есть Б" при этом там даже и не пахнет. Поддерживаю в этом отношении Рихтера - все классы, которые изначально не задуманы служить базовыми для других сразу же метить как "sealed", чтобы предотвратить возможные злоупотребления в будущем.
Это мне напомнило одну дискуссию про protected и private. Типа, если мы видим в коде protected, то по-любому в проекте где-то должен быть наследник, ради которого был выбран не private. Лично я считаю, что это глупый инструментализм (когда инструмент ставят выше цели, например, телегу впереди лошади). Согласно духу protected, это всё скрытое, что относится к общему случаю (всё, что private, относится исключительно к частным случаям).
Аналогично, я вижу дух sealed в том, что автор подчёркивает: из этого общего случая не бывает исключений. Поскольку я не Нострадамус, такая уверенность у меня возникает крайне редко, и я крайне редко испытываю в нём потребность.
С другой стороны, если бы я, как Рихтер, работал над дотнетом (в частности, BCL) и каждый день видел, что вытворяют юзеры с моими базовыми классами, я бы, возможно, писал его чаще ))))
Кстати, с sealed еще интересная такая штука, что он в некоторых ситуациях может прилично ускорять некоторые вызовы. Вот тут статья про это с бенчами: https://www.meziantou.net/performance-benefits-of-sealed-class.htm.
Агрегирование, которое автор зачем-то называет композицией, нужно, чтобы показать, что А это часть Б.
Кстати, вот, в переводе GoF (издание на русском 2020 года) в этом контексте используется термин именно "композиция":
Два наиболее распространенных приема повторного использования функциональности в объектно-ориентированных системах — это наследование класса и композиция объектов.
В старом издании (русском) 2007 года - тоже. Как в оригинале - проверить не могу, у меня под рукой его нет. Но думаю, если бы там было написано не "composition", а "aggregation", то перевели бы как "агрегирование", потому что термин тоже устоявшийся.
Наверно, это я ошибся с терминологией:
https://en.wikipedia.org/wiki/Object_composition#Aggregation
Тем не менее, я по-прежнему утверждаю, что когда нужно наследование, его композицией не заменишь.
В посте про "я за простоту", вы рассуждаете о математиках. Для того, чтобы создавать не вполне, a натурально рабочие, и, более того, производительные системы, сейчас достаточно изучить пару фреймворков для обеих сторон.
KISS - призван как раз исключить это всё из рабочих разговоров. Все эти тонкости ООП и ФП, на практике (ну там где бизнес, сроки, и прям здесь и сейчас, ФОТ, диффицит кадров), нужны только людям, которые их изучили до тех пор, как фреймворки и библиотеки инкапсулировали эти знания. Бизнесу нет дела то того, соответствует ли их продукт "Наследование нужно, чтобы показать, что А это частный случай Б" (простите, но наследование разработчику нужно, чтобы не писать код родителя), если никто не жалуется и он потратил на это столько сколько рассчитывал или меньше, а так же если новый разработчик легко подхватывает написанное предшественниками.
Ещё раз, цитата автора:
всегда предпочту композицию наследованию
Это значит, он пишет код, где такой выбор актуален. И значит, он разрабатывает достаточно (для этого выбора) сложный софт. Ну а дальше всё просто. Это два абсолютно разных приёма, как отвёртка и молоток. Что бы вы сказали про мастера, который всегда предпочтёт молоток отвёртке? То же самое я скажу про программиста, который всегда выбирает агрегирование, лишь бы не наследоваться. Я не знаю, вы вообще встречали таких среди коллег? Я — да, и неоднократно.
Самое ужасное, что они просто кокетничают насчёт тупости, а в душе считают себя очень умными. Я имел дело с индусами и китайцами (а китайцы, между нами говоря, запросто дадут прикурить индусам в плане «индусского» кода), но самый отвратительный и не читаемый код писали мои соотечественники с высшими образованиями. Не все, конечно, а те из них, у кого хватило ума прочитать какой-нибудь «Совершенный код» или «Паттерны», но не хватило ума разобраться в основах: зачем нужен тот или иной инструмент, и когда надо использовать наследование, а когда агрегирование.
Вспомнился "единственный в мире малыш котопёс". Достаточно яркий пример единства и противоположности наследования и агрегирования.
Есть прекрасный и прикольный сайт https://grugbrain.dev с похожим посылом ( и даже на хабре есть частичный перевод в https://habr.com/ru/articles/673640/)
Я программист, и я как идиот, считал числа Фиббоначи линейно за O(n), когда можно было посчитать через матрицы за логарифм O(log n).
Я программист и вообще никогда не считал числа Фиббоначи. Теперь уже не уверен, программист ли я.
Мне даже удалось их применить по делу. У меня логирование от длины очереди того что в этой очереди лежит происходит по числам Фибоначчи. Точнее по формуле, за начало я принял что было удобнее. Таким образом логов меньше и появляются они в нужные моменты когда производительность проседает и очередь растёт. Т.е. по сути я логирую в определенных чек поинтах от размера очереди рассчитанных по формуле Фибоначчи - работает лучше чем при других опробованных способах.
А Формула Бине? :)
(Что-то вроде О(1)?)
Формула Бине содержит возведение в степень n, а оно работает за время O(log(n))*
*Если предположить, что операции умножения работают за O(1), что на самом деле не так. Автор оригинального комментария тоже пренебрегает этим, а так же сложностью сложения чисел в наивном методе. Подробнее про сложности в этих двух метода тут.
Вы просто работаете по принципу KISS. Вполне рабочий подход, даже в крупных фирмах.
Автора статьи просто зовут Груг, и он делает всё правильно)
Наткнулся на статью про Груга ))) И да, Груг делает всё правильно )))
Меня смутила пара моментов. Я встретил пару статей в которых Google нашёл слово "JSON-over-HTTP", затем немного странного в репозиториях автора: https://github.com/nalgeon/redka, кмк троллейбус_из_хлеба.jpg, если надо KV - то почему не redis? sqlite3 хоть и не нуждается в запущенном сервере, всё же требует библиотек для работы с ним.
При этом я не отрицаю важность стремления к KISS, на мой взгляд следование этому паттерну одна из сложнейших практик для опытного программиста.
Далее "Внешние зависимости я ввожу по минимуму (в идеале вообще обхожусь без них)" - это хорошо, но если есть хорошие готовые библиотеки или ещё лучше стандартная библиотека (та что поставляется с языком программирования), то не использовать это почти что грешно, ведь библиотеки прошли ревью сообщества и имеют опыт применения в продакшене.
"Оставляю комментарии, чтобы напомнить себе в будущем, почему та или иная функция делает то, что делает, или зачем нужна определенная if-ветвь", серьёзно? Комментарий на то зачем нужна ветвь if?
Тот же Робер Мартин в своих лекциях рассказывает, что комментарии - порочная практика с тех пор, как пропало ограничение на длину имени функций и переменных, я, често признаюсь, не помню названия языка(ов), при отсутствии таких ограничений декларативный код описывает себя достаточно подробно, при условии, что у автора кода есть способности к выражению мысли в принципе. К тому же, когда я призывал к "давайте чаще комментировать", мне, как оказалось весьма справедливо, указали на то, что комментарии тоже надо поддерживать. Изменил код, не изменив комментария, - немного беда.
В моей практике я сталкивался с построчным описанием выполнения кода, вместо описания бизнес-требований, которые реализовывал этот код, ну т.е. вместо "здесь ограничение на значение переменной, связанное с такой-то спецификой бизнеса", мне оставили комментарий "если А больше или равно Б, то идём в другую ветку", что ровно также и никак иначе понималось из кода :)
"К дженерикам прибегаю только при крайней необходимости" - по-другому никто не делает. Просто в Go дженерики завезли не сразу, а так это просто тип как параметр, использование дженериков не требует никаких специальных навыков. И вообще раз мы за простоту, то почему было не ограничиться Python целком.
Наверно мне минусов насуют, за то что я не аплодирую стоя этому парню, но не привыкать.
Я люблю обходиться без зависимостей и библиотек, если код буду поддерживать один я. Я люблю обходиться без наворотов там, где это очевидно возможно. Я люблю аргументы "Зачем вам практики Google, если на ваш сайт заходите только вы". Я люблю sqlite3 везде где можно обойтись только им, при этом я не гнушаюсь просто JSON в файл писать, если у 100 пользователей и 7 записей в год. При этом я не люблю Docker до тех пор пока мой код работает на те же 100 человек и он в принципе на том же Python/JS/Ruby/PHP, я не люблю Apache Kafka, если можно обойтись самописной Que или тем же легковесным Redis. Я не люблю СУРБД, если можно обойтись SQLite.
Во всех остальных случаях голову необходимо иметь и использовать по назначению. Все сложные вещи придуманы не просто так, и хорошо понимать зачем они придуманы и границы их применимости.
Ну, не со всем соглашусь. Особенно по поводу комментариев.
Тебе нужны комментарии в ветке if, если сама логика бизнес-процесса начинает теряться в смысле вселенной.
// В случае если вторая буква в названии месяца совпадает со среднем значением всех букв в твоём имени, каждого второго месяца в котором нечётное количество дней а Марс идёт в ретрограде, мы обычно не пишем этот лог в базу данных.
У меня таких комментов - пруд пруди. На сервере они встречаются реже, а чем больше к фронтам, тем чаще такое бывает.
По поводу внешних зависимостей - то же. У меня стандартный пакет на ноде тянет 10 зависимостей. Сам Typescript, что-то для БД, zxcvbn, и что-то для обработки крипты и хеш-функций. Всё остальное - ручками. Особенно, грёбанный роутер, ибо задрали всякие заводы по производству и внедрению зависимостей. Когда проект на bun занимается тем, что тянет 1к зависимостей, ты понимаешь, что уже давно свернул не туда.
С другой стороны, если посмотреть на его репозитории, то можно увидеть что он сам на Сях пишет. Так что наверное, притворяется.
"С другой стороны, если посмотреть на его репозитории, то можно увидеть что он сам на Сях пишет" на этому хрупком предположении...
Простите, но как способность писать на сях, определяет хоть что-нибудь? Я могу все свои бесполезные произведения переписать на любой язык, что с того? Это каким-то образом мгновенно повышает авторитет автора текста?
Я тоже как-то писал на С++ без знания языка, успешно, датчики заработали на esp32. Доволен ли я собой сверх меры - да, стал бы кому-то нести "смари чё" - нет.
Сложность Computer Science никогда никуда не денется. Подходы и рекомендации принципов разработки и сопутсвтующих техник и технологий будут преследовать всех и каждого, кто решится развиваться в этом направлении.
Следовать им - хорошо, не следовать - успешно от случая к случаю.
Все практики и инструменты призваны облегчить путь разработчика к решению его проблем, но есть нюанс - границы применимости, как с тем же Agile, прости господи.
Причём, отрицая бесполезность комментариев вида "если А больше или равно Б, то идём в другую ветку", вы привели пример хоть сколько-нибудь полезного комментария. Я писал именно про комментарии, которые поясняли именно работу кода, не предающих никак смысл происходящего, для чего этот код в принципе написан, а не как он работает. В вашем примере здравого смысла нет, но что поделать, если таковы бизнес-требования
// В случае если вторая буква в названии месяца совпадает со среднем значением всех букв в твоём имени, каждого второго месяца в котором нечётное количество дней а Марс идёт в ретрограде, мы обычно не пишем этот лог в базу данных.
По-моему, ничего сложного в том чтобы такую логику написать достаточно понятно без комментариев - что мешает просто разбить её на отдельные части? Или это принцип KISS нарушит? :)
И, как по мне, так принцип KISS, на самом деле, давно запятнан, подобно символу свастики :) Слишком уж часто им стараются оправдать несоблюдение или банальное незнание каких-либо практик, а то и откровенный говнокод.
Относительно комментариев есть очень простое правило: в комментарии не надо писать, что мы делаем — нужно писать, почему мы это делаем.
Плохо:
spreadsheet.add_sheet(name: input_name.first(63)) # Берём первые 63 символа от входного имениХорошо:
spreadsheet.add_sheet(name: input_name.first(63)) # Для заголовка страницы берём только
# первые 63 символа потому что наши партнёры будут открывать этот документ
# в MS Excel, у которого сносит крышу, если имя страницы в документе длиннее
# 63 символов.(Все примеры выдуманы, все совпадения с реальностью случайны.)
А ведь можно:
MAX_VISIBLE_SYMBOLS_TO_OUR_PARTNERS = 63
spreadsheet.add_sheet(name: input_name.first(MAX_VISIBLE_SYMBOLS_TO_OUR_PARTNERS))
тогда и MagicNumbers антипаттерна можно избежать
Нельзя, потому что тогда непонятно — а чего это партнёры вдруг так захотели? Дело-то не в том, что партнёры так захотели, а в том, что ёксель так не может (а партнёры, ёпрст, без ёкселя не умеют). А придумать имя константы, чтобы коротко и ясно — так не всегда получается.
В таком случае ваш комментарий также вводит в заблуждение и ограничение на какую-то длину должно быть учтено в библиотеке:
from excel import spreadsheet, MAX_HEADER_LENGHT
spreadsheet.add_sheet(name: input_name.first(MAX_HEADER_LENGHT))
MS_EXCEL_MAX_PAGE_TITLE_SYMBOLS = 63
MAX_VISIBLE_SYMBOLS_TO_OUR_PARTNERS = MS_EXCEL_MAX_PAGE_TITLE_SYMBOLS
если надо KV - то почему не redis?
Вы видимо не следили за новостями https://www.opennet.ru/opennews/art.shtml?num=60820
Признаюсь, не слежу. Но там написано сразу же успокаивающее:
Сопровождение старых веток Redis 7.x, выпущенных до смены лицензии, будет продолжаться как минимум до выпуска Redis Community Edition 9.0
Если вам не нужен Redis-кластер (а он нам не нужен же в этом посте) можно не беспокоиться и продолжать им пользоваться. В принципе, если приложение простое, то можно и простой Dict/Map/Set использовать и хранить его в JSON файле.
ограниченны vs ограничены, как правильно?
Перевод сделан гуглом?
ЗЫ. Статья больше на крик отчаяния похожа.
Спасибо! Наконец то человек понимающий основополагающий принцип kiss. Теперь такого мало стало...
На программиста из Google они большого впечатления, конечно, не произведут
Тоже мне эталон))
Ага, я после того как посмотрел имплементацию протокола GRPC от Гуггла на нескольких языках, сбил оскомину "элитарности" их программистов )
Какие собеседования, такой и код в итоге - неподдерживаемый, неидиоматичный, неудобный в использовании, в простонародье "говнокод" от олимпиадников, которые не думают о том, кто и как этим будет пользоваться, "вещь в себе", а не продукт
Не то чтобы я заступаюсь за гугл, но возможно та часть кода, что исполняется непосредственно на клиентах/серверах написана так по причине каких-нибудь хардкорных оптимизаций. У них gRPC в продакшене вполне может использоваться в каких-нибудь микросервисах с адовыми нагрузками (и логично, что они писали его в первую очередь для себя), где даже микрооптимизации помноженные на переваривариваемые объемы могут дать существенную выгоду.
On contrary, код браузера Chromium от того же Гугла по большей части очень даже приличный и понятный (насколько это возможно для такой огромной и сложной по своему сути программы).
Иногда я чувствую себя точно также, как и автор статьи...
Да какой же вы тупой, если Вы умеете думать аналитически, делать выводы и искать решения проблемы?)) Тупой это когда вот это вот все не доходит, и человек дальше бьется об ту же стену))) В Вашем случае все проще, у Вас мозг устроен так, что описанные Вами задачи для него не подходят) Это примерно как человек технического склада ума лезет в гуманитарку, либо наоборот, и все выходит криво) Просто одним везет сразу найти нужную траекторию, другим нет, вот и вся разница) Продолжайте анализировать и искать свой фарватер, вот и весь рецепт)
Коллега! Тоже заметил что тем дальше, тем больше стремление выбирать наиболее простые решения. Минимум зависимостей, минимум уровней абстракций.
ООП - хорошо, но не везде эффективно применимо.
Оптимизирующий компилятор хорошо, но правильно подобранный для конкретного решения алгоритм даст куда больше чем "регистровая оптимизация".
Для каждой задачи всегда найдется наиболее подходящий и удобный для ее решения инструмент. Использование нескольких инструментов (в т.ч. и языков) - это нормально, удобно и эффективно.
Автор, вы супер! :)
Я мечтаю, чтобы весь легаси код, с которым я работаю, писал автор и такие как такие же как он.
Я, например, последние два дня потратил на то, чтобы разобаться как работает бибилиотека на С++ которую писал видимо ну очень умный программист, и я скажу это боль.
Для тех программистов, которые пишут отдельный класс для того чтобы просто хранить дескриптор открытого файла (причем это класс с кучей перегруженных методов, с шестью разными конструкторами на все случаи жизни), а для того чтобы открыть файл и записать в него данные используют четыре разных класса использующих дружские отношения, и лепят сверху шаблоны, вобщем для них в аду есть свой маленький, но надеюсь очень горячий котел.
А самое главное, весь этот ад не дает никакого прироста ни в производительности ни в безопасности, и при этом полностью убивается понимание того что делает программа.
Я наверное тоже тупой, вообще не понимаю для чего это было сделано именно так, зачем так сложно, где преимущества такого подхода? Все бошльше склоняюсь к мысли, что это все было наворочено исключительно для "хоба смотри как могу"...
Для тех программистов, которые пишут отдельный класс для того чтобы просто хранить дескриптор открытого файла
У программистов, которые умеют это делать правильно, потом не будет возникать вопросов "какого ... у нас висит по стопятьсот ненужных открытых файлов", просто потому что кто-то где-то просто забыл вызвать CloseHandle().
Для этого достаточно закрывать всё используемое - в деструкторе класса, где этот файл используется. Зачем еще переусложнять?
А вот и не достаточно, если закрывать файл в деструкторе "большого" объекта - может возникнуть ситуация частично построенного объекта, когда файл уже был открыт, но конструктор не был завершён. В таком случае деструктор не будет вызван.
Эта проблема общая для всех языков, но особенно чувствителен к ней именно C++ - "благодаря" отсутствию конструкции try/finally. И правильное решение - как раз индивидуальные обёртки для каждого дескриптора.
Ну и вы совершенно напрасно считаете этот подход усложнением. Как только класс-обёртка написан - весь остальной код сильно упрощается, а вовсе не усложняется.
Я был бы абсолютно согласен с вами, если бы это был действительно большой объект, или если бы мы не знали заранее количество файлов с которыми надо работать, но в том объекте, было ровно ДВА дескриптора, контролировать их закрытие не составляет труда и расширения количества в принципе не ожидается. Имхо решение проблемы закрытия двух файлов ценой потери читаемости программы, это переусложнение не имеющее смысла.
Если файл нужен только на небольшом этапе жизненного цикла объекта - например только в пределах одного метода?
Это вообще отдельная тема. Достаточно много людей, которые пишут некие интерфейсы совершенно не задумываясь о том, кто и как ими будет пользоваться. Т.е. о типичных сценариях использования. В результате получаются жуткие монстры с кучей параметров, 70-80% которых никогда не используются и передаются каким-то дефолтными значениями. А за всю эту универсальность приходится платить производительностью.
Респектую автору! без понтов и по делу. Такой программист вызывает больше доверия и действительно адекватно делает свои задачи, чем самовлюбенный бабуин
Я думаю что это просто умелое применение принципов "Keep It Simple and Stupid" и "Choose Boring Technology"
Когда программист в первую очередь решает задачи бизнеса, а не играет в кубики, экспериментирует и прокачивает своё эго, наворачивая сложность на ровном месте
Вроде так и должно быть в идеале?
Поддержу двумя руками!
Очень созвучно моему видению.
Считаю два самых важных для меня инструмента - SQL и регулярные выражения.
Рекрутер: От вас требуется вот это все уметь, вот вилка зп.
Я: Я умею это все. Дайте мне денех в верхних пределах вилки.
Рекрутер: Вы нам не подходите, по причине меркантильности/отсутствия второстепенного скилла/отсутствия софтскиллов/наличия прыща на подбородке/Луны в Стрельце.
Я: (ухожу) Наверное, я плохой специалист...
Раньше люди старались стать умнее и делились своими новыми познаниями, а сейчас гордятся своим невежеством и делятся этим)
У Стива Макконнелла есть очень известная книга "Совершенный код", и там почти что треть всей книги посвящена управлению сложностью, и там есть такая цитата Дейкстры: «Компетентный программист полностью осознает строго ограниченные размеры своего черепа, поэтому подходит к задачам программирования со всей возможной скромностью»
Это принцип KISS +документирование + житейская мудрость.
Мужик, все мы ищем как облегчить свой путь и это нормально! А про моду - за ней гоняться не стоит, сама придет, языки входят и выходят...
Это замечательно. Это исповедь разработчика/программиста. Или наставление - с удовольствием давал бы это в виде клятвы джунам.
Достаточно было дать ссылку на свой гитхаб, чтоб понять какой программист.
Я программист, и я тупой