Привет!
Ну чтож. У меня наконец-то оглушительный успех с 100%-вайбкодингом.
Знакомьтесь - Gvido - Gnome VIbecoded toDO [manager] - это менеджер задач для Gnome Activities overview.
Его ключевая особенность в том, что он повторяет сильные стороны UX-а бумажных заметок на мониторе, но лишён их недостатков.
Про него нельзя забыть, потому что он постоянно мозолит глаз. Но при этом он не занимает рабочее пространство на мониторе. И задачи не отклеиваются.
Плюс для тех кому привычнее клавиатура, сохранить задачу в Гвидо проще и быстрее, чем записать её на заметку.
У виджета куча фич:
1. "Свободные" задачи и списки задач с добавлением, удалением, раскрытием, перемещение драгНдропом и добавлением подзадач
2. Комментарии к задачам
3. Возможность управления чисто с клавиатуры
4. Отмена удаления задач и списоков и редактирования текста
5. ресайз
6. Доступность: поддержка экранного чтения, увеличенного размера шрифта и высокой контрастности
Сделал я его на 100% вайбкодингом. Фреймворки-шмеймворки, спеки-шмеки, харнесы-шмарнесы - фигня всё это, должен я вам признаться 😂
Началось всё с чата в вебе с поиском такой штуки. Гопатыч не нашёл и говорит - "Дай закодим?".
Я говорю - а давай. И он закодил прототип прям в чате.
Пару итераций в чате, потом открыл директорию в кодексе, ещё гора итераций в духе "Добавь подзадачи", "Выровняй кнопки по вертикали" и вуаля, Гвидо готов.
Календарно у меня ушло на это примерно 11-13 часов (со вчерашнего обеда). часов 8-10 из них - это фоновый режим пока яработал погонял агентов, делающих основную работу и возился с детьми.
В кодексе сначала писала terra, потом она упёрлась в баг, что комменты к задачам при раскрытии рендерелилсь чёрным пятном. За 3-4 итерации не смогла решить. Сол-5.6 тоже не смог решить. А Астра - смогла. После чего я перешёл на новый 6-sol, который щяс стоит как 5.6-terra.
Про код могу сказать только одно - там один файл на 1800 js-строк, в которых я не в зуб ногой. И я хз что там с перформансом IO и UI и надёжностью хранения данных.
Ну и да, сегодня мне эта дура Гном уже умудрилась повесить и с первой попытки 6-сол не понял в чём проблема. Но пока не критично😄
А вообще в том и затея - попробую так пожить и посмотреть упрусь ли я на этом котике в тупик из-за техдолга.
Ещё в этой связи стоит сказать, что скорость обратной связи и формирования продукта в целом и и создания целостного продукта (а не только АПИ к бэку) - окрыляет, это чистый дофамин, советую попробовать:)
Может и хер с ним, какой там код внутри. Лишь бы не упереться в баги, которые даже астра не может починить 😂 И тормоза. И потерю данных
С учётом того, что виджет полезен только пользователям Gnome, которые активно используют Activity overview, пригодится он может паре человек максимум, но если вдруг вы из них - попробуйте, расскажите о впечатлениях:)
#ai@ergonomic_code #tools@ergonomic_code
Подписывайтесь: VK | MAX
Ну чтож. У меня наконец-то оглушительный успех с 100%-вайбкодингом.
Знакомьтесь - Gvido - Gnome VIbecoded toDO [manager] - это менеджер задач для Gnome Activities overview.
Его ключевая особенность в том, что он повторяет сильные стороны UX-а бумажных заметок на мониторе, но лишён их недостатков.
Про него нельзя забыть, потому что он постоянно мозолит глаз. Но при этом он не занимает рабочее пространство на мониторе. И задачи не отклеиваются.
Плюс для тех кому привычнее клавиатура, сохранить задачу в Гвидо проще и быстрее, чем записать её на заметку.
У виджета куча фич:
1. "Свободные" задачи и списки задач с добавлением, удалением, раскрытием, перемещение драгНдропом и добавлением подзадач
2. Комментарии к задачам
3. Возможность управления чисто с клавиатуры
4. Отмена удаления задач и списоков и редактирования текста
5. ресайз
6. Доступность: поддержка экранного чтения, увеличенного размера шрифта и высокой контрастности
Сделал я его на 100% вайбкодингом. Фреймворки-шмеймворки, спеки-шмеки, харнесы-шмарнесы - фигня всё это, должен я вам признаться 😂
Началось всё с чата в вебе с поиском такой штуки. Гопатыч не нашёл и говорит - "Дай закодим?".
Я говорю - а давай. И он закодил прототип прям в чате.
Пару итераций в чате, потом открыл директорию в кодексе, ещё гора итераций в духе "Добавь подзадачи", "Выровняй кнопки по вертикали" и вуаля, Гвидо готов.
Календарно у меня ушло на это примерно 11-13 часов (со вчерашнего обеда). часов 8-10 из них - это фоновый режим пока я
В кодексе сначала писала terra, потом она упёрлась в баг, что комменты к задачам при раскрытии рендерелилсь чёрным пятном. За 3-4 итерации не смогла решить. Сол-5.6 тоже не смог решить. А Астра - смогла. После чего я перешёл на новый 6-sol, который щяс стоит как 5.6-terra.
Про код могу сказать только одно - там один файл на 1800 js-строк, в которых я не в зуб ногой. И я хз что там с перформансом IO и UI и надёжностью хранения данных.
Ну и да, сегодня мне эта дура Гном уже умудрилась повесить и с первой попытки 6-сол не понял в чём проблема. Но пока не критично
А вообще в том и затея - попробую так пожить и посмотреть упрусь ли я на этом котике в тупик из-за техдолга.
Ещё в этой связи стоит сказать, что скорость обратной связи и формирования продукта в целом и и создания целостного продукта (а не только АПИ к бэку) - окрыляет, это чистый дофамин, советую попробовать:)
Может и хер с ним, какой там код внутри. Лишь бы не упереться в баги, которые даже астра не может починить 😂 И тормоза. И потерю данных
С учётом того, что виджет полезен только пользователям Gnome, которые активно используют Activity overview, пригодится он может паре человек максимум, но если вдруг вы из них - попробуйте, расскажите о впечатлениях:)
#ai@ergonomic_code #tools@ergonomic_code
Подписывайтесь: VK | MAX
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - d-r-q/gvido: Карточка со списком дел и заметками в правом верхнем углу GNOME Activities overview.
Карточка со списком дел и заметками в правом верхнем углу GNOME Activities overview. - d-r-q/gvido
🔥7🎉3
Привет!
Я жив и даже что-то делаю по ЭП и ErgocodeAi, но пока окончательно распихать всю толпу своих любых детей по садам и няням не выходит, поэтому на канал и блог времени ещё нет.
Поэтому вот вам мемасик на злобу дня:)
Я жив и даже что-то делаю по ЭП и ErgocodeAi, но пока окончательно распихать всю толпу своих любых детей по садам и няням не выходит, поэтому на канал и блог времени ещё нет.
Поэтому вот вам мемасик на злобу дня:)
GitHub
Тестовые HTTP-клиенты переведены на актуальный гайдлайн · ergonomic-code/Project-Mariotte@bed9246
Новая схема позволяет в общем случае:
1. За счёт свойств расширения избавиться от бесконечного роста и тотального знания ролевых клиентов (Guest)
2. За счёт базового ApiSession легко переключаться ...
1. За счёт свойств расширения избавиться от бесконечного роста и тотального знания ролевых клиентов (Guest)
2. За счёт базового ApiSession легко переключаться ...
❤3
А, ну и раз такая пьянка, то за одно ещё одна линка на альтернативный подход к архитектуре: Асимметрия модульного монолита, и там даже есть ссылка на бесплатную книгу, которую ещё не дочитал, поэтому не сформировал своё мнение окончательно.
Во многом мы с автором сходимся, но расходимся в условиях (у него есть та самая сложная бизнес-логика, которой у меня нет) и предпочтениях (он нашёл своё счастье в ООП и богатой доменной модели, в отличие от меня).
Во многом мы с автором сходимся, но расходимся в условиях (у него есть та самая сложная бизнес-логика, которой у меня нет) и предпочтениях (он нашёл своё счастье в ООП и богатой доменной модели, в отличие от меня).
❤2
Эргономичный код
А, ну и раз такая пьянка, то за одно ещё одна линка на альтернативный подход к архитектуре: Асимметрия модульного монолита, и там даже есть ссылка на бесплатную книгу, которую ещё не дочитал, поэтому не сформировал своё мнение окончательно. Во многом мы с…
Блин. Я дочитал. И тотально разочаровался. Автор просто придумал JPA/Hibernate/NHibernate на ручной тяге поверх EntityFramework и передачу списка вообще всех репозов в методы сущностей/агрегатов/бизнес-логики. По сути, книга о том, как сделать производительность большого императивного кома грязи сносной, если ты хочешь остаться в ОО, но не знаешь про хибер. Не рекомендую к прочтению.
Имхо, моя идея что лучше перестать пытаться натянуть ежа на глобус и признать, что сущность на самом деле живёт в БД, а объекты в памяти программы - это просто временные слепки-суррогаты этой сущности на момент запроса - будет пооригинальнее и даёт больше пользы для снижения когнитивной нагрузки и повышения поддерживаемости кода.
Собственно отрывок из черновика статьи Модель неизменяемых реляционных данных с чуть более подробным описанием идеи:
PS>
Вот и пиши после этого книги, чтобы аноны в интернетах их обсирали 🤦♂️🤣
Имхо, моя идея что лучше перестать пытаться натянуть ежа на глобус и признать, что сущность на самом деле живёт в БД, а объекты в памяти программы - это просто временные слепки-суррогаты этой сущности на момент запроса - будет пооригинальнее и даёт больше пользы для снижения когнитивной нагрузки и повышения поддерживаемости кода.
Собственно отрывок из черновика статьи Модель неизменяемых реляционных данных с чуть более подробным описанием идеи:
Для того чтобы справиться с этим несовершенством реального мира, функциональные программисты-практики идут на компромисс - они допускают появление в системе изменяемых объектов, но минимизируют количество их экземпляров, и делают изменяемыми не сами записи, а их коллекции (репозитории).
И в этом случае сущность обретает для себя вполне конкретный дом - ячейку в коллекции идентифицируемой ключём этой сущности. То есть сущность инкапсулирована внутри коллекции - вы можете запросить её текущее состояние, но изменить это состояние вы можете только через коллекцию.
Обратите внимание на то, насколько близка эта модель к тому, как действительно работают современные БД - данные хранятся на диске организованными записи, которые ссылаются друг на друга по ключу. И эти записи инкапсулированы внутри базы данных - вы можете запросить их текущее состояние в свой процесс, но это будет лишь копия не связанная с оригиналом и для того чтобы изменить оригинал, вам надо попросить об этом БД.
PS>
Вот и пиши после этого книги, чтобы аноны в интернетах их обсирали 🤦♂️🤣
Эргономичный подход
Модель неизменяемых реляционных данных (v1.0.0)
см. "Immutable Relational Data" by Richard Feldman
Черновик №1 Функциональные программисты используют, вы не поверите, самую обычную модель информации, в которой информация организована в записи - наборы пар атрибут-значение, соответствующие определённым…
Черновик №1 Функциональные программисты используют, вы не поверите, самую обычную модель информации, в которой информация организована в записи - наборы пар атрибут-значение, соответствующие определённым…
❤3👍3
Не, ну кстати, справедливости ради, есть у автора одна любопытная идея.
Чтобы защитить инварианты сущности, автор предлагает делать конструктор приватным, я для создания экземпляров делать внутренний интерфейс, у которого есть протектед метод, который делегирует вызов в конструктор:
В оригинальном виде, правда, это половинчатое решение - этот интерфейс может реализовать кто угодно и создать сущность без проверки инвариантов. И в шарпе (по словам гопатыча), нет возможности это как-то залечить. Зато в Котлине есть.
interface можно сделать sealed и тогда его реализовать можно будет только в той же директории.
Правда в котлине нельзя сделать протектед метод в интерфейсе, но можно сделать sealed класс.
В итоге получается такая конструкция:
На самом деле, в моём мире простых решений для простых круд приложений я вообще на эту тему не заморачиваюсь - делаю конструктор приватным и Spring Data Jdbc на это пофиг - он его спокойно зовёт.
Но иногда (раза два за последние годы) мне хочется сделать конструктор приватным, но гору кода фабрики создания сущности вытащить в соседний файл. И раньше я просто забивал на инкапсуляцию и делал конструктор публичным. И никто не умирал.
А вот теперь в третий раз можно будет подумать об использовании этого трюка. И снова решить не городить огород - люблю я, знаете ли, делать вид что я умный и для каждой проблемы рассмотреть два-три варианта решения, прежде чем выбрать самое первое, простое и очевидное 😂
#kotlin@ergonomic_code
Чтобы защитить инварианты сущности, автор предлагает делать конструктор приватным, я для создания экземпляров делать внутренний интерфейс, у которого есть протектед метод, который делегирует вызов в конструктор:
public class Client
{
public interface IRepository : IBaseRepository<Client>
{
protected static Client Restore(
Guid id, string name, string address, Conditions condition)
=> new(id, name, address, condition);
}
private Client(
Guid id, string name, string address, Conditions condition)
{
// ...
}
}
В оригинальном виде, правда, это половинчатое решение - этот интерфейс может реализовать кто угодно и создать сущность без проверки инвариантов. И в шарпе (по словам гопатыча), нет возможности это как-то залечить. Зато в Котлине есть.
interface можно сделать sealed и тогда его реализовать можно будет только в той же директории.
Правда в котлине нельзя сделать протектед метод в интерфейсе, но можно сделать sealed класс.
В итоге получается такая конструкция:
// в файле my_app.clients.Client.kt
class Client private constructor(
val id: UUID,
val name: String,
) {
sealed class Repository {
protected fun restore(id: UUID, name: String) =
Client(id, name)
}
}
// в файле my_app.clients.ClientRepository.kt
class ClientRepository : Client.Repository() {
fun restoreFromDb(id: UUID, name: String) =
restore(id, name)
}
На самом деле, в моём мире простых решений для простых круд приложений я вообще на эту тему не заморачиваюсь - делаю конструктор приватным и Spring Data Jdbc на это пофиг - он его спокойно зовёт.
Но иногда (раза два за последние годы) мне хочется сделать конструктор приватным, но гору кода фабрики создания сущности вытащить в соседний файл. И раньше я просто забивал на инкапсуляцию и делал конструктор публичным. И никто не умирал.
А вот теперь в третий раз можно будет подумать об использовании этого трюка. И снова решить не городить огород - люблю я, знаете ли, делать вид что я умный и для каждой проблемы рассмотреть два-три варианта решения, прежде чем выбрать самое первое, простое и очевидное 😂
#kotlin@ergonomic_code
😁3
Telegram
Эргономичный код
Инженерное совершенство
и детальный анализ
My father-in-law is a builder. It is difficult to get his attention in a magnificent space because he is lost in wonder. We were in a cathedral together years ago and I asked him what it would cost to build it…
и детальный анализ
My father-in-law is a builder. It is difficult to get his attention in a magnificent space because he is lost in wonder. We were in a cathedral together years ago and I asked him what it would cost to build it…
Привет!
Прочитал пост How to be more ambitious: A tutorial for humans with models антропиковского лида разработки Claude.ai, Cowork, и Code Desktop
И там есть совет:
А между тем, если делать нормально, то 200мс - это вполне себе решаемая задача. Для старомодных кожанных мешков, а не мясных прокси, во всяком случае.
Теперь в целом понятно, какой ценой Антропик получают свой кратный рост кол-ва мёржа ПР-ов - ценой моего времени. Клодом не пользуюсь, но за гопатыча могу с уверенностью сказать: он и тормозит, и багов в нём больше, чем звёзд на небе.
А я не хочу жить в мире, где на меня вендоры каждый день вываливают тонны нового шлака, который грузится по 5-10 секунд. Я хочу жить в мире, где мне ведоры через день дают грамм золота, который грузится 200мс.
Не знаю как этого добиться, но буду бороться за то, чтобы вендоры использовали ИИ для повышения качества, а не скорости.
#ai@ergonomic_code
Подписывайтесь: VK | MAX
Прочитал пост How to be more ambitious: A tutorial for humans with models антропиковского лида разработки Claude.ai, Cowork, и Code Desktop
И там есть совет:
Pick unreasonable goals and tell the model that they’re very reasonable: You need your website to load in 5s instead of 10s? Ask for 200ms.
А между тем, если делать нормально, то 200мс - это вполне себе решаемая задача. Для старомодных кожанных мешков, а не мясных прокси, во всяком случае.
Теперь в целом понятно, какой ценой Антропик получают свой кратный рост кол-ва мёржа ПР-ов - ценой моего времени. Клодом не пользуюсь, но за гопатыча могу с уверенностью сказать: он и тормозит, и багов в нём больше, чем звёзд на небе.
А я не хочу жить в мире, где на меня вендоры каждый день вываливают тонны нового шлака, который грузится по 5-10 секунд. Я хочу жить в мире, где мне ведоры через день дают грамм золота, который грузится 200мс.
Не знаю как этого добиться, но буду бороться за то, чтобы вендоры использовали ИИ для повышения качества, а не скорости.
#ai@ergonomic_code
Подписывайтесь: VK | MAX
💯5
Привет!
Я вот уже 6.5 лет работаю с текстами в разных видах - наброски книги, блог, вики, канал, теперь, ещё и контекст для ИИ. Выходило и выходит по-разному, но мне чёт раньше никогда не приходило в голову, что этому надо учиться.
Сейчас я пытаюсь описать для ИИ модель организации инфраструктурного кода для сетапа фикстуры тестов, но выходит не очень хорошо. И размышляя о том как это всё-таки сделать, меня чёрт дёрнул погопатить модель/методику для текстов описывающих модели/методики.
К моему удивлению, оказалось что на самом-то деле есть дофига матчасти, которую можно изучить:
1. Бесплатный курс от гугла по техписательству
2. Книга The Minto Pyramid Principle: Logic in Writing, Thinking and Problem Solving. Есть русский перевод, но ругают за "машинность" и то, что переводчики не разобрались в теме.
3. Книга Ясно, понятно: Как доносить мысли и убеждать людей с помощью слов
4. Diátaxis - фреймворк/архитектура документации.
5. The Science of Scientific Writing - научная статья о том как люди понимают научные статьи
6. Ну и тут ещё стоит упомянуть классическую (в моей картине мира) Пиши, сокращай
И так как на мой взгляд скоро нам всем придётся стать своего рода писателями - берите на вооружение:)
Сам пока только начал читать Diátaxis, поэтому отзывов пока не дам. Надеюсь в этот раз не выйдет как с архитектурой свободных сущностей.
#books@ergonomic_code
Подписывайтесь: VK | MAX
Я вот уже 6.5 лет работаю с текстами в разных видах - наброски книги, блог, вики, канал, теперь, ещё и контекст для ИИ. Выходило и выходит по-разному, но мне чёт раньше никогда не приходило в голову, что этому надо учиться.
Сейчас я пытаюсь описать для ИИ модель организации инфраструктурного кода для сетапа фикстуры тестов, но выходит не очень хорошо. И размышляя о том как это всё-таки сделать, меня чёрт дёрнул погопатить модель/методику для текстов описывающих модели/методики.
К моему удивлению, оказалось что на самом-то деле есть дофига матчасти, которую можно изучить:
1. Бесплатный курс от гугла по техписательству
2. Книга The Minto Pyramid Principle: Logic in Writing, Thinking and Problem Solving. Есть русский перевод, но ругают за "машинность" и то, что переводчики не разобрались в теме.
3. Книга Ясно, понятно: Как доносить мысли и убеждать людей с помощью слов
4. Diátaxis - фреймворк/архитектура документации.
5. The Science of Scientific Writing - научная статья о том как люди понимают научные статьи
6. Ну и тут ещё стоит упомянуть классическую (в моей картине мира) Пиши, сокращай
И так как на мой взгляд скоро нам всем придётся стать своего рода писателями - берите на вооружение:)
Сам пока только начал читать Diátaxis, поэтому отзывов пока не дам. Надеюсь в этот раз не выйдет как с архитектурой свободных сущностей.
#books@ergonomic_code
Подписывайтесь: VK | MAX
Google for Developers
Technical Writing One introduction | Google for Developers
👍6
Привет!
У меня давно, ещё во доИИшную эру на ревью были замечания в духе "Тут написана дичь".
В буквальном смысле.
Например, берёшь код
И мысленно пытаешься превратить его в текст на естественном языке.
Для этого, первым делом разбиваешь все цепочки вызовов:
Превращаешь вызовы методов в английские предложения, сохраняя их смысл: команды — в повелительные предложения с обращением, утверждения и проверки — в повествовательные с подлежащим:
Потом пытаешься прочитать полученное.
И в данном случае видишь дичь — список запросов сам по себе не может авторизовать устройство. Он может лишь свидетельствовать о том, что запрос на авторизацию устройства был выполнен/получен.
Затем пытаешься написать тоже самое, но "по-русски":
Дальше, если хочется, можно ООПизировать этот текст или инкапсулировать проверку:
И потом обратно перевести эти тексты в код:
В данном случае разница невелика — это просто один из свежих примеров.
Но подобные упражнения меня много раз выводили на серьёзные баги (вот, например) или серьёзные архитектурные улучшения.
Идею, что "код должен читаться как книга" я впитал на заре своей карьеры от первого и последнего техлида, которого я считал круче себя:)
И с тех пор я больше ни разу не видел (ну или не припоминаю, по крайней мере), чтобы кто-то ещё проделывал подобные упражнения.
А сейчас пресловутые фронтьирные ИИ-модели пишут подобной дичи ещё больше чем джуны, которые в школе учили немецкий. Поэтому я пошёл добавлять в ErgocodeAi соответствующий рычаг и первым делом пошёл искать, что люди пишут и думают на эту тему. И оказалось, что я не одинок — в гайдлайнах дизайна АПИ Swift-а прямым текстом написано "Prefer method and function names that make use sites form grammatical English phrases" и "Clarity at the point of use is your most important goal".
В общем, вопреки тому, что сейчас со всех углов кричат, что код уже даже и читать не надо — я считаю, что всё ещё надо и внимательно. И вот эта техника — чтение и оценка кода как текста на английском — может находить очень серьёзные косяки, которые более формальными методами ещё сложнее выявить.
#ergo_approach@ergonomic_code
Подписывайтесь: VK | MAX
У меня давно, ещё во доИИшную эру на ревью были замечания в духе "Тут написана дичь".
В буквальном смысле.
Например, берёшь код
externalSystem.getAuthRequests().shouldAuthorizeDevice(deviceSerialNumber)
И мысленно пытаешься превратить его в текст на естественном языке.
Для этого, первым делом разбиваешь все цепочки вызовов:
val authRequests = externalSystem.getAuthRequests()
authRequests.shouldAuthorizeDevice(deviceSerialNumber)
Превращаешь вызовы методов в английские предложения, сохраняя их смысл: команды — в повелительные предложения с обращением, утверждения и проверки — в повествовательные с подлежащим:
External system, get me [list of received] authorization requests
Let authorization requests be the retrieved list of requests.
Authorization requests should authorize the device with serial number X.
Потом пытаешься прочитать полученное.
И в данном случае видишь дичь — список запросов сам по себе не может авторизовать устройство. Он может лишь свидетельствовать о том, что запрос на авторизацию устройства был выполнен/получен.
Затем пытаешься написать тоже самое, но "по-русски":
External system, get me [list of received] authorization requests
Let authorization requests be the retrieved list of requests.
[List of received] authorization requests should contain authorization request for the device with serial number X.
Дальше, если хочется, можно ООПизировать этот текст или инкапсулировать проверку:
External system, verify that an authorization request was received for the device with serial number X.
И потом обратно перевести эти тексты в код:
val authRequests = externalSystem.getAuthRequests()
authRequests.shouldContainAuthRequestForDevice(deviceSerialNumber)
// или
externalSystem.verifyAuthRequestWasReceived(deviceSerialNumber)
В данном случае разница невелика — это просто один из свежих примеров.
Но подобные упражнения меня много раз выводили на серьёзные баги (вот, например) или серьёзные архитектурные улучшения.
Идею, что "код должен читаться как книга" я впитал на заре своей карьеры от первого и последнего техлида, которого я считал круче себя:)
И с тех пор я больше ни разу не видел (ну или не припоминаю, по крайней мере), чтобы кто-то ещё проделывал подобные упражнения.
А сейчас пресловутые фронтьирные ИИ-модели пишут подобной дичи ещё больше чем джуны, которые в школе учили немецкий. Поэтому я пошёл добавлять в ErgocodeAi соответствующий рычаг и первым делом пошёл искать, что люди пишут и думают на эту тему. И оказалось, что я не одинок — в гайдлайнах дизайна АПИ Swift-а прямым текстом написано "Prefer method and function names that make use sites form grammatical English phrases" и "Clarity at the point of use is your most important goal".
В общем, вопреки тому, что сейчас со всех углов кричат, что код уже даже и читать не надо — я считаю, что всё ещё надо и внимательно. И вот эта техника — чтение и оценка кода как текста на английском — может находить очень серьёзные косяки, которые более формальными методами ещё сложнее выявить.
#ergo_approach@ergonomic_code
Подписывайтесь: VK | MAX
Telegram
Эргономичный код
Привет!
Поучительная история о важности именования.
У меня тут джуны недавно в Проекте Э запилили пуши.
И пока ревьювил бэк я там наткнулся на строчку с дип линкой (в которых я не шарю) "myapp://<some-screen>", которая отправляется в МП.
И она мне сразу…
Поучительная история о важности именования.
У меня тут джуны недавно в Проекте Э запилили пуши.
И пока ревьювил бэк я там наткнулся на строчку с дип линкой (в которых я не шарю) "myapp://<some-screen>", которая отправляется в МП.
И она мне сразу…
🔥6❤5💯4👍3
Привет!
В ЭП, да и в ErogocdeAi, грядут серьёзные изменения. Не буду пока раскрывать все карты, но одно из ключевых изменений: я решил всё-таки развести правила работы с продовым кодом, с тестами и ТДД в более-менее независимые части и перетряс под это разделение вики.
У меня средненький наконец-то вышел в сад на полный день, младшенькому вроде нашли (тьфу-тьфу-тьфу) няню, никто не болеет (тьфу-тьфу-тьфу, тук-тук-тук), поэтому есть шанс что я начну потихоньку оживлять канал.
PS>
Плюс решил завести отдельный канал для ИИ-луддизма — подписывайтесь, если вам близка эта тема:) Там как раз и ссылка на жутковатую историю про кодекс подоспела:)
#ergo_approach@ergonomic_code
Подписывайтесь: VK | MAX
В ЭП, да и в ErogocdeAi, грядут серьёзные изменения. Не буду пока раскрывать все карты, но одно из ключевых изменений: я решил всё-таки развести правила работы с продовым кодом, с тестами и ТДД в более-менее независимые части и перетряс под это разделение вики.
У меня средненький наконец-то вышел в сад на полный день, младшенькому вроде нашли (тьфу-тьфу-тьфу) няню, никто не болеет (тьфу-тьфу-тьфу, тук-тук-тук), поэтому есть шанс что я начну потихоньку оживлять канал.
PS>
Плюс решил завести отдельный канал для ИИ-луддизма — подписывайтесь, если вам близка эта тема:) Там как раз и ссылка на жутковатую историю про кодекс подоспела:)
#ergo_approach@ergonomic_code
Подписывайтесь: VK | MAX
Эргономичный подход
Способ быстро создавать кодовые базы, которые легко менять для поддержки новых требований
1