Готовлю еще один доклад для харьковской Uneta по принципам проектирования.
Основные цели:
- донести, что в своей работе разработчику стоит руководствоваться не только спецификацией и требованиями, если хочется иметь на выходе расширяемый, легко сопровождаемый, и поддающийся тестированию код
- дать общее понимание о некоторых принципах проектирования
- натолкнуть на дальнейшее самостоятельное изучение этого вопроса
Доклад будет частично построен на заметке о качественном коде и проектировании. Частично, потому что этот материал пойдет лишь в начало доклада, а в основной его части я планирую все-таки рассказать про популярные на данный момент принципы проектирования (как общие, так и ООП): SoC, DRY, KISS, YAGNI, Low Coupling, High Cohesion, а также пятерку SOLID. Принципов много, и каждый из них, конечно, достоин отдельного небольшого доклада, поэтому придется рассматривать их достаточно поверхностно. Также очень хочется успеть дать какие-то взаимосвязи между ними, чтобы они лучше запоминались, и хотя бы пару примеров. Таким образом, доклад будет больше посвящен теории, а не практике.
Вторым докладчиком будет мой бывший одногруппник Денис Резник. Тема его доклада: “Защита данных в SQL Server 2008 при помощи Transparent Data Encryption”.
Встреча будет проходить в Харьковском национальном университете радиоэлектроники (ХНУРЭ), пр. Ленина 14, ауд. 329 (м. Научная), 5 марта 2010 в 18:25, то есть в эту пятницу вечером.
Если что-то изменится с местом, временем или форматом встречи – я сообщу дополнительно в комментариях.
Жду всех, кто захочет послушать и пообщаться на эту тему :)
К сожалению, не смог "нагуглить" ничего про принцип SoC, подозреваю возникала опечатка и имелось в виду IoC?
ReplyDeleteSoC = Separation of concerns
ReplyDeleteна самом деле это просто buzz words для привлечения внимания.
так, SoC ~ High Cohesion ~ SRP in SOLID это про тоже самое
Буду, уже взял билеты.
ReplyDeleteИгорь прав, это Separation of Concerns. Некоторые принципы действительно родственны и пересекаются, но на мой взгляд, все-таки картинка немного другая:
ReplyDeleteSoC ~ Low Coupling
High Cohesion ~ SRP
Применение первой пары может повлечь за собой появление второй, и наоборот, но это далеко не факт.
Кстати, если у вас есть предложения по некоторым другим принципам, которые можно осветить - буду очень благодарен.
> Кстати, если у вас есть предложения по некоторым другим принципам, которые можно осветить - буду очень благодарен.
ReplyDeleteя думаю того, что вы перечислили на целую книжку хватит, если с примерами. Они там все друг с другом повязаны и один из другого следуют.
ваш доклад технический, для инженеров, да? тогда ничего другого не нужно.
мне лично было бы интересно послушать размышления про "декаденство" этих подходов, где лежит та тонкая линия когда затраты на улучшения дизайна системы и/или кода перестают приносить выгоду и становятся бесполезным расходованием средств.
как исходя задач бизнеса предвидеть требования к системе в будущем и в таком духе.
З.Ы. вы меня особо не слушайте, я все равно в Харьков не приеду.
Да, доклад технический, поэтому основная цель все-таки осветить принципы. Однако я собираюсь вкратце затронуть тему баланса, потому что нет никакого смысла (кроме получения эстетического удовольствия) писать идеальный код - во многих случаях это нецелесообразно с финансовой точки зрения.
ReplyDeleteС другой стороны, лично мне кажется, что НЕ использование принципов проектирования в программировании в большинстве случаев дает очень небольшую экономию, а вот негативные последствия от плохого дизайна могут быть очень неприятными. Если бы мы говорили о модульных тестах, TDD, code review и прочем, то там экономия на лицо, хотя апологеты TDD с нами бы не согласились :) Но вот сколько стоит создание двух классов вместо одного, вынесение интерфейса, распределение классов по слоям или модулям? При помощи современных инструментальных средств и опыта большинство этих задач делаются практически на лету. Поэтому, как и в случае с паттернами, принципы стоит как минимум знать и уметь ими руководствоваться, чтобы уже потом выбирать наиболее целесообразное решение, балансируя между требованиями к системе и имеющимися ограничениями: сроками, бюджетом, стабильностью приложения и т.д.
если это не команда из 1-3 человек, то тот кто балансирует "между требованиями к системе и имеющимися ограничениями: сроками, бюджетом, стабильностью приложения и т.д." не думает о том, создать два класса вместо одного или нет, этот человек или группа товарищей вовсе может даже не пишет код.
ReplyDelete* сейчас скажу ересь *
Я вообще начинаю думать, что все эти мелкие телодвижения по улучшению микропроектирования, почти никакого эффекта на систему в целом не оказывают.
Согласен, написал про балансировку, не подумав. В большой команде большинство людей имеет лишь требования и ограничение по времени на свою задачу. Но это только подтверждает одну здравую мысль: чем больше у вас программистов, которые могут принять более-менее правильное решение в микропроектировании, тем меньше работы у вас как у лида/менеджера, нужное подчеркнуть.
ReplyDelete>> Я вообще начинаю думать, что все эти мелкие телодвижения по улучшению микропроектирования, почти никакого эффекта на систему в целом не оказывают
Думаю, просто мои примеры "улучшений" были не очень хорошими. Все-таки принципы можно применять и не на уровне "мелких телодвижений". Кстати, а что тогда по-вашему приносит эффект? Более тяжелая артиллерия в виде модульных тестов или практик XP, на которые как обычно не хватает времени? Или макропроектирование? Сейчас вроде бы пошла тенденция убегать от предварительного проектирования в сторону эволюционного, потому что для этого появилась теоретическая база и инструменты, наработаны практики и дошел уровень разработчиков.
хороший эффект приносит угадывание будущего.
ReplyDeleteвот тут я знаю что нагрузка будет пустяковая - тут мы делаем тяп-ляп, по быстрому. Вот тут я знаю, что функциональность отомрёт скоро - снова можно как хочешь кодировать. А вот тут будет взрывообразный рост нагрузки и новых требований - тут мелочи важны.
Это если с технической точки зрения.
А если с человеческой - вот тут нагрузка пустяковая - изолируем функциональность и даём студенту. Вот тут важный кусок, тут дано что бы несколько людей могли понимать, что происходит.
Эффект в угадывании кому чем лучше заняться. Ведь не всё можно изолировать и раздать.
Вот ваш принцип YAGNI например запросто приводит к бесконечному рефакторингу. Который стоит запредельно дорого если остальные практики XP не применяются. Значит слепо кодить нельзя, надо думать вперёд. Т.е. знать будущее.
Знать будущее тяжело.
Спасибо за ответ.
ReplyDeleteДа, это даст эффект, хотя вы сами написали, что знать будущее тяжело. Конечно, такие оценки необходимо проводить и варьировать глубину написания кода, если так можно выразиться.
По поводу YAGNI. Я и сам его не очень люблю, и стараюсь всегда думать и перепроектировать в важных местах наперед. Но, во-первых, плюс YAGNI в том, что он противодействует бездумному перепроектированию (а вот здесь мы, может, будем менять базу данных на другую). А, во-вторых, если уж делать обзор принципов, то нужно зацепить и его, рассказав о его плюсах и минусах. Кстати, тот же Фаулер, который любит XP, постоянно пишет про эволюционное проектирование и YAGNI :) Но я пока так и не сумел поверить в этот подход. В реалиях наших проектов у нас редко бывает время на нормальное покрытие модульными тестами и XP практики, поэтому приходится пользоваться, что есть под рукой.
Будем =) Доклад обещает быть интересным, надеюсь много внимания было уделено обсуждению.
ReplyDeleteбыло = будет? :)
ReplyDeleteПонятия не имею, сколько времени останется. Я вот думаю сокращать материал, все-таки его очень много :( Наверно, лучше поверхностнее рассказать, но больше пообщаться в конце, чем долго нудить самому, а?