Комментарии 18
Что-то я не очень понял на счет треугольника. Разве время и деньги не связаны воедино?
Я бы даже сказал что они все связанны вот так:
Я бы даже сказал что они все связанны вот так:
качество = стоимость / время
Треугольник параметров — это же эталонное «Быстро, качественно, недорого. Выбирайте любые два».
По вашей формуле получается, что дешево, но очень быстро — это качественно.
Ошибаетесь. По этому треугольнику получается, что если быстро и дешево, то качества не будет.
Чем дальше точка от параметра, тем меньшее воздействие он на эту точку оказывает.
Просто качество — лишь одна сторона результата. Согласитесь, что быстро невозможно создать что-то полноценное, получается просто абсурдно, если подставить маленькие цифры.
Каждый сам для себя может умножить время на «коэфицентраздолбайства хаброчитайства»
Каждый сам для себя может умножить время на «коэфицент
Ужасный подход. Если на каждое требование заказчика «хреначить говнокод», чтобы «дешевле» — здесь никакой архитектуры (и по Фаулеру и без него) быть не может. Учитывая, что впоследствие на переделку денег также обычно никто давать не хочет. Сама архитектура приложения должна быть гибкая, чтобы просьба «добавить страницу партнеров» не вызывала у программистов чувство страха.
Недавно проскочило во френдленте:
Недавно проскочило во френдленте:
Я не вижу в статье примеров говнокода. Посыл в ином. Нет смысла вводить новую таблицу и делать админку, если в ближайшей перспективе будет добавлено всего 3 партнера, потому что:
Более того ваш тезис «архитектура должна быть гибкой» не противоречит тому что я написал. Я пишу, что нужно создавать «легко-изменяемый» код. Думаю, что это синоним гибкости. Можете аргументировать, что тут «ужасного» и где здесь «говнокод»?
А то что денег не дадут, если вы не можете обосновать необходимость рефакторинга для бизнеса:
Нужно понимать, если вы не пишете «нефте-газо-добывающий» софт, деньги у клиента не растут на дереве и от успешности его бизенса зависит его возможность платить вам. Программистам свойственно обращать внимание только на код: то, что большинство ваших пользователей и заказчиков даже не может «потрогать руками». Код — это не цель, а средство для приложения. Плохо-структурированный сильно-связанный код содержит ошибки и его сложно расширять, поэтому такие средства не дают достижения цели, но кроме кода есть еще бюджет, юзер-интерфейс, маркетинг, дистрибуция. Попробуйте с нуля разработать и продать свое приложение. Когда ваши доходы будут напрямую зависеть от продаж продукта, а не измеряться в ежемесячной величине.
- Возможно это функционал вообще «не пойдет» и по окончанию контракта нужно будет удалить эти разделы к чертовой бабушке
- Требования могут поменяться кардинально — меньше кода — значит меньше придется переписывать/рефакторить
- Это время можно потратить на какой-либо другой более важный функционал
- <Во второй части я сам пишу, что так нельзя делать бесконечно и в определенный момент нужно сделать рефакторинг… В данном случае рефаторинг сделать достаточно просто.
Более того ваш тезис «архитектура должна быть гибкой» не противоречит тому что я написал. Я пишу, что нужно создавать «легко-изменяемый» код. Думаю, что это синоним гибкости. Можете аргументировать, что тут «ужасного» и где здесь «говнокод»?
А то что денег не дадут, если вы не можете обосновать необходимость рефакторинга для бизнеса:
- Стоит научиться говорить с клиентом на одном языке
- Может быть это действительно рефакторинг ради рефакторинга?
Нужно понимать, если вы не пишете «нефте-газо-добывающий» софт, деньги у клиента не растут на дереве и от успешности его бизенса зависит его возможность платить вам. Программистам свойственно обращать внимание только на код: то, что большинство ваших пользователей и заказчиков даже не может «потрогать руками». Код — это не цель, а средство для приложения. Плохо-структурированный сильно-связанный код содержит ошибки и его сложно расширять, поэтому такие средства не дают достижения цели, но кроме кода есть еще бюджет, юзер-интерфейс, маркетинг, дистрибуция. Попробуйте с нуля разработать и продать свое приложение. Когда ваши доходы будут напрямую зависеть от продаж продукта, а не измеряться в ежемесячной величине.
Все правильно автор говорит. Великий опыт хорошего разработчика и состоит с том, чтобы не лепить горы абстракций там, где не надо, и четко знать, где можно «сговнокодить».
Например, обучая джуниора основам С, нельзя ему даже рассказывать про оператор goto. Опытный же программист знает, как его правильно применить при, скажем, выходе из циклов большой вложенности. Точно также, иногда можно и сговнокодить, если ты хорошо понимаешь что ты делаешь, и если это не скажется на архитектуре всей системы в целом.
Например, обучая джуниора основам С, нельзя ему даже рассказывать про оператор goto. Опытный же программист знает, как его правильно применить при, скажем, выходе из циклов большой вложенности. Точно также, иногда можно и сговнокодить, если ты хорошо понимаешь что ты делаешь, и если это не скажется на архитектуре всей системы в целом.
С ростом приложения возникает опасность сделать его слишком сильно-связанным, а это сделает систему неповоротливой и будет мешать изменению кода.
Не буду в очередной раз описывать, что такое IOC/DI и с чем его едят, просто нужно взять за правило:
Не создавать зависимости явно
Использовать IOC-контейнеры
Явное лучше чем не явное.
IOC-контейнеры не облегчают жизнь, лишь позволяют делать конфигурируемыми некоторые элементы. Втыкать их везде приложение — зло.
А по поводу тестов можно ломать много копий, но чтобы не плодить их слишком много проще всего использовать следующее правило: любое нетривиальное изменение кода должно приводить к тому, что ломается как минимум один и, в идеале, ровно один тест.
Разумеется всегда можно изменить код так, чтобы тесты не порушились, а код перестал работать (можно, например, отдельно обработать варианты, используемые в тестах), но мы же тут не с врагами, а с ошибками боремся. Другая крайность встречается реже, но мне с ней тоже довелось встретится и могу сказать, что току от неё тоже нет: если у вас добавление одного пробела в формат вывода приводит к тому, что падают 100500 тестов, то можете считать, что тестов у вас нет ибо нормальный человек не будет даже разбираться с тем, что произошло, а просто «одним махом» заткнёт их все и даже смотреть на причину их падения особо не будет.
Разумеется всегда можно изменить код так, чтобы тесты не порушились, а код перестал работать (можно, например, отдельно обработать варианты, используемые в тестах), но мы же тут не с врагами, а с ошибками боремся. Другая крайность встречается реже, но мне с ней тоже довелось встретится и могу сказать, что току от неё тоже нет: если у вас добавление одного пробела в формат вывода приводит к тому, что падают 100500 тестов, то можете считать, что тестов у вас нет ибо нормальный человек не будет даже разбираться с тем, что произошло, а просто «одним махом» заткнёт их все и даже смотреть на причину их падения особо не будет.
Если упало много тестов и это невозможно проанализировать — плохо организовано тестирование.
Отличный пример толкового тестирования — SQLite. Да, система изначально писалась для военных целей, но никто не мешает перенять методику. Затратно, но действительно круто.
Отличный пример толкового тестирования — SQLite. Да, система изначально писалась для военных целей, но никто не мешает перенять методику. Затратно, но действительно круто.
Тема затронута достаточно глубокая и интересная. Но, пример кода: короткий, красивый и бессмысленный.
Если на то пошло, то почему бы не сверстать эти же странички в Фронтпейдже, ведь их всего три, и в этом году не будут меняться?
Если на то пошло, то почему бы не сверстать эти же странички в Фронтпейдже, ведь их всего три, и в этом году не будут меняться?
Это пример из реальной жизни. Я переписал код, так как не вправе открывать код приложения. И реальный пример обсуждения. Мой коллега был за то, чтобы «сделать по-правильному» с БД, новой сущностью и т.д. На тот момент уже существовала инфраструктура. Если верстать на фронтпейдже мы будем вынуждены копипастить верстку в 3 файла. В приложении уже есть «нарезанный» лейаут, грех им не воспользоваться. Весь слой представления у нас уже готов, в крайнем случае потребуется добавить пагинацию. Это легко решается добавлением чего-то типа PagedList. Код в представлении останется таким же. А снизу добавится пагинатор. Список, объявленный в коде, гораздо проще отрефакторить в тот или иной персистанс (все поля уже объявлены), чем собирать сущность из трех html-страниц.
Большой пласт, который я не рассмотрел в статье — деплоймент. Суммарную сложность решения нужно рассчитывать в том числе, учитывая этот факт. Например, нужно добавить новый сервис. Можно реализовать его, как компонент, для существующего контейнера ил как самостоятельную службу/демон или захостить на веб-сервере. Возможно, что реализовать отдельную службу проще, но при этом придется менять процесс деплоймента. Но это уже отдельная тема. Автоматический деплой в основном реализуют в основном только «большие» компании/продукты. Пока большая часть разработчиков деплоит «руками» разговаривать об этом просто бесполезно. Из более простых примеров — главная страница приложения. Нужно показывать набор иконок. Можно захардкодить их во вью, а можно сделать запрос к БД. Если набор иконок меняется только с релизами, хранить их во вью проще.
Второй момент: логика, «размазанная» по приложению. Один функционал на уровне Entity, другой — в сервисах, третий — в котнтроллерах. Это, пожалуй, самый сложный момент, который относится больше не к «разработке» как таковой, а скорее к процессуальной составляющей. Все достаточно большие приложения, в разработке которых я принимал участие, так или иначе страдали от этой проблемы. Причем это опыт как на пост-советском пространстве, так и на европейском. Я думаю, что вообще нет серебряной пули, позволяющей избавиться от этой проблемы. Я обычно прошу всех разработиков, как можно раньше сообщать о сложностях связанных именно с дизайном системы, чтобы по возможности быстро провести рефакторинг, таким образом иссекая загнивающие куски в зародыше.
Большой пласт, который я не рассмотрел в статье — деплоймент. Суммарную сложность решения нужно рассчитывать в том числе, учитывая этот факт. Например, нужно добавить новый сервис. Можно реализовать его, как компонент, для существующего контейнера ил как самостоятельную службу/демон или захостить на веб-сервере. Возможно, что реализовать отдельную службу проще, но при этом придется менять процесс деплоймента. Но это уже отдельная тема. Автоматический деплой в основном реализуют в основном только «большие» компании/продукты. Пока большая часть разработчиков деплоит «руками» разговаривать об этом просто бесполезно. Из более простых примеров — главная страница приложения. Нужно показывать набор иконок. Можно захардкодить их во вью, а можно сделать запрос к БД. Если набор иконок меняется только с релизами, хранить их во вью проще.
Второй момент: логика, «размазанная» по приложению. Один функционал на уровне Entity, другой — в сервисах, третий — в котнтроллерах. Это, пожалуй, самый сложный момент, который относится больше не к «разработке» как таковой, а скорее к процессуальной составляющей. Все достаточно большие приложения, в разработке которых я принимал участие, так или иначе страдали от этой проблемы. Причем это опыт как на пост-советском пространстве, так и на европейском. Я думаю, что вообще нет серебряной пули, позволяющей избавиться от этой проблемы. Я обычно прошу всех разработиков, как можно раньше сообщать о сложностях связанных именно с дизайном системы, чтобы по возможности быстро провести рефакторинг, таким образом иссекая загнивающие куски в зародыше.
Второй момент: логика, «размазанная» по приложению. Один функционал на уровне Entity, другой — в сервисах, третий — в котнтроллерах. Это, пожалуй, самый сложный момент, который относится больше не к «разработке» как таковой, а скорее к процессуальной составляющей.
Мы решали это путем введеления кретериев которые бы указывали в какой слой выводить эту логику и выделяли в документ «Руководство разработчика», в котором велся changelog.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
The Good, the Bad and the Ugly code