Ну дело не в сравнении кита со слоном или кого там, а в том, что даже в условиях полной победы коммунизма в виде электромобиля отхода от ископаемого топлива пока не просматривается. Если в электрогенерации ещё можно рассуждать о ветряках или атомных станциях (кому что ближе), то что делать с кораблями и самолётами независимо от того, как они соотносятся с моим личным авто, непонятно.
Ну мы в любом случае продолжаем жечь — какой-нибудь океанский контейнеровоз потребляет за один рейс топлива больше, чем я за всю жизнь, и замены пока не видно. С самолётами аналогично.
Вы перегибаете палку. Тут куда ни плюнь — везде истории успеха, которые создают ощущение, что все молодцы, и только ты один лузер, поэтому полезно бывает ознакомиться с альтернативным опытом, даже если там есть элементы нытья.
А по теме — ну так все, включая автора, прекрасно знают, что если валяться на кровати и есть как не в себя, кончится это плохо, а надо, наоборот, брокколи и бег. Но штука в том, что здоровый образ жизни не всем одинаково легко даётся. Есть люди, для которых физическая активность настолько в радость, что в свободную минуту они с удовольствие на турнике подтянутся лишний раз. А для других — это именно «ну давай всё же сделаем эти чёртовы приседания, не хочется в 40 сдохнуть от инфаркта».
Поэтому задача очень даже имеет право на обсуждение. Если себя ежедневно насиловать, то перспектива сдохнуть в 40 уже не выглядит столь ужасной — зачем такая жизнь? Да, поиск программы активности лично под себя — это для многих длительный и сложный процесс, чего тут поделаешь.
Табы в тотал коммандере делаю, так же как и в браузере.
Всё-таки основная масса атомарных файловых операций проходит в рамках одной-двух директорий: скопировать/переименовать/перенести.
Ну так им же не шашечки, а ехать — я бы тоже на их месте крепко задумался, зачем мне это переписывать. Это для вас там код, который устроен разумно или нет, а для них — коробка типа телевизора, и что там внутри — хоть лампы вперемешку с микросхемами — работает и ладно. Должна же быть разумная бизнес-цель, которая окупит эту работу, а не просто ради красоты.
Да пока вы перепишете, оно тоже перестанет быть современным. И современное — оно такое… Представьте себе поддержку системы на node.js через сорок лет — ещё неизвестно, что лучше, кобол или вот это.
Естественно, с самого начала имелся ввиду процесс, более или менее, современного вида, когда каждое изменение просматривается одним-двумя коллегами
Ну так дайте ссылку на современное определение. В википедии такого нет (и определение из википедии ссылается на печатные источники), а наши личные представления о прекрасном чего обсуждать.
Про code review — я и говорю, вы мне предлагаете стрельбу по движущейся цели. Сначала «их нет», теперь они «методологически неправильны». Кто делает и когда делает review — неважно, почитайте хотя бы определение из википедии, там такие ограничения никто не ставит.
Про ван Тассела тоже мимо — читайте разделы 5.17-5.18 и около них. Более того, снова движущаяся мишень. Мне лично книга ван Тассела не слишком нравится — там много общих рассуждений и мало конкретики. Однако она ни разу не претендует на новизну и глубину — автор на некотором (довольно поверхностном) уровне обсуждает сложившиеся практики. Моя цель — показать, что такие практики были, а если требуется более глубокое и вдумчивое описание существовавших процессов — это уже другая задача.
Верно, то есть UNIX уже десять лет как писали к тому моменту, и ничего, справлялись.
напридумывала молодёжь всякого, вместо того чтобы просто без багов писать.
Да я, в общем, не вижу в этом взгляде особых проблем: ведь тот же репозиторий нужен для того, чтобы совместно редактировать код. Но если система построена как UNIX — как коллекция небольших утилит — то ничего совместно редактировать и не надо. Конечно, хорошо бы ещё следить за версиями в своём собственном коде, но при известной дисциплине и этого можно добиться.
Я не говорю, что этот метод хорош, но при некоторых договорённостях управленческого порядка вполне работоспособен.
а и, трудно поверить, что люди знали про автотесты, код-ревью и техдолг с рефакторингом, но нигде про это не написали ни статей, ни книг.
Ну, вы утверждаете отсутствие чего-либо. Это довольно смелый подход. Если мы не будем заниматься стрельбой по движущимся мишеням, я предложу просто два контрпримера на поверхности:
Статья 1976 года про code reviews, на Google Scholar можете найти полный текст.
Ну так то, что UNIX появился в 70-е, дела принципиально не меняет: вы ведь точно так же можете сказать, что «в 80-е ситуация была совсем другой, не было интернета и репозиториев», то есть с точки зрения обычной разработки ситуация была такой же, как в 70-е. Ну да, в 80-е появились персональные компьютеры, но UNIX всё равно оставался в основном проектом для мейнфреймов.
Штука не в том, что «мы знаем про...», а в том, что вы почему-то полагаете, что они про это не знали. Я так не думаю; но тут надо копать глубже в историю, конечно. На сегодняшний день книга Брукса выглядит несколько капитанской, но это ровно потому, что его идеи (как и других единомышленников, конечно) теперь считаются «здравым смыслом», ну и замечательно.
И эти продукты живут и развиваются. В 70-е ничего подобного не было и не могло быть
Ну здрасьте, а UNIX, а существующие до сих пор пресловутые системе на КОБОЛе?
Брукс же не говорит, что это «невозможно», там вся книга про то, что надо понимать суть сложностей и методы борьбы с ними. Собственно, непонятно, что принципиально изменилось в этом вопросе.
Про «технический долг» — это да, как в анекдоте «жопа есть, а слова нет». Собственно, «философия UNIX» (которая сейчас, мне кажется сильно размылась) — это как раз один из видов ответа на данный вопрос, родом как раз из семидесятых — как уменьшать технический долг и упрощать рефакторинг. Делаем гибкий универсальный API (текстовый ввод-вывод), разбиваем систему на минимальные части, далее занимаемся ими по отдельности. Микросервисная архитектура, если угодно.
Ну вы же пытаетесь опровергать не цитату, а Брукса. В книге описывается вполне чёткий сценарий:
«Предположим, что трудоемкость задачи оценивается в 12 человеко-месяцев, и три человека должны выполнить ее за 4 месяца, причем в конце каждого месяца имеются четыре контрольные точки A, B, C и D, в которых можно произвести измерения. [имеется в виду, что всего 4 точки — одна точка в конце календарного месяца]. Предположим теперь, что первая контрольная точка была достигнута лишь по истечении двух месяцев. Какие альтернативы имеются у менеджера?»
То есть какой тут онбординг — половина срока прошла, и вся наша скромная команда из трёх человек по уши в работе. Вот ещё новичков им не хватало. Сейчас, так понимаю, в этом отношении ничего не меняется.
Это утверждение очень сложно доказать или опровергнуть, но мне кажется, что тут вряд ли что-то изменилось. Брукс по сути пишет о паре больших итераций (написали, выбросили, переписали). Сейчас в моде большая дробность, но суть не меняется — всё равно накапливается технический долг, и приходится тратить время на реорганизацию и переписывание. Ну да, придумали для этого слово «рефакторинг». А если оказывается, что в системе надо поддерживать годами одно и то же API или форматы данных, то уж точно здравствуй, энтропия.
Обучаемость не падает после 30, это миф, но одно дело написать "10 лет опыта работы с тем-то", а совсем другое — "год с хвостиком, только начал изучать". Понятно, что имеет смысл продавать свои самые сильные стороны в первую очередь.
Не, ну с этим я не спорю — конечно, отдельные эпизоды такого рода были, были и люди, которые задумывались об этих вопросах. Но мне кажется, что основной массив исходников жил в условиях «дикой природы», да и судебная практика ещё не устаканилась, даже в 90-х годах была масса прецедентных решений.
Да много чего на ум приходит. GIF, ZIP, AVI и ещё огромная куча форматов. Более того, я бы сказал, что форматы в среднем переживают софт, поэтому в нашей повседневной практике используется масса форматов, придуманных тогда, когда об открытости и вопросах лицензий вообще мало кто задумывался. А с реализацией везде проблемы: docx открыть в OpenOffice — криво, odt открыть в MS Word — точно так же криво, чего тут удивительного. HTML страницы в разных браузерах тоже по-разному отображаются, хотя казалось бы.
Не передергивайте: софт и формат данных — это совершенно разные, не связанные между собой вещи. И да, закрытый и неопубликованный формат — это больший риск, который в моём представлении выше риска проприетарщины. Но прямого отношения эти вещи друг к другу не имеют.
Я не думаю, что на эту тему имеется хоть какая-то надёжная статистика. Безусловно, технически у открытого софта больше шансов «пережить зиму», если понадобится, но на практике мы знаем массу примеров всех возможных сочетаний этих двух категорий: живое/сдохшее, проприетарное/открытое. К тому же, опять-таки, «долговременная живучесть» — важный фактор, но лишь в ряду прочих факторов. Вполне можно решить, что конкретно моей ситуации это вообще непринципиально. Допустим, есть у меня софт, который делает бэкапы. Если он по какой-либо причине перестанет работать, я найду аналог, вряд ли это такое уж экстраординарное дело. Но бывают случаи и гораздо сложнее, конечно.
Ну мы в любом случае продолжаем жечь — какой-нибудь океанский контейнеровоз потребляет за один рейс топлива больше, чем я за всю жизнь, и замены пока не видно. С самолётами аналогично.
А по теме — ну так все, включая автора, прекрасно знают, что если валяться на кровати и есть как не в себя, кончится это плохо, а надо, наоборот, брокколи и бег. Но штука в том, что здоровый образ жизни не всем одинаково легко даётся. Есть люди, для которых физическая активность настолько в радость, что в свободную минуту они с удовольствие на турнике подтянутся лишний раз. А для других — это именно «ну давай всё же сделаем эти чёртовы приседания, не хочется в 40 сдохнуть от инфаркта».
Поэтому задача очень даже имеет право на обсуждение. Если себя ежедневно насиловать, то перспектива сдохнуть в 40 уже не выглядит столь ужасной — зачем такая жизнь? Да, поиск программы активности лично под себя — это для многих длительный и сложный процесс, чего тут поделаешь.
Всё-таки основная масса атомарных файловых операций проходит в рамках одной-двух директорий: скопировать/переименовать/перенести.
Ну так им же не шашечки, а ехать — я бы тоже на их месте крепко задумался, зачем мне это переписывать. Это для вас там код, который устроен разумно или нет, а для них — коробка типа телевизора, и что там внутри — хоть лампы вперемешку с микросхемами — работает и ладно. Должна же быть разумная бизнес-цель, которая окупит эту работу, а не просто ради красоты.
Да пока вы перепишете, оно тоже перестанет быть современным. И современное — оно такое… Представьте себе поддержку системы на node.js через сорок лет — ещё неизвестно, что лучше, кобол или вот это.
Ну почему же, например, в Django есть пакет локализации на основе gnu gettext — и работает это очень похоже на то, что у вас описано.
Ну так дайте ссылку на современное определение. В википедии такого нет (и определение из википедии ссылается на печатные источники), а наши личные представления о прекрасном чего обсуждать.
Про ван Тассела тоже мимо — читайте разделы 5.17-5.18 и около них. Более того, снова движущаяся мишень. Мне лично книга ван Тассела не слишком нравится — там много общих рассуждений и мало конкретики. Однако она ни разу не претендует на новизну и глубину — автор на некотором (довольно поверхностном) уровне обсуждает сложившиеся практики. Моя цель — показать, что такие практики были, а если требуется более глубокое и вдумчивое описание существовавших процессов — это уже другая задача.
Верно, то есть UNIX уже десять лет как писали к тому моменту, и ничего, справлялись.
Да я, в общем, не вижу в этом взгляде особых проблем: ведь тот же репозиторий нужен для того, чтобы совместно редактировать код. Но если система построена как UNIX — как коллекция небольших утилит — то ничего совместно редактировать и не надо. Конечно, хорошо бы ещё следить за версиями в своём собственном коде, но при известной дисциплине и этого можно добиться.
Я не говорю, что этот метод хорош, но при некоторых договорённостях управленческого порядка вполне работоспособен.
Ну, вы утверждаете отсутствие чего-либо. Это довольно смелый подход. Если мы не будем заниматься стрельбой по движущимся мишеням, я предложу просто два контрпримера на поверхности:
Статья 1976 года про code reviews, на Google Scholar можете найти полный текст.
Известная книга ван Тассела 1978 года. В пятой главе вполне себе про автотесты, в т.ч. про автогенерацию тестовых данных.
Штука не в том, что «мы знаем про...», а в том, что вы почему-то полагаете, что они про это не знали. Я так не думаю; но тут надо копать глубже в историю, конечно. На сегодняшний день книга Брукса выглядит несколько капитанской, но это ровно потому, что его идеи (как и других единомышленников, конечно) теперь считаются «здравым смыслом», ну и замечательно.
Ну здрасьте, а UNIX, а существующие до сих пор пресловутые системе на КОБОЛе?
Брукс же не говорит, что это «невозможно», там вся книга про то, что надо понимать суть сложностей и методы борьбы с ними. Собственно, непонятно, что принципиально изменилось в этом вопросе.
Про «технический долг» — это да, как в анекдоте «жопа есть, а слова нет». Собственно, «философия UNIX» (которая сейчас, мне кажется сильно размылась) — это как раз один из видов ответа на данный вопрос, родом как раз из семидесятых — как уменьшать технический долг и упрощать рефакторинг. Делаем гибкий универсальный API (текстовый ввод-вывод), разбиваем систему на минимальные части, далее занимаемся ими по отдельности. Микросервисная архитектура, если угодно.
«Предположим, что трудоемкость задачи оценивается в 12 человеко-месяцев, и три человека должны выполнить ее за 4 месяца, причем в конце каждого месяца имеются четыре контрольные точки A, B, C и D, в которых можно произвести измерения. [имеется в виду, что всего 4 точки — одна точка в конце календарного месяца]. Предположим теперь, что первая контрольная точка была достигнута лишь по истечении двух месяцев. Какие альтернативы имеются у менеджера?»
То есть какой тут онбординг — половина срока прошла, и вся наша скромная команда из трёх человек по уши в работе. Вот ещё новичков им не хватало. Сейчас, так понимаю, в этом отношении ничего не меняется.
Обучаемость не падает после 30, это миф, но одно дело написать "10 лет опыта работы с тем-то", а совсем другое — "год с хвостиком, только начал изучать". Понятно, что имеет смысл продавать свои самые сильные стороны в первую очередь.