> А шо так не уверенно отвечаете? Всегда есть вероятность что по факту окажутся какие-то (ж-до)масоны, орден подпольных брадобреев, элонмаск, зеленые человечки, рептилоиды или AI решивший постебаться. Никакие законы природы не запрещают это. А поскольку я лично не стоял за каждым комитящим строчки кода - откуда я знаю наверняка какая у них (само)идентификация была?! :)
> Раз в вашем определении, программер этот тот, кто способен написать и удалить куче
> строк в программе (алгоритме). И это нормально, это суть программера в вашем определении.
Еще в моем определении подразумевается что програмер способен алгоритмы понимать и писать.
> Но увы не в моем. Почему не в моем? В моем определении, программер
> (точнее инженер) этот тот кто в полноте продумает всю программу (алгоритм),
Попробуйде целиком продумать город размером с Нью-Йорк? Чтобы каждый житель оказался по итогам счастлив? Каждым камушком на самой мелкой улочке? Надеюсь, это даст понять что упомянутый подход катит не всегда и не везде. То что вы в результате хотите проектировать только центр коттеджного поселка - а что делать если те рожи хотят именно мегаполис на цать миллионов?! Вы обречены откатиться к итеративному подходу и решать проблемы по мере поступления. И если народ требует брадобрея вот тут - значит, он должен быть в этом доме. Даже если это идет вразрез с грандпланом мега-архитекта, это значит что наступило поменять гранд-план. И в этом месте будет брадобрей, а не то что вы там себе возомнили. Потому что жизня показала что это должно быть вот так. Даже если вы это не предусмотрели.
Лично я не знаю на этом глобусе никого способного предусмотреть ВСЕ в штуке масштаба САБЖА. Так же как я не знаю никого кто мог бы спроектировать с ноля "Нью-Йорк, только лучше" на одном дыхании.
> докажет её безошибочность и выпустит в продакшен,
О, вы еще и в вопросах качества не шарите? Хочу вас расстроить:
1) Ставлю на то что с таким подходом вы не релизнете софт такого масштаба НИКОГДА.
2) Я готов поспорить что если вы все же удумаете заявить что в софте такого масштаба нет багов, я легко докажу обратное. И даже найду дюжину багов, чтобы уж вы макнулись от души, с головой.
3) И таки вы абсолютно не рубите в больших проектах и подходах.
> чтобы не пришлось на виду делать "удалено 480891 строк".
В нормальном курсе событий статистика порядка 50/50 или 40/60 для удалено/добавлено совершенно нормальна для типового софтварного проекта крупного масштаба который относительно устаканился. Если добавлено сильно больше - это значит что навернули каких-то новых фич. В данном случае видимо новые драйверы, это неизбежно двигает картину в сторону добавлено.
> Что значить вообще удалить строку из алгоритма? О чем это говорит?
Это может говорить например о том что прогер посмотрел на алгоритма, почесал репу, придумал вариант лучше и перекроил сие. Или ему не понравился общий вид и он отрефакторил в что-то более удобоваримое. А может быть еще и ставшее полезное "вон тем трем чувакам, хотевшим похожего", так что _их_ почти-дубль фичи был вытерт, а вот это чутка адаптировано еще и для них. А может он нашел какой-то баг. Или мало ли чего там еще. Для ответа на конкретный вопрос в конкретном случае есть git log (-p), дающий весьма конкретный ответ.
> Удалить весь алгоритм и заменить другим - это еще можно понять.
А можно и не весь. А можно улучшить. А можно отрефакторить. Програмеры довольно сложные существа, равно как и их программы. Если не считать совсем уж вебмакак и б-длокодеров.
>>Чувак, ты хоть 1 программу с системой контроля версий писал?
> А зачем вообще она нужна?
Факин лол. Ну вот смотри, фигачил ты два дня, будучи уверенным что все ЗБС. И все вроде было ЗБС. Но вот всплыл некий Фатальный Недостаток, о которым ты даже не подумал сперва. При том ты изначально в душе не е...шь что его вызывает. Вопрос: где ты его посадил в этом интервале? И как сие починить? Кроме как профакать 2 дня вджоба целиком и вернуть все как было? А то просто профакать 2 дня впустую - обидно, да? :)
Ну вот с git сие как 2 байта переслать: если мы изредка комитили относительно логически консистентные точки - говорим git bisect, довольно быстро узнаем где сломалось, получаем перед мордой проблемный фрагмент кода и чешем репу уже предметно над проклятым кусочком с фига ли он нам тут все испортил.
...а чего делаешь в таком раскладе ты? :))). Даже если забыть про то что тот ноутпад жестко мультиплеерный и еще надо подумать как все это агрегировать с вон той тыщенки человек. Если б ты был PM тимы о тыще чел, ты бы этим озаботился, но это явно не твой уровень.
> Следить за тем кто сколько строк удалил или переименовал blacklist в blocklist?
Для хранения истории изменений. Это отличный рабочий инструмент для програмера. Упомянутое лишь весьма частный пример использования истории изменений.
> сложение двух чисел разве не fire and forget?
В случае Arian V это почти так и было :). И я готов поспорить что они после этого малость поменяли алгоритм, хе-хе. Я бы удивился если бы это было не так.
> Разве детерминированные алгоритмы это не fire and forget?
С реалистичной точки зрения это катит только для очень небольших масштабов. И даже там порой "тойота" случается.
