Комментарии 279
В отличие от оригинальной статьи, эта вызывает во мне больше симпатии. За ней чувствуется опыт и адекватное отношение к жизни в целом, а не только к одному её аспекту - работе.
Обе статьи — абстракция без конкретики. Каждый читает и каждый думает о своём.
Наблюдай и делай красиво, воруй у других. Тащи себе в привычку все лучшее, что ты увидел у других.
Первый читатель: О, да, да! Всё верно!
Второй читатель: О, да, да! Всё верно!
Когда они встречаются: Ты сделал некрасиво! Нет, это ты сделал некрасиво!
Видя говно(код) нажимай CTRL-A + DEL без раздумий
Первый читатель: О, да, да! Всё верно!
Второй читатель: О, да, да! Всё верно!
Когда они встречаются: Ты зачем удалил мой красивой код? Он был говнокодом!
И так по всем пунктам. Что в той статье, что в этой. В итоге многие лайкают (или дизлайкают), но каждый видит статьи через своё своё субъективное мнение, которое, вполне вероятно, не совпадет с другими поставившими лайк (дизлайк).
Гороскопы так же "работают". Напишут абстракций побольше, в итоге большинство любителей гороскопа уверенно скажут "да-да, это про меня"
А по факту универсальных и единственно верных решений нет и быть не может. Надо каждый раз думать, обсуждать.
Для того, что бы прийти к следующему неверному решению? ;)
ИМХО прав и первый и второй и даже ваше мнение. И код нужно было создать, удалить и пересоздать.
Когда они встречаются: Ты зачем удалил мой красивой код? Он был говнокодом!
Понимание эстетики может разниться, но главное, чтобы оно было. Тогда по-любому работа будет сделана хорошо.
Как говориться не все так однозначно...
Вывод первый. Максимально изучи стандарты, принятые в отрасли. Беспрактис. Паттерны.
что здесь может увидеть каждый "свое"?
Вывод второй. Наблюдай и делай красиво, воруй у других. Тащи себе в привычку все лучшее, что ты увидел у других. Лучшие практики, лучшие проектные фишки. Лучшие технологии. Лучший инструментарий.
каждый "свои" лучшие практики вытащит? Лучший - не имеющий себе равных по качеству. (Определение из интернета) То есть нужно провести анализ, или обратиться к авторитетным источникам каким-либо которые уже провели этот анализ. Так что по сути у каждого "свое" быть не может. Если кому-то в команде не нравится какой-то паттерн, фича и т.д., потому что он "всю жизнь без него писал, и все работает", то это не делает его хуже и он свой статус - "лучшего" не теряет.
Вывод третий. Выбирай сложность согласно максимально возможному будущему развитию проекта.
А здесь ? Совет закладывать помощней фундамент, испокон веков это условное правило было. С опытом придет.
Так что как минимум половину статьи к абстракции сложно притянуть, хотя и можно при желании
Что такое "качество"? Что значит "не имеет равных"? Как узнать что ты изучил все решения? Что делать, если нет авторитетных источников? Как определить, какие источники авторитетны, а какие нет? Как выбрать подходящие бестпрактисес и паттернс? Что значит "подходящие"? Как провести анализ не будучи учёным или аналитиком? Как быть уверенным в результатах анализа без рецензентов? Как узнать "максимально возможное будущее развитие проекта"? По каким критериям? Спросить или самому решить? Как узнать, что не ошибся? Как узнать, что уже пора строить дом, а не закладывать фундамент ещё мощнее? Что фундамент, а что дом в контексте программирования? Решить это самому, спросить у ЧатДжипити или найти авторитетный источник? Что делать, если другой авторитетный источник противоречит первому?
И самое главное, что кушать, пока решаешь эти вопросы?
все же бывает важно остановиться, что бы спор не превращать в сплошные дефиниции прикладных значений слов).
Но даже не останавливаясь можно сходить на второй диалектический круг - если мы определим, что такое "качество" и "соответствие кода качеству", т.е. некоторым формальным измеряемым вещам, то становится опять же не важно, простой или сложный этот код. Он будет соответствовать, а значит быть качественным. А сколько там уровней абстракций заряжено - если в определении качества не будет про "минимально необходимое для решения точно поставленной задачи с бесконечной себестоимостью кода количество уровней абстракции", то и значения это иметь не будет?
Прикладные слова -- это именно то, что и нужно определять, чтобы не оказаться в ситуации, когда ты и команда по разному понимают и цель, и способы достижения её. Так же можно остановиться на том, что нужно делать хорошо, а плохо не делать и вообще никаких статей больше не писать, ведь всё остальное дефениции.
А по поводу определения "качества" всё куда хуже. Можно и нужно определить, что такое качество и как проверять соответствует ли код этому "качеству", только остаётся ещё доказать, что этот соответствующий "качеству" код будет решать поставленные перед программистами задачи.
Например, обфусцированный код может решать задачу усложнения чтения, одновременно мешая внесению правок. Качественен ли он со стороны обфускации? Конечно! Помогает ли это работе с кодом в команде? Помогает ли "сделать фундамент" для будущего развития проекта? Вряд ли, по крайней мере, это не доказано.
Я вопросы выше написал не для тренировки, я их задаю себе, когда выбираю, как программировать так, чтобы добиваться необходимого для проекта результата.
Я одновременно с Вами и согласен, т.к. "наука это суть математика" и надо бы все выразить в числах иначе все болтовня и не согласен, т.к. в математика с рядами по 500+ членов в первом приближении очень далека от прикладного смысла. Поэтому в систему уравнений ввожу еще одну формулу: "все ради лулзов" - писать и читать код должно быть еще и интересно. А этот аспект измерить крайне тяжело. И он будет прям сильно субъективен.
Множество кода не было бы написано в принципе выгоревшими сотрудниками, если бы не какой то дополнительный интерес в его создании. Множество кода оказалось бы хуже по "качеству" (что бы это ни значило), без живой вовлеченности человека в творческий процесс, исполненного на минимальный "от*вались" по формуле: если можно не вылкадываться здесь, то можно вообще не выкладваться.
Ну и совершенно мое субъективное мнение - я до сих пор не знаю как я программирую. Это для меня черный ящик почти 40 лет. Вечером вкладывашь "дано", утром получаешь "решение". Так для меня этот ящик все это время и работает. Поэтому лично мне всяка попытка как то формализовать этот процесс, как то его зарегулировать, сделать предсказуемее кажется бредовой - в общем случае я над процессом не властен.
Если нужен какой то определенный результат, то с работой моего черного ящика это можно получить только в несколько итераций. А на вопрос - а что сразу нельзя вот так то написать - нет нельзя. Я не конвеер, я творю. И то, что я вижу вокруг - никто не конвеер. Все хотят, что бы это работало как конвеер, натягивают эту сову на глобус изо всех сил, потому что без ИТ сейчас просто до свидания с рынка, но пока еще программирование не конвеер, а штучные творческие решения.
Ну про эстетику мало кто пишет. А ведь эстетика тоже важна — вспомните хрущёвки, которые с технологической точки зрения великолепны (вообще вся система микрорайона), но эстетически отталкивают. Поэтому + статья заслужила вот тем абзацем.
вспомните хрущёвки, которые с технологической точки зрения великолепны
LOL. Вы сами когда-нибудь в "хрущевке" жили? :)) Я, в принципе, их совсем не критикую. В те времена, когда большая часть городского населения жила в общежитиях и бараках, а отдельная комната в "коммуналке" считалась уже едва ли не элитным жильем, массовое и дешевое панельное строительство было действительно очень грамотным и хорошим решением, но говорить о каком-то его "техническом великолепии" это просто оборжака :))
Для 60-х годов прошлого века (если мы про СССР говорим) хрущевки были просто прорывом в массовом строительстве. Они и еще лет 100 простоят.
Микрорайон, как машина для жилья — это до сих пор state of art. Просто очень мало людей это может понять.
>Они и еще лет 100 простоят.
Не умаляя прорывности идеи хрущевок, хочу спросить, а Вы внутри них были за последние лет двадцать? Сквозные дыры в плитах лестничных площадок, осыпающиеся балконы видели? Не рассчитывали их на такой срок эксплуатации, их строили как времянки. Предполагалось скорое наступление коммунизма и строительство уже нормального жилья. Впрочем, качество в них сильно разнится, какие-то до сих пор стоят, превысив все мыслимые сроки, но сквозные дыры в плитах я видел еще в 2002 году!
Не умаляя прорывности идеи хрущевок, хочу спросить, а Вы внутри них были за последние лет двадцать?
Если под хрущевками понимать панельные пятиэтажки, то они по качеству ничем не отличаются от советских панельных девяти- и шестнадцати-этажек.
Сквозные дыры в плитах лестничных площадок, осыпающиеся балконы видели?
Там, где налажен текущий ремонт - нет.
Не рассчитывали их на такой срок эксплуатации, их строили как времянки
Это не так. Скорее, это даже миф такой сложился, мол их строили на 50 лет, а потом под снос. Не знаю, кто этот миф запустил, но 50 лет это срок до кап-ремонта. А так они и 200 и 300 лет простоят.
сквозные дыры в плитах я видел еще в 2002 году!
Честно говоря, жить в современных "небоскребах" не менее стремно, чем в винтажных исторических хрущевках. Бог его знает, на чем там строители сэкономили: то ли на шумоизоляции, то ли на теплоизоляции, то ли на надежности.
Не скажу за все хрущевки, возможно были и капитальные проекты, но в тех, где я бывал, толщина плит намного меньше, чем в девятиэтажках (в такой жил много лет), тем более, в семнадцатиэтажных домах позднего СССР.
Те самые плиты со сквозными дырами были сантиметра три толщиной, (кроме краев) и армированы хлипкой металлической сеткой (не буду врать про сечение, давно это было, но слово "пруток" явно не применимо, скорее толстая проволока)
Наборной фундамент там проблема, разъезжаются эти дома. Не везде, но я таких много видел
Не бытовое, а техническое великолепие. Возвести сто квартир в две недели - это торжество научно-технической мысли
Проблема в том, что про эстетику пишут как про однозначное для всех понятие. Например, у нас автор корпоративной core‑либы считает эстетичным разделять почти все строки с кодом пустыми строками. (Увеличить межстрочный интервал у себя в редакторе? Нет, пусть от моей эстетики страдают все) Вообще, статья мне показалась с долей наброса.
Есть такое. Но это лучше, чем ничего.
Вообще, статья мне показалась с долей наброса.
А-то.
Может Кодер выделяет смысловые конструкции, которые условно нужно вдохнуть выдохнуть и начать анализировать следующий абзац? А то что часто - ну часто вздыхает. Я люблю отступами выделить усложненную часть, идущую одним блоком
вот она - смерть автора на лицо!
А по факту универсальных и единственно верных решений нет и быть не может. Надо каждый раз думать, обсуждать.
Ну это типо разные школы карате получается)
Статья ни о чём, автор видимо действительно монтажник который определяет нахождение проводки металлодетектором.
1. Телефонная линия по витой паре это нормально и широко принято в цивилизованных странах. У меня рядом с электрощитком патч панель куда выведена вся слаботочка из всех комнат. Если хочется - подключу телефон, если не хочется - Ethernet. Зачем городить кучу разных проводов когда можно обойтись одним?
2. К электрощитку прилагается документация на 20 страниц с планом проводки во всех комнатах. Без неё квартиру не имеют права продавать. Там росписи и печати ответственных за работы.
3. Электромонтажник учился в специальном учебном заведении и получил лицензию которую обязан обновлять раз в 2 года. Если он это не сделает или сделает проводку не в соответствии с документацией - лицензия оканчивается и его запрещено пускать на объект.
4. Красивый код это типа брейнфака который печатает свой код? Не нужен он в индустриальном программировании, равно как и абстракции на всё. По сути кодер должен делать то что написано в тикете трекера, на остальное бизнес не согласен выделять ресурсы. Да, есть конторы где к примеру 4 часа в неделю выделяют на самосовершенствование. Но техдолг в 30 тысяч тикетов (включая рефакторинги, абстракции и даже тесты) это нормально для фирмы, занимающейся коммерческой разработкой. Она делает то за что платит заказчик. Он не платит за абстракции, он платит за продукт. Нет денег нет фирмы нет красивого кода. Для красивого есть опенсорс.
5. Учиться и воровать у других чревато. Видал я клубки проводов в подрозетнике - когда рамка едва держится из-за того что монтажник добавил слабины. Режь так как написано, не оставляй сопли. А если и учиться - то в профессиональном сообществе (том которое лицензирует). Там народ поумнее нашего и стандарты пишет не зря.
6. Абстракции это хорошо если они описаны в доступной документации с примерами и не задержали разработку. Был у меня опыт работы в одном стартапе где двое программистов-звёзд писали бекенд с абстракциями и всеми делами полгода без деплоев, публичных интерфейсов и всего такого. Фронтендщики реально страдали от того что им нечего было делать, равно как и QA. Через полгода выложили идеальный код и все попали в цейнтнот - продукт надо предоставить через месяц, но его нет. Начались овертаймы, взаимное раздражение, в итоге команда распалась. А бекендщики потом растрепали в городке какие лохи их коллеги и не умеют программировать.
Да, нормально, пока вы помните что у вас воткнуто в одном порту на одном этаже и в другом на другом и не ошибаетесь случайно. Если у вас нет дефицита пространства для кабельной магистрали что бы кинуть такой запас. Вы в этом пункте топите за оверпрайс по кабелям и работам, а в п6 уже назад сдали, не нужен говорите весь этот универсализм. В цивилизованных, что характерно, опять же странах.
Вы просто счастливчик, что ее видели. В 90х мы получали помещения вообще as is. Без единой бумаги. Что то старое всеми забытое советское. Если честно у меня не было уверенности что у заказчика была хотя бы единственная бумага о том что он владелец или представитель. И тут вы опять за оверпрайс по всеобъемлемому документированию и стандартизации, которое Вам досталось само собой забесплатно, но вероятно против когда то же касается собственного кода. Какжетак? Уже не надо проще? Надо по всем уставам?
И программист тоже учится. В современное ИТ просто нельзя без учебы, порог входа уже непомерно высок. Значит ли это что все его поделки автоматически имеют знак качества, гарантированные его лицензией? Строек, запоротых лицензионными сверху донизу конторами я повидал, день строителя праздную не без причины. С начальником отдела контроля качества строительства пол года сидел в одном кабинете, наслушался и насмотрелся, поверьте. Некоторые из домов обхожу на большому радиусу, равному их высоте. Говнокода, написанного людьми с иконостасом сертификатов за спиной я повидал не меньше.
Послушайте, если Вы знаете что нужно индустриальному программированию и заказчику, если заказчик все это знает, почему он сам ли, с ИИ ли теперь это не напишет? Почему 9 из 10 ТЗ от него, а в моем личном опыте 10 из 10 такой шлачище? Шлачище даже на этапе простого описания его бизнес-процесса? Заказчит все отлично знает как кто что должен ему сделать, кроме того что он действительно конкрено хочет, как он хочет что бы разруливались граничные ситуации. Таких заказчиков в строительстве тоже 9 из 10, поверьте. И на вопрос - уточните как конкретно в этом конфликтном случае строить у него стандартный ответ: ну у вас же лицензия, опыт, сделаете как надо, а я уж оценю как Вы сделали как мне не надо, не примину, за мной не заржавеет.
Не используйте плохих рамок и плохих подразетников. Кроилово приведет к попадалову. Если рамка сделана по гостам, но на отцепись, не покупайте такую рамку. Замените подразетник, если сможете. Не дайте себе привыкнуть к говнокоду, к говноинструментарию, хоть и по всем гостам. "По форме все верно, а по факту издевательство" - это про этот случай. Профессиональное общество, поверьте, оно не в институтах, оно растет с каждым проектом и самосовершенствуется на них. Оно отлично знает цену всем своим стандартам и их соответствию реалиям, там не боги горшки обжигают.
Ваш стартап был построен вокруг этих программистов-рокстаров, не так ли? Вся остальная контора зависела от них и все держалось на них, родят они или нет, не так ли? Они не шмогли, бывает, это венчур, это стартап, это не в потоке кодить. Вы им теперь предъявляете за это? Стабильность в госконторе, вместе с зарплатой в 3 копейки, но Вы же не в госконторе оказались почему то, а в стартапе?
Да, нормально, пока вы помните что у вас воткнуто в одном порту на одном этаже и в другом на другом и не ошибаетесь случайно.
то ничего не будет. В спецификации cat5 было ПРЯМО написано - синяя пара - телефония, О-З лан, коричневая уменьшенного сечения и с шагом намотки 1.5-2 см - экранирующая, и её параметры не нормированы (в отличие от остальных). Увы, я как-то потратил 4 часа, но везде только "обновлённый cat5e", там уже нет например про коричневую пару. Далее, телефония бывает и isdn, и там тоже нужная витая пара а не лапша.
К слову, cat3 по сути и есть телефонная витая пара...
Так вот. Возьми стандартный порт rj45, который на самом деле 8p8c, и воткни туда rj11 (телефонный). И 2 средних (рабочих) контакта К УДИВЛЕНИЮ садятся ровно на синюю пару, и сам коннектор сидит вполне штатно и уверенно. Интересно, почему же?
Я в юность был админом на одном заводе, сотни портов - и все так и были сделаны. А далее приходили на коммутационную панель и там расключали порты, где телефон, а где сеть, там ещё те самые тип 110 были, причём прямо коннекторами на патчкордах. Одна часть прямо на ножи без всяких обжимок, вторая - смотря какой кабель, телефон или сеть, в своё оборудование.
Это на мой взгляд была медвежья услуга всем в то время. 50 жильный кабель на 25 абонетов занимает сколько там, 2/3 дюйма сечением? 5/8? Раскидываетя и разводится в охотку по этажам гораздо быстрее utp-шек за один проход, и несколько емнип дешевле, кабелировать все здание с запасом сразу на этапе ремонта труда не составляло - если нет еще проекта этажа кидали к месту ящика типичное количество жил, крепили скобой к потолку до хороших времен если клиент пару тройку этажей заказывал.
И по 10 пар городских на типичное офисное пространство в 150 квадратов, емнип, но уже могу соврать. Разноцветным кабелем разводка и оно получается прям самодокументированное при открытии ящика уже все. Любо дорого работать. Админу заказчика при сдаче обжимной 110й Krone тот что серый с ножничками в подарок к ящичу и человек счастлив.
С ящика уже до клиентских точек кидали всегда 2 конца витой пары пока 5й категории, все равно бросовая цена, неясно что там в итоге будет, два компа или два телефона. А вот с 6й потруднее дела пошли, но ее редко заказывали и мы вкладывались во все эти радиусы изгиба и количество витков расплетения прям с душей. Мол вот, довелось поработать на настоящем инженерном проекте.
а потом "теперь у нас цифровая телефония" и бегай с Ж в мыле, перекладывай все кабели, сверли стены итд - или ставь чуть не по свичу на кабинет, потому что линий не хватает. А так - тупо воткнул воип телефон в порт бывшего аналога - получил связь. Потому что уже заранее расключено что все синие пары на аналоге, по 2 пары на цифре. "универсальный порт". Увы, не работает если нужен гигабит, но даже в 2025 на заводе минимум 60% линий - достаточно сотки...
А между стойками была оптика и 25-50-100-* парки для телефонии
Возьми стандартный порт rj45, который на самом деле 8p8c, и воткни туда rj11 (телефонный). И 2 средних (рабочих) контакта К УДИВЛЕНИЮ садятся ровно на синюю пару, и сам коннектор сидит вполне штатно и уверенно. Интересно, почему же?
(Усталым старческим голосом:) Есть такое слово, сынок: обратная совместимость...
И 2 средних (рабочих) контакта К УДИВЛЕНИЮ садятся ровно на синюю пару,
И два контакта 6p4c (который RJ11 или RJ14)) по обе стороны от центральной пары (зелёная пара в EIA/TIA-568B) тоже подсоединяются по телефонному стандарту для четырёхпроводных телефонов, например, системных телефонов Panasonic. Магия, однако
в данном случае не "обратная совместимость", а "универсальность разъёма". Для понимания - "старый" телефонный джек это такой квадрат, где-то 3х3см, с 4 длинными ножами + пластиковая направляющая. А RJ, они же *p*c - делались в одно время и сразу универсально.
Но техдолг в 30 тысяч тикетов (включая рефакторинги, абстракции и даже тесты) это нормально для фирмы, занимающейся коммерческой разработкой. Она делает то за что платит заказчик. Он не платит за абстракции, он платит за продукт. Нет денег нет фирмы нет красивого кода.
Тут какое-то бинарное мышление с неявной дихотомией между «наяриваем красивый код, напрочь игнорируя нужды заказчика и теряя деньги» и «делаем только то, что просит заказчик, заказчик рефакторинг не просит — не делаем».
Кстати, за какие конкретно тикеты платит заказчик фотошопа, автокада или clion'а?
Заказчик готов обменять свои деньги на определённый продукт, да. Но это не значит, что он платит только за то, чем он будет пользоваться прямо сразу после получения продукта. Те деньги, которые он даёт вашей фирме, фирма вольна распределять по своему усмотрению на техдолг, на текущие тикеты, на самообразование сотрудников и на директору фирмы на яхты (или сгущёнку, смотря что за фирма и что за директор).
Более того, даже если у продавана в вашей фирме происходит такой диалог с заказчиком:
— (З) Хочу такую-то финтифлюшку.
— (П) 1500 баксов.
— Не, 1200 максимум.
— Ну ок.
то это не значит, что вы все 1200 баксов обязаны потратить на ровно эту финтифлюшку, покуда она будет всё равно доставлена на устраивающем заказчика уровне.
И, собственно, решение вопроса распределения доходов на разные задачи — это ровно то, что отличает успешные фирмы от шараг.
Ну и ещё тут вопрос о том, что такое «нормально» в вашей фразе про нормальность тысяч тикетов. Воровство — это тоже в определённом смысле нормально — оно в каком-то объёме есть во всех социумах и известно любому человеку, но это не значит, что с вашим обоснованием «я украл потому, что воровство нормально и присутствует во всех культурах» согласится обворованный или прокуратура.
Имхо, четвертый вывод наиболее важен.
Часто на собеседования спрашивают - а что ты вот прям клевого сделал на прошлых работах? У меня есть парочка историй, которые я в таких случаях рассказываю. И даже не важно что там стало с проектом и компанией, мне было интересно, я получил свою дозу эндорфинов - это помогает продолжать работать и двигаться дальше. Эстетика это тоже о том же: если над проектом работать эстетически приятно, то это то что ты заберешь с собой, когда сменишь работу.
четвертый первый или четвертый второй? я не смог без пасхалки, коллега))
По сути скажу даже больше, это то, что ты забережь даже когда сменишь профессию и даже когда решишься отойти от дел.
Именованный четвертым =)
Да. Вот это то меня и печалит в наступлении ИИ - если клевый код будут писать не люди, что они с собой возьмут? Ну, кроме выгорания, выгорать то все равно кожаным.
Это крайне недооцененная мысль. И Вы, возможно, сейчас даже сами не понимаете всей ее глубины. Дело в том, что не бывает незаслуженных призов. По природе человека. Изи ком - изи гоу. Вместе с потерей проблем мы потеряем и достижения.
Я о ней уже давно думаю по вечерам, бродя с собакой по лесу, так что вроде понимаю.
Кстати, аналогичное с фотографией. Я это дело люблю, иногда выходит ок. Но мне тут куда более важен процесс, чем результат - результат то и сгенерить можно.
А может переоцененная? Потеряем одну проблему и как следствие достижение при её решении, обретём другую проблему. И будут ждать нас новые призы и достижения от решения очередных проблем...
Правда нас это не коснётся, век человека не долог, новыми инструментами, новые проблемы будут решать новые люди и получать новые достижения
Забавно, я вот помню, что раньше мне было, что расказать и про великие достижения и про великие фейлы, а теперь я только помню, что мне когда то было, что расказать.
И когда это спрашивают на собесе, я чешу намечающуюся лысину и честно говорю, что не помню, но почему то никто не верит, все думают, что я что то скрываю )))
Нет ощущения что жизнь проходит мимо и надо поспешить зафейлиться и достичь высот уже с учетом текущего багажа опыта? Это одна из главных моих мотиваций что хотел, мог, но не сделал. Не пригласил, не рискнул, не попробовал, не проиграл. И в итоге выглядит так, что проиграл. Или это уже следующий этап в просветлении?
Со временем начинаешь предвидеть результат по такому с первого взгляда простому правилу: нет предпосылок - будет отрицательный, есть предпосылки - можно пытаться (но без гарантии). Что-то, что тебя выделит на фоне всех остальных, кто фэйлится. Как в хардкорной соревновательной игре: чтобы победить босса, надо высокую стамину, или крутую шмотку, или помощь друга, или отличную реакцию, или чтобы босс застрял в текстурах. А если у тебя всё как у среднестатистического игрока - ты проиграешь.
Вяглядит так, что это уже стало не важно, ну плюс еще черта характера минимум амбиций и умение ценить то, что имею, очень сильно помогает не думать о таком и беречь нервы )
Опять же я и фейлился и достигал, просто оно стало не так важно и было изьято из архива) Там теперь куда более интересные для меня вещи )
Блин, ну это как-то грустно. Может стоит больше обращать внимание на достижения?
Эстетика важна. На работе ты проводишь большую часть жизни. Жить красиво это не пришел домой на 2 часа поел с красивой посуды и лег на красивую кровать. Жить красиво это прежде всего о работе, о твоем продукте, о твоем инструментарии, о твоих мыслях, которые с тобой даже когда ты дома
Вот это верно. Почему-то среди программистов повелось, что костылестроение и говнокод это как минимум данность, а как максимум даже повод для бравады. Сколько этих дурацких анекдотов из 90х про угрюмых программистов в грязных свитерах, у которых всегда и везде "велосипед на костыльной тяге". Уж в наше-то время со всеми доступными помогайками нет проблемы содержать кодовую базу в адекватном состоянии.
Никто из всей цепочки от инвестора до Вашего непосредственного ни думал на такую дистанцию
А когда я говорю, что айтиндустрия это отрасль сознательно делающая сиюминутный мусор, на меня ругаются. :)
делающая очень дорогой сиюминутный мусор. Это много объясняет в отношении к этому мусору!
Один раз нашу почти гениальную кодовую базу в миллион строк руководство слило в утиль одним неудачным кредитом. В программировании есть принцип не заниматься микро-оптимизацией, пока не выполнена макро-оптимизация. Так вот любой наш код и вообще весь проект в масштабах бизнеса это микро-оптимизация.
Делающая очень дорогой и иногда очень полезный мусор.
Все прилагательные: дорогой, мусорный, очень - не важные, а вот уровень полезности значение имеет, это измеримо, а это уже ближе к сути.
Дорогой - тоже измеримо, но тут и разговор будет другой, уже с цифрами, а не просто: дорого/дешево
У меня есть ощущение, что все эти "надо" стали появляться как грибы в тот момент когда все стало дорого. Раньше код был дешев и факультативен, было время и на излишнюю стркутуризациб и на излишнюю оптимизацию. И мы действительно творили. А сейчас он стал обязателен и дорог. И заказчик вынужден лезть буквально под руку считая строчки и часы твоего труда. Многим людям в профессии стало не до интереса, а до денег здесь и сейчас.
Момент о падающей стене, держащейся на скрутках неучтенной электрики, в очередной раз разбил вдребезги миф о дятле, разрушающем цивилизацию, построенную программистами.
Почитал с удовольствием.
> миф о дятле, разрушающем цивилизацию, построенную программистами
Так эта цивилизация 6щё не построена.
Строится, да, но ещё не построена.
В этом мифе все - аллегория. Строители тоже не строили цивилизацию. Как и электрики. Строили все вместе, последние полсотни лет включая и программистов. Речь об уровне кволити ашуранс в разных сферах и подходе к работе в целом.
Если очень хочется холивар, то могу подкинуть тему: чей вклад в современные небоскребы, самолеты, ракеты и все остальные аспекты цивилизации больше: программистов, или строителей. Сам участвовать не буду, здоровье не позволяет.
Если очень хочется холивар
Если вы перестанете выдумывать мифические холивары (хейтеров, троллей и т.п.), то обнаружите, что сказанное Вами является максимально серъёзным.
Например, сейчас распространено планирование жилища с помощью софта, и если софт плохой - вы купите мебель, которая вам не подойдёт по размерам.
Со всем остальным планированием и проектированием ровно то же самое - человек жмёт кнопку и получает расчёт, не задумываясь о том, имеет ли расчёт физический смысл.
Код с кучей заглушек на все случаи жизни на разных уровнях абстракции выглядит уродливо, особенно когда потом оказывается что 90% из них не нужны, но в каких-то из них стоит TODO, а в другие что-то внесли и непонятно это просто так стоит или работает иногда.
Аналогично если массив никогда не будет больше 5 элементов и всегда будет индексироваться целочисленными индексами - не стоит превращать его в инстанциацию темплейта на основе сбалансированного дерева Адельсона-Вельского-Ландиса (ошибка которую я делал в мои 20+ лет - сейчас мне 50+)
Начинал я с коаксиала брошенного под ногами, а вот заканчивали мы уже на 6е так: заходили до штукатурки и спрашивали у лендлорда, хотелось бы ему сдать это помещение богатенькому быстроразвивающемуся колл-центру в ближайшие 10 лет и если да, то мы под штукатурку шагом в полтора метра закладывали пустую гофру с проволокой, делая метки над армстронгом, в углу кидали силовые штанги под 19й ящик и бронировали место для кабельной трассы с проводкой и землёй к нему. Считай что ненужные типовые абстракции бизнесс-процесса "помещение в аренду" с заглушками.
Для понимающих детали этого бизнесс-процесса все более чем приятно и понятно.
Но согласен, пункт спорный.
От строительтсва далекий человек, поэтому пользуюсь случаем: допустим, капитальный ремонт квартиры. Хочется для связности условный Cat6e. Но потом когда-нибудь его не хватит на супер-пупер быстрый ethernet. Получается по таким подготовленным кабельным трассам можно новый кабель протянуть будет на замену? Как "проволока с гофрой" выглядит, насколько инвазивный процесс?
Все же мне тяжело представить в квартире такую плотность слаботочки, таки совершенно другая нагрузка. Вам, условно, не нужен телефон проводной 24/7 прям под рукой, домофон ездящий за секретарём, квартиру очень вряд ли разобьют на две каждая со своей сигналкой и пр.
А вот базу под электрику я бы закладывал по максимуму на возможный десяток лет исходя из чутья и не любви к удлинителям.
Делал бы под потолком за штукатуркой горизонтальный кабель нужного сечения, с запасом вставлял коробки и вниз вкладывал бы каналы до уровня розеток, если что её врезать. Канал, из той же гофры можно, кто то трубку кидает с проволокой что бы металлодетектор видел ход канала и нижний уровень розетки когда полочку вешаешь. В коробку над ним можно бирку с описанием чего это было. Но это если штробить не надо, слой штукатурки позволяет.
А задумываться над несуществующими будущими технологиями вопрос сложный. Столько всего было, что не прижилось даже из того, что было на рынке некоторое время.
Я не уверен что аналогии из хардвара хорошо ложаться на софтвар. Вон, мост какой-нибудь хрен построишь не через вотерфол, а сайтик легко.
Меня тоже пункт про абстракции, прям напряг, словно стеб промелькнул...
Сразу закладывать норм базу данных, а не екселевскую табличку - норм
Сразу разделять ответственность в коде и задумываться о тестировании - норм.
Но и границы должны присутствовать, иначе с "эстетикой" проблемы начнутся...
Аналогия из вашего хард занятия.
Сделали классно, с запасом на 6-й категории, всё подключили по кабелю к коммутатору. А тут дзынь через год после запуска, поставили вифи роутер и всё...
Любая аналогия, далека о правды, она лишь способ передать мысль и причина задуматься.
А вот и нет, не всё. У Вас как у арендодателя остался актив - возможность сдать помещение потребителю с требованием к кабельной системе. Это повышает ценность Вашего актива, вы можете поднимать цену арендаторам, аргументируя тем, что у вас уже не один возможный клиент, а два. Торговаять тем, что на запуск его офиса в работу ему нужно на неделю меньше времени с гораздо большей эффективностью и без лапши из кабелей с потолка. Только на этом себестоимость работ можно отбить.
Наличие конечно лучше отсутствия )))
Торговаться конечно можно и аргументировать, вот и плитка тут итальянская...
Опять таки, нужно торговаться (время и силы) и ждать того самого заказчика, а сосед уже сдал в аренду... Не мне спорить о бизнесе деланья ремонта и сдачи в аренду...
Но аналогию я привёл именно для того чтобы указать на безусловность наличия пределов и у уровней абстракций и у уровней надёжности, и у уровней качества которые закладываются, у всего.
Всегда помнить, что «нет ничего более постоянного, чем временные решения».
Лет десять назад дiд Панас запроектировал на одном объекте (= одной таблице в базе) дополнительную колонку interest_rate. «Зачем? — спрашивали его. — Это ж константа!» Дiд Панас ничего не говорил, а только ухмылялся в усы: «А вы поживите с моё, сы́нки».
А полгода назад к дiду Панасу подошли с вопросом — «а нельзя ли поменять это значение?» «Конечно, можно!» — ласково сказал дiд Панас, нажал несколько клавиш, закрыл таск и вернулся к медитации.
В точку!
А мог бы нажать несколько клавиш и добавить столбец в БД.
Так он его и добавил. Десять лет назад. Пользуясь своим развитым навыком телепатии предсказамуса.
А потом за десять лет вокруг всего этого наросло огромное количество кода. Которое нельзя было бы взять и добавить «несколькими нажатиями клавиш».
те 10 лет фирма переплачивала деньги за хранение мусора, его кластеризацию и бэкап.
На миллионе записей того мусора — восемь мегабайт. Следует отметить, что фирма хранит несколько терабайт мусора по принципу «чтобы было» — и не чешется.
вы уверены, что физически таблица занимает 1-1 место на диске? вот пример, как правильно считать в постгре - https://wiki.postgresql.org/wiki/Disk_Usage
Если честно, очень странно, что столбец interest_rate понадобился только через 10 лет... Как-то они чудовищно тормозили.
Красавчик - этот ваш дед Пихто - как ловко он просидел в фирме 10 лет чтоб потом несколько клавиш нажать с умным видом!
И все эти 10 лет другие программисты смотрели на это и думали, что не так же просто это было добавлено, ведь могло бы хватить простой константы. Шли смотреть есть ли где-то другое значение в БД. В дэв БД его не было, конечно, и это легко было проверить, но что там на проде, к которому нет доступа? Значит надо админов дёргнуть, ну или аналитика какого, с read-only доступом.
И все 10 лет другие программисты смотрели на это и думали, что не так же просто это было добавлено, ведь могло бы хватить простой константы.
И предусматривали случаи обработки, когда это значение другое. И именно поэтому потом через 10 лет значение получилось сменить.
Было бы оно константой - попытки изменения вылезли бы вооот таким табуном ошибок.
хах, просыпаюсь сегодня утром, захожу на рабочий комп - а там вся почта в err log.
добавил вчера поле в таблицу, на которую ссылались сотни объектов, и среди них один пакет, в котором есть процедурка в 20 потоков обрабатывающая очередь. а т.к. таблицу изменили, то пакет стал невалиден и его надо компильнуть, а т.к. там одновременно 19 других потоков с ним работает, то ни один не может этого сделать норамально. И получай некую ошибку ORA-04021, которую я впервые в жизни увидел. А на этот пакет ссылается ещё 15 других, которые тоже падать начинают с этой же загадочной ошибкой.
Просто нажми несколько клавиш, да добавь столбец в БД, говорили они -)
Красивая сказка. В реальности оказалось, что interest_rate меняется динамически в зависимости от ставки ЕЦБ и смысла иметь это поле в таблице CLIENTS нет вообще никакого, там оно только историю изменений засирает.
Но так как поле уже есть, а физически удалять поля из таблицы в системе 24*7 это то еще приключение, будет оно висеть вечно, как памятник глупости и самонадеянности...
Иногда для мвпшки какого то промежуточного релиза хочется иметь что то вроде доп столбца, доп таблички, чисто для утилитарных целей на некоторое ограниченное время. Пока не устаканется представление как же правильно на самом деле. Бизнес же так же подстраивается под ит-систему, он не статичен, не в камне высечен, а предсказать его подстройку это те еще софтскильные компетенции, не у всех на таких спецов деньги есть.
В реальности оказалось, что interest_rate меняется динамически в зависимости от ставки ЕЦБ
Ну как Вам сказать.... У Вас там в России interest_rate за 10 лет 100500 раз поменялась, а у нас — нет. А другие вещи — строго наоборот (например, президенты).
Достаточно того, что она может поменяться. То, что она не менялась в течении длительного времени, совершенно не значит, что она не может поменяться в любой момент.
Это как с датами - когда-то казалось что двухзначного обозначения года вполне достаточно. А сейчас уже думают о том, что будет когда UNIXTime закончится (видимо, придется новую эпоху открывать, как это уже случалось со временем в GPS).
У Вас там в России
https://www.hypochart.de/zinsentwicklung/leitzinsen
https://www.infina.at/trends/verhaeltnis-fix-und-variabel-verzinste-wohnbaukredite/
В ЕС 2015 доля кредитов с плавающей ставкой была 84%, сейчас 23%.
за 10 лет 100500 раз поменялась, а у нас — нет.
В Японии живете? других стран я не знаю....
В Японии живете? других стран я не знаю....
Условия банков для бизнесов очень сильно отличаются. У Вас есть многомиллионный бизнес в США? Нет? Тогда давайте Вы не будете мне рассказывать, как его вести.
Лет десять назад дiд Панас запроектировал на одном объекте (= одной таблице в базе) дополнительную колонку
interest_rate
одну?? какой-то легкомысленный дед. В моей реальность ставок бывает с пяток разных!!
Если я правильно понял, речь о процентной ставке? Я бы тоже думал ноль секунд о необходимости такого поля. Константа - это число пи или адрес графической памяти в спектруме. А в экономике константам места нет.
в экономике константам места нет.
Так-то оно так, но по факту 8 лет это значение не менялось.
То есть даже не со дня основания Америки? Как же быстро у некоторых людей начинается вечность. А со своей стороны я бы никогда не предположил, что типа bool для описания пола может не хватить. К счастью, до наших краёв эта тенденция не докатилась.
Ну я повторяю: при постановке задачи N лет назад были поползновения принять её константой, и 8 лет всё нормально было.
С одной стороны, много разумных мыслей.
С другой - видимо, автор никогда не сталкивался с очень большими long-life проектами которые живут десятилетиями и при этом масштабируются и развиваются.
И да, попадается код, который приходится полностью переписывать (обычно, это оптимизация). Но много такого, что работает себе и работает и трогать его не надо. Потому что для бизнеса это будут просто расходы, ничего не приносящие.
А вот "взять все и заменить" будет стоить просто космических денег.
А что касается простоты кода, то он во многом определяется бизнес-логикой. Если логика простая - не надо ее усложнять ради мифической "концептуальности". Но бывает и такая, которую просто не описать - тут приходится мозгой ворочать чтобы получилось если не просто, то хотя бы читаемо и понятно.
Согласен с обеими статьями.
Видя говно(код) нажимай CTRL-A + DEL без раздумий
Нет! Закомментируй его и ниже пиши свой, хороший. Не удаляй его даже когда все вроде бы заработает как надо. Потому что возможно там где-то зарыта хитрая задумка.
Мы долго думали над удалять нельзя комментить. Приняли решение удалять все, что старее одного релиза, старая версия в истории. Даже если будет таск на вернуть все взад, возврат сделать исходя из нового видения, команда наработает недостаюшие компетенции. Подход не серебряная пуля, но право на жизнь имеет.
Тогда не удалять хотя бы в моменте. Чтобы при необходимости можно было подсмотреть, а что же там все таки имелось в виду. )
Если у вас система контроля версий, то код не удаляется — он уходит в страну вечной охоты вечного хранения.
А системы контроля версий на что? Я принципиально стараюсь не держать закомментированного кода, если вдруг понадобится - всегда можно из истории гита вытащить.
Чтобы знать, где оно было, надо знать, что оно было. А у git-а с discoverability, как и многих инструментов, -- не очень. Я хоть и не согласен с "оставить рядом", но комментарий на последний коммит указывающий можно. А серьезнее, то засунуть в тесты и гонять 1-к-1.
Закомментированый код - это как правило то, что там по логике (или стандартам) должно быть, но в данной конкретной реализации дает какие-то отрицательные эффекты. И вот тогда это оборачивается в каммент с пояснением почему именно так и почему именно здесь отошли от привычной логики/стандарта.
Раскапывать это потом по гиту можно, но это лишнее время во-первых и риск что кто-то этим заниматься не будет и просто "восстановит как надо по стандарту", а потом будет долго удивляться почему в другом месте поведение поменялось, во-вторых.
Каким образом следующий разработчик должен догадаться о существовании альтернативной версии? Даже с существующей историей смотреть на миллион версий назад — сложная задача.
История не всегда сохраняется. Я работаю над проектом, где в части файлов есть пометки о копирайте / задачах из начала 90-х и даже конца 80-х, но первый коммит в гите — 2019-й год с текстом "Import source code from the vendor". Если там что-то было раньше, то заглянуть в историю невозможно.
Ах вот вы какие, любители оставлять горы закомментированного мусора в коде! Что ж, я всё думал, что это из-за лени и пофигизма, а оказывается, тут прямо искренняя уверенность в том, что это правильно и хорошо :)
Не согласен. Я как-то анализировал странное поведение в коде и очень уж захотелось внести одно исправление. Даже придумал какое и осталось найти «куда». Нашёл, а там коммент оставлен, с примером изменения которое я и планировал сделать. И написано было в комменте, что так менять нельзя, т.к. это приведёт к такому-то некорректному поведению. Видимо чел тогда не доразбирался и оставил на будущее. Хорошо, что предупредил.
Ну так это особая ситуация, когда есть чёткое послание от автора: "Так делать не нужно, оно не сработает".
В исходном комментарии речь шла про другое: "не удаляйте старый код, а закомментируйте его и пусть лежит, вдруг когда-нибудь понадобится". Такой подход превращает код в свалку.
Можно, конечно, пошутить, что жалко удалять уже написанный код, но в принципе, пока переписываешь контекст нужно какое-то время иметь перед глазами старый код, даже если он переживёт несколько коммитов. Для себя я субъективно придерживаюсь правила - до мерджинга с основной веткой разрешаю не стирать что угодно. Могу даже перед мерджем что-то оставить. На усмотрение. А так-то согласен - чистый код выглядит привлекательно и быстрее читается.
Вот, вот. Выкачу в прод, поживу, а потом и удалю. Код в комментах, он вот тут, рядом. А лазить по веткам в поиске измененного, или не умею или не привык.
меня учили привыкать некпривычному и уметь то что не умею. Тоже коментировал (свой же код, только учусь), но когда открыл для себя систему контроля (десктоп + ноутбук (бегал с флешкой бл...) то опять помолился и поблагодарил бога моего Линуса за чудо сотворенное.
Не нужно лазить по веткам. Всё современные IDE дают возможность в пару кликов увидеть историю изменений конкретного файла в удобном виде.
Спасибо, услышал, учёл, закомментировал очередной кусок
Это если через 10 лет не поменяют систему контроля версий или репозиторий криво смигрируют) да ещё и трекер не сменят на другой
Если история достаточно длинная - фиг вы там чего найдете, если не знаете, что именно ищете. А закомментированное - вот оно.
Ну, код целиком, конечно, не очень правильно оставлять, но у меня был случай, когда от меня с интервалом в два-три года два раза требовали поменять поведение, которым я и не управлял) Первый раз я достаточно быстро нашёл флажок в ui, код, который из нескольких флажков выбирал режим работы и через несколько компонент спускал ко мне. В комменте к и вправду странному коду был указан номер тикета и фамилия коллеги, который это написал. Почитал тикет, посмотрели его с этим коллегой и отписались, что это поведение решение маркетинга. А вот через несколько лет, хотя смутно помнил, что что то такое исследовал уже, этот код искал дольше, нашёл тот коммент - трекер сменили, старый архив закрыли, коллега уволился, перфорс сменили гитом, маркетинг и саппорт весь поменялся, если бы не архив почты, где этот тикет мелькал раз в 3 года, пришлось бы ещё месяц со всеми переписываться. Не, можно конечно было поправить эти флажки чтобы клиент стал счастливым, только тогда прилетела бы сотня запросов от других клиентов почемв стало по другому..
Поэтому я за комменты в странных или критических местах
Здорово! Одна просьба — делитесь, пожалуйста, информацией об этих ведущих практиках с потенциальными нанимающимися. Лично мне такое спрашивать в голову обычно не приходит, не дорос ещё до таких техник, поэтому на месте интервьюируемого я бы хотел о таком слышать без всяких наводящих вопросов с моей стороны.
Зачем?
Зачем мне удовлетворять ваши желания, заботиться о приходящих и не приходящих вам мыслях?
Зачем мне называть мой подход, ведущими практиками?
Зачем мне удовлетворять ваши желания, заботиться о приходящих и не приходящих вам мыслях?
Чтобы сэкономить время и силы и себе в том числе. А то так наймёте человека, который слишком отстал для таких практик, не сработаетесь с ним, он уйдёт, и вы потеряли время на найм и онбоардинг. Надо ли оно вам?
А вообще показательный вопрос, конечно.
Зачем мне называть мой подход, ведущими практиками?
Ну а какие они? Не ведомые же.
Так вы оказывается о мне заботитесь ))
Вам моего времени жалко... Не утруждайте себя, подумайте о хорошем, о мне не нужно.
Я лично не называл то что я делаю ни ведущими практиками, ни best practice, ни как. И защищать их не собираюсь. Доказывать ничего не собираюсь, зачем?
Нравится навешивать ярлыки, навешивайте, мне это не интересно.
На самом деле я забочусь о других людях, потому что не всем придёт в голову спрашивать «а используете ли вы комментарии для версионирования кода?», а такая практика — это трэш и угар. Особенно с мотивацией «не умею/не привык» — это тоже интересный сигнал о вашей команде, который будет полезен потенциальным нанимающимся.
Твори, программист. Ты один из представителей последних творческих профессий, последняя цитадель.
Абсолютно вредная статья и советы. Насмотревшись на поделия этих "творцов" предыдущий автор и написал свой пост.
Я не исключаю даже того, что он на мой код смотрел. Как то на заре я писал фин контур, где делал гуи аналитики по кубам. Только после универа, запилил ядро в виде расчёта матрицы и векторов итогов. Там были рекурсии последовательные по н-мерному пространству. Перебор? Абсолютно! Я сам с трудом понимал как это в итоге работает. За гранью. Но тесты не заваливало. Пять лет без правок на проде. При том что на контур навешали весь фин учет в итоге. Приятным бонусом защищённый диплом по этому проекту.
Если Вам, уважаемый Последователь, не вытянуть этого уровня, если вам не интересно, если вам чисто сейчас бабок срубить, может и не надо? Оставьте тем, кто хочет и в итоге сможет.
Вам просто сейчас даже гайку на машине не завинтят. Количество оборотов, усилие, смазка цвета, контракта и прочая последовательность. Бампер просто не покрасят. Ибо выгорел, выцвел, зернистость, лак и т.д. и это линейные технологические операции.
Вам просто сейчас даже гайку на машине не завинтят. Количество оборотов, усилие, смазка цвета, контракта и прочая последовательность.
"Я уже и унитаз приносил, и жопу показывал - все равно мне туалетную бумагу не продали".
Только после универа, запилил ядро в виде расчёта матрицы и векторов итогов. Там были рекурсии последовательные по н-мерному пространству. Перебор? Абсолютно! Я сам с трудом понимал как это в итоге работает. За гранью. Но тесты не заваливало. Пять лет без правок на проде.
Хм.
Я сам с трудом понимал как это в итоге работает.
Пять лет без правок на проде.
Возможно, тут есть какая-то связь…
У меня на одной прошлой работе был такой проект: разобраться, что именно делает одно расчётное ядро (по поиску аномалий во временных рядах), которое было написано как раз товарищем только после универа. Рекурсий по пространствам там не было, но там был .cpp-файл на пару тыщ строк, где все функции обменивались данными друг с другом через одну глобальную std::map<std::string, std::string> (да, вы угадали, вычисленные в одной функции float-коэффициенты передавались в другую функцию через конвертацию в строку и обратно), и средняя функция выглядела как пара десятков строк вида
void updateStep14() {
double k = utils::toDouble(coeffs["k4"]);
ensureActual14();
int m = utils::toDouble(coeffs["mPrev"]);
fixupKs();
double mm = m * 62.4 + k * k;
coeffs["mNew"] = utils::toString(mm);
}(хотя наличие названия updateStep14 — это ещё хороший случай).
Перебор? Абсолютно!
Понимал ли я с трудом, как это работает? С трудом. Календарный год пытался понять.
Тесты не заваливало, да. Их просто не было.
На проде без правок было не пять лет, а все десять, просто потому, что это никто не хотел трогать. Даже несмотря на то, что оно тормозило как не в себя.
То есть за 10 лет по факту притензия у вас к 2000 строчному коду только в скорости, правильно? В остальном его плюсы перевешивали минусы настолько, что просто из первоначального ТЗ никто эти 2000 строк не переписал с нуля? 10 лет?
Объясню почему спрашиваю. Мы как то купили одну закрытую систему дережных расчетов. А потом спустя год оказалось, что вносить в нее правки мы не можем, а тот кто может требует нереальных денег за это. Ну кидалово, но юристы у нас были не про ИТ нюансы в момент заключения. И мы в моем лице занялись реверс-инженерингом линейных матричных преобразований, потому что нельзя было изменять расчеты ни на копейку, нам нужен был точный аналог, что бы избежать тяжб с контрагентами. И прогоняя через ситему датасеты смотрел на результат и придумывал эту формулу с порядком применения округлений, типом округлений, типами данных операторов и прочей этой мутотенью. Таки и получилось же.
rem К слову если хотите обфусцировать закрытый код таким образом от реверса - поменяйте тип округления для каких нибудь цифр кратных пи. Это все очень сильно усложнит.
То есть за 10 лет по факту притензия у вас к 2000 строчному коду только в скорости, правильно?
Нет. Его ещё хотели расширить на другие виды входных данных, и проверить, что его предположения всё ещё выполняются спустя 10 лет, но это невозможно, потому что непонятно, что он делает.
В остальном его плюсы перевешивали минусы настолько, что просто из первоначального ТЗ никто эти 2000 строк не переписал с нуля?
Первоначальное ТЗ звучало как «сделать систему определения аномалий во временных рядах». Переписать это с нуля — это с нуля провести исследования о том, что и как работает в данном контексте.
Но в итоге ровно это я и сделал, да. Этот код в итоге был выкинут и даже не переписан.
Нет. Его ещё хотели расширить на другие виды входных данных, и проверить, что его предположения всё ещё выполняются спустя 10 лет, но это невозможно, потому что непонятно, что он делает.
Отмечу, что у нанимателей нет никаких методов на Костю Сапрыкина, чтобы он пейсал ремонтопригодный код. Всё держится исключительно на внеэкономических мотивациях вроде «стыдно перед коллегами».
Ну вообще-то можно депремировать и вообще увольнять.
У нанимателей-непрограммистов нет никаких методов понять, что команда пишет ремонтопригодный код, это да, но это другой вопрос (и стыдом и мотивациями он тоже не чинится).
У нанимателей-непрограммистов нет никаких методов понять, что команда пишет ремонтопригодный код, это да, но это другой вопрос (и стыдом и мотивациями он тоже не чинится).
Более того, у нанимателей нет даже понимания, что есть ремонтопригодный, а есть неремонтопригодный код. И какой конкретно им нужен — они тоже не знают.
Да и среди программистов дофига любителей «переписать с Кобола на Яву», хотя кто там знает, какой из этих ЯВУ лучше подходит для предметной области?
В общем, всё мёртво.
Да и среди программистов дофига любителей «переписать с Кобола на Яву», хотя кто там знает, какой из этих ЯВУ лучше подходит для предметной области?
Красивая шутка :)
Ну реально для финансовой бизнес-логики нужны ADT/GADT, классы типов (хотя бы Num/Show), сборщик мусора, сильная типизация (чтобы не терять точность на случайном переводе из целых в вещественные), генерики Хаскеля (для разнообразной сериализации), энергичность (ленивость требует большей квалификации).
В общем, получается практически Хаскель с расширением Strict. Что Кобол, что Ява бесконечно далеки от всего этого.
На самом деле сборщик мусора нужен при активной работе с динамической памятью. Тот же Кобол работает исключительно со статикой - там сборщик мусора напрочь не уперся.
Это даже не говоря о том, что все это работает на "больших машинах", где принципы совершенно иные. Любая программа работает в рамках своего задания (job). Которое как контейнер - завершалось задание - освободились все выделенные в нем ресурсы. Вообще все. Все файлы закроются, вся память освободится.
А вот что реально нужно для бизнеса, так это нативная поддержка типов с фиксированной точкой, даты, времени и всего остального, что есть в БД. И вся арифметика с этим связанная. Чтобы не надо было после чтения записи из БД дополнительно тратить время и память на создание объектов с которыми можно работать. Просто объявляет структуру "такую же как формат записи" (одной строкой), читаете туда запись (просто с диска в структуру-буфер) и потом напрямую работаете с ее полями.
Все это работает в hi-load системах где лишнее создание объектов (и даже просто лишняя работа с динамической памятью) - непозволительная роскошь в рантайме.
Это даже не говоря о том, что все это работает на "больших машинах", где принципы совершенно иные.
«Большие машины» — это редкость и экзотика. Hi-load и типичные финансы? Hi-load — это торговля на бирже, хеджфонды. В остальном, достаточно, чтобы параллелилось и квадратов O(N^2) было по-меньше.
Дата/время/десятичные вычисления делаются на классах типах непринуждённо. И сериализация на generic'ах. Динамическая память давно уже не является непозволительной роскошью, поэтому и не стоит себя ограничивать.
Нет, то, что вы пишете — это да, нужно. Но это нужно как Руст — в каких-то уголках мироздания, а не для рядового перекладывателя JSON'ов и расчётчика зарплат/выплат по купонам.
«Большие машины» — это редкость и экзотика. Hi-load и типичные финансы? Hi-load — это торговля на бирже, хеджфонды. В остальном, достаточно, чтобы параллелилось и квадратов O(N^2) было по-меньше.
Что для вас "типичные финансы"? Банк с 50млн клиентов, 100млн банковских операций (в штатном режиме, в периоды пиковых нагрузок кратно больше) в сутки (а это не просто вычесть с одного счета и прибавить к другому, там куча всяких проверок в рамках контроля платежей). И плюсом к тому еще куева хуча различных процессов, которые на сервере крутятся. Там работа с десятками миллионов записей - обычно дело (у меня была задача, где нужно было искать совпадения по заданному алгоритму между двумя наборами - 96млн элементов в одном и 8тыс элементов в другом - посчитайте количество комбинаций).
Дата/время/десятичные вычисления делаются на классах типах непринуждённо
Когда все это повторяется 20-30 миллионов раз и смотришь статистики какого-нибудь Performance EXplorer'а, то видно что просто на обертку сырых данных в объект уходит процентов 10-15% времени и ресурсов процессора. Фактически - в никуда.
А на подготовку динамического SQL запроса (а других та же Java не умеет) в рантайме запросто может уходить до 30% времени. Опять же, в пустоту. Ни на что. Те же COBOL или RPG умеют статический SQL с планом запроса в compile time, а там, где нужно поработать по одной таблице по индексу - вообще без SQL. В результате экономим и время и ресурсы процессора.
Динамическая память давно уже не является непозволительной роскошью, поэтому и не стоит себя ограничивать.
Ровно до тех пор, пока счет не идет на сотни миллионов операций и ваша поставка не попадает на нагрузочное тестирование.
Да, есть много попыток сократить накладные расходы на динамику (всякие QuickPool и стратегии расширения памяти в динамических массивах, но все это не от хорошей жизни).
Да, есть ситуации, когда динамика неизбежна. Но всегда есть баланс - где можно обойтись статикой, а где без динамики никак.
Тем более, что на тех же "больших машинах" оперативка измеряется терабайтами + одноуровневая модель памяти.
И куда проще, когда ваш язык поддерживает всякие decimal/numeric/date/time типы из коробки. И никакие дополнительные объекты вам не нужны чтобы прочитать запись с диска, прибавить к полю с датой, скажем, три дня и записать ее обратно на диск. И никаких внешних зависимостей. Все внутри языка (скажу больше, оно даже внутри самой ОС поскольку сама ОС разрабатывалась для решения этих задач)
Нет, то, что вы пишете — это да, нужно. Но это нужно как Руст — в каких-то уголках мироздания
С этими "уголками мироздания" вы сталкиваетесь много раз на дню. Например, когда расплачивается в магазине чем-то, кроме налички. Или когда эту наличку в банкомате снимаете.
а не для рядового перекладывателя JSON'ов и расчётчика зарплат/выплат по купонам.
Вот это верно. Но вот если кого и можно заменить ИИ, так это вот этих "рядовых перекладывателей JSON'ов"
100млн банковских операций (в штатном режиме, в периоды пиковых нагрузок кратно больше) в сутки (а это не просто вычесть с одного счета и прибавить к другому, там куча всяких проверок в рамках контроля платежей)
Хм.
Если считать, что все они происходят за восьмичасовой банковский день (а не размазаны по 24 часам), то это средняя нагрузка в примерно 3500 операций в секунду, или 300 микросекунд на операцию на одно ядро. Это очень много времени. Это дофига времени. Это халява, я бы даже сказал. Это можно выделять и освобождать память, совершенно об этом не думая. Можно использовать стандартный std::nordered_map и std::ector.
Более того, даже если вы некоторые из этих транзакций будете обрабатывать не 300 микросекунд, а 3 миллисекунды, или даже три секунды (ну будет у одного чувака из тысячи в магазине спиннер четыре секунды вместо одной крутиться после прикладывания карточки, тоже мне), вы ничего не потеряете. Если вы шардируете это на разные подмножества аккаунтов, раскидаете их по разным ядрам 16-ядерной машины с околонулевым контеншном, увеличив бюджет с 300 микросекунд до 5 миллисекунд (соответствующим образом увеличив вариабельность), то вы снова ничего не потеряете.
В HFT всё это — гроб гроб кладбище потери денег. И да, в HFT это тоже не только вычесть-прибавить, это тоже и проверки, и разные модели, и поиск сигналов во входящих сообщениях (сотни миллиардов в течение восьми банковских часов на какой-нибудь NYSE), и прочее счастье, где цена лишней сотни наносекунд — разница между прибылью и убытками вас как компании.
(у меня была задача, где нужно было искать совпадения по заданному алгоритму между двумя наборами - 96млн элементов в одном и 8тыс элементов в другом - посчитайте количество комбинаций
Да, я помню, вы очень гордились, что в RPG, что ли, там всё считывается прямо в байты в памяти, ничего не копируется, и так далее. Правда, вы не учли, что если один из наборов данных отсортировать, то можно заменить O(n) на O(logn), что для n = 96×10⁶ даёт некоторое преимущество, которое ни одно copy elision не даст.
А на подготовку динамического SQL запроса (а других та же Java не умеет)
Казалось бы, причём java к тайпклассам и хаскелю.
Если считать, что все они происходят за восьмичасовой банковский день (а не размазаны по 24 часам), то это средняя нагрузка в примерно 3500 операций в секунду, или 300 микросекунд на операцию на одно ядро. Это очень много времени. Это дофига времени. Это халява, я бы даже сказал. Это можно выделять и освобождать память, совершенно об этом не думая.
Вот когда "не думая", оно достаточно быстро переходит в разряд "дефектов производительности".
Это же не единственный процесс на сервере, а всего лишь один из тысяч, если не десятков тысяч работающих одновременно. Большие машины тем и хороши, что они изначально проектировались для одновременного выполнения многих заданий. Как по железу, так и по софту.
Вот зашел клиент в мобильное приложение - на сервер сразу полетели запросы разные по сбору информации.
Заводят нового клиента - там сразу десяток проверок разных активируется.
Открыли счет - тоже проверки плюс в ФНС уведомление сформировать и отправить.
И много-много чего еще. И все одновременно.
Да, я помню, вы очень гордились, что в RPG, что ли, там всё считывается прямо в байты в памяти, ничего не копируется, и так далее. Правда, вы не учли, что если один из наборов данных отсортировать, то можно заменить O(n) на O(logn), что для n = 96×10⁶ даёт некоторое преимущество, которое ни одно copy elision не даст.
Все в кучу. Что не копируется - это один момент. Нет лишних операций по созданию чего-то с чем язык уже потом сможет работать. И все это опирается на то, что в самой ОС есть поддержка работы с этими типами данных на уровне MI (машинных инструкций). Например, для дат и времени Т.е. никаких дополнительных объектов не нужно чтобы вычислить, к примеру, разность между двумя датами. Нужны только адреса областей памяти где эти даты лежат.
Та задача - совершенно другой аспект. При чем там сортировка, если сравнение идет не по равенству строк, а по принципу "все уникальные элементы (слова) строки А должны входить в строку Б без учета количества повторений и порядка следования". И даже когда все сравниваемые строки уже заранее разбиты на элементы и все что можно проиндексировано (есть витрина эти строк), все равно решение с использованием SQL, распараллеленное на несколько потоков, работает 7-10 часов. А возможности прямого доступа к БД без SQL позволяют построить алгоритм, делающий тоже самое за 20-30 минут.
Ну и имеем ввиду, что строки эти постоянно меняются в процессе работы. Т.е. появляется еще один процесс, отслеживающий изменения и актуализирующий витрину (это называется "журнальный монитор" - их очень много на разные процессы).
Тут нельзя рассматривать каждый процесс в отдельность. Только все в совокупности. Как оно все вместе живет, как разные процессы друг с другом взаимодействуют. И всегда помнить что если ваш процесс начинает потреблять слишком много ресурсов, это может отрицательно сказаться на остальных. Поэтому и проводим всегда нагрузочное тестирование чтобы понять - а где можно снизить потребление ресурсов. А там сразу видно что вся эта чехарда с лишними объектами и динамической памятью может очень сильно грузить машину. И что всего этого можно легко избежать
Вот когда "не думая", оно достаточно быстро переходит в разряд "дефектов производительности".
Если совсем не думать, то это вообще в любой области так. Однако, ваш бюджет на недуманье сильно больше, чем в упомянутом изначально @vkni трейдинге.
Вот зашел клиент в мобильное приложение - на сервер сразу полетели запросы разные по сбору информации.
На тот же самый и на то же ядро, где обрабатываются транзакции? Интересная архитектура.
Заводят нового клиента - там сразу десяток проверок разных активируется.
Открыли счет - тоже проверки плюс в ФНС уведомление сформировать и отправить.
И много-много чего еще. И все одновременно.
Сколько клиентов и счетов в день открывается?
На тот же самый и на то же ядро, где обрабатываются транзакции? Интересная архитектура.
Тут, понятно, что молодые-креативные наворотили бы микросервисов, а потом страдали бы тем, что нужно постоянно заниматься синхронизацией БД (к торой десятка полтора тысяч таблиц) между микросервисами.
Поэтому да - вся БД лежит на ядре и все данные получаются оттуда. По всем запросам.
Там есть (насколько знаю) несколько более мелких машинок, которые работают только на чтение (и часть запросов отправляется туда, но это далеко не все. Только то, что что меняется относительно редко и не требует репликации в реальном времени (которая сама по себе достаточно большая проблема).
На самом деле система справляется. Именно за счет использования специальной, заточенной именно на эти задачи платформы.
Однако, ваш бюджет на недуманье сильно больше, чем в упомянутом изначально @vkni трейдинге.
Не стал бы так категорично.
Сколько клиентов и счетов в день открывается?
Мне трудно ответить. Надо статистику собирать. Не 1-2 десятка точно. Насколько знаю, сервис поиска совпадений клиентских данных со списками Росфина (а он вызывается как раз при заведении нового клиента в том числе) - один из самых нагруженных. И именно там долго возились с его оптимизацией - там тоже все не так просто т.к. поиск по совпадению с ФИО идет не на равенство строк, а с анализом словоформ - 6 падежей + 2 варианта транслитерации. Плюс разного рода заморочки когда проверяется одно ФИО + 2-3 ДУЛ (разные документы удостоверяющие личность). Короче, там все непросто получилось.
А есть еще проверки рисков (санкционные, страновые/региональные, репутационные), база недействительных паспортов, корректность ИНН и еще куча всего... Карточка клиента - это где-то 8 экранов разной инфы. И все надо проверять.
А там сразу видно что вся эта чехарда с лишними объектами и динамической памятью может очень сильно грузить машину.
Ну народ же давно перешёл на всякие кластеры и абсолютно параллелизуемые системы. И вы просто добавляете ещё говно-серверов, и у вас эти несчастные питоновские скрипты начинают работать быстрее. Нужно 10 тыс потоков — заказываете стойки в датацентре и получаете их. Деньги-то у банков бесконечные.
Да, всё делается из говна и палок, да, датацентр с этими несчастными серваками требует угольной электростанции, по-сути, но всем насрать. И пока инфраструктура не долбанётся, никаких оптимизаций не предвидится. А уж тем более этих дедовских методов работы без динамической памяти.
Ну народ же давно перешёл на всякие кластеры и абсолютно параллелизуемые системы. И вы просто добавляете ещё говно-серверов, и у вас эти несчастные питоновские скрипты начинают работать быстрее. Нужно 10 тыс потоков — заказываете стойки в датацентре и получаете их. Деньги-то у банков бесконечные.
Вы серьезно?
Какие дата-центры? Центральный сервер банка изолирован от внешнего мира. Общение с ним только через очереди или ESB шину. И доступ к нему имеет очень ограниченное количество людей. Там же и персональные данные и банковская тайна.
И никаких там питовских скриптов нет, не было и не будет.
Да, всё делается из говна и палок, да, датацентр с этими несчастными серваками требует угольной электростанции, по-сути, но всем насрать. И пока инфраструктура не долбанётся, никаких оптимизаций не предвидится.
Ну это, видимо, у сайторазработчиков так.
А уж тем более этих дедовских методов работы без динамической памяти.
Чем плоха статическая память (кроме того, что там нет проблем с фрагментацией, утечками и накладными расходами на выделение-освобождение) ? Это на десктопах проблема с памятью. На больших машинах этой проблемы нет. Одноуровневая память + 12Тб (у нас) физической оперативки. ОС выдает 4Гб памяти на каждое задание. 16Мб на один объект (сплошной кусок памяти). Каких-то проблем с памятью тут вообще нет.
Ну это, видимо, у сайторазработчиков так.
До недавнего времени невозможно было себе представить, что банк будет считать согласием на передачу биометрии факт захода в банкомат. И многое другое.
Так что, не обольщайтесь, скоро везде будут принципы работы как в создателей говносайтов.
Люди которые помнили о том, что "банк это банк, а не говно сайт", умрут естественным путём и их заменят вот эти вот.
Центральный сервер банка изолирован от внешнего мира. Общение с ним только через очереди или ESB шину.
Почему он один? Почему это не кластер?
Ну это, видимо, у сайторазработчиков так.
А-то.
Чем плоха статическая память
Отсекает огромное количество алгоритмов. Требует высокой квалификации программистов.
У нанимателей-непрограммистов нет никаких методов понять, что команда пишет ремонтопригодный код
Чисто теоретически — нанять для аудита нескольких сторонних экспертов из числа весомых контрибьютеров известных долгоживущих опенсорс‑проектов.
Проблема в том, что, как правило, они не могут этого осознать.
Причём осознать не на уровне отдельного человека, а на уровне орг. стуктуры. То есть, каждый может и понимает, и даже ритуальные фразы говорит, но вот это «беги быстрей», закон Паркинсона и т.д. не оставляют ни малейших шансов самой структуре делать простой, а значит ремонтопригодный и эффективный софт.
Я достаточно давно ковыряю разный опенсорс, чтобы улыбнуться над этим предложением, и достаточно недавно ковырял, в частности, исходники okular (было интересно, как они там кое-что сделали) с одним файлом на несколько kLOC и смешением всех возможных уровней логики, чтобы улыбка стала ещё шире.
Я пыталась отвязаться от субъективного видения «хорошего/ремонтопригодного кода» каждым разработчиком и предположить, что долгий срок жизни поддерживаемого проекта — достаточный критерий для обозначения его кода в какой‑то степени ремонтопригодным. Неремонтопригодные проекты, как вы сами говорили, выкидывают и пишут новые.
Но... Я не учла, что за долгое время жизни проекта его код может почти полностью переписываться не один раз, так что критерий долгожительства, к сожалению, действительно придется отмести.
Однако остается фактор открытости кода, который дисциплинирует желанием «не ударить в грязь лицом перед всем миром».
Неремонтопригодные проекты, как вы сами говорили, выкидывают и пишут новые.
К сожалению или к счастью, не всегда. Иногда процесс можно заливать деньгами.
Однако остается фактор открытости кода, который дисциплинирует желанием «не ударить в грязь лицом перед всем миром».
Или «просто код писать люблю, почему не выложить бы на гитхаб». Или «это экспериментальные всякие проекты». Или «мейнтейню потому, что сам пользуюсь, а на ударяние в грязь лицом мне плевать».
Тем более, что личная практика показывает, что у разных людей разные представления об ударении в грязь. Кому-то это действительно качество кода, но кому-то — решение конкретно его проблемы, или демонстрация возможностей и навыков, или мало ли что ещё.
К сожалению или к счастью, не всегда. Иногда процесс можно заливать деньгами.
Да практически всегда. Или монопольным положением, что, в общем, то же самое, просто напрямую.
Или «просто код писать люблю, почему не выложить бы на гитхаб».
Эта лазейка скоро прикроется LLMками, генерящими непонятную херню с компиляторной производительностью, только на ЯВУ.
Кмк, в GUI идут довольно специфические люди. Со своим видением прекрасного.
Да ладно, иногда прикольно чё-т такое поковырять — я иногда и кое-что гуёвое попиливаю, и даже ради отвлечения с CSS на своём блоге играюсь. Ты так тогда хотя бы видишь результаты своего труда, а не просто какое-то абстрактное «Foo.agda: typechecked successfully», или чуть менее абстрактное, но всё равно далёкое «код стал на 300 нс быстрее».
Ты так тогда хотя бы видишь результаты своего труда
У тебя для этого есть газон!!! :-) Я тут, кстати, распылитель дополнительный поставил, вот увижу результаты труда через несколько месяцев.
Но если без шуток, то да, конечно! На ICFP всегда разные демонстрации роботов и практических применений — это аншлаг и вызов автора на бис. :-) :-) :-)
поменяйте тип округления для каких нибудь цифр кратных пи.
э . у вас там pi-based система счисления, основанная на углах? или откуда ещё такое возьмётся?
или для простых чисел или фибоначи или еще по какой формуле получаемой. Понять систему станет на порядок сложнее, если вообще возможно. Ясно что дело в копейках, но тогда копейки имели значение что время на эту работу выделили. А так имея матрицу коэффициентов, входные и выходные данные подобрать мат функции было относительно не сложным занятием, больше возни доставило получение нужного кодового представления этих функций, нужные округления и подбор типов переменных.
Понять систему станет на порядок сложнее,
Хм. у вас там денежными расчетами занимается черный ящик с секретной логикой внутри, штоле?
Это не самый удивительный виданный мною факап.
Ну, зачем-то кто-то это задумал же.
может откаты при закупках именно этого ПО. Может именно этот модуль шел в довесок комплексной системе автоматизации и порешали, что потом как нибудь разрулим. Я полагаю некоторый цветочно-букетный период их проги писали изменения в код, но он был закрыт, а потом посчитали что клиент подсажен надежно и выкатили настоящий прайс. Как примерно должно было быть они знали. А как конкретно - в той программе. "а всей правды мы не узнаем" (с)
rem К слову если хотите обфусцировать закрытый код таким образом от реверса - поменяйте тип округления для каких нибудь цифр кратных пи. Это все очень сильно усложнит.
Говорят, самый правильный способ — это сделать собственный DSL + встроить в систему интерпретатор этого DSL...
Как электрик в прошлом подписываюсь под каждым словом!
Господин, написавший про красные флаги перфекционизма, прошу продублировать Ваша коммент, по ошибке нажал на отклонить
Если что отвечаю на отклоненный пост про перфекционизм. Благодарен за мнение, оно в точку.
Мы в конечном итоге ограничены внешними рамками, когда нас заставят выкатить релиз. Закончатся деньги на кабель, смежники подожмут по времени, легранд раскупят конкуренты и тд. Скорее всего мы выкатим его не сбалансированный. Перегруженным абстракциями и перепроверками, но недогруженным функционалом.
“I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may.“.
И тут уже ж не ясно, кто из нас настоящий, искренний перфекционист, просто не отдающий себе отчёта об этом.
MVP не панацея. AGILE тоже. Столпы методологий не смогли. Программист не сможет по определению. Пусть ошибается.
Работа - это не место для экспериментов. Если там такое проходит - пусть. Но лучше пусть такого не будет. Место для своих фантазий, романтики и тд скорее подходит для своих личных дел или какого-то научного кружка.
Технологичные проекты действительно требуют нестандартных решений. Но даже нестандартные решения будут написаны стандартными методами. ОС так и пишут на С, хотя прошло уже сколько лет? А там принципы сильно не изменились за все это время.
Если работа доставляет удовольствие и хочется "творить" - это замечательно, но и про риски забывать не надо. Можно начать писать проект на своем языке, но скорее всего долго он не проживет. А от этого решения будет зависеть зарплата других сотрудников и частично их будущее (особенно если много людей семейных и с детьми). Не только конечные пользователи.
Само по себе программирование - это вероятно и творческое занятие. Но коммерческая разработка затрагивает человеческие жизни. Возможно, человек, которые написал программное обеспечение для упавшего боинга, тоже любил эксперименты. И вместо того чтобы сосредоточится на решении конкретной задачи и считывания показателей с двух приборов, забил голову красивыми мыслями и просто забыл о парных компонентах системы.
я не специалист внутренних расследований боинга, поэтому набрасывать не буду, но встречную конспирологию выкачу:
А у боинга разве не должно быть отдела тестирования, отк, приемки, внутренней дисциплины, сертификации? Эти то отделы чем занимались? Насколько я с желтых статей помню некоторые из них занимались как раз работой прямо противоположной их требованиям, а некоторые ничем. Но, вероятно у них семьи, кредиты, дети, мы их должны понять.
А виноватым сделаем программиста. Возможно того единственного чувака, который какую то работу в итоге и сделал. Он же работал? Он. А это непростительная ошибка в такого рода токсичных командах.
Я согласен с тем, что такая крупная компания не могла допустить такое по-умолчанию. И проблема оказалось на всех уровнях. Но первый, кто отвечает за написаный код, тот кто написал его.
Если человек написал приложение, он должен сам его и проверить, как конечный пользователь, и потом уж отдать для команды тестирования для выявления нестандартного поведения. Но код должен до них добраться уже рабочий. Более того, только человек, который написал приложение, знает все тонкости его работы и обязан уведомить о возможных критических нюансах команду тестирования.
Семьи и кредиты не оправдывают смерть почти четырех сотен людей.
В любом случае, я хотел показать пример, где работа - это не место для мечтаний. Один из предыдущих топовых менеджеров сравнивал производство ПО с производством автомобилей на заводе. И лично я с ним полностью согласен. Почему машины можно выпускать по чертежах, а ПО строится как попало? Каждый лепит, что ему захочется. Если следовать таким путем, тогда в автосалонах были бы одни буханки где-то подбитые молотком, а где-то брусочком подпирающие каркас машины. И каждый раз выглядели бы по-разному. Единственное, чтобы их обьединяло - возможность ездить.
От части слишком низкий порог входа. Каждый может начать писать код на каком-то питоне просто почитав описание на википедии или посмотрев пару каких-то туториалов. Ваш пример с кабелями очень хороший. Для работы же в медицинских учреждениях нужно сначала много лег учить теории, чтобы потом можно было хотя бы уточки менять лежачим.
С другой стороны - отсутствующий менеджмент. Каждый может создать свой проект и вести его так, как они считает нужным. Все любят пощеголять друг перед другом, потому нанимают хороших для этого специалистов не все.
И как следствие - отсутствие четких регламентов. Может это и слишком старомодно, но дисциплина какая-то должна быть в команде. Тогда и команда работает сплоченней. Профессиональность команды часто можно увидеть, когда наступает критическая ситуация и решать вопрос надо уже прямо сейчас. Пример тому - службы быстрого реагирования, которые годами оттачивают свои навыки. Ну или если далеко не ходить - футбол, баскетбол или другой командный вид спорта.
Я это все к тому, что ваш посыл о творении - он очень хороший и правильный, но к сожалению, это не про работу. Я лично это вижу как научное исследование, где нету никаких ограничений, лимитов по времени, рисков и тд. Но многие обычно недооценивают серьезности происходящего или того, что они делают. А в реальных продуктах это всегда касается в той или иной степени жизни других людей. Если не ваших коллег, тогда конечного потребителя.
После кабельной практики я вернулся ближе к отделу разработки на галере и меня за вьедливость определили в пожарную команду последнего шанса, когда ничего больше не помогало. Дебаг и замеры моё второе хобби и вот что я скажу вам, господа говнокодеры самозванцы ненавижу вас: никогда, никогда даже самый гиблый ваш код от которого компьютер вонял фекалиями еще до включения не был причиной прям серьёзных факапов. В подавляющем количестве случаев причина была в бизнесе и даже методиках управления и исправление не покупалось за деньги. Сколько стоит уволить некомпетентного родственника из управления? Сколько сказать гендиру что он не гениальный, а самый обычный мудак? Будем жестки, но справедливы. Никто так себя не сношает за качество, как вы сами. Даже если там его нет. Не исправил бы прог боинга его, боинга, проблем.
Согласен. Можно даже с квадратными колесами на велосипеде ехать не туда, куда надо. Но с круглыми колесами явно по-приятней и безопасней. Социальные сети так устроены, что мы видим только истории успехов, а провалы и падения - нет. Сколько людей начинающие свое дело не дошли до заветной мечты ? У скольких не хватило терпения?
Я расцениваю положение дел с двух сторон: и со стороны исполнителя, и со стороны клиента. Если рассматривать со стороны клиента - мне тут повезло наверное больше чем многим, потому что я могу дать качественную оценку работы. Но многие не могут.
Исполнители моих задач никогда не будут фантазировать в своих решениях, потому что это пустая трата моих денег. С каждой свистоперделкой я буду тратить бюджет непонятно на что и откладывать свои цели в длинный ящик просто потому, что кому-то стало немного скучно или он слишком творческая личность. Это не университет и не исследовательский центр. Мой приоритет - скорость развития проекта и стоимость поддержания.
Но не каждый может позволить себе дать эту качественную оценку. Многие начинают создавать свои проекты за последние деньги рискуя всем. Они платят ХОРОШИЕ деньги и надеятся найти тех, кто сможет ПРОСТО ХОРОШО СДЕЛАТЬ ТО, ЧТО ОНИ ПРОСЯТ. Но находят мечтателей, которые делают красивые кнопки и просто развлекаются как могут. Проходит год - проект не сделал. Прощание. Поиск нового. Приходит другой - говорит тут все говно, надо все переписывать, и говорит это убедительно, так как он меняет проекты каждый месяц и уже научился лапшу вешать, а человек, который деньги платит - раз в год. Через год тоже самое. Проект умирает. Результат - убитая мечта и куча потерянных денег.
Вы же сами писали, что работу нужно делать хорошо. Хорошо - значит подход изначально правильный. Вы же кабеля, которые прокладывали, не скручивали в лошадок или зайчиков, как надувные шарики? Правильно. Делали все строго по четко намеченому плану.
То что вы описали - это разбазаривание корпоративных ресурсов. Просто в средних и больших компаниях это мало заметно. Но это плохо в любом размере компании. Для маленьких компаний это может быть фатальной ошибкой закрывшей бизнес (свесят потом все как обычно на менеджеров, что не приняли нужных решений по развитию, хотя когда-то надо было фичу сделать за неделю - делали ее почему 2 месяца), а для больших - удар по репутации (будет кусок работать медленно, иметь уязвимость в коде публично освещенную потом в социальных сетях и тд).
А тут мы выходим уже за пределы именно стилистики кодинга и идем в куда как более сложные и интересные мне дебри морали.
У вас был договор, составленный на берегу? Вероятно был.
Вы свою часть договора перед прогом выполнили сполна, оплаты, документацию, технику? Допустим что да.
Он внедряя "свистоперделки" сорвал свою часть? Если да, то это уже не вопрос стилистики, а вопрос морали и я не встану на сторону этого исполнителя, даже если этот исполнитель был я. Если нет, то договор выполнен, вопрос на пять лет считаем решенным. А через пять вы то сами думали на яхте по фиджи рассекать, а не всем этим вот заниматься, правда?
Такой подход Вас устраивает?
От куда человек не знающий технических деталей сможет понять куда приведет его этот технический специалист через год, два, три или пять? Он может только надеятся на то, что его не обманули и человек действительно знает, что он делает. Часто дело в потраченном времени, которое уже не вернуть. Конкуренты не дремлят, и пока кто-то играется, другие забивают рынки.
То что бизнес принимает неправильные решения - это его право. Такое же право есть у покупателя на возможность разбить свою машину из салона. Но машину он свою должен получить такую, как написано в техническом описании.
Человек заказавший разработку ПО, как покупатель в магазине. Он дал деньги - получил продукт. Хороший технический специалист должен обьяснить все подводные камни замысла клиента, предложить несколько вариантов решения его задачи и выбрать с ним наиболее подходящий. Когда машину покупают, вам расскажут о ней все что можно и обьяснять почему одна лучше другой. Здесь также должно быть.
Я имею небольшое производство и постоянно отвечаю за качество предоставляемого товара. Я не могу выпустить сегодня товар по одному рецепту, а завтра по другому. Есть четкие технические карты, по которых работают сотрудники и никто не имеет права от них отклонятся. Да, это скучно в какой-то степени, делать каждый раз одно и то же. Но также это является определенным показателем профессионализма. Будет странно покупать в магазине один и тот же товар, каждый раз с разным вкусом или визуальным оформлением. Со временем технология производства стает более простой за счет нового оборудования и практик. Но это не приходит с бухты барахты - это отдельный процесс, требующий внимания и понимания всей команды.
Вы пытаетесь оправдать такое себе "экспериментальное программирование" тем, что если через 5 лет таких экспериментов проект не закрылся - все хорошо. Но это значит только то, что бизнес сумел пережить трудности, которые вы ему доставили. Например, урезанием бюджета на тот же маркетинг, дополнительным ограничением функциональности ПО из-за нехватки времени и тд.
Я не оправдываю любое поведение вашего "босса". Я лишь говорю о том, что каждый должен делать свою работу четко с планом без лишних издержек.
Когда машину покупают, вам расскажут о ней все что можно и обьяснять почему одна лучше другой
все, к сожалению, очень не так. Даже с пресловутой тойотой.
Будет странно покупать в магазине один и тот же товар, каждый раз с разным вкусом или визуальным оформлением.
Тут можете быть спокойны, если что то подобное уже написали, Вам впарят абсолютно точную побитовую копию за те же деньги. Вопрос в том коде, что еще не написан.
С ТЗ тоже все не просто. Заказчик на разбирательстве включает в ТЗ такое ненаписанное понятие как "общепринятые практики", "соответствие государственным стандартам" по умолчанию и прочее, что Ваш продукт должен был содержать, потому что суть его бизнеса подразумевает автоматизацию обмено с банковской системой, гос органами и биржами.
Но это значит только то, что бизнес сумел пережить трудности, которые вы ему доставили.
Это вот прям очень далеко от наших российских реалий. Прям как будто про другой край земли. Наш бизнес очень и очень многое умеет пережить, поверьте. Потеря всей кодовой базы и вообще всей базы подозреваю там даже не во второй сотне. Сдек как пример.
Говорю же, никто среднестатистическому программисту так не сношает мозг за качество как сам программист и его ближайший коллега. Они думают что они и их работа имеет некоторую значимость. Мне самому очень приятно так ошибаться и я этим с удовольствием и занимаюсь.
Почему машины можно выпускать по чертежах, а ПО строится как попало?
Потому что молодым-креативным "по чертежам" скучно и не интересно. Это "кровавый энтерпрайз" - дом престарелых от IT. Где любая хотелка от бизнеса должна быть представлена в виде BRD которое должно быть согласовано, на основе него должно быть принято архитектурное решение, потом составлено FSD и только потом разработка. А потом еще многоуровневое тестирование - компоненты, бизнес, интеграция, нагрузка, техтест... Которое по времени занимает в разы больше самой разработки. И где железное правило - любое изменение кода (хоть одна строка) влечет за собой полный цикл ретестов.
И там точно нет места "а вот мне походу дела классная фича в голову пришла - ща запилю, посмотрим что получится..."
Ну люди, незаинтересованные в синице в руке уйдут с этих проектов в стартапы за стильным модным современным журавлем. А из стартапов те, кому нужна предсказуемость придут сюда и все станет хорошо.
Но.
Если Вы в проект включили xml - будьте добры работать по практикам и инструментарию xml, будьте добры это выучить чуть больше, чем скопировав код со стековерфлоу и w3s. Избыточность - возможно, но таковы стандарты, они неспроста так.
Если Вы выставляете апи для интеграций хотя бы прочитайте об уровнях зрелости реста. Не надо как проще. Вы из профессии сделаете эй мальчик принеси подай.
От части слишком низкий порог входа. Каждый может начать писать код на каком-то питоне просто почитав описание на википедии или посмотрев пару каких-то туториалов.
Если бы все было так просто, но все таки солидарен с вами, когда уже начал писать на нем(обучился) было чувство недопонимания, чувствовал себя эдаким читером незнайкой пока не познакомился с книжкой Лутца (или Лутз) встретил видос Codonaft а про CS...закончилось все тем что я даже школьную математику не знал и понеслась...
— Почему так долго?
— Да вот, снова перерабатываю архитектуру, чтобы пришедшим после меня было легче сопровождать мой код.
...
Код надо писать так, чтобы именно тебе, любимому, было удобно писать и сопровождать, а уж если тебе пооцесс написания нравится - вообще супер.
А что там подумает тот лошара, которому поридется сопровождать твой код после тебя - глубоко начхать. Если кто-то считает иначе - да пожалуйста, трахайтесь на здоровье.
А что там подумает тот лошара, которому поридется сопровождать твой код после тебя - глубоко начхать
А что если ты пишешь не свой уютный говнокодик в гордом одиночестве, а работаешь над чем-то серьезным, да еще и в большой команде? Может статься, что при таком подходе "лошары" начнут думать всякое и про твой код, и про тебя лично много чего интересного так быстро, что "после тебя" там наступит сильно раньше чем тебе хотелось бы.
Я не видел ни одного проекта, как то видимо затормозившегося из-за оверкодинга одного разраба. Ну клинику давайте не брать. Как редкость видел проект упавший под тяжестью собственной переусложненности всей командой от постановщиков, методистов, кодеров. Но это немного другое, верно? Те задержки на спринт-другой которые тимлиду ровно жить мешают ну это не серьезно.
А вот проектов тормозящихся на пол года "бесшовного перехода" из за того, что в проде мвп-шка прокрутилась несколько лет я видел очень много. И задействованных людей в итоге в тестировании, переобучении там гораздо больше.
Когда один вместо бд использует простенький одностраничный xml, попробовать, вроде работает и далее файлы плодятся десятками, некоторые достигают размеров сотен страниц. Вся эта прелесть преподносится как среда разработки для низкоуровневых программеров приборов, которые должны эту технологию использовать, если заменили прошивку или не дай бог сделали новый девайс с сотней другой регистров. В конечном итоге все это длится несколько лет и автор этой хрени сваливает в другую контору, руководство задает тебе вопрос, а как сделать более человеческий интерфейс без этой ужасной возни с огромными xml файлами, ибо это очень неудобно, хоть и работает. А никак, отвечаешь. Надо переписывать с нуля, потому что там костылей немеряно. И проблема даже не в этом , а в том как перенести из файлов xml не потряв связность дерево объектов в БД. В файлах давно сам черт ногу сломит что наворотили, смешав в кучу регистры и указатели на кнопки комбобоксы интерфейса. Естественно разбираться с этим говнокодом не стали. Просто написали с нуля. Перенос файлов был сделан в SQL и это было непросто. Можно отдельную статью написать.
Ну да, если ты Rockstar и единственный разработчик на проекте, то все так. В остальных случаях надо смотреть. Идеи здравые, но... Видели мы и их последствия. Скажем так - очень часто они не подпадают под "тащи к себе лучшее, из увиденного".
Вы видели проекты, как то серьезно, значимо потерявшие при этом? Можете написать реальные примеры? Когда проложившийся склайтом для логов прог прям завалил траекторию проекта без встречных плюшек и прочее подобное?
Смотря что брать за критерии оценки. Я видел классные проекты, сделанные единственным реально высококлассным разработчиком. К сожалению, я гораздо чаще видел, мягко говоря, весьма посредственные проекты, сделанные тем, кто таковым себя считал. При этом ценность "встречных плюшек" обычно была не очевидна ни для кого, кроме самого автора.
И не надо меня спрашивать про реальные проекты. Я не имею привычки злопамятно хранить плохие решения и не занимаюсь и не занимался их сопровождением. В лучшем случае доработкой, но обычно переработкой. И, самое главное - помимо проекта надо доставать контекст. Это практически не возможно в рамках комментариев и ровно по тем же причинам отсутствует в вашей статье. Не брать же за реальные примеры описание всяческих конструкций, выполненных дендрофекальным методом на потребу дня.
Плюс всегда есть возможность сказать - ну это же точно делал не мастер. Я же не такой. Круче меня только яйца, и то если очень долго варить. Критичнее надо относиться. И в первую очередь к себе. В частности рекомендация не писать простой код (без крайней на то необходимости) - это явное наплевательское отношение к тем, кто по каким-то причинам будет этот код сопровождать. И, на самом деле, совершенно не важно с какой стороны пятилетки от сдачи кода это понадобится. Включая (но не ограничиваясь) наплевательское отношение к будущему себе. Впрочем, оговорюсь, есть моменты когда сложный код необходим.
А пользоваться реально хорошими решениями сторонних разработчиков - да безусловно. Но только в том случае, если персонально тебе кристально понятно как они работают и какие накладные расходы создают для твоего проекта. Иначе это будет не проект, а монстр-Франкенштейн (ну или лоскутное одеяло, если такая аналогия понятнее). Да, оно будет работать, но жгучего желания делать так же не вызовет. Что, в свою очередь, соответствующим образом охарактеризует автора.
Мешанина из простых решений бывает сложнее, чем очень сложная структура. Она не менее подвержена сбоям. Она так же с трудом анализируется еще на этапе первой линии поддержки, так же привыкшей к некоторым паттернам. Она так же как и сложный код является источником трудно-уловимых ошибок, когда на вход пойдет строка с непечатаемыми символами, которую валидаторы бы отловили сразу. То, что в моменте, на каком то одном таске простой код оказался эффективнее, не говорит о том что он будет эффективнее всегда. Автор первой статьи посидел одну ночь лишнюю, подумал сколько же можно, выкатил первый релиз статьи. Потом он посидит исправляя простой код и выкатит другую статью. Правды в стилистике кода он не найдет, ее там нет и никогда не было. И поэтому моя статья о другом.
Проблема сложных решений не в том, что они что-то там как-то ошибки/поддержка. Проблема в том, что это ресурсы, потраченные в никуда - т.к. все эти навороты "на будущее" потеряют актуальность уже через две недели, и код надо будет выкинуть и переписать. В лучшем случае выкинуть и переписать - в худшем, вместо того чтобы сделать все заново и правильно, будут из-за лени невкорячиваемое вкорячивать в уже написанные неактуальные абстракции с понятными последствиями.
С небольшой поправочкой, но все меняющей: проблема неудачных сложных решений. Автор же первой статьи не озаботился реальной статистикой, очищенной от ошибки выжившего? И я, к справедливости, такой статистикой тоже не озаботился, помогают ли или мешают сложные решения на больших числах проектов. Ну и плюс само понятие сложности субьективно конечно.
Я пологаю за мое время в профессии такой работы не проведут, а если и проведут ее результаты будут столь сложны, что почти бесполезны как и множество уже существующих упрощений методологии, рождающих другие необходимые методологии как снежный ком.
И лично мне важно, что будет в сухом остатке и что бы это не оказалось бегом в белечьем колесе.
С небольшой поправочкой, но все меняющей: проблема неудачных сложных решений.
Чтобы сложное решение было удачным, необходимо угадать будущее. Поскольку в 9 случаях из 10 оно не будет угадано, в этих же 9 случаях из 10 сложное решение будет неудачным.
Чтобы сложное решение было удачным, необходимо угадать будущее.
Это ложный тезис. Там должно быть слово оптимальное(наилучшее из возможных) вместо слово удачное.
Да и то, далеко не всегда будущее (поведение вашей, ну конечно же, "суперсложной" системы) не детерминировано.
А чаще под словом "удачное" (инженеры и обычные люди) подразумевают решение которое лучше большинства других (достаточных по формальным критериям).
P.S. Не компетентен оценивать прикладной программистский аспект спора, но местами кажется что это попытки доказательства/опровержения тезиса "разработка софта - это абсолютный неконтролируемый, и беспощадный:), хаос"
Математически только если эти две сущности не связаны. Но они то связаны.
Да и смотрите, со мной работает очень сильный программист, на разборе его кода я очень вырос. Я не буду его просить писать проще, зачем?
Пусть показывает класс, я подхвачу.
Быть сильным программистом не значит писать сложный код. Это две совершенно разные плоскости.
Мне доводилось видеть очень простой и очень изящный код сильных программистов. Сила которых не в том, что они могут навернуть 100500 уровней абстракций, а в том, что они для сложной, казалось бы, задачи находят простое, изящное и очень эффективное решение. Просто умея видеть ее под другим углом.
Встреченные мною на разнообразных стройках поделки с кабелями вызывали разнообразные чувства. От смеха до ужаса, от благоговения до испанского стыда.
Иногда еще это были "парадоксальные топологические загадки", и вопрос "зачем?" сменялся на вопрос "как ?". Ну связистов то-традиционно "кишкомотами" называют, но если с ними, по одной эстакаде или каналам, кладут свои "удалые-силовые" кабеля электрики - там такая "синергия" начинается.
Что лучше: 100 строк сложного кода или 1000 строк простого? Код сложный, потому что для его написания необходима высокая квалификация или потому что он запутанный с непрозрачной логикой? Лично я давно уже не мыслю такими категориями. Я стремлюсь к коду, который а) предельно компактный, б) с прозрачной логикой, в) не требует отдельного документирования, г) удобный для пере-использования, д) предельно надёжный.
Другой момент, что для получения предельно компактного кода нужно заранее озаботиться о том, как эту компактность обеспечить высокоуровневой абстракцией. Ну например, чтобы мочь писать
var ini = new Ini(); // имя .ini файла по умолчанию совпадает с именем сборки
string connstr = ini["database"]["connectionstring", "значение по умолчанию"];
int timeout = ini["database"]["timeout", 3000];
ini.ValueChanged += OnValueChanged; // не обязательно перезапускать программу, если что-то поменялось в .ini файлепотребовался отдельный класс на 2000 строк. Простой в понимании кода, но совсем не простой для написания - 10 итераций за 15 лет прошёл. Не каждый программист может позволить себе переписывать одно и то же по нескольку раз.
Красиво можно сделать по разному. Я как разраб которому приходится сидеть лишнюю ночь что бы что то закрыть готов посидеть над вариантом красивого кода/архитектуры. И у меня тоже дети, планы и т.д. Но я готов, мне нормально. И я украду в итоге Ваши паттерны для себя, если они мне понравятся.
Да, но: красота это категория искусства, а не математики. Я люблю искусство, красоту, музыку (и занимаюсь ею в том числе), у меня есть код, формулы и архитектуры, которые лично мне кажутся воплощением красоты, но: это следствие, а не причина или самоцель. А самоцели я перечислил выше, и к искусству они не имеют никакого отношения. Голимая математика.
Эээ брат, я как то с одним спортсменом на секунды заспорил о красоте, мол вот у тебя бег все ясно, кто первый тот победил, а гимнастика, там все мутно, что есть красота? На что он сказал - эффективные движения в основном красивые. Если некрасивые, значит мне есть куда расти. Значит скорее всего где то недорабатываю. Мол это генетическое судя по всему понятие, близкое к эффективности. И, если так, то и музыка и арт вам в плюсы. Математика тоже ж красота.
Хорошие правила. Есть еще одно - всегда оставайся мастером-любителем... Мастера профессионалы теряют нюх и страх и приобретают пофигизм. Что приводит к жутким косякам иногда. Где любитель 7 раз перепроверит, перечитает инструкции, перестрахуется - мастер зафигачит разом и уверенно. без сомнений. повезет будет работать долго, нет - случится факап. А так мой код живет 25+ лет уже... и 5 лет я его не трогаю тк отошел от дел.
Представил себе:
Каждый следующий электрик удаляет старую проводку и ставит свою
Каждый следующий электрик удаляет старую проводку и ставит свою
В электрике цоколь лампочки E27 как запатентовали в 1881 году, так до сих пор и используют. А если станет как в программировании - каждые пару лет то жилы проводов сделаем треугольными вместо круглых, то количество фаз увеличим до 8, то форму розеток поменяем - то действительно придется всю проводку удалить и пробросить заново. Ну или закомментировать заштукатурить.
Идеально! гораздо лучше чем скрутики меди с алюминием или перегруз старых сетей. Если старая не справляется с задачами - нужна новая.
Каждый следующий электрик удаляет старую проводку и ставит свою
Вот вы тут ржОте, а хотелось бы, потому как дом 1950 года постройки, изоляция на проводах тканевая и реально истлела: если начать их сейчас шевелить — облезнет нафиг и начнёт в стенах коротить. Так что мечтаю удалить старую и поставить современную.
У него у проводки 50-х годов изоляция истлела, значит, и недоволен.
А кое у кого проводка 90-х годов (алюминий), и не изоляция истлела, а сама проводка крошится. Её тронешь (хоть клемму прицепить, хоть как-то к ней подключиться) - а от неё кусочек отваливается, потом следующий, и так до тех пор, пока провод не перестаёт торчать из перекрытия.
Они так и делают. По возможности. По понятным причинам.
Каждый следующий электрик удаляет старую проводку и ставит свою
Если кап. рефакторинг ремонт - да. И/или если на предыдущую проводку нет документации.
На мой взгляд, как минимум часть советов очень плохие или даже вредительские, как по отношению к себе, так и по отношению к бизнесу\компании. Нет никаких правил, есть конкретные проекты и задачи, где-то и заговнокодить норм, где-то абстракции не нужны, а где-то, о ужас, и эстетика подождет следущего раунда инвестиций.
А заговнокодить вводить в норму, кодить без эстетики и умышленно принижать вертикальную сложность проекта это не плохо/вредно по отношению к себе и компании?
"Все хорошо что в меру, а не в срок все блага превращаются в порок"(с). Но мы создаем зачастую в условиях огромной неопределенности, а критик в условиях огромной определенности послезнания, поэтому он всегда в белом пальто. Токсичное отношение к творческому процессу это вот гарантированный 100% подтвержденный путь в никуда. Но, без свякого сомнения очень удобный большинству.
Тут проблема в границе применимости аналогии между строительством и программированием.
В строительстве стандарты описаны гораздо четче, и меняются гораздо реже. Поэтому следовать таким стандартам - это хорошо.
В программировании, наряду со стандартами, есть и просто хайп. Который двигают в массы под лозунгом "теперь все так делают, а кто не успел, тот ретроград". За таким хайпом следовать нет смысла.
Хайпа полно и в строительстве, особенно котеджном, малоэтажном и в слаботочке в том числе. Есть еще задачи, не решаемые дешево в старых стандартах и там попытка использовать новые технологии это какой то выход. Смысл в каком то разрезе всегда есть, но однозначно это риски. Когда то мы одни из первых в городе покрывли вайфаем суперсложное динамичное пространство дизайнерского помещения. Закупали для компов внешние антенки. Хайп - однозначно, время опередили лет на десять, когда это стало уже стандартом, но угадали и задачу решили. На тот момент даже футуристично все это выглядело, переезжающее место сотрудников вслед за дизайном.
Выбирай сложность согласно максимально возможному будущему развитию проекта. Ты повидал многое, ты знаешь, как случаются факапы, как случаются успешные успехи, которые не случаются потому что в кузнице не оказалось гвоздя. Ты знаешь куда ведут все модные тенденции, не стесняйся закладывать их в проект, если он может туда прийти.
Дорогой Мастер, от лица специалиста по безопасности, которому потом поручат чинить уязвимости в вашем переусложненном шедевре, покорнейше прошу вас проследовать в афедрон. Если вы умеете будущее предсказывать - бросайте дурацкое ИТ и зарабатывайте миллиарды на ставках на спорт и лотереях, а здесь сложность систем и так запредельная, чтобы ее еще дополнительно делать "на вырост". You Ain't Gonna Need It!
Вы исполнитель и не принимаете управленческих решений, не знаете, как будет происходить развитие вашего продукта, не отвечаете за его судьбу, и не представляете, как дорого чинить результаты подхода "надо предусмотреть вообще все, что нам предсказывает наша внутренняя Ванга".
Да, оверинжиниринг определенно зло, тоже не раз сталкивался с кодом в котором заложили "функционал на вырост", который пошел в разрез с реальным развитием проекта и не только многократно усложнял поддержку в начале, но и препятствовал внесению реально необходимых правок в последствии, в результате приходилось переписывать большие блоки с нуля. Причём забавно, что все люди писавшие переусложнённый код покидали проекты раньше, чем начиналось развитие этих блоков, а найти того, кто сможет в таком монструозном коде что-то допилить всегда проблематично. А если кто-то не до конца разобрался с изначальной и не всегда очевидной задумкой автора - здравствуйте тяжелые будни отладки наведенных багов, кучи спагетти-кода и прочие попытки в краткие сроки реализовать требования бизнеса. И я лично считаю, что если твой код не будет понятен и даже очевиден стажёрику, недавно пришедшему на проект - это плохой код и проблемы с ним гарантированно возникнут.
А специалист по безопасности мне ничего не хочет рассказать про атаки инъекциями на все эти самописные строковые функции которые как попроще? Про xml файлы собранные без всей обвязки работы с xml с валидацией, генерацией исключений? Про те же самые паттерны обвязки по безопасности торчащих наружу API, которую специалист вставит просто по умолчанию, как бы сложно оно не было в проекте типа 127.0.0.1/about, потому что в прошлый раз шифровальщик прошел защиту именно через эту дыру?
Вам - ничего не хочу, потому что ваши примерны никакого отношения к простоте не имеют. Костылить строки вместо стандартных, собирать запросы вручную при наличии prepared statements, открывать API без аутентификации на всю сеть - это все не про "так проще", а про "мы вообще не в курсе, чем мы тут занимаемся, но надо сделать вчера еще, поэтому некогда объяснять - срезаем все углы".
Просто - это не значит плохо, или глупо, или недоработано, или дыряво, или еще как-то с изъяном, просто - это так, чтобы сделано было все необходимое, и не сделано было ничего лишнего. Подчеркиваю, все необходимое, и ничего лишнего. Что-то перестало быть нужным - удаляйте, removed is debugged, что-то понадобилось - добавляйте, но руководствуясь тем же принципом.
Software - оно потому и soft, что легко поддается изменениям, и бороться с неконтролируемым ростом сложности (а с ней и неконтролируемым ростом числа уязвимостей, потому что уязвимости - они тоже следствие сложности в первую очередь) в нем нужно в момент потенциального добавления этой сложности, другого момента у вас зачастую уже не будет.
Т.е. "просто" уже и не совсем "просто" и модуль авторизации должен быть уже в мвп-шке? Даже в этой ветке не все далеко с Вами согласятся. И даже, пожалуй, я, по обстоятельствам. Но опять же, наше предстваление о простоте будет скакать как стрелка компаса в зависимости от тех условий, где нашему проекту случилось оказаться. И работать в условиях по три пост-критика на одного рабочего путь к выгоранию и говнотворчеству. У меня прям сейчас в проекте безусловно талантливые люди говнокодят "кабычегоневышло". Все понимая. Кому это надо, бизнесу?
Тем не менее многие под "просто" как раз и понимают решение в лоб, без использования практик и фреймворков/библиотек, которые, как правило, за тебя уже решили кучу проблем, пусть их использование и усложняет проект.
Тестировщик не является частью it, когда уже люди поймут это?) Поэтому к своим тестировщикам отношусь как к мусору, неспособный сделать что то свое, а не просто сидеть тыкать кнопочки лишь бы найти баг, фу
Не читая всех комментов чисто по статье.
Как и все диалектическое, оба подхода в целом верные. Суть написания хорошей программы в балансе бестпрактикс, личного опыта и конечных целей. Для локальной утилиты, чаще всего нет нужды городить ООП и применять паттерны и прочие хорошие но не практичные на коротких дистанциях пректики. Для серьезного ПО, да ещё и в команде, это становится жизнено необходимо, особенно когда уровень разработчиков в команде разный, и не ясно кто придет вослед. И не важно, через 5 лет будет доработка, или завтра. Но, такие усилия даром не даются. Это труд хорошего архитектора с огромным опытом, который правильно понимает и предметную область и инструменты, которыми будут пользоваться при написании. А значит - это и большие деньги. Но которые в целом отбиваются далее на расширении и поддержке решения хоть в какой то обозримый промежуток времени.
Мало кто думает, я сейчас возьму и напишу новую нелтленку аля фотошоп или блендер. Но если есть инвестор, который серьезно в проект решился вложиться, то как раз и возникает вопрос в анализе и создании архитектуры проекта, которую желательно создать "на берегу", и стараться по максимуму её придерживаться, даже если она окажется ошибочной. Грамотный модульный проект, даже при ошибочном проектировании архитектуры, затем куда проще исправить, нежели мешанину из "работает - не трожь". Поэтому - все подходы правильные! Главное - понимать когда стоит лениться, а когда надо делать над собой усилия и писать по установленным лекалам.
Выбирай сложность согласно максимально возможному будущему развитию проекта.
Ну прям из крайности в крайность...
После прочтения обеих статей, а также после изучения комментариев вижу, что камнем преткновения является само по себе определение простоты кода. Почему-то очень многие утверждают, как будто бы само по себе ООП сложное, паттерны сложные, фреймворки сложные. Кто-то там уже бросился измерять простоту кода как длину функций, выраженную в экранах.
Моё мнение такое: все эти ООП, паттерны и прочие фреймворки нужны только для того, чтобы упрощать код. Да, именно для упрощения. Если после применения паттерна код стал сложнее, значит этому паттерну здесь не место. Хороший программист напишет код со всеми нужными абстракциями так, что код всё равно будет оставаться простым. Излишняя сложность кода всегда появляется только там, где тот, кто пишет код, не понимает, что он делает.
Однажды мне довелось видеть квинтэссенцию "простого" кода. На сайте на битрикс надо было поправить импорт. Импорт был какой-то кастомный и всю его логику кто-то записал в отдельный php-инклюд на 1600 строк, и там не было объявлено вообще никакой функции! Даже Ctrl + F не выдавал совпадений по слову function. И ни одного комментария. Просто 1600 строк потока сознания без какого-либо намёка на структуру. Ну и поскольку это инклюд, который инклюдится хз откуда, там есть куча переменных, которые объявлены непонятно где, но они видимы. Дебагер на брейкпоинте показывает порядка 200-300 разных переменных, из которых большая часть начинается с $ar. Ничего хуже ни до, ни после этого я в своей практике не встречал, но отмечу, что по мнению очень многих комментаторов этот код идеально подходит под понятие простого.
Моё мнение такое: все эти ООП, паттерны и прочие фреймворки нужны только для того, чтобы упрощать код. Да, именно для упрощения.
Очень близко к моим представления, но я бы сказал для эффективности, почти неразрывно связанной с красотой. Эффективность только кажется простой и почти всегда красива.
Хороший программист напишет код со всеми нужными абстракциями так, что код всё равно будет оставаться простым. Излишняя сложность кода всегда появляется только там, где тот, кто пишет код, не понимает, что он делает.
И да и нет. Простой эффективный код получится на третье итеррации. На такой рефакторинг рабочего еще с первого релиза кода обычно никто время не выделяет. А первый релиз может быть написан по инерции другого проекта, где рука другими паттернами набита.
А почему никто не написал самого главного,
ну прямо самого, самого:
Да "пофигу" вообще какой код, самое главное, что бы был человек который его сопровождает.
У любой проблемы в бизнесе должно быть "имя, фамилия и отчество" и это решает все.
Видимо этими статьями интересуются как раз такие люди которые сопровождают код.
Да "пофигу" вообще какой код, самое главное, что бы был человек который его сопровождает.
Ну вот поставят вас завтра на такой код, и всем станет пофигу на "какой код": у проблемы же появилось имя и отчество. Всем, кроме вас.
В целом согласен с автором. Поверьте мне, у меня 40 лет стажа ( Хотя верить на слово никому нельзя..)
Следующий пост "Пиши простой или сложный код там где это нужно"
Я бы предложил "не пиши никакой код".
ну это классика: "Лучший код - это ненаписанный код"
А это финальный четвёртый пост. Дзен программирование.
нет, господа. финально просветленные вы сядите и подумаете "а не включить ли мне сюда фишечку?" и включите с нескрываемым удовольствием внутренного следования по пути проведения и в гармонии с собой.
У меня работа такая: выслушивать начальство и его умные предложения, ждать пока оно эти предложения изменит, ждать пока ещё изменит, ждать пока отменит... А насчёт фишечек. У нас тут извенитий микроконтроллеры. Фишечки мы добавляем только после очень серьезного анализа. кого я мля обманываю...
Менеджер: а давайте запилим %%%ню!
Аналитик: а давайте не будем! это же %%ня!
Менеджер: ок.
Лучший код - который не написан
Дзен программирования
Это как-то так:
Во-первых, разработка ПО отличается от других инженерных дисциплин простотой и динамикой изменений. Аналогии с электропроводкой неприменимы
Во-вторых, если вы разрабатываете только ради денег, и чтобы порадовать начальство, тогда советы ничего. Особенно, если ваши проекты действительно живут не больше пары лет. Если же вы работаете вдолгую ради пользователей и коллег, то надо разграничить:
Наблюдай и делай красиво, воруй у других
работает для кода, но не работает для дизайна. Код должен быть красивым, дизайн — адекватным.
В-третьих, Антуан Жанович почти 100 лет назад гениально сказал: "совершенство достигается не тогда, когда уже нечего прибавить, но когда уже ничего нельзя отнять." По-этому, не надо лепить ненужного.
смотрите, я за пару лет выкатил одно по сути мажерное обновление, а сеть мне переделывали уже трижды. А в молодой перспективной компании компания будет переезжать из офиса в офис чаще, чем релизы выпускать.
Никакой просты и динамики в нынешней разработке софта не осталось в помине. Легаси и глубочайшая встроенность в основные бизнес-процессы заставит вас только согласовывать через всю вертикаль изменения больше, чем офис построить. Тимлиды мыслят полугодиями как мне кажется.
И простоты изменений не осталось тоже. Такие неявные взаимосвязи, что с кабелями не повторить. Не идет кабель за океан на забытые телефоны, а апи в богом забытых интергациях висит десятками лет и подвинуть его та еще проблема.
Пробовали мы писать автоматизацию на одной таблице одной БД из двух колонок ради прикола. Вот уж где ничего не отнять. Всю пятницу, как сейчас помню. Математика, в общем, не согласная.
смотрите, я за пару лет выкатил одно по сути мажерное обновление, а сеть мне переделывали уже трижды.
Это аргумент. А я за 10 лет поменял три места жительства, а оператор остался тот же. Только кабель на оптику сменился в прошлом году. А обновлений выкатываю по два в неделю. И офиса три поменялось, и во всех сеть как перед заездом строили, так и стоит. Так что моё кун-фу сильнее.
Никакой просты и динамики в нынешней разработке софта не осталось в помине
Наоборот, стало ещё проще чем раньше. Один хипстер со смузи и лавндовым рафом может за два дня целую систему переделать. Посмотрю, как вы электросеть района переложите за два дня.
заставит вас только согласовывать через всю вертикаль изменения больше, чем офис построить.
Мне кажется, вы свою личную боль распространяете на всю индустрию. Я вам искренне соболезную, но это ошибочный подход.
И простоты изменений не осталось тоже. Такие неявные взаимосвязи, что с кабелями не повторить
Простите за прямоту, но если проектировать, используя предложенный подход, то ничего удивительного.
Не идет кабель за океан на забытые телефоны, а апи в богом забытых интергациях висит десятками лет и подвинуть его та еще проблема.
Я поддерживаю продукт для прозвона старинных пачинко-аппаратов через беспроводной японский ISDN. Мой кабель, к сожалению, идёт за океан на забытые телефоны.
Да вот если б знать, куда развитие проекта заведет, все бы только и делали, что писали изумительно красивый, гибкий код. Но в любом коде рано или поздно должна начинаться конкретика. Слишком простой код требует переписывания при расширении архитектуры. Чрезмерно гибкий - головная боль для анализа и дебага.
А есть еще вечно пожимающие сроки, когда перелопачивать коренным образом архитектуру тупо нет времени. Без какой либо гарантии, что через пару недель(а то и часов) снова не придется всё перелопачивать, потому как пользователи выкатили еще вагон восхитительных идей и пожеланий.
Нормальный рабочий код всегда содержит некоторый процентаж откровенных костылей. Часть будет переписана всем скопом, когда наберется некоторая критическая масса технического долга, а некоторые благополучно встретят тепловую смерть вселенной.
Сделать просто - сложно, нужно время, что бы научиться
Ну, в целом, тот что видел я (за лет 25 практики) не так уж однозначно плохо. Да, почти все подлежит улучшению или сносу со временем. И этот неизбежно по вышеописанным в статье причинам. Поэтому, не быть рукожопым это, наверное, сейчас самое актуальное требование отрасли, иначе она тебя просто извергнет.
Процессы, их объёмы и скорость растут в геометрической прогресси, попробуй тут накинь энтропии! Статья опоздала лет на 20.
Автор, судя по всему, не работал на долгих проектах. И уж тем более не работал на хорошо написанных долгих проектах.
А что такое простой код в принципе не понимает.
Но голосовалка явно показывает контингент хабра.
Вы такую интригу заложили в пост, можете немного расшифровать? 12 лет мой самый долгий проект, проект не лучший по исполнению был однозначно, пяткой в грудь бить не буду, но лучший из конкурентов по его возможностям заказчику из того, что я видел до и после.
ПС. Команда за время почти не менялась, тимлид нас не то, что не ограничивал, сыпал идеями и технологиями так, что и уходить не хотелось. Планка, задачи, адекватность, свобода и ответственность и награждения все на месте, все в балансе.
Мистер читал Юрия Брига?
Очень знакомый стиль и настроение написания.
Я бы не выражал мысль именно так, но это авторский замысел и критиковать его - дело бесполезное и вообще моветон.
Замечу, разве что, что получать удовольствие и удовлетворение можно от разных аспектов работы :) можно от процесса, а можно от результата. Можно от результата технического, а можно, опять-таки, от финансового.
И вообще все мы разные, и это прекрасно. И если ты делаешь что-то по какой-то причине, то поясни окружающим знаем, желательно чтобы они тебя поняли. Потому что человеку нужен человек.
И если ты не находишь понимания раз за разом на своем месте... То твоё ли это место?
Прошу прощения, с Бригом сталкиваться не приходилось.
С кодерами не на своем месте приходилось и вопрос там был совершенно не в простоте/сложности. Совершенно. Скорее в отсутствие какой либо как нибудь вменяемой структуризации кода. Хоть простой хоть сложной, лишь бы какой.
Проблема возможно в их излишних софт-скилах, такие люди зачастую прям выстреливают во всей околоИТишной обвязке - руководстве, техподдержке, отличные "драйвера" для мира людей в ИТ. Они превосходны в этих задачах, но им лучше не кодить.
А сделает ли человек красиво-сложно или красиво-просто тут уж как повезет. Мне самому не столь принципиально. Если я потеряю даже ночь времени разбирая красивое, хоть и сложное творение это не в минус карме этого человка. Мне интересно.
Если будет простое изящное решение - так может случиться что это и хуже, потому что я вот не уверен что выдержу в такой стилистике свои правки, а говнокодером себя чувствовать так и заснуть не сможешь и на итерациях оптимизации все сроки посрываешь.
Не пиши простой код