Мимо 12 лет в IT и если честно, в этом комментарии вы написали полную херню, уж простите. Начнем с того, что системный аналитик и девопс - это НЕ рост разработчика. Вы как HR наверное понимаете, что Senior разработчик получает не меньше Senior DevOps/Senior Analyst. Это просто горизонтальная ротация, смена специализации.
К статье. Я искренне не понимаю, почему опыт ТЕСТИРОВЩИКА или АНАЛИТИКА должен предшествовать опыту ПРОДАКТА? Ну вы это серьезно? Где вы это берете? Product менеджер - отдельная специальность, можно начать сразу с этого став, внезапно, Junior Product Manager. И такой каши в вашей статье и картинках пруд пруди. Вы выдаете горизонтальную ротацию за рост. Это не так. Если я был Senior разработчиком, а стал Senior тестировщиком, или, скажем, Senior Project manager'ом - я НЕ вырос. Это как говорить, что из дизайнера сайтов можно вырасти в дизайнера упаковок.
Тогда стоило бы явно об этом сказать, как минимум. Мол, забиваем на все вокруг: бизнес, менеджеров, требования и говорим о сферическом написании кода в вакууме. Но нет. Этой оговорки тут не наблюдается
Статья прикольная, с интересом прочитал, но все таки, я бы реально добавил в нее критику, а то выглядит как реклама(хоть я и не думаю, что это она). А с критикой статья будет еще полезней и интересней
Что если для написании программы вам нужно не код писать, а, например, рисовать картинку, или танцевать? Процесс создания такой программы(рисование\танец) уже не будет являться программированием? По моему будет. Будет ли его результат кодом? Ну нет же(если только машинным на выходе). То есть получается, код все-таки не является целью и результатом программирования?
Так никто не спорит с тем, что копать нужно! Но лучше копать в то, что интересно, а не во все подряд. Ну или хотя бы в то, что нужно, как вы сказали) По этому и говорю, что пример с планировщиком - хороший. Особенно, например, для разработчика смарт-контрактов на Solidity. Там вот это прям вообще бесполезное знание, вообще никак и ни на что не повлияет и повлиять не может. А для кого-то другого это может быть частью ежедневной работы
Я ни в коем случае не несу посыл "пофиг, как оно работает". Я говорю о том, что в каждом моменте можно копать очень глубоко и жизни не хватит, чтобы все раскопать даже до атомов, не то что до кварков. Пример с планировщиком ОС отличный именно потому, что это вообще никак не влияет на код, который я пишу на питоне. Именно по этому мне не важно, как это работает. Это уже инкапуслировано, я пользуюсь интерфейсом. Все. Зачем тебе знание, которое никак не влияет на твои дейсвтия?
Абстракции над этим всем, слава богу, придумали разработчики языков программирования, виртуальных машин, библиотек и прочие умные люди, которым это все очень интересно. А мне интересно бизнес-задачи решать. Еще раз повторю: я неплохо знаю, как все устроено) И свой язык программирования в универе делал и Таненбаума читал, так что не пойму при чем здесь ребенок\не ребенок. При этом я еще раз повторяю, что эти знания в работе были не более полезны, чем аэродинамика. Даже более страшную вещь скажу, для того, чтобы быть бэкенд-разработчиком сегодня, чаще всего не обязательно даже знать как работает TCP/IP, достаточно понимания HTTP. Вы вот используете буквы и слова, предложения складываете, а понимаете при этом что такое фонемы и морфемы? Похоже на позицию ребенка, знаете ли. Или вот вы чай завариваете, а понимаете ли все химические и физические процессы, которые при этом происходят? А вы уверены?
Абстракции для того и нужны, что бы для того, чтобы писать на любимом питухончике не нужно было уметь в уме переводить питон в ассемблер, а ассемблер в машинный код, понимаете о чем я? Я перекладываю JSON из запроса в базу данных и отдаю какой-то другой JSON в ответе. Похеру мне на планировщик операционный системы на работе, честно! Это я говорю при том, что я интересовался тем, как все и работает и книжки читал, но эта информация была полезна мне в работе не больше, чем знание аэродинамики.
добавление новых фич - это тоже "изменение существующего кода", как и удаление устаревших фич.
Все верно, с этим никто не спорит, тезис про time-to-market это никак не отменяет. Нас одинково интересует time-to-market как изменения старых фич, так и добавления новых, так и удаления) Это очевидно.
Я давно в IT и наблюдал эволюцию подхода к кодированию своими глазами. Начиная от "программа должна правильно выполнять свою задачу" (write), через "программа также должна быть ещё и понятна" (read) и до "программа, до кучи, должна быть ещё и легко изменяемой" (modify).
Хорошо, но как игнорирование тестов в определенной ситуации, или, например, непрохождение code-review улучшает показатели write/read/modify?
Потому что главной задачей разработчика ПО является как раз таки поддержание кодовой базы в актуальном состоянии, чтобы она могла продолжать решать задачи бизнеса
Абсолютно верно. Но упущена КРИТИЧЕСКАЯ деталь. Бизнес бывает разный. Это не единая сущность. И у разного бизнеса мало того, что есть разные потребности, бывают еще и разные стадии жизненного цикла. Невероятно странно было бы использовать теже подходы, что используются при разработке банковского ПО для создания лендинга сельского цветочного магазина, не так ли?
Не просто создать приложение "согласно ТЗ" и свалить в закат, а дать инструмент, способный эффективно работать в изменяющейся среде
Тут все верно, но опять же нужно уточнить, что понятие "эффективно" для каждой бизнес-задачи будет свое. У всех будут свои метрики. Именно из-за этого уточнения ломается следующая часть утверждения.
продолжительное время, и поддерживать этот инструмент в актуальном состоянии.
Далеко не всему бизнесу нужна поддержка ПРОДОЛЖИТЕЛЬНОЕ время. В качестве самого яркого примера я приведу стартап. Вот вы с другом сели и придумали классную идею проекта. Какой бы классной она ни была, с вероятностью примерно в 95% она никому кроме вас с другом нахер не нужна. На этом этапе ваша бизнес-задача не состоит в том, чтобы создать легко поддерживаемый продукт с высоким качеством кода. Почему? Потому что это существенно удорожает разработку именно на ранних стадиях проекта. А у вас нет еще ни одного клиента, прибыли и вы не знаете, сможете ли вообще отбить свои затраты на разработку. Оверинжиниринг на этом этапе - крайне распространенная причина провала проекта вообще. Многие просто даже до рынка не доходят.
При всем при этом, есть компания, ну, скажем Ericson, которая поставляет в том числе софт для вышек сотовой связи с каких-то бородатых годов, когда еще JavaScript даже в зародыше не было. Очевидно, что в такой корпорации для того софта, подходы к разработке должны быть совершенно иные. И там как раз нельзя делать все то, о чем тут пишет автор. Там надо именно что СТРОГО придерживаться принятых стандартов.
Автор поста не побоялся привнести свет в массы и заслуженно получил минусов, потому что массы не любят, когда их просвещают ;)
По причинам, которые я описал выше, я поставил автору минус. Автор посчитал, что суть программирования не в том, что приносить пользу бизнесу исходя из задач, потребностей и жизненного цикла бизнеса, а в какой-то его субъективной красоте кода.
Для меня это примерно как если бы психолог на сеансе мне сказал, что суть психологии не в том, чтобы помочь клиенту, а в том, что бы за его деньги убедить его в своих(психолога) представлениях о жизни.
Это заблуждение. Хорший код может заменить ЧАСТЬ документации. Тольку ту, которая предназначена непосредственно для разработчиков. А это далеко не ВСЯ документация. Не говоря уж о том, что лазить по условному файлу routes.php вместо того, чтобы открыть привычный Swagger - такое себе удовольствие. А это пример именно разработческой документации, которую по вашему может заменить код. Может. И из буханки хлеба трамвай можно сделать, да, но зачем?
Вы пытаетесь опровергнуть мой тезис о том, что тесты и документации в крупной корпорации должны быть везде словами:
> Всякие канареечные релизы (тест на проде), автотесты препрода и т.д. снижают риски
ТАК Я ЖЕ ОБ ЭТОМ И ГОВОРЮ!! Снижают риски вводя девопс подход, при котором НЕЛЬЗЯ мержить ветку без код ревью. Снижают риски написанием тестов и не только модульных, а еще и функциональных, интеграционных и всяких других) Корпорации не снижат количество стандартов и бюрократии, а как раз таки повышают. Даже по вашим же словам комментом выше)
Вот с годами развития IT-индустрии, выяснилось, что в проектах с большой историей и большим количеством разработчиков эти "риски" выстреливают часто. По этой причине и придуманы все эти практики вроде document first, TDD, CI\CD, code review и прочее. Неужели так сложна мысль о том, что все это придумали не потому что работы было маловато, а как раз наоборот?)
Программа это некий исполняемый файл. Что значит исполняемый файл? То, что он содержит набор инструкций, который может быть выполнен компьютером. Должен ли этот набор инструкций быть понятень человеку? Нет! В моем понимании машинный код не является кодом в том смысле, в котором идет рассуждение в статье. Его уж точно нельзя назвать ни легко изменяемым, ни легко читаемым.
Бизнес не интересует и не должен интересовать КОД вообще ни в каком виде. И про изменяемость вы подменяете понятия. Бизнесу пофигу насколько легко изменять код, его интересует, насколько программа может быстро и легко адаптироваться к новым бизнес-требованиям. Программма может адаптироваться к новым бизнес-требованиям без измнения в коде. Код никого, кроме непосредственно программиста вообще не интересует. Если завтра придумают инструмент, где ты не пишешь код, а рисуешь блок-схемы в Figma и из этого получаешь рабочие программы, все внезапно перейдут на такой инструмент - то и программисты про код забудут.
Мимо 12 лет в IT и если честно, в этом комментарии вы написали полную херню, уж простите. Начнем с того, что системный аналитик и девопс - это НЕ рост разработчика. Вы как HR наверное понимаете, что Senior разработчик получает не меньше Senior DevOps/Senior Analyst. Это просто горизонтальная ротация, смена специализации.
К статье. Я искренне не понимаю, почему опыт ТЕСТИРОВЩИКА или АНАЛИТИКА должен предшествовать опыту ПРОДАКТА? Ну вы это серьезно? Где вы это берете? Product менеджер - отдельная специальность, можно начать сразу с этого став, внезапно, Junior Product Manager. И такой каши в вашей статье и картинках пруд пруди. Вы выдаете горизонтальную ротацию за рост. Это не так. Если я был Senior разработчиком, а стал Senior тестировщиком, или, скажем, Senior Project manager'ом - я НЕ вырос. Это как говорить, что из дизайнера сайтов можно вырасти в дизайнера упаковок.
Тогда стоило бы явно об этом сказать, как минимум. Мол, забиваем на все вокруг: бизнес, менеджеров, требования и говорим о сферическом написании кода в вакууме. Но нет. Этой оговорки тут не наблюдается
Потому что формально он ничем и не владел?))
Статья прикольная, с интересом прочитал, но все таки, я бы реально добавил в нее критику, а то выглядит как реклама(хоть я и не думаю, что это она). А с критикой статья будет еще полезней и интересней
Что если для написании программы вам нужно не код писать, а, например, рисовать картинку, или танцевать? Процесс создания такой программы(рисование\танец) уже не будет являться программированием? По моему будет. Будет ли его результат кодом? Ну нет же(если только машинным на выходе). То есть получается, код все-таки не является целью и результатом программирования?
Очень рекомендую попробовать Miro) Там можно собрать решение на любой вкус, в связке с Notion получите вообще ракету)
Так никто не спорит с тем, что копать нужно! Но лучше копать в то, что интересно, а не во все подряд. Ну или хотя бы в то, что нужно, как вы сказали) По этому и говорю, что пример с планировщиком - хороший. Особенно, например, для разработчика смарт-контрактов на Solidity. Там вот это прям вообще бесполезное знание, вообще никак и ни на что не повлияет и повлиять не может. А для кого-то другого это может быть частью ежедневной работы
Это бесполезный диалог, вы меня не слышите :)
Я ни в коем случае не несу посыл "пофиг, как оно работает". Я говорю о том, что в каждом моменте можно копать очень глубоко и жизни не хватит, чтобы все раскопать даже до атомов, не то что до кварков. Пример с планировщиком ОС отличный именно потому, что это вообще никак не влияет на код, который я пишу на питоне. Именно по этому мне не важно, как это работает. Это уже инкапуслировано, я пользуюсь интерфейсом. Все. Зачем тебе знание, которое никак не влияет на твои дейсвтия?
Абстракции над этим всем, слава богу, придумали разработчики языков программирования, виртуальных машин, библиотек и прочие умные люди, которым это все очень интересно. А мне интересно бизнес-задачи решать. Еще раз повторю: я неплохо знаю, как все устроено) И свой язык программирования в универе делал и Таненбаума читал, так что не пойму при чем здесь ребенок\не ребенок. При этом я еще раз повторяю, что эти знания в работе были не более полезны, чем аэродинамика. Даже более страшную вещь скажу, для того, чтобы быть бэкенд-разработчиком сегодня, чаще всего не обязательно даже знать как работает TCP/IP, достаточно понимания HTTP.
Вы вот используете буквы и слова, предложения складываете, а понимаете при этом что такое фонемы и морфемы? Похоже на позицию ребенка, знаете ли. Или вот вы чай завариваете, а понимаете ли все химические и физические процессы, которые при этом происходят? А вы уверены?
Абстракции для того и нужны, что бы для того, чтобы писать на любимом питухончике не нужно было уметь в уме переводить питон в ассемблер, а ассемблер в машинный код, понимаете о чем я? Я перекладываю JSON из запроса в базу данных и отдаю какой-то другой JSON в ответе. Похеру мне на планировщик операционный системы на работе, честно!
Это я говорю при том, что я интересовался тем, как все и работает и книжки читал, но эта информация была полезна мне в работе не больше, чем знание аэродинамики.
Все верно, с этим никто не спорит, тезис про time-to-market это никак не отменяет. Нас одинково интересует time-to-market как изменения старых фич, так и добавления новых, так и удаления) Это очевидно.
Хорошо, но как игнорирование тестов в определенной ситуации, или, например, непрохождение code-review улучшает показатели write/read/modify?
Абсолютно верно. Но упущена КРИТИЧЕСКАЯ деталь. Бизнес бывает разный. Это не единая сущность. И у разного бизнеса мало того, что есть разные потребности, бывают еще и разные стадии жизненного цикла. Невероятно странно было бы использовать теже подходы, что используются при разработке банковского ПО для создания лендинга сельского цветочного магазина, не так ли?
Тут все верно, но опять же нужно уточнить, что понятие "эффективно" для каждой бизнес-задачи будет свое. У всех будут свои метрики. Именно из-за этого уточнения ломается следующая часть утверждения.
Далеко не всему бизнесу нужна поддержка ПРОДОЛЖИТЕЛЬНОЕ время. В качестве самого яркого примера я приведу стартап. Вот вы с другом сели и придумали классную идею проекта. Какой бы классной она ни была, с вероятностью примерно в 95% она никому кроме вас с другом нахер не нужна. На этом этапе ваша бизнес-задача не состоит в том, чтобы создать легко поддерживаемый продукт с высоким качеством кода. Почему? Потому что это существенно удорожает разработку именно на ранних стадиях проекта. А у вас нет еще ни одного клиента, прибыли и вы не знаете, сможете ли вообще отбить свои затраты на разработку. Оверинжиниринг на этом этапе - крайне распространенная причина провала проекта вообще. Многие просто даже до рынка не доходят.
При всем при этом, есть компания, ну, скажем Ericson, которая поставляет в том числе софт для вышек сотовой связи с каких-то бородатых годов, когда еще JavaScript даже в зародыше не было. Очевидно, что в такой корпорации для того софта, подходы к разработке должны быть совершенно иные. И там как раз нельзя делать все то, о чем тут пишет автор. Там надо именно что СТРОГО придерживаться принятых стандартов.
По причинам, которые я описал выше, я поставил автору минус. Автор посчитал, что суть программирования не в том, что приносить пользу бизнесу исходя из задач, потребностей и жизненного цикла бизнеса, а в какой-то его субъективной красоте кода.
Для меня это примерно как если бы психолог на сеансе мне сказал, что суть психологии не в том, чтобы помочь клиенту, а в том, что бы за его деньги убедить его в своих(психолога) представлениях о жизни.
Какие фреймворки? Наверное красивые))
Да и хер бы с ним, если с ОС не работаешь) А - абстракции
Или вы? В статье ведь речь не про продукт, а про код. Нужно ли объяснять, что продукт и код это вообще разные вещи?
Это заблуждение. Хорший код может заменить ЧАСТЬ документации. Тольку ту, которая предназначена непосредственно для разработчиков. А это далеко не ВСЯ документация. Не говоря уж о том, что лазить по условному файлу routes.php вместо того, чтобы открыть привычный Swagger - такое себе удовольствие. А это пример именно разработческой документации, которую по вашему может заменить код. Может. И из буханки хлеба трамвай можно сделать, да, но зачем?
Вы пытаетесь опровергнуть мой тезис о том, что тесты и документации в крупной корпорации должны быть везде словами:
> Всякие канареечные релизы (тест на проде), автотесты препрода и т.д. снижают риски
ТАК Я ЖЕ ОБ ЭТОМ И ГОВОРЮ!! Снижают риски вводя девопс подход, при котором НЕЛЬЗЯ мержить ветку без код ревью. Снижают риски написанием тестов и не только модульных, а еще и функциональных, интеграционных и всяких других) Корпорации не снижат количество стандартов и бюрократии, а как раз таки повышают. Даже по вашим же словам комментом выше)
Вот с годами развития IT-индустрии, выяснилось, что в проектах с большой историей и большим количеством разработчиков эти "риски" выстреливают часто. По этой причине и придуманы все эти практики вроде document first, TDD, CI\CD, code review и прочее. Неужели так сложна мысль о том, что все это придумали не потому что работы было маловато, а как раз наоборот?)
Программа это некий исполняемый файл. Что значит исполняемый файл? То, что он содержит набор инструкций, который может быть выполнен компьютером. Должен ли этот набор инструкций быть понятень человеку? Нет! В моем понимании машинный код не является кодом в том смысле, в котором идет рассуждение в статье. Его уж точно нельзя назвать ни легко изменяемым, ни легко читаемым.
Бизнес не интересует и не должен интересовать КОД вообще ни в каком виде. И про изменяемость вы подменяете понятия. Бизнесу пофигу насколько легко изменять код, его интересует, насколько программа может быстро и легко адаптироваться к новым бизнес-требованиям. Программма может адаптироваться к новым бизнес-требованиям без измнения в коде. Код никого, кроме непосредственно программиста вообще не интересует. Если завтра придумают инструмент, где ты не пишешь код, а рисуешь блок-схемы в Figma и из этого получаешь рабочие программы, все внезапно перейдут на такой инструмент - то и программисты про код забудут.
Добавлю, что большинство упавших продов в моей жизни начиналось именно с да я тут только одну строчку поменял, ревью можно не делать