Уже довольно давно многие успели посмотреть замечательный мультик "Make Love, Not Warcraft", но с тех пор его стерли с YouTube. Тем не менее он все ещё существует в сети (правда с переводом на русский).
Я долго крепился, но все-таки не выдержал и выложу сюда данное архитектурное решение. Это кусочек реальной базы данных, использующейся в реальной программе.
Таблица DAY_CATEGORY:
Таблица CALENDAR_DAY_CATEGORY (вернее её начало и конец):
Не комментирую.
Очень часто в повседневной работе возникает вопрос компромисса. Насколько глубоко нужно изучать предмет? Насколько в программе нужно предусматривать возможности расширения? Лучшее действительно враг хорошего? Когда нужно остановиться в улучшениях? Насколько ревностно стоит следовать стандартам форматирования кода? Действительно ли скобка поставленная не на той строке обозначает некоторую критическую проблему в ДНК человека, её поставившего? Все подобные вопросы объединились в моей голове под общим "заголовком" - "Где провести черту?"
Сегодня хотел обсудить такую тему, как использование систем контроля версий при разработке программного обеспечения. На самом деле, мне даже сам факт очередного обсуждения данного вопроса не нравится. Уж вроде столько всего говорено-переговорено и самыми большими гуру и теми у кого и труба пониже и дым пожиже, и книжек написано достаточно. Но тем не менее вопросы и "ситуации" все равно возникают, так что не обессудьте.
Про то, что такое система контроля версий и зачем она нужна, я думаю все, кто когда либо программировал, знают. Ну, а если кто не знает, отошлю на википедию.
Несмотря на то, что подобные системы существуют уже очень давно, частенько возникают вопросы по правильному их использованию, а именно - вопросы типа "где провести черту".
Что должно находиться в системе контроля версий?
Ответы на этот вопрос варьируются от "только исходный код" до "всегда используйте систему управления исходными текстами", причём и та и другая стороны вполне категоричны. Где же провести черту? Нужно ли хранить в системе управления исходными текстами все письма, написание которых сопровождало написание программы? А нужно ли хранить там документацию? А различные версии логотипа? А, скажем, внутренние технические документы? А меняющийся, с течением времени, список телефонных номеров разработчиков?
У меня на этот счёт очень простой взгляд. Мы занимаемся производством программного продукта. Производством того, что мы поставляем конечному пользователю (заметим, что конечный пользователь - это "роль" - им вполне можем быть мы сами). Поэтому в системе контроля за исходными текстами должно находиться все что нужно чтобы собрать версию нашего продукта заново. То есть это исходные тексты программы, документация, картинки, сборочные скрипты, тексты лицензионных соглашений и так далее. Очень просто проверить находится ли в системе исходных текстов все что нужно - необходимо взять "чистый" компьютер, поставить на него то программное обеспечение которое необходимо для сборки продукта, "взять" из системы управления версиями какую-то версию продукта и попробовать запустить процесс сборки (сетевой доступ к чему-либо, кроме системы контроля версий можно отменить). Если получится нормальная сборка продукта - значит в системе есть все что должно быть.
Должно ли в системе контроля версий быть что-то ещё? Вопрос вкуса. Мне кажется что на уровне общих "правил" не стоит пытаться засунуть туда все что можно себе представить.
В какой момент вещи должны попадать в систему контроля версий?
Здесь тоже есть масса мнений. Начиная с мнения - "положу перед релизом", до попыток положить каждое изменение, в том числе и неработающий код.
Заметим, что крайности бывают двух видов - "слишком редко" и "слишком часто".
Проблема "слишком редко", на мой взгляд, достаточно легко решается введением практики "ежедневной сборки". Если такая практика существует (даже если сборка не ежедневная, а просто производится достаточно часто), то трудность сама собой исчезнет.
Проблему слишком частого внесения изменений решить несколько сложнее. Часто вводят строгое правило - "не чекинить не работающий код", которое в результате может вылиться у людей в отторжение и даже боязнь внесения кода в систему контроля версий вообще. Данную проблему можно решить разными способами, но на мой взгляд самым простым является заведение в системе контроля версий "своей" ветки для каждого из разработчиков, в которой он сможет работать так, как ему удобно. В момент "сборки" можно просто переложить готовые файлы из личной ветки в общую (ну и сделать "merge" при необходимости).
Замечание для "администраторов"
Частой проблемой, стоящей на пути разработчиков, пытающихся организовать систему контроля версий тем способом, который им кажется удобным, являются задачи администрирования.
Любая программная система требует регулярного обслуживания, резервного копирования, наличия достаточного места на диске, адекватной производительности компьютера на котором она работает и сети через которую в неё осуществляется доступ. К системам контроля версий это относится в полной мере.
Часто бывает так, что принимается решение не хранить какие-то виды документов или не создавать отдельных каталогов для пользователей из соображений "административного характера". А именно - не хватит места на дисках, резервное копирование будет занимать много времени, не хватит лент, используемая система контроля версий "плохая" и если хранить в ней двоичные документы, то ведёт себя плохо.
Мне кажется, что эти соображения очень опасны. По крайней мере для компании, чьей основной деятельностью и источником заработка является производство программного обеспечения. Представьте себе, что начальник службы безопасности банка скажет - "У нас недостаточно места в главном хранилище, чтобы хранить все ценности, поэтому давайте так - все золото мы оставим в хранилище, а акции и бумажные деньги пусть лежат в кабинетах сотрудников. Здание, в принципе, охраняется, конечно стены и замки в кабинетах не такие надёжные как в хранилище, но ведь и бумажные деньги не столь ценны, как золото". Понимаете, мне кажется что лучше расширить хранилище. Может быть даже купить или построить новое. Для компании, производящей программное обеспечение, нет ничего более ценного чем программисты и исходные тексты написанных ими программ- зачем же на этом экономить?
Довольно много разговоров сейчас идет про различные "чудеса", информация о которых то и дело сообщается нам различными СМИ. Много чего интересного можно узнать: про телепатию, астрологию, людей "улучшающих" свойства воды, можно узнать о "торсионных полях" и чудесных свойствах пирамид, о спящих где-то в Гималаях лемурийцах, о великой российской империи, чьим царским кладбищем были египетские пирамиды.
Все эти явления получили у нас название "лженауки". Вот определение лженауки, данное академиком РАН Александровым Е. Б.:
Однако, основное содержание термина предполагает лишь заведомую (априорную) ОШИБОЧНОСТЬ позиций оппонентов рациональной науки, отводя в ней обширное пространство для добросовестных заблуждений. Поэтому, в западной литературе обычно используется более мягкий ("политкорректный") термин "псевдонаука", а также "паранаука".
Итак лже- или пара- наука. Люди, находящиеся вокруг, талантливые и не очень, жулики, добросовестно заблуждающиеся ученые или новые непризнанные Ньютоны и Эйнштейны. "Традиционная" наука не жалует всех этих людей. Российской академией наук сформирована специальная "Комиссия по борьбе с лженаукой и фальсификацией научных исследований".
Недавно комиссия начала издавать бюллетень "В защиту науки". Бюллетень предназначен для того чтобы:
... развенчивать самые разные направления лже-науки, в том числе и те, которые проникли сегодня в медицину, в образование, в бизнес.
Всем людям, поверившим нашей прессе и пытающимся убедить себя в существовании разного рода "чудес" я предлагаю этот бюллетень прочесть.
Я очень скептически отношусь ко всяким паранаучным заявлениям, однако должен признать что и бюллетень вызывает у меня не менее скептические ощущения. "Развенчивать" - это конечно благородная затея, но мне кажется не самая полезная.
Почему лженаука так популярна? Почему СМИ накидываются на сообщения разного рода "волшебников", люди раскупают книги Фоменко? Бюллетень дает ответ на этот вопрос:
... что у нее[лженауки] нет тормозов. Она, в отличие от науки, может обещать все,что угодно (то, что это обман, и что он когда-нибудь вскроется, не столь важно). Лженауке свойственно манипулировать чудесами – от контактов с пришельцами до получения необыкновенного алмаза, который, полежав немного в пирамиде, «всасывающей космическую энергию», становится значительно тверже обычного. Новоявленные алхимики обещают дешевые материалы в золото и даже получают финансовую поддержку государства! Этот перечень можно продолжать бесконечно.
Мне кажется есть ещё одна важная причина - лженаука подается людьми, имеющими отличные способности популяризации. Вы не замечали что книги Фоменко гораздо более увлекательны чем многие "традиционные" учебники истории?
Где популяризация "традиционной", "нормальной" науки? Где книги, которые можно было читать с интересом? Книгу профессора Куна "Легенды и мифы древней Греции" прочитали наверное миллионы человек. Почему? Потому что она была интересна! Где фильмы, популяризирующие науку? Рассказывающие о научных достижениях?
Известно, что люди любят то, что интересно. Неужели настоящая наука не может быть "подана" так, чтобы заинтересовать потенциального читателя, зрителя слушателя?
Я прошлой зимой был в Московском Политехническом Музее на экскурсии "От Абака до Компьютера". На экскурсии присутствовало 4 человека, считая меня. Да,да - 4 человека. Это и понятно - экскурсия не интересная, и даже я бы сказал скучная. Неужели о рождении компьютеров нельзя рассказать интересно? Книгу о том как работает компьютер Чарльза Петцольда "Code: The Hidden Language of Computer Hardware and Software
А неужели физика или история такие скучные науки что ничего интересного о них рассказать нельзя? И интересно только читать академика Фоменко и господина Акимова?
Мне кажется в "традиционной" науке достаточно много ярких, интересных, захватывающих событий - нужно только талантливо, увлекательно о них рассказать. Лучшая защита от "лженауки" - хорошее знание науки "традиционной". Тогда и защищать науку не придется - все само встанет на свои места.
blog: 
LinkedIn
Мой Круг