Перевод. Но как же я согласен с автором. Код должен быть понятным.
У меня ещё с первой книги (стоит в шкафу, если что) вызывало недоумение использование общего состояния и сверхмалых функций.
Когда я начал использовать их, оказалось, что читать код нисколько не проще, а даже сложнее. То что могло быть просто быть просто строчкой кода, теперь вызов функции. И я не знаю, что она там меняет. В итоге, только полное чтение всего кода.
Идеи Мартина не прошли проверки временем и практикой.
А вот чистые функции - это сила. Они снижают нагрузку на мозг, потому что функцию можно заменить результатом вычисления от того, что ты видишь в вызове
Ссылочная прозрачность — свойство, при котором замена выражения на вычисленный результат этого выражения не изменяет желаемых свойств программы
В общем играем в игру. Сотрудник: я мегакрут, но рассказывать про это не буду и так понятно. HR: я ничего не понимаю, просто скажи мне то, что требуется по вакансии, я потом метчи посчитаю.
А истина где-то посередине.
Что я понял из статьи как соискатель: на разные вакансии нужны разные люди, На собесе нужно показать, что ты именно тот человек. Не вижу никаких сложностей, если вакансия действительно подходит. В противном случае придётся врать.
нравится самое начало жизненного цикла проекта или поддержка?
нравится разбираться неопределённостью или задача должна быть проработана аналитиком?
нравится работать в ширину или в глубину?
Ответы на эти вопросы у всех разные и должности требуют разного. Если без разницы, то отвечаешь, то что соответствует вакансии. Если что-то важно, то говоришь об этом, чтобы потом не жалеть.
В этом конкретном случает ничего не мешает, это была иллюстрация.
Просто придётся писать методы расширения для каждого метода, который мы хотим вызвать в цепочке и нет никакого общего метода их вызова в цепочке. Для коллекции есть, а для одиночных значений нет. А бывают случаи, когда иметь такой синтаксис было бы удобно.
Для коллекции я могу сделать orders.Select(ToDto), а для одиночного значения ничего такого нет, будь добр вызывать ToDto(order).
Более того, для коллекции я могу вызывать цепочку селектов, сделал несколько преобразований над объектом, а для одиночного объекта, приходится делать матрёшку вызовов или использовать промежуточные переменные.
Мой опыт говорит, что ИИ для кодилова хорош в двух случаях:
Нам без разницы какой код мы получим. Походит для маленьких программ, желательно, работающих в закрытом контуре.
Мы точно знаем какой код (конфиг) хотим получить и можем его свалидировать. Подходит для проектов любого масштаба.
А вот если мы делаем что-то больше и не можем свалидировать результат, то в какой-то момент всё начнёт рассыпаться, а ИИ будет ходить по кругу, исправляя одно и ломая другое. К тому же мы не знаем фигня ли написана или нет.
Безумная идея: ноносервисы! ещё более маленькие сервисы полностью написанные нейронками по требованиям и архитектура учитывающая, что сервисы могут работать плохо.
У меня была похожая задача, сначала тоже хотел json сохранять, но потом подумал, что читать целиком его всё равно никто не будет, зато нужно несколько приседаний при записи и чтении, что видно в статье. И всё ради чего? Ради того, чтобы это был валидных json. Автору нужно поддержать старый контракт, а я перешёл на .jsonl, в котором каждый айтем данных хранится на отдельной строке в файле в виде цельного json-объекта.
Даже курсорное чтение из s3 прикрутил, когда АПИ вместе с данными возвращало смещение в файле, чтобы можно было батчами вычитать все данные.
А если рядом положить файл с смещением каждой, скажем, каждой сотой строки, то вообще с произвольного места читать можно будет :D
Одно дело, когда коммитится багфикс в две строчки (отдельный вопрос зачем там ревью).
Обычно после таких багфиксов прод и ложится :)
состоял из десятка новых таблиц в БД и набора новых классов логики
Тут, действительно, понадобится выделить отдельное время. Стараюсь до такого не доводить. Если задачи большая, то создают ветку в которую через ревью мержу этапы работы.
Стив Макконел в книге совершенный код приводил такую статистику:
Software testing alone has limited effectiveness — the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent.
Одно лишь тестирование программного обеспечения имеет ограниченную эффективность: средний уровень обнаружения дефектов составляет всего 25% для модульного тестирования, 35% для функционального и 45% для интеграционного тестирования. В то же время, средняя эффективность проверок дизайна и кода составляет 55 и 60%.
Мы ленивые. Если дойдёт до 4-х коммитов, значит проблема важная. На практике будет: 1й говорит: а может быть сделать по другому? Бах коммит 2й говорит: вот тебе не пофиг, апрув.
Перевод. Но как же я согласен с автором. Код должен быть понятным.
У меня ещё с первой книги (стоит в шкафу, если что) вызывало недоумение использование общего состояния и сверхмалых функций.
Когда я начал использовать их, оказалось, что читать код нисколько не проще, а даже сложнее. То что могло быть просто быть просто строчкой кода, теперь вызов функции. И я не знаю, что она там меняет. В итоге, только полное чтение всего кода.
Идеи Мартина не прошли проверки временем и практикой.
А вот чистые функции - это сила. Они снижают нагрузку на мозг, потому что функцию можно заменить результатом вычисления от того, что ты видишь в вызове
Очень хорошая статья на тему Функциональное программирование — это не то, что нам рассказывают.
И вообще, Хватит писать «чистый» код. Пора писать понятный код
Опять работать...
В общем играем в игру.
Сотрудник: я мегакрут, но рассказывать про это не буду и так понятно.
HR: я ничего не понимаю, просто скажи мне то, что требуется по вакансии, я потом метчи посчитаю.
А истина где-то посередине.
Что я понял из статьи как соискатель: на разные вакансии нужны разные люди, На собесе нужно показать, что ты именно тот человек.
Не вижу никаких сложностей, если вакансия действительно подходит. В противном случае придётся врать.
Первое сложное и неочевидно, а вот через плитку реально наглядно.
И мы его проходили в школе.
Если у меня коллекция xxx, то я могу последовательно вызывать преобразования, потому что за меня написали кучу методов расширения.
Если у меня только 1 элемент xxx, то я так не могу, т.к. никто не написал готовых метод, и приходится писать свой. Выглядит не консистентно.
А ещё лучше иметь на уровне языка поддержку pipe оператора, чтобы отладка нормально работала.
Мы все работаем работу за деньги, но подскажи:
нравится самое начало жизненного цикла проекта или поддержка?
нравится разбираться неопределённостью или задача должна быть проработана аналитиком?
нравится работать в ширину или в глубину?
Ответы на эти вопросы у всех разные и должности требуют разного.
Если без разницы, то отвечаешь, то что соответствует вакансии.
Если что-то важно, то говоришь об этом, чтобы потом не жалеть.
В этом конкретном случает ничего не мешает, это была иллюстрация.
Просто придётся писать методы расширения для каждого метода, который мы хотим вызвать в цепочке и нет никакого общего метода их вызова в цепочке. Для коллекции есть, а для одиночных значений нет. А бывают случаи, когда иметь такой синтаксис было бы удобно.
Допустим, есть функция ToDto.
Для коллекции я могу сделать orders.Select(ToDto), а для одиночного значения ничего такого нет, будь добр вызывать ToDto(order).
Более того, для коллекции я могу вызывать цепочку селектов, сделал несколько преобразований над объектом, а для одиночного объекта, приходится делать матрёшку вызовов или использовать промежуточные переменные.
Мы вот для коллекции используем линку через методы расширения, а для одиночных значений так нельзя :(
Поэтому написал свой Pipe оператор.
Выглядит так: `order?.Pipe(ExtractData) ?? EmptyData();`
Видимо слава питона не даёт покоя. Тоже хотят, чтобы программы распространялись копипастой
А чего этот человек не умеет?
Grappl оказывается платный.
Я думал это кто-то сделал чисто поиграться.
Такой же опыт с кодиловом по аналогии: хорошо делает, главное показать как надо.
Особенно смешно, что разрабы начали писать документацию, потому что не хотят объяснять нейронке одно и то же :D
Мой опыт говорит, что ИИ для кодилова хорош в двух случаях:
Нам без разницы какой код мы получим. Походит для маленьких программ, желательно, работающих в закрытом контуре.
Мы точно знаем какой код (конфиг) хотим получить и можем его свалидировать. Подходит для проектов любого масштаба.
А вот если мы делаем что-то больше и не можем свалидировать результат, то в какой-то момент всё начнёт рассыпаться, а ИИ будет ходить по кругу, исправляя одно и ломая другое. К тому же мы не знаем фигня ли написана или нет.
Безумная идея: ноносервисы! ещё более маленькие сервисы полностью написанные нейронками по требованиям и архитектура учитывающая, что сервисы могут работать плохо.
У меня была похожая задача, сначала тоже хотел json сохранять, но потом подумал, что читать целиком его всё равно никто не будет, зато нужно несколько приседаний при записи и чтении, что видно в статье. И всё ради чего? Ради того, чтобы это был валидных json. Автору нужно поддержать старый контракт, а я перешёл на .jsonl, в котором каждый айтем данных хранится на отдельной строке в файле в виде цельного json-объекта.
Даже курсорное чтение из s3 прикрутил, когда АПИ вместе с данными возвращало смещение в файле, чтобы можно было батчами вычитать все данные.
А если рядом положить файл с смещением каждой, скажем, каждой сотой строки, то вообще с произвольного места читать можно будет :D
Обычно после таких багфиксов прод и ложится :)
Тут, действительно, понадобится выделить отдельное время. Стараюсь до такого не доводить. Если задачи большая, то создают ветку в которую через ревью мержу этапы работы.
В любом случае - это прекрасный повод завести код стайл :) Прийти и задушнить всех.
А потом стать тимлидом и выдвигать свои требования.
Стив Макконел в книге совершенный код приводил такую статистику:
По ощущению, бьётся с реальностью?
Мы ленивые. Если дойдёт до 4-х коммитов, значит проблема важная.
На практике будет:
1й говорит: а может быть сделать по другому? Бах коммит
2й говорит: вот тебе не пофиг, апрув.
Это умная лампочка с WiFI и на ней лучше запускать сервер, чем дум.
энтузиаст взял XXX и показал как на нём что-нибудь запустить на примере YYY.
Короче, новость про "запустил", а не про "майнкрафт".