How to become an author
Search
Write a publication
Pull to refresh

Comments 84

Какую проблему это решает? То, что висят ветки и их не хочется удалять?
Total votes 33: ↑31 and ↓2+29
Часто бывает когда коммит ломает обратную совместимость в минорной ветке, ну и тут либо git revert на несколько коммитов, либо git reset.
Total votes 2: ↑1 and ↓10

И чем в этом случае поможет новая команда?

This comment wasn’t rated yet0
Через незамкнутые ветки из репозитория вытекает энергия!
Total votes 75: ↑74 and ↓1+73

Просто плагин к jira генерирует нулевой codecount репорт для незамерженных веток.

Разработчики страдают. А так могли бы спокойно докладывать что вот, я добавил 1000 новых строк, которые потом удалил за ненадобностью. Итого работы на 2000 строк, плати.

Total votes 1: ↑1 and ↓0+1

А ведь кто-нибудь через пару месяцев наткнется на эту статью и попробует замкнуть

Total votes 42: ↑42 and ↓0+42
А если разработчики гита оценят шутку и замкнут? Вместо дерева — циклические графы, весело! Вы не понимаете, какое же это эстетическое удовольствие создавать новые топологически-художественные коммиты, это же новое веяние в интеллектуальном развитии нейросетей, гит-история начнет самообучаться и после само-рефлексии начнется цивилизация гита.
Total votes 15: ↑14 and ↓1+13

Надеюсь, что в таком случае естественный отбор уничтожит этого закольцованного уродца в зародыше, он же будет нежизнеспособен.

This comment wasn’t rated yet0

Гит это и так граф, а не дерево. В дереве были бы невозможны мержи. Правда граф ациклический.

Total votes 3: ↑3 and ↓0+3
Ага, а точнее направленный ациклический граф (DAG). Об этом, кстати, я написал в конце статьи.
Total votes 5: ↑5 and ↓0+5

То что это орграф следует из утверждений, что это не дерево, и он не содержит циклов :-)

Total votes 1: ↑0 and ↓1-1

А затем их поработят иллитиды, а затем они разобъются на гитзераев и гитиянки, а затем придет Зертимон и Git, затем Дак'кон, Безымянный, Неразрывный Круг Зертимона, опять Безымянный, Трансцендентный, Война Крови, священная война, холивар, холивар, холивар...

Total votes 1: ↑1 and ↓0+1
И все это будет происходить в великом государстве Гитландия!
This comment wasn’t rated yet0
Упс, только из-за вашего комментария вспомнил что сегодня первое апреля.
Total votes 15: ↑15 and ↓0+15
Главное чтобы короткого замыкания не произошло
Total votes 1: ↑1 and ↓0+1
UFO just landed and posted this here
1 апреля, кто-то читает теги

Вот с какой целью вы добавляете это в теги? (и ещё несколько публикаций грешат тем же)


Розыгрыш не должен быть подписан «это розыгрыш».

Total votes 15: ↑13 and ↓2+11
UFO just landed and posted this here

Да ладно вам, с первых же слов этой статьи понятно, что к чему :)? Серьёзно, кто-то на это повёлся?

Total votes 1: ↑1 and ↓0+1
Поддержу. Мне кажется, что лучше 2 апреля расставить соответствующие тэги на соответствующие статьи, чем портить эффект розыгрыша.
Total votes 8: ↑7 and ↓1+6
Без подписи «розыгрыш» вы попадаете под статью о фейковых новостях))). Тем более в эру копипаста розыгрыш на хабре или stackoverflow может причинить серьезный урон инфраструктуре
Total votes 1: ↑1 and ↓0+1
Надо тег соответствующий хотя бы :)
This comment wasn’t rated yet0
Отлично! Не на шутку задумался, только в комментариях пришёл в себя…
Total votes 5: ↑5 and ↓0+5
эта шутка выглядит основательнее и серьезнее, чем некоторые статьи :)
Total votes 18: ↑18 and ↓0+18
Ненавижу 1 апреля я тупые около IT шутки в этот день. Имею возможность на работе читать статьи и т.д. по инструментарию, читаю в статью вообще не понимаю что это, зачем и как это решает проблему обозначенную в начале. А голова болит прямо сутра, думаю просто я ничего не понимаю. Пытаюсь из комментов понять, хорошо хоть там относительно сверху написано что это «шутка».
Total votes 16: ↑10 and ↓6+4

Тоже не люблю такое. Это сми же, какие нафиг шутки. Давайте в новостях шутить что началась 3 мировая и на нас летит ядерная ракета. Гы-гы же.

Total votes 7: ↑1 and ↓6-5

Тупые? Забавно. Только эта статья лучше, чем многие велосипеды

Total votes 7: ↑5 and ↓2+3
20-25 лет назад проект писался максимум тремя программистами на языках для мальчиков и был вылизан до блеска, всё что нужно было — архивирование версий перед крупными доработками, больше для сохранности. Теперь по три сотни программистов пишут свои кривые косяки, используя кривые же библиотеки, путаясь в версиях не только собственных ляпов, но и в версиях багов и «особенностей» библиотек. В итоге на выходе имеем совершенно тривиальные задачи, решённые всё более нетривиальными способами со всё убывающей нагрузочной способностью, релизы софта, год от года становящиеся всё более глючными, обрастающими ненужным функционалом с катастрофически убывающей юзабилити.
И вместо трёх программистов теперь 350 вынужденных инвалидов, решающих больше проблему состоятельности методов решения проблемы, нежели саму проблему.
Я знал, что доживу до времен, когда как программист стану более не нужен на рынке, не знал только, что времена эти наступят при моей еще жизни.
Total votes 12: ↑2 and ↓10-8

Да-да, archive_prod3_release_copy (5)_fix27.rar это верх совершенства, а гит ненужная помойка.

Total votes 11: ↑10 and ↓1+9
Какой один? Как синхронизировать работу хотя бы 5 разработчиков разумными силами?

Вот есть у меня PR, у меня за 2 дня 1500 строк добавлено, 1000 строк удалено. У 4 разработчиков схожие цифры. Где-то треть изменений пересекаются. Как их все объединить, не потеряв работы?
Total votes 2: ↑2 and ↓0+2
Выделяйте в проекте «чёрные ящики». Синхронизируйте работу только на уровне стыковки чёрных ящиков, протоколы взаимодействия должны быть выдолблены перфоратором на стене офиса. На каждом этапе модификаций один человек работает с одним чёрным ящиком. Причем этап это не 3 часа «эффективно сменеждеренного» времени, а минимум пара дней. Спешка хороша только при долбёжке чужой жены в доме её мужа.
Total votes 4: ↑0 and ↓4-4
А, ну то есть самостоятельно внедрять басфактор в проект. Ушел человек, который писал модуль Х, и никто не знает, как его чинить и что в нем менять.

Или, например, нужно за неделю сделать несколько фич, и один человек никак не успевает. На тех местах где я работал задачи было принято параллелить, даже если они частично пересекаются. Что предлагаете делать в вашем случае?
Total votes 1: ↑1 and ↓0+1
В крайнем случае, вы рискуете переписанием ОДНОГО модуля.
Если разбиение достаточно грамотное, то один модуль содержит вполне линейный код, который проанализировать новому человеку не займёт много времени.

А вот рвать время в клочья — это же гарантированный ахтунг с косяками, и гит или любой другой механизм контроля версий — тут просто выполняет роль подтирки на почти гарантированный случай при попытке надрать время — случай, когда все обо… ались и виноватыми будут назначены исполнители, которые, да, начнут уходить…

Ну, к слову, линейность кода — показатель хорошо продуманной системы данных и модулей с субмодулями. А вот многоэтажные логические конструкции — показатель строго противоположного. Я запрещал раньше своим студентам и коллегам использовать табуляцию меньше 8 символов, логика простая: если твой код не влазит на экран по ширине — ты лошара.
Total votes 5: ↑0 and ↓5-5
В крайнем случае, вы рискуете переписанием ОДНОГО модуля.
Если разбиение достаточно грамотное, то один модуль содержит вполне линейный код, который проанализировать новому человеку не займёт много времени.

Я правильно понимаю, что предлагается переписывать модуль каждый раз, как уходит человек его разработавший?

Total votes 2: ↑2 and ↓0+2
Зачем?? Если в модуле не так много процедур и они все линейные и написаны читаемо, то в этом нет смысла.

С другой стороны, строго по Генри Форду — какой смысл в проекте, из которого непрерывно бегут люди? Для кого этот проект тогда? Кому он греет карман и душу, кроме владельца проекта? — Раз работникам он неинтересен, то и клиенты получают значит УГ очередное. Это так, бизнес на розах 7го марта, пустышка ценою в маркетинг пустышки.
Total votes 2: ↑0 and ↓2-2
У меня все явственнее видится ваш проект как программа, которую одни и те же люди пилят на протяжении десятков лет, и которые знают каждый её закоулок. Это, конечно, похвально, но у людей разные требования.

С другой стороны, строго по Генри Форду — какой смысл в проекте, из которого непрерывно бегут люди?

Из проекта не бегут люди, у людей бывают разные мотивы. Например, полгода назад у нас ушел девопс, только потому, что ему хотелось больше командировок в страны ближнего и дальнего востока. К продукту не было никаких претензий, просто хотелось путешествовать.

Раз работникам он неинтересен, то и клиенты получают значит УГ очередное.

Мне интересен проект, это не значит, что я не могу уйти на еще более интересный проект. А еще на меня может тупо кирпичь упасть. Я могу поскользнуться и разбить голову. Меня могут ограбить, я могу попасть в ДТП. Куча способов выпасть из разработки.

— Ладно, возьмем менее радикальные варианты. Заболеть человек может? Ну вот просто заболел, и не может свой модуль писать. А модуль очень нужно сделать в течение недели. Ну, например, представьте, что от этого зависит новогоднее выступление президента. Второго января никому не интересно будет, что вы сделали, 31 декабря несъезжаемый дедлайн. Как быть, если никто в команде не понимает, что в этом модуле происходит. Да даже не модуле, а подсистеме. Ведь «20-25 лет назад проект писался максимум тремя программистами», то есть выпавший программист не один модуль за собой тянет, а треть всех модулей в проекте. Предлагаете за неделю во всем разобраться или переписать треть проекта?
Total votes 3: ↑3 and ↓0+3
Есть некоторая культура кодирования. Если её нет — её надо вводить. В конце концов, нет никакого оправдания для имён переменных вроде POwnRsLockCm. Нет никакого оправдания конструкциям
if()
if()
else if()
else
else
if()
if()
else if()
if()
else
else
else
/// Ну, вы поняли ))
Нет никакого оправдания вариантам вроде
A(){
}
B(){
…
A()
…
}
…
…
…
Z(){
…
Y();
…
}
Как нет и никакого оправдания называть итератор сложнее чем i.
Нет никакого оправдания разбивать проект на 200 файлов, если он вполне логично вписывается в 20, включая файлы визуальной настройки среды разработки.
Нет никакого повода подключать какой-бы-то ни было движок СУБД, если все ваши данные можно свести в 5 несчастных таблиц, в каждой несчастные 200 миллионов записей.
Есть тупо культура, и культурно написанный код всегда читается другим/новым/забывшим специалистом.
Мы ведь все забывшие специалисты — участок, который отлажен и пашет годами — он тупо забывается.
Более того, культурно написанный код более открыт для поиска ошибок, а потому реже их содержит — они видны уже самому разработчику еще до этапа тестирования.
Total votes 2: ↑0 and ↓2-2

Отлично, согласен со всем написанным.


Непонятно только, как он отвечает на заданные вопросы.

This comment wasn’t rated yet0
Это к тому, что может и заболеть, и забеременеть, и уехать в Канаду. В нормальном случае не нужен другой человек, который в курсе заведомо, что делал ушедший, если у ушедшего было достаточно времени, что бы без нервотрёпки писать и доводить до ума красивый, аккуратный и компактный код, где вся сложная математика задокументирована, а всё остальное написано прозрачно и понятно даже человеку с невысокой квалификацией.
This comment wasn’t rated yet0
Это к тому, что может и заболеть, и забеременеть, и уехать в Канаду.

Верно

В нормальном случае не нужен другой человек, который в курсе заведомо, что делал ушедший

Вывод диаметрально противоположенный правильному.

если у ушедшего было достаточно времени, что бы без нервотрёпки писать и доводить до ума красивый, аккуратный и компактный код, где вся сложная математика задокументирована, а всё остальное написано прозрачно и понятно даже человеку с невысокой квалификацией.

1. аккуратная документация может быть только у продукта, который настоялся хотя бы несколько лет. Документировать когда апи кардинально меняется каждый год не очень получится
2. задокументировать так, что не придется понимать код затруднительно. Возьмите исходный код rustc, там все задокументировано выше некуда, и попробуйте что-нибудь понять.
3. Достаточно времени это сколько? Человек который болеет не будет ничего объяснять, он в очереди в поликлинике сидит или постельный режим соблюдает, человек который увольняется будет в компании 2 недели, за которые трудно объяснить все, человек который помер вообще вряд ли что-то объяснит.
Total votes 1: ↑1 and ↓0+1
rustc…
После этого даже желание как-то реагировать отпадает. )))

Вот ответьте на простой вопрос:

50 лет назад были узкоплатформные ассемблеры.
35 лет назад был кроссплатформный С, потом плюсы.
20 лет назад была совсем платформо-независимая ява и такой же SQL.
Какого дьявола понадобилась вся вот эта остальная языко-платформо-помойка из всяких решеток, питонов, и прочей холеры с дотнетами, которую мы развели себе на голову и теперь георически с ней боремся?..
Сколько проблем вся эта мусорка создала по сравнению с тем, сколько решила?
Ну вот правда, куда теперь без Git? ))))))

Вместо стандартизации и унификации мы теперь идем на поводу у маргинальных диктатур экспресс-решенчества.

Логшика какая была в свое время?
Мало спецов, они дорогие, давайте сделаем средства разработки для лохов.
Сегодня спецов много, но решают они лоховские задачи лоховскими средствами за лоховские деньги.
Доигрались?

Вот медики молодцы, блюдут корпоративный ценз еще со времен Гиппократа :)
Total votes 6: ↑0 and ↓6-6
У меня тоже после этого комментария пропало всякое желание общаться.

Честь имею, удачи и терпения вам по работе, они вам понадобятся.
Total votes 2: ↑2 and ↓0+2
Взаимно, и вам удачи и терпения.
Без них ни в какой работе просвета не видать.
This comment wasn’t rated yet0
UFO just landed and posted this here
Нужно, я всегда за стандартизацию и многое давно назрело.
Эволюция С, что мне в нем нравится, очень консервативна, в С не тянут слепо любую появляющуюся тенденцию. Есть правда и некоторые спорные вещи, например за появление template я бы поубивал, столько косяков напложено с применением шаблонных типов. Слава богу эта лихорадка остыла немного. А вот реализация объектного подхода в С(++) изумительная и синтаксически внятная.
This comment wasn’t rated yet0
UFO just landed and posted this here
И всё же я сторонник жесткой типизации. И противник неявного накладного кода. Одно с другим прямо связано. Причем сегодня это не аппаратная проблема, а культурная. За слово auto отбивал бы руки и мозги.
Total votes 2: ↑1 and ↓10
UFO just landed and posted this here
UFO just landed and posted this here
Поменялось апи (мутабельная структура на иммутабельную), отсюда много изменений в рамках её использования. Вот уже пара сотен строк (в тестах, в основном). Ну и по-мелочи.

PR на 1500 измененных строк, к слову, потому что 1 измененная строка дает 1 удаление и 1 добавление.
Total votes 1: ↑1 and ↓0+1
>Я знал, что доживу до времен, когда как программист стану более не нужен на рынке, не знал только, что времена эти наступят при моей еще жизни
Вы не знали, что времена, до которых вы доживете, наступят при вашей жизни?
Total votes 1: ↑1 and ↓0+1
))) Нда, вот так бывает, когда правишь предложение по три раза )) С кодом аналогично — надёжнее переписать ))

Так это и происходит… Сперва утверждается что «переписывать неделю — дорого», а потом оказывается, что наложенная за 5 минут заплатка тянет за собой убытки ещё годами. При этом на времязатраты кодирования накладываются еще бОльшие времязатраты на менеджмент. О нервах вообще молчу.

Через какое-то время из проекта расползаются ключевые фигуры и спустя 10 лет проект становится громоздким возом заплаток, который лечить уже никто не собирается ни за какие деньги — проще начать новый проект.
This comment wasn’t rated yet0
Гит никак не мотивирует писать или не писать заплатки.
Total votes 1: ↑1 and ↓0+1
Ничего не имею против гита самого по себе. Просто он относится к разряду инструментов, которые могут отвлечь внимание от основной цели, если эта цель, разумеется, создание качественного, а не маркетингового продукта.
Есть вещи, которые позволяют ослабить проектную составляющую. А проект это в первую очередь именно проект — цельная концепция, в которую любая рюшечка вписывается сама собой логично.
Когда настает момент, что новая рющечка не вписывается — необходимо перепроектирование, иначе и эта, и все последующие рюшечки автоматически становятся заплатками.
Total votes 6: ↑0 and ↓6-6
Рюшечка вполне может вписываться, просто разные рюшечки требуют развития в разных направлениях. Например если есть фича добавить логгирование + Любая другая фича, они пересекутся, потому что один человек будет менять функции X, Y, Z, а другой будет добавлять в эти же функции это логгирование. В гите неизбежно будет конфликт, который при условии их простоты (например, описанный случай под такое попадает) будет автоматически разрешен. В случае с файлами мне видится решением разве что использование сторонних тулзов для сравнения директорий чтобы сделать то же самое в полуавтоматическом режиме. Зачем себе усложнять жизнь, непонятно.

Или возьмем более интересный момент. У гита есть куча интересных инструментов, например git bisect. Вопрос — как его эмулировать? Или «нинужна»?
Total votes 1: ↑1 and ↓0+1
А это потому что у вас не вынесено отдельного чёрного ящика, который идентичен для Х, У и Z. Тогда ведение протокола («логгирование») добавляется девочкой, которая правит черный ящик стандартных процедур/объектов/янии7у для контекстов X, Y и Z, а сами контекстные правки спокойно делаются другой девочкой.
Только на этапе проектирования-допроектирования вы должны взять перфоратор и добавить на бетон протокол для нового черного ящика, что бы обе девочки понимали, что могут делать любые вещи, которые не противоречат тому, что на стене.
This comment wasn’t rated yet0

Погодите, вот у нас есть


void X() {
   Foo(1, 2)
}

Вот девочка добавляет логгирование


void X() {
   log!("Before Foo");
   Foo(1, 2)
   log!("After Foo");
}

Вот мальчик в это время у себя реализует бизнес-требование передавать айди текущего пользователя в функцию:


void X() {
   Foo(1, 2, CurrentUserId)
}

Какого рода черные ящики тут должны существовать? Как эти изменения дружить друг с другом?

This comment wasn’t rated yet0
Пример решения вашей проблемы:

class SomeLogTypeClass {
private:
baseClassForXYZ *context;
public:
void __cdecl SomeLogTypeClass L(baseClassForXYZ *c){
context=c;
…
}
…
void __cdecl Log(int m){
… context.UserId…
}
};
…
void __cdecl XClass::X(){
SomeLogTypeClass Log(this);
…
Log.Log(a);
…
Log.Log(b);
…
}

Как вариант, без претензий на вашу конкретику, мне она неизвестна.
И прошу пощения за инлайн, тут неудобно набирать код.
Суть в том, что бы сделать любой субмодуль проекта максимально автономным, насколько это позволяет требование многопоточности, если таковая используется.
В данном случае, перфоратором долбится только то, что в базовом классе есть UserId.
Можно даже сразу прописать в конструкторе базового класса UserId=0, что бы принимать это как знак нештатной ситуации, когда величина останется непрописанной.
Total votes 4: ↑0 and ↓4-4

У вас очень много деталей, за которыми леса не видно. Можно без плюсов и вот этого всего? Мы не выдумываем иерархию, в которой эта задача решалась бы без изменений (мы ведь не пророки, да?), Мы смотрим ситуацию, когда один и тот же метод должны поправить два человека, причем их задачи никак не связаны — один человек реализует бизнес-логику, другой — инфраструктурную задачу.


Желательно использовать псевдокод как я привел выше, а не писать на плюсах.

Total votes 2: ↑2 and ↓0+2
Понимаю, что часто усложнение и/или избыточное дробление к добру не ведут. Тогда разнесите задачи во времени. Сегодня петя вылизывает свою часть и оставляет старый метод для сохранения функциональности старого кода,
завтра маша вносит свои правки по логике, послезавтра Федя спокойно переводит всё на новый код.
В таком варианте вы можете спокойно подвергнуть каждый этап качественному тестированию и оценить все риски.
Total votes 1: ↑0 and ↓1-1
  1. Во-первых не всегда заранее очевидно, что нужно менять для задачи. Например, оценили, что нужно поменять модуль Х, а во время реализации оказалось, что там были неочевидные завязки на Y и Z, которые в это время правил другой разработчик.
  2. Во-вторых это просто издевательство над пользователями. "Да, мы знаем, что вы все хотите фичу Х, но у нас Ксюша делает логгирование, поэтому мы не можем её сделать. Зато смотрите, теперь мы поддерживаем новую файловую систему! (разработчику нефиг было делать и он сварганил что-то из низа беклога, что не пересекается по текущим задачам).
  3. В-третьих при количестве разработчиков за десяток количество комбинаций растет настолько, что в голове удержать что сейчас делать можно, а что нельзя нереально.
  4. В-четвертых косячить люди все равно будут, потому что они люди собственно.


Подытожим, метод с архивами работает на командах, где люди 20-30 лет сидят на одном проекте, никогда с него не уходят, четко делят границы ответственности по всем модулям, никогда не болеют и не ошибаются.


И до сих пор непонятно, что с гитом не так, ведь с гитом будет все ровно точно так же :) Гит ведь строго мощнее варианта с архивами. Еще и место экономит, потому что дельта-кодирует все.

Total votes 4: ↑4 and ↓0+4
Ну, так же, по пунктам.
1. Ситуация абсолютно идиотская. Обычно такая ситуация следствие полного отсутствия стадии проектирования, либо следствие безалаберного проектирования, либо отсутствие реализационного видения структуры проекта в виду избытка образования в знаменателе с недостатком опыта независимой разработки в числителе, либо ошибочного видения из-за приверженности некой однобокой парадигме от какого-нибудь забулдыжного коучера, или как их там…
2. Над пользователем не нужно издеваться, заказчик всегда прав, Надо работать вместе с заказчиком, вникать в причину его проблем, а не слепо реализовывать глупости, которые он придумывает, что бы компенсировать глупости разработчика.
Часто слеп и разработчик и заказчик, Только совместные усилия позволяют увидеть правильное продуктовое решение.
Да, бывает, что время не терпит, но потом оно появляется и его надо использовать что бы убирать наставленные впопыхах костыли.
3. Да, Форточки с фортокопродуктами были созданы с вовлечением иногда тысяч индусов. И никакой менеджмент и никакие инструменты не смогли сделать с этим что-либо. Из окон до сих пор торчат тысячи костылей, которые торчали еще в 1994м. Сейчас в той же стадии развития находятся линуксы во всём своём ассортименте. И, несмотря на то, что минули десятилетия, поменялись инструменты, создано еще 40 ненужных языков, ситуация не меняется — то же количество костылей, просто костыли своеобразные.
4. Тем не менее, количество косяков обратно пропорционально качеству и детальности проработки концепта. Как и качество косяков — самые надежные и нелечимые источники косяков заложены в самом концепте.
— Всё с гит-ом так. Только 20 лет назад ты садился и за неделю писал микросервер или CGI, которые волокли на паршивеньком мэйнфрейме столько запросов, сколько мог пропустить к тебе канал. И тебе не нужно было 20 косоруких инвалидов. Хватало одной девочки, которая умеет ровно резать сыр и наливать коньяк. И ничего практически не глючило. И, поэтому, не нужен был гит. :)

А теперь, блин, нужен!!! :)
Total votes 4: ↑0 and ↓4-4
  1. То есть по-вашему на этапе планирования всегда можно точно оценить список файлов, которые будут затронуты при реализации задачи?
  2. а не слепо реализовывать глупости, которые он придумывает


Приходит такой юзер "вот у вас график по заявкам в разрезе периодов, а нам бы наоборот, по периодам в разрезе заявок", а вы ему такой "что за глупости ты тут мне несешь. Не нужно тебе оно".


  1. Вот так вот махом все продукты созданные более чем парой людей стали нинужным индусософтом? Понятно-понятно.


  2. Видел я софт написанный 20 лет назад, goto на goto и goto погоняет. Звали меня как-то в один бодишоп проект на делфи и .net 1.1 писать. нет, там не было тысяч индусов, всего пара разработчиков. Если аргумент "ну нормальные люди так не писали", попробуйте личным примером показать. Возьмем какую-нибудь несложную софтину, может даже тестовое задание какое-нибудь, и покажете как без этих новомодных плохих технологий все круто и быстро работает.


Total votes 3: ↑3 and ↓0+3
goto в структурных языках — моветон,
это чуваки явно пересели с бейсика на паскаль )).
Вообще ветвления — это моветон, много ветвлений говорит о непродуманности структур данных.
Ну давайте для примера софтину.
Могу дать код, который долбит по таблице (или паре таблиц, уж не точно помню) отчёт в формате HTML объемом 2-3Гб за пару-тройку секунд на паршивеньком нотбуке. Этот же код забирает данные в таблицу из диспетчерской в текстовом формате.
Там правда была всего неделя на разработку, из которой я 5 дней пил с заказчиком самогон.
Есть и замысловатая математика, но вам это будет скорее всего неинтересно.
Total votes 1: ↑0 and ↓1-1
так вот в чем ваш секрет… ящик самогона — и никаких гитов не надо. вобще ничего не надо. все равно бюджет уже кончился )
Total votes 1: ↑1 and ↓0+1
В 1994-м, в форточках были тысячи индусов? Внезапно…
This comment wasn’t rated yet0
Нет, тысячи им понадобились позже. В 94м там всё еще было относительно хорошо, кроме слюней зависти к Apple и Sun systems, но не было OLE и DDE и кучи других вещей «самих в себе».
А потом стало нужно много кода, поклонники всяких Free-BSD орали «где безопасность?», попёрли всякие NT, ну и там уж понеслось…
Ну и в итоге за всю историю родилось всего два годных продукта — Win7 и офис 2003. Остальное восполнили 3rd-party — Adobe, Oracle, 1C… Сам же микрософт в остальном оказался печален — наклепал многоверсий ублюдочных библиотек и довольно слабо проработанную среду разработки, кто писал драйвера под форточки — поймёт.
Total votes 1: ↑0 and ↓1-1
Я знал, что доживу до времен, когда как программист стану более не нужен на рынке, не знал только, что времена эти наступят при моей еще жизни.

Вы точно программист?
Total votes 4: ↑3 and ↓1+2
Теперь уже не уверен, раньше был программистом и электронщиком, а теперь пишу только когда кто-то из друзей упирается рогом в невозможность решить малыми средствами сложную задачу. Сажусь, рисую концепт и методично пару дней пилю то на С то на ассемблере, пока не впишу задачу в требуемый ресурс времени. Обычно бесплатно, из любви к искусству. Иногда еще, когда человек понимает, что не может решить задачу путями, которым его учили на физмате — тогда рожаю адекватный задаче алгоритм или протокол. Я могу писать на решетках и на явах, могу писать запросы, писал много и под 1С, но меня это бесит, не моё. Как буд-то кто-то пытался упростить жизнь, создавая эти инструменты, но в итоге усложнил и сделал простое ненужно сложным. Это уже не мой мир, это мир поколения, которое мы учили. Хреново учили, наверное.
This comment wasn’t rated yet0
Впал в ступор пока не посмотрел на календарь и не почитал комменты.
This comment wasn’t rated yet0
всю статью не покидало странное ощущение встревоженности, неужели это не шутка, не дай бог это не шутка!
Total votes 1: ↑1 and ↓0+1
«Мы рождены, чтоб шутку сделать былью»?
(Microsoft Linux уже есть. И зелёные (цветные) телевизоры из анекдота.)
This comment wasn’t rated yet0
Мне такие шутки напомниают историю как в конце 90х компьютерный журнал пошутил про разблокировку разгона процессора путём его сверления, а следующих номерах публиковали письма недовольных разгонщиков. Осторожнее надо быть.
Total votes 4: ↑4 and ↓0+4
я себе сегодня сказал, что я не попадусь на шутки… поздравляю, у Вас получилось.
Я уже было начал писать инструкцию своей тиме о новвоведении в гит…
Total votes 3: ↑3 and ↓0+3
Так-то говоря, это просто расширенный мердж. Зачем команду-то вводить новую? Так просто всем инструментам нужно было бы просто повыкидывать кучу проверок на слияемость и заменить на `return true`.

Киньте proposal кто-нибудь что-ли.
Total votes 1: ↑1 and ↓0+1
Я это понял ещё до того, как писать комментарий выше. Почему бы не поддержать хорошую шутку :)?
P.S.: про первое апреля я уже часов 12 как знаю из-за StackOverflow.
Total votes 2: ↑2 and ↓0+2

Аха, ну да они ещё те тролли

This comment wasn’t rated yet0
А теперь без шуток. Если есть такая «висячая» ветка, которую нельзя просто cмерджить, но хочется сохранить в истории основной ветки, то можно сделать искуственный мердж, о котором я написал тут. Пример:
git checkout master
git merge --ff $(git commit-tree HEAD^{tree} -m "Empty commit. Artificial merge of branch 'alpha' into 'master'" -p HEAD -p alpha)

Мы получим пустой коммит, то есть коммит, который ничего не меняет, так как его единственная цель — это просто замкнуть ветку через мердж. После этого ветку можно спокойно удалить, зная, что вся ее история сохранена.

P.S. Читаю эту статью 5 апреля, и пока не дошел до комментов, думал «что это за бред» )
Total votes 2: ↑2 and ↓0+2
Sign up to leave a comment.

Articles

Show the best of all time
Unlock dark mode

Your account

Sections

Information

Services

Support
© 2006–2024, Habr