Comments 24
одна из самых красивых идей в IT — это двухбуквенные операторы сравнений утилиты test
Если что они из Fortran-а.
одна из самых красивых идей в IT — это двухбуквенные операторы сравнений
> Если что они из Fortran-а.
Не буду спорить насчет красоты, но как программист на фортране, я с какого-то времени стал предпочитать этим двухбуквенным совершенствам менее традиционные, но более короткие >, <, >=, <=
и так далее
Во-первых, один-два символа вместо четырех. Во-вторых, без точек, которые у нас обязательны в логических операторах типа .and., .not. и пр. Иначе от них начинает рябить в глазах, например:
if (ab.eq.cd.or.ef.gt.gh) ...
Лично я в таких ситуациях (да и в более простых тоже) почему-то предпочитаю:
if (ab == cd .or. ef > gh) ...
Хотя, если совсем уж начистоту, то на самом деле я всегда пишу так:
if ((ab == cd) .or. (ef > gh)) ...
Конечно, согласно известной присказке, о синтаксисе не спорят. Но если язык допускает и первое и второе, то разговор о вкусах неожиданно может обрести смысл ;-)
менее традиционные, но более короткие
>, <, >=, <=
Занятно, что изначально, в первом драфте языка bp 1954, как раз были >, <, >=, <=. Но в первую версию языка это всё не попало, нормальный IF с логическими выражениями позже завезли.
У меня ж целый материал тут есть про историю Фортрана, вдруг вы не видели https://habr.com/ru/articles/740018/
Спасибо за наводку,
действительно пропустил!
Мой камень в огород Хабра, который не позволяет удалять из ленты неинтересные лично для меня материалы, в результате чего она всегда перегружена, и многие интересные вещи проскакивают мимо. Особенно если не листаешь ее ежедневно...
А я всего-то-навсего просил сделать фильтрацию статей в ленте по "черному списку тегов", по принципу "все, кроме...". Точнее, я бы хотел двойной фильтр, чтобы:
1) если в статье есть интересующий меня тег (белый список), то она всегда попадала мне в ленту, независимо от пп.2. Но,
2) если в статье есть заведомо неинтересный мне тег (черный список), то она исключалась бы из моей ленты (кроме случаев из пп.1).
Но вместо этого можно лишь настраивать белый список, что и долго, и неудобно ввиду обилия возможных тегов. А главное, этот метод еще и требует постоянной актуализации списка, так как список возможных тегов меняется...
Сейчас займусь изучением ;-) А то мои познания из истории языка опирались преимущественно вот на это ;-))
Скажу наверное крамольную мысль: не всякий миддл превратится в сеньора. Может не хватить желания, настойчивости, знаний, навыков, софт-скиллов, склада ума, насмотренности.
Отсюда и появляются попытки обесценивания уровня сеньор. Когда миддл "формошлёпит" 5 лет и думает, что по прошествии этого срока он автоматически превращается в сеньора.
Заметил в последние годы что на хабр набежало много вайтишников которые искренне считают что максимум через 5 лет после курсов они уже синьоры.
поясните, пожалуйста, про обесценивание, может я Вас неправильно понял.
Я эту тему не затрагивал, но Вы об этом говорите. Вы увидели попытки обесценивания в статье?
Я эту тему не затрагивал, но Вы об этом говорите. Вы увидели попытки обесценивания в статье?
К статье как раз относится первая часть моего комментария. Вторая часть - следствие из этой мысли.
А мысль простая - нет серебряной пули, не всякий миддл станет сеньором и может быть ему это и не надо
Спасибо, что пояснили. Я с Вами согласен, не все смогут и не всем надо. А навязывание, что всем надо - это плохо.
Но тем не менее, я считаю, что взять в свою работу какие-то практики можно, пусть даже это и не приведет к смене должности. Например, плохого от чтения кода не случится. Я же самом-то деле не о должностях, а о мышлении, как его развивать. И я старался сделать текст короче, не расползаясь в пояснения по связанным вопросам. Поэтому есть ряд упрощений, в том числе и в заголовке
для меня, одна из самых красивых идей в IT — это двухбуквенные операторы сравнений утилиты test -
eq,ne,gt,lt,ge,le
Если это для вас одна из самых красивых идей, с которыми вы знакомы в IT, то вам рано писать статьи о том, как стать сеньором.
ок, допустим это мой личный недостаток, слишком парюсь с именованием, поэтому идею по удачному именованию оценил выше, чем оно того заслуживает.
Но это не было выводом статьи или чем-то, что я предлагаю.
Мне было бы более интересно обсудить рекомендации из статьи
Сегодня ты сеньёр крутой, а завтра мидл простой.
(При переходе из одной компании в другую. Работает и в обратную сторону).
та, ситуация, о которой Вы говорите - это крайность и плохая практика, не надо до этого доводить работу в команде. Я этого не имел ввиду, мне жаль, если Вы сделали такой вывод. Тезис был в том, что обычно синьор лучше мидла справляется в условиях недостатка информации. И эта ситуация недостатка информации встречается чаще, чем хотелось бы, по разным причинам, не только из-за управления. Например, может не быть хорошей доки по опенсорсному проекту, который надо интегрировать
Вы приводите вопросы управления (кому какие задачи оптимально отдавать), они в статье не затрагивались, это отдельная тема. Ну то есть, допустим, какие-то задачи кому-то давать неоптимально. Как от этого меняются подходы к саморазвитию разработчика?
Вот это слишком категоричное утверждение.
если пытаться в паре строк описать ситуацию, то упрощения неизбежны. Я согласен с Вами, что бывают исключения и нельзя судить о професиональных качествах конкретнго человека по некой усредненной модели
Например, для меня, одна из самых красивых идей в IT
То есть до Лиспа автор ещё не добрался.
вижу, что это место зацепило не только Вас)
Надо было написать - идея по именованию. Я поправлю, чтобы обсуждение статьи не сводилось к обсуждению одной фразы.
Как бы то ни было, та фраза - это не вывод, и не основная мысль.
Ой, да ладно, какой Лисп, йот-комбинатор же! https://en.wikipedia.org/wiki/Iota_and_Jot
Понравилась статья, но хотелось бы как-то глубже что ли)) насчет работы сеньором без контекста: столкнулся с ситуацией, когда фронт писали бэкендеры, при этом очень давно. Ведущие бэкендеры)) так вот, аналитик ушел, пришел джун. И я джун. И вот мы сидим и думаем, как правильно кнопки показывать в кебабе. Старый аналитик, вероятно, не лучше джуна, потому что сделал таблицу из 38 разных состояний и прописал для каждого из 38 состояний какие кнопки в каком состоянии. 11 кнопок на 38 состояний, вместо того, чтоб написать условие для каждой кнопки. И новый аналитик просто копипастит его таблицу... А бэкендер написал так как видит. По итогу теперь пришли к тому, что надо просто все переписать. Но аналитику не трогают, чтоб в следующий раз снова вернуться к вопросу а что и когда)))
Для каждого проекта есть 3 важные вехи, которые нужно заполнять друг за другом и без которых не обходится планирование фичи:
Бизнес требования - что хочет бизнес от приложения. Описание бизнес процессов.
Дизайн - технический и интерфейсный. Под техническим подразумевается архитектура проекта, бизнес логика, ограничения, используемые инструменты. Под интерфейсным - дизайн для фронтенда, контракты API, бизнес логика компонентов
Связи - используемые библиотеки и их версии, зависимости от других сервисов
Чтобы дать задачу джуну, нужно заполнить все три пункта, чтобы было максимально очевидно, что и как делать. А после нужно тщательно проверять на ревью.
Чтобы дать задачу мидлу, достаточно остановиться на дизайне, а связи отдать на его усмотрение, предварительно обговорив некоторые детали. А ревью кода можно проводить не так досконально, как у джуна.
Для синьора нужны лишь бизнес требования, все остальное он разберёт самостоятельно, сходит к стейкхолдерам, поговорит с тиммейтами, назначит созвоны, соберёт контекст, подготовит архитектуру, проанализирует подходящие для задачи инструменты и так далее.
От мидла к синьору. Часть первая