Поясните, пожалуйста, как вы решаете вопросы версионировния (кто, что, когда и зачем изменял) и переиспользования (что в трёх разных флоу одну и ту же подзадачу люди не решают сами, кто во что горазд), а так же проблему наращивания сложности графа процесса и нелинейного роста трудоемкости его поддержки?
У вас есть какой-то выделенный "архитектор" и какие-то процессы "кодревью"?
Как по мне, изображение не требует "поддерживаемости" и является законченным результатом. Код - это формализованный процесс, то есть он подразумевает задачу поддержки и модификации (в идеале -за прогнозируемое конечное время)
Может быть, я не специалист. Но, как будто, такое выравнивание приведёт к жуткой фрагментации памяти, что точно нежелательно. Вроде как - менеджеры памяти стараются прямо так уж не хулиганить. Но, повторюсь, не специалист.
Тут ищется число в 4 байта, при этом для того, чтобы его найти, искомая память разбивается на блоки по 4 байта. Как будто это не надёжно, потому что по факту оно может лежать между блоков, два байта в конце одного блока и два байта в начале другого. Или три в конце одного, один в начале следующего.
Как будто тут просто "повезло", что перед искомым числом хлама оказалось аккурат кратно 4 байтам.
Если всегда делать все по обозначенной инструкции - то бизнес не получится. И платить вам за вашу экспертизу будет... нечем.
Веток может быть две. Пуш может быть сразу в мастер. Может не быть пул-реквестов. Есть, например, trunk based development.
Выбор версии технологий не всегда зависит от команды, часто она связана ограничениями, наложенными реализацией пакетных зависимостей.
Про аджайлы и прочие скрамы - один грамотно подготовленный сектант способен полностью парализовать доставку фич. Это будет очень гибко. Но совершенно бесполезно.
Если делать как гугл - гуглом не станешь. Прочитайте про культ карго.
Ну и на счёт любых моделей - модель - не равно явление. Это лишь его описание. И нельзя безапелляционно заявлять про модель, опуская границы применимости.
Как, например, классическая физика работает при скоростях много меньше скорости света и масштабах много больше размера атома. Если приближаться к - там уже релятивистская и квантовая физики соответственно.
Ваши формулировки вредны, если цель в том, чтобы работа коллектива была рентабельна при сохранении человеческого отношения к людям.
Если код содержит много комментариев, то это может означать, что качеству самого кода не уделено достаточно внимания. Например, неудачно разбит на методы(в поле зрения разработчика на попадает весь квант логики, приходиться "комментировать"), заложена большая цикломатическая сложность(поясняем, что происходит в третьем вложенном if), переиспользуются переменные(поясняем, что это теперь уже не строка из БД, как двумя экранами назад, а реконструированный из нее data object), ...
Но это не самая большая беда комментариев. На взрослых проектах кодовая база велика, разработчиков много, задач в трекере много, нельзя гарантировать, что один и тот же разработчик может закрыть навсегда какой-то функционал. Он меняется совместно с нуждами бизнеса, где-то уже переиспользуются. Что-то делается в режиме — "Вася в отпуске, нужно вчера, глянь". В общем, комментарии менять просто забывают. Т.е. в код добавляется потенциально ещё одно место, где человек может ошибиться. А значит — ошибка лишь вопрос времени. В итоге, на существенной части кодовой базы содержание комментариев не соответствует коду. Либо просто бессмысленно в силу того, что нашлось более удачное название представления бизнес-сущности в коде.
Реально полезный кейс — это пояснение выбора той или иной логики решения, введение в контекст. Например, в силу переезда с одного технического решения на другое — появляется временная двойственность Api. Во всех новых реализациях используется новое Api, но вот тут понадобилось поддержать обратную совместимость там, где новое Api ещё не достаточно протестировано/не реализует функционал/… В Git будет видно, что коммит новый, а Api используется старое. В итоге, без осознания — "почему", рефакторинг с заменой на новое — убьет кусок кода и бог его знает, где и когда это всплывёт.
В основном, это нужно редко, ибо профессиональный разработчик либо знает бизнес-домен, либо все равно в процессе разбора и будет спрашивать старших товарищей.
Поясните, пожалуйста, как вы решаете вопросы версионировния (кто, что, когда и зачем изменял) и переиспользования (что в трёх разных флоу одну и ту же подзадачу люди не решают сами, кто во что горазд), а так же проблему наращивания сложности графа процесса и нелинейного роста трудоемкости его поддержки?
У вас есть какой-то выделенный "архитектор" и какие-то процессы "кодревью"?
Как по мне, изображение не требует "поддерживаемости" и является законченным результатом. Код - это формализованный процесс, то есть он подразумевает задачу поддержки и модификации (в идеале -за прогнозируемое конечное время)
Да нет, я прекрасно понимаю, о чем вы) Просто говорю, что это не единственный возможный путь)
Статья не про РФ :) Поэтому есть разные нюансы :)
Только корпорейт может позволить себе писать ТЗ несколько месяцев) В условиях стартапа это почти всегда неуместно :)
Прикачу под новый год - посмотрим. Интересно, что под капотом там получилось.
Отлично! Ребята правильно подсвечивают, что стоит поинтересоваться кодом - но это мы будем делать уже при масштабировании, за деньги заказчика :)
Своими глазами видел систему и процесс, ибо знаком с автором) Меня, как СТО, это все несколько пугает)
Новый уровень абстракции работает. И работает достаточно хорошо, чтобы получить MVP.
Может быть, я не специалист. Но, как будто, такое выравнивание приведёт к жуткой фрагментации памяти, что точно нежелательно. Вроде как - менеджеры памяти стараются прямо так уж не хулиганить. Но, повторюсь, не специалист.
Мне вот не понятно. Поправьте, если не прав.
Тут ищется число в 4 байта, при этом для того, чтобы его найти, искомая память разбивается на блоки по 4 байта. Как будто это не надёжно, потому что по факту оно может лежать между блоков, два байта в конце одного блока и два байта в начале другого. Или три в конце одного, один в начале следующего.
Как будто тут просто "повезло", что перед искомым числом хлама оказалось аккурат кратно 4 байтам.
"devops - это не специалист, а культура" :)
Если всегда делать все по обозначенной инструкции - то бизнес не получится. И платить вам за вашу экспертизу будет... нечем.
Веток может быть две. Пуш может быть сразу в мастер. Может не быть пул-реквестов. Есть, например, trunk based development.
Выбор версии технологий не всегда зависит от команды, часто она связана ограничениями, наложенными реализацией пакетных зависимостей.
Про аджайлы и прочие скрамы - один грамотно подготовленный сектант способен полностью парализовать доставку фич. Это будет очень гибко. Но совершенно бесполезно.
Если делать как гугл - гуглом не станешь. Прочитайте про культ карго.
Ну и на счёт любых моделей - модель - не равно явление. Это лишь его описание. И нельзя безапелляционно заявлять про модель, опуская границы применимости.
Как, например, классическая физика работает при скоростях много меньше скорости света и масштабах много больше размера атома. Если приближаться к - там уже релятивистская и квантовая физики соответственно.
Ваши формулировки вредны, если цель в том, чтобы работа коллектива была рентабельна при сохранении человеческого отношения к людям.
Если код содержит много комментариев, то это может означать, что качеству самого кода не уделено достаточно внимания. Например, неудачно разбит на методы(в поле зрения разработчика на попадает весь квант логики, приходиться "комментировать"), заложена большая цикломатическая сложность(поясняем, что происходит в третьем вложенном if), переиспользуются переменные(поясняем, что это теперь уже не строка из БД, как двумя экранами назад, а реконструированный из нее data object), ...
Но это не самая большая беда комментариев. На взрослых проектах кодовая база велика, разработчиков много, задач в трекере много, нельзя гарантировать, что один и тот же разработчик может закрыть навсегда какой-то функционал. Он меняется совместно с нуждами бизнеса, где-то уже переиспользуются. Что-то делается в режиме — "Вася в отпуске, нужно вчера, глянь". В общем, комментарии менять просто забывают. Т.е. в код добавляется потенциально ещё одно место, где человек может ошибиться. А значит — ошибка лишь вопрос времени. В итоге, на существенной части кодовой базы содержание комментариев не соответствует коду. Либо просто бессмысленно в силу того, что нашлось более удачное название представления бизнес-сущности в коде.
Реально полезный кейс — это пояснение выбора той или иной логики решения, введение в контекст. Например, в силу переезда с одного технического решения на другое — появляется временная двойственность Api. Во всех новых реализациях используется новое Api, но вот тут понадобилось поддержать обратную совместимость там, где новое Api ещё не достаточно протестировано/не реализует функционал/… В Git будет видно, что коммит новый, а Api используется старое. В итоге, без осознания — "почему", рефакторинг с заменой на новое — убьет кусок кода и бог его знает, где и когда это всплывёт.
В основном, это нужно редко, ибо профессиональный разработчик либо знает бизнес-домен, либо все равно в процессе разбора и будет спрашивать старших товарищей.
Такие дела.
Лень считать?)))