IMHO, это всё относится к пункту Business. Всё, что вы перечислили (ТЗ, definition of done, таски) нацелено на создание кода, решающего определённую задачу.
Вот тут мне сложно вам что-то ответить. Вы почему-то решили, что "легкость изменения кода" подразумевает отказ от тестов и code review. Ни у себя в комментах, ни у автора статьи я не видел такого утверждения. Автор говорил, что писать код нужно так, чтобы тестов нужно было меньше. Вполне здравое утверждение, как по мне.
Потому что главной задачей разработчика ПО является как раз таки поддержание кодовой базы в актуальном состоянии, чтобы она могла продолжать решать задачи бизнеса
Прочитайте это ещё раз. Если вы выдающий девелопер, который может написать с одного захода приложение, которое будет работать всегда, то и то вы укладываетесь в это определение. Просто ваши усилия на поддержание после выпуска продукта равны нулю, вы их все вложили до. Никакой КРИТИЧЕСКОЙ детали я не упустил, это вы выдумали её существование. Даже лендинг в сельском магазине со временем нуждается в обновлениях, вот только они уже будут искать другого разраба, потому что имеющийся не берёт телефон. Некоторые могут сказать, что другой разраб сделает другой продукт, вот только решать он будет те же самые бизнес-задачи - лендинг сельского магазина.
Далеко не всему бизнесу нужна поддержка ПРОДОЛЖИТЕЛЬНОЕ время. В качестве самого яркого примера я приведу стартап.
И что? Много вы видели стартапов, которые завелись с одной итерации по методу водопада? В стратапах, как правило, народ плохо представляет, что именно он хочет, и пробует различные варианты, иногда параллельно (A/B-тестирование, например). Там требования к изменяемости кода ничуть не меньше. Кстати, а ПРОДОЛЖИТЕЛЬНОЕ (большими буквами) время - это не меньше скольки? Обычно, продолжительное - это больше нуля. А у вас?
По причинам, которые я описал выше, я поставил автору минус. Автор посчитал, что суть программирования не в том, что приносить пользу бизнесу исходя из задач, потребностей и жизненного цикла бизнеса, а в какой-то его субъективной красоте кода.
Ну, вы поняли, как смогли понять, и отреагировали, как смогли отреагировать. Только и всего.
TTM - это про то, как каждый коммит (изменение) задеплоить в продакшн максимально быстро. А лёгкость изменения существующего кода - оно разве не про то же? Чем проще тебе менять исходный код, тем быстрее ты выведешь в продакшн новую версию продукта. Просто это один из первых этапов в workflow, но он тоже работает на ту же цель - сокращение TTM. Именно поэтому я и упомянул про Continuous Deployment/Delivery.
Continuous Deployment/Delivery - это слон, а легкость изменения кода - ну не знаю, бантик на его шее, что ли. Слона видят все, а бантик ещё разглядеть нужно. Если вам "слон" заслонил "бантик", возможно вы просто смотрите на него со стороны хвоста.
Ну, вообще-то, да. Я вот тоже споткнулся, пытаясь выудить информацию из вот этого текста:
В одной компании где работал директор радостно рассказывал HR что у меня есть аккаунт на Хабре, я организовывал митапы. Я звал своего друга с прошлой работы выступать. Через некоторое время пришел бывший менеджер автора статей "Made at Intel" и превратил мою активность в комитет-бюрократию с совещаниями и процессами/roadmap и транслировал это в свои KPI. Комитет без бюджета для оплаты проезда и проживания для выступления сприкеров на международных конференциях.
Кто работал? Кто рассказывал? У кого аккаунт и кто организовывал? При чём тут ваш друг? Менеджер автора статей - это как "тень отца Гамлета". Самое главное в нём - какое-то отношение к "Made at Intel" (я х.з., что это). Бюрократия - это действие/процесс, комитет - структура. Комитет-бюрократия - это действие или структура? Комитетная бюрократия или бюрократический комитет? Судя по "превратил мою активность" - первое, судя по "комитет без бюджета" - второе.
Вы явно в теме того, что рассказываете, но вам не удалось тут изложить свою мысль так, чтобы я смог её поместить себе в голову. Я бы прошёл мимо (мало ли какие мысли в мою голову не помещаются), если бы не коммент @taras_82 (значит не только у меня с этим была проблема) и ваш ответ на него ("проблемы индейцев шерифа не волнуют").
А, всё, понял. Вы про HARP и только про HARP говорили, а я про $mol в целом. Да, конечно, если развивать именно HARP, то тут нужно максимальное покрытие по различным ЯП. Согласен.
Так и я о том же. Для разработки веб-приложений, имеющих UI в браузере, достаточно одного языка и для бэка, и для фронта. Зачем делать платформу для двух-трёх-... языков? Это не даст популярности среди "не-веб" разрабов, но заберёт имеющиеся ресурсы. А веб-разрабы уже умеют в JS/TS.
Пусть даже поддержка в формате "вот Вася Пупкин запилил поддержку на байткоде для ZX80" она проекту только в плюс пойдёт.
Я бы не хотел в своём проекте отдуваться за кривую реализацию Васи. Более того, я рекомендую всегда оценивать границы применимости инструмента перед его применением. А так-то и молотком можно шуруп "закрутить".
А чем python для веб-проектов лучше PHP, или Ruby, или Java, или C#, или Go, или Rust? На JS/TS можно написать и фронт, и бэк. Более того, можно написать код, который будет работать и на фронте, и на бэке. Так зачем тянуть в проект другие языки, когда можно обойтись одним? Старина Оккам бы не одобрил такое.
Возможно, это неочевидно, но добавление новых фич - это тоже "изменение существующего кода", как и удаление устаревших фич.
Я давно в IT и наблюдал эволюцию подхода к кодированию своими глазами. Начиная от "программа должна правильно выполнять свою задачу" (write), через "программа также должна быть ещё и понятна" (read) и до "программа, до кучи, должна быть ещё и легко изменяемой" (modify).
Потому что главной задачей разработчика ПО является как раз таки поддержание кодовой базы в актуальном состоянии, чтобы она могла продолжать решать задачи бизнеса. Не просто создать приложение "согласно ТЗ" и свалить в закат, а дать инструмент, способный эффективно работать в изменяющейся среде продолжительное время, и поддерживать этот инструмент в актуальном состоянии. Баг и секьюрити фиксы - они ведь тоже про актуализацию состояния ПО в изменяющемся мире.
Автор поста не побоялся привнести свет в массы и заслуженно получил минусов, потому что массы не любят, когда их просвещают ;) Я-то за его ответ сразу плюс статье поставил, ещё не читая, но я уже больше двадцати лет в IT.
Что-то типа такого предполагалось. 4 - это браузер по сущностям (таблицам), в узлах (фолдерах) - связи с другими сущностями (foreign keys). 5 - это условия связывания сущностей (таблиц) по ключам, 6 - результирующая выборка (данные).
В основе лежала идея дать возможность операторам делать произвольные выборки данных и сохранять запросы в своих favorites в веб-приложении. Принципиальную модель сделали на php/angular, затем сделали красиво на python/smartclient (вот этот скриншот), а потом забросили.
Вот теперь я понял ваш посыл. Программист - это человек, который знает, какую программу нужно запустить, чтобы получить результат, требующийся бизнесу. В таком случае вы правы - такому программисту код ни читать, ни писать, ни изменять нет нужды.
А в чём тогда задача бизнесмена? Найти такого программиста?
IMHO, автор статьи прав, что в некоторых случаях лёгкость изменения существующего кода становится, по сути, бизнес-задачей разработки ПО. Continuous Deployment/Delivery - это об этом. Кстати, в соседней теме про лунный модуль говорится, что тот внештатно прилунился вследствие программной ошибки и что теперь тамошние разрабы стали опытнее. Так-то может оказаться, что никакой "модели водопада" не существует. Вернее, существует в рамках лишь одной итерации. И это относится и к автопрому, и прочему эмбеддеду. Просто у них итерации идут годами.
Когда-то имел какое-то отношение вот к этому проекту - https://pypi.org/project/damvitool/ Базовая идея была такая: на серверной стороне при подключении в БД (MySQL или PostgreSQL) делался анализ имеющихся таблиц и отношений между ними (foreign keys), после чего модель данных в виде JSON отправлялась на фронт и использовалась для построения запросов к базе при помощи графического интерефейса. В общем, можно было через конструктор визуализировать структуру данных произвольной базы и давать пользователю возможность составлять запросы произвольной вложенности без знания SQL.
Дружище, тут тебе никто ничего не обязан доказывать. Тебе дали возможность, а как ты ею воспользуешься - твоё дело. Считаешь, что википедия, это "прекрасный пример общественного контроля за информацией" - ну и хорошо.
В спорах не рождается истина, кто бы что ни говорил. Спор - это древний ритуал ранжирования самцов в стае и к истине отношения не имеет. Истина же рождается лишь в тех дискуссиях, где каждая из сторон стремится её найти. А если человек не хочет, то зачем совершать над ним насилие? Я вообще против насилия. Пусть даже и интеллектуального.
Я, например, не умею в иероглифы. Я их не пойму, даже если увижу. А кто-то лишь слово такое слышал - иероглифы, он не поймёт, что видит иероглифы, даже если будет на них смотреть в упор.
IMHO, это всё относится к пункту Business. Всё, что вы перечислили (ТЗ, definition of done, таски) нацелено на создание кода, решающего определённую задачу.
согласен (y)
Аргумент.
Стало понятнее (y) Всё-таки проблемы индейцев шерифа волнуют :)
Вот тут мне сложно вам что-то ответить. Вы почему-то решили, что "легкость изменения кода" подразумевает отказ от тестов и code review. Ни у себя в комментах, ни у автора статьи я не видел такого утверждения. Автор говорил, что писать код нужно так, чтобы тестов нужно было меньше. Вполне здравое утверждение, как по мне.
Прочитайте это ещё раз. Если вы выдающий девелопер, который может написать с одного захода приложение, которое будет работать всегда, то и то вы укладываетесь в это определение. Просто ваши усилия на поддержание после выпуска продукта равны нулю, вы их все вложили до. Никакой КРИТИЧЕСКОЙ детали я не упустил, это вы выдумали её существование. Даже лендинг в сельском магазине со временем нуждается в обновлениях, вот только они уже будут искать другого разраба, потому что имеющийся не берёт телефон. Некоторые могут сказать, что другой разраб сделает другой продукт, вот только решать он будет те же самые бизнес-задачи - лендинг сельского магазина.
И что? Много вы видели стартапов, которые завелись с одной итерации по методу водопада? В стратапах, как правило, народ плохо представляет, что именно он хочет, и пробует различные варианты, иногда параллельно (A/B-тестирование, например). Там требования к изменяемости кода ничуть не меньше. Кстати, а ПРОДОЛЖИТЕЛЬНОЕ (большими буквами) время - это не меньше скольки? Обычно, продолжительное - это больше нуля. А у вас?
Ну, вы поняли, как смогли понять, и отреагировали, как смогли отреагировать. Только и всего.
TTM - это про то, как каждый коммит (изменение) задеплоить в продакшн максимально быстро. А лёгкость изменения существующего кода - оно разве не про то же? Чем проще тебе менять исходный код, тем быстрее ты выведешь в продакшн новую версию продукта. Просто это один из первых этапов в workflow, но он тоже работает на ту же цель - сокращение TTM. Именно поэтому я и упомянул про Continuous Deployment/Delivery.
Continuous Deployment/Delivery - это слон, а легкость изменения кода - ну не знаю, бантик на его шее, что ли. Слона видят все, а бантик ещё разглядеть нужно. Если вам "слон" заслонил "бантик", возможно вы просто смотрите на него со стороны хвоста.
Ну, вообще-то, да. Я вот тоже споткнулся, пытаясь выудить информацию из вот этого текста:
Кто работал? Кто рассказывал? У кого аккаунт и кто организовывал? При чём тут ваш друг? Менеджер автора статей - это как "тень отца Гамлета". Самое главное в нём - какое-то отношение к "Made at Intel" (я х.з., что это). Бюрократия - это действие/процесс, комитет - структура. Комитет-бюрократия - это действие или структура? Комитетная бюрократия или бюрократический комитет? Судя по "превратил мою активность" - первое, судя по "комитет без бюджета" - второе.
Вы явно в теме того, что рассказываете, но вам не удалось тут изложить свою мысль так, чтобы я смог её поместить себе в голову. Я бы прошёл мимо (мало ли какие мысли в мою голову не помещаются), если бы не коммент @taras_82 (значит не только у меня с этим была проблема) и ваш ответ на него ("проблемы индейцев шерифа не волнуют").
А, всё, понял. Вы про HARP и только про HARP говорили, а я про $mol в целом. Да, конечно, если развивать именно HARP, то тут нужно максимальное покрытие по различным ЯП. Согласен.
Я об этом и только об этом. Если UI на Delphi, то и бэк разумно делать на нём же.
Так и я о том же. Для разработки веб-приложений, имеющих UI в браузере, достаточно одного языка и для бэка, и для фронта. Зачем делать платформу для двух-трёх-... языков? Это не даст популярности среди "не-веб" разрабов, но заберёт имеющиеся ресурсы. А веб-разрабы уже умеют в JS/TS.
Я бы не хотел в своём проекте отдуваться за кривую реализацию Васи. Более того, я рекомендую всегда оценивать границы применимости инструмента перед его применением. А так-то и молотком можно шуруп "закрутить".
А чем python для веб-проектов лучше PHP, или Ruby, или Java, или C#, или Go, или Rust? На JS/TS можно написать и фронт, и бэк. Более того, можно написать код, который будет работать и на фронте, и на бэке. Так зачем тянуть в проект другие языки, когда можно обойтись одним? Старина Оккам бы не одобрил такое.
Возможно, это неочевидно, но добавление новых фич - это тоже "изменение существующего кода", как и удаление устаревших фич.
Я давно в IT и наблюдал эволюцию подхода к кодированию своими глазами. Начиная от "программа должна правильно выполнять свою задачу" (write), через "программа также должна быть ещё и понятна" (read) и до "программа, до кучи, должна быть ещё и легко изменяемой" (modify).
Потому что главной задачей разработчика ПО является как раз таки поддержание кодовой базы в актуальном состоянии, чтобы она могла продолжать решать задачи бизнеса. Не просто создать приложение "согласно ТЗ" и свалить в закат, а дать инструмент, способный эффективно работать в изменяющейся среде продолжительное время, и поддерживать этот инструмент в актуальном состоянии. Баг и секьюрити фиксы - они ведь тоже про актуализацию состояния ПО в изменяющемся мире.
Автор поста не побоялся привнести свет в массы и заслуженно получил минусов, потому что массы не любят, когда их просвещают ;) Я-то за его ответ сразу плюс статье поставил, ещё не читая, но я уже больше двадцати лет в IT.
Что-то типа такого предполагалось. 4 - это браузер по сущностям (таблицам), в узлах (фолдерах) - связи с другими сущностями (foreign keys). 5 - это условия связывания сущностей (таблиц) по ключам, 6 - результирующая выборка (данные).
В основе лежала идея дать возможность операторам делать произвольные выборки данных и сохранять запросы в своих favorites в веб-приложении. Принципиальную модель сделали на php/angular, затем сделали красиво на python/smartclient (вот этот скриншот), а потом забросили.
Вот теперь я понял ваш посыл. Программист - это человек, который знает, какую программу нужно запустить, чтобы получить результат, требующийся бизнесу. В таком случае вы правы - такому программисту код ни читать, ни писать, ни изменять нет нужды.
ОК, что в вашем понимании "код" и что в вашем понимании "программа"? Существует ли программа без кода и кто исполняет такую программу?
А в чём тогда задача бизнесмена? Найти такого программиста?
IMHO, автор статьи прав, что в некоторых случаях лёгкость изменения существующего кода становится, по сути, бизнес-задачей разработки ПО. Continuous Deployment/Delivery - это об этом. Кстати, в соседней теме про лунный модуль говорится, что тот внештатно прилунился вследствие программной ошибки и что теперь тамошние разрабы стали опытнее. Так-то может оказаться, что никакой "модели водопада" не существует. Вернее, существует в рамках лишь одной итерации. И это относится и к автопрому, и прочему эмбеддеду. Просто у них итерации идут годами.
Когда-то имел какое-то отношение вот к этому проекту - https://pypi.org/project/damvitool/ Базовая идея была такая: на серверной стороне при подключении в БД (MySQL или PostgreSQL) делался анализ имеющихся таблиц и отношений между ними (foreign keys), после чего модель данных в виде JSON отправлялась на фронт и использовалась для построения запросов к базе при помощи графического интерефейса. В общем, можно было через конструктор визуализировать структуру данных произвольной базы и давать пользователю возможность составлять запросы произвольной вложенности без знания SQL.
Дружище, тут тебе никто ничего не обязан доказывать. Тебе дали возможность, а как ты ею воспользуешься - твоё дело. Считаешь, что википедия, это "прекрасный пример общественного контроля за информацией" - ну и хорошо.
В спорах не рождается истина, кто бы что ни говорил. Спор - это древний ритуал ранжирования самцов в стае и к истине отношения не имеет. Истина же рождается лишь в тех дискуссиях, где каждая из сторон стремится её найти. А если человек не хочет, то зачем совершать над ним насилие? Я вообще против насилия. Пусть даже и интеллектуального.
Я, например, не умею в иероглифы. Я их не пойму, даже если увижу. А кто-то лишь слово такое слышал - иероглифы, он не поймёт, что видит иероглифы, даже если будет на них смотреть в упор.
так ты ж не смотрел даже.