Comments 16
Если посчитать количество символов ";", чтобы приблизительно оценить объём, то получится, что в коде примерно 711 тысяч строк
Учитывая, что не все строки заканчиваются на ; - то реально строк еще больше.
Делаю свою браузерную MMORPG с 2016 года - сделано еще очень мало (основная работа съедает почти все время и силы), а когда уже 100 тысяч строк.
Ну а вообще такие долгострои по своему уникальны. Одна только история их разработки заслуживает отдельной интересной истории.
Ну а вообще такие долгострои по своему уникальны. Одна только история их разработки заслуживает отдельной интересной истории.
Далеко не всегда. Вот у меня есть аналогичный "долгострой", которому недавно исполнилось 30 лет. Но при паре десятков пользователей (и вдобавок базовый язык - фортран) - кому может быть интересна такая история?
Ну тут явно ввиду имелись успешные долгостории.
А что понимать под успешностью? Например, мой - вполне успешен, имхо. У половины пользователей (и у меня самого) это - основной рабочий инструмент. Как у ведьмы - метла, без которой особо не полетаешь. Просто он весьма узконишевый. Ну и к тому же русскоязычный, что снижает количество потенциальных пользователей до минимума. Поди сыщи сейчас настоящую ведьму в наших краях...
Интерес, скорее, будет обусловлен не просто "успешностью", а массовостью применения. Широко используемая технология, развиваемая в течение многих лет, интересна широкому кругу, и наоборот.
Господе, Не будь занудой. Понятно же, что контекст имел ввиду славу проекту. Сарафанное радио распиарило в свое время этот проект так, что о нем даже офисный планктон упоминает, как о каком то древнем Граале игростроя.
Да, для узконишевого проекта (как ваш) массовость применения не будет являться составляющей успешности, а вот для игры - будет. Это говорит о том, что наполнения и функционала, добавляемого в течении продолжительного срока проекта хватает для удержания старых и привлечения новых игроков. Кроме того, об игре говорят, пишут, стримят, энциклопедируют, модифицируют, вдохновляются ей в других проектах. Играют в нее, наконец (даже с учетом всего того разнообразия, что предлагалось на игровом рынке за все прошедшие годы).
Вы не поверите, например мне.
С интересом почитал бы историю становления Вашего долгостроя. Язык значения для меня особо не имеет.
Так что, жду)
Далеко не всегда. Вот у меня есть аналогичный "долгострой", которому недавно исполнилось 30 лет. Но при паре десятков пользователей (и вдобавок базовый язык - фортран) - кому может быть интересна такая история?
Многим. Я бы послушал. Потому что истории провалов намного более поучительны, чем истории «успешного успеха»
С интересом почитал бы историю становления Вашего долгостроя. Язык значения для меня особо не имеет.
Так что, жду)
...Многим. Я бы послушал. Потому что истории провалов намного более поучительны, чем истории «успешного успеха»
Хорошо, мне не сложно. Только должен предупредить, что я не программист, а научный сотрудник. Поэтому история у меня будет одновременно типовая и нетипичная, а точнее - офтопик. Типовая - потому что проектов, подобных нашему, в научной среде миллион и маленькая тележка (только большинство из них умирает гораздо быстрее). А офтопик - потому что научные программы обычно пишутся "для себя", что в корне отличает их от обсуждаемых здесь продуктов "для пользователей". Почему я и сомневаюсь, уместен и здесь этот лонгрид. Впрочем, некоторые аналогии с разработкой нормальных программ у нас тоже прослеживаются. Так что пожалуй не поленюсь и все-таки напишу ;-)
Но сначала о том, зачем вообще научные сотрудники пишут программы.
В науке основной результат - это статьи. Цель анализа данных - поиск закономерностей; иногда - оценка параметров. Никого не интересует, как именно ты все это считал. Только вот задачи в науке часто нетиповые, и найти для них готовые программные инструменты получается далеко не всегда. Даже если такие есть, об этом трудно узнать, не попробовав. А чтобы попробовать, надо программу установить и освоить - что очень недешево в плане времени. А вдруг она "не взлетит"? Любой человек боится оказаться у разбитого корыта, когда половина времени, отпущенного на проект, уже истекла. А еще надо будет объясняться с завлабом - на кой черт мы купили эту программу, если она не умеет сделать вот эту вот закорючку (без которой завлаб не признает результат драгоценным). В силу всех этих факторов небольшие программы для научных расчетов часто пишутся самостоятельно, даже если это велосипедный велосипед. (Впрочем, иногда это оправданно, если ехать надо по шпалам, и поэтому колеса нужны не круглые, а квадратные).
Но главное, когда программа "своя", а опыт разработки не очень большой, почти всегда возникает иллюзия, что ее можно сделать быстро и качественно (и со всеми необходимыми финтифлюшками) приблизительно к завтрашнему утру. Только вот законы природы действуют одинаково на всех программистов, даже научных сотрудников. Время идет, а тестирование обнаруживает все новые баги. А когда результат наконец-то посчитан, становится ясно, что изначальные требования были хорошими, но неправильными. Ведь наука - это движение в неизвестность, и путь, который казался прямым, почти обязательно упирается в тупики и завалы. В общем, все хорошо, только надо чуть-чуть переделать логику интерфейса, а также структуры данных и алгоритмы. Буквально совсем немного... а вот эти три функции из пятидесяти можно вообще не менять!
А сроки сдачи отчета горят... чтобы статья успела выйти до декабря, хорошо бы отправить ее в журнал в феврале. Тут уже режется все, что можно. Программа наконец запустилась, но работа с ней напоминает движение по минному полю: шаг влево, шаг вправо в лучшем случае подвесят компьютер, в худшем - рушат институтскую сеть. Единственно правильные опции и ответы, при которых на выходе получается что-то разумное, записаны на бумажке у автора, которая приклеена к монитору. Исчерканная вкривь и вкось по диагонали невразумительными аббревиатурами, она же играет роль ежедневника, а также справочной системы к Программе. О том, чтобы что-то изменить в коде, не может быть и речи (кое-как заработало - так не трогай!). Да и как там что-то изменишь, если смысл написанных накануне в полуобморчном состоянии операторов уже утром становится одной из тайн мироздания даже для автора, а имена переменных, созданных в горячке аврала, формируются по шаблону i1, j13 и k1937?
В общем, нет ничего удивительного, что работа с такой программой заканчивается на следующий день после сдачи отчета. Да, в статье алгоритм может быть описан, как превосходный (и иногда в этом есть доля правды). Считается, что научные сотрудники очень радуются, когда их статьи читают, а методы - применяют. Наивный, но логичный IT-шник даже может подумать, что то же самое относится к их программам. Скажу по секрету, почти у каждого научного сотрудника-программиста в ящике стола лежит молоток, которым можно тихонько ударить по диску с программой, отдавая его коллеге. Это гораздо менее стыдно, чем признаваться, что ты ни черта не смыслишь в собственном коде.
Надеюсь, я ответил на вопрос о провалах? <sarcasm mode: off>
Ну а теперь о нашем проекте.
Его отличие от многих подобных в том, что он создавался на геофизическом полигоне, одной из главных задач которого были наблюдения за процессами в Земле в сейсмоактивном районе. Мы измеряли все, что могли, непрерывно в течение многих лет. Поддержание аппаратуры в рабочем состоянии в полевых условиях стоило огромных усилий. Каждый второй сотрудник занимался получением данных, а каждый первый - их обработкой. Каждая серия наблюдений была уникальной и потому бесценной, а общее отношение к экспериментальным данным можно описать одним словом: "СВЯТОЕ".
Но, это была вторая половина прошлого века, когда почти все приходилось делать вручную. Когда я приехал работать на полигон, компьютеры только-только входили в жизнь. Например, данные автоматического мониторинга двигательной активности животных печатались на рулонной ленте (и это был последний писк техники!), а результаты измерения электрических параметров передавались с отдаленных станций по рации и радист их записывал на бумажке. Затем оператор брал эти ленты и записи и вручную набирал файлы, которые хранились на магнитных дисках СМ-4 (советский аналог PDP-11). Понятно, что когда вводишь тысячи цифр вручную, ошибок не избежать. В лучшем случае можно перепутать или пропустить цифру, в худшем - загнать данные не в тот файл. Ну и работать с разрозненными файлами (каждый в своем формате), содержащими множество опечаток, тоже было не очень удобно. Моей первой задачей была автоматизация ввода и организация базы данных временных рядов. Да, их по-прежнему набирали вручную, но теперь не в редакторе, а в специальной программе, которая предлагала меню со списком рядов, сама подставляла дату и время следующего наблюдения, а также сравнивала вводимые значения с предыдущими и сразу выдавала предупреждение, если обнаруживалось что-нибудь подозрительное. Так начался наш пакет. А поскольку данные - это святое, меня не просто не торопили с релизом, а наоборот, всячески поддерживали в стремлении как-то улучшить программу, сделать интерфейс более удобным для оператора и более защищенным. Плюс я и сам с удовольствием сидел за монитором. С одной стороны, это было захватывающе и ново (диплом я делал на ЕС ЭВМ, где задания запускались в пакетном режиме, а тут впервые увидел настоящий интерактив). С другой - это была затерянная в горах экспедиция, где долгими зимними вечерами делать особо нечего, и самое интересное из возможного - это работа.
Понятно, что в то время мы писали на самом примитивном фортране, почти не имея фундаментальных знаний о программировании. Нас - физиков и геологов - в ВУЗе просто этому не учили. Но когда изо дня в день работаешь с одним и тем же собственным кодом, который все разрастается, к базовым принципам структурного программирования (уже доступного в языке) очень быстро приходишь своим умом. Так, у меня почти сразу появились нормальные (насколько это было возможно) имена переменных, структуры данных в include-файлах (вместо дублирования кода), деление программы на функции небольшого объема (одна процедура - одна задача), и, разумеется, комментарии. Логически связанные группы функций объединялись в изолированные от другого кода библиотеки. Обойтись без операторов IF + GOTO тогда было сложно, но они почти сразу же были поставлены в жесткие рамки. В частности, я следил, чтобы ни один GOTO не перекрывался с другим (то есть между любым GOTO и его целевой меткой не должно быть ни других GOTO, ни их целевых меток), а сам прыжок, как правило, должен быть на одну из ближайших строчек (иначе фрагмент кода выносится в функцию). Это позволило впоследствии довольно легко от них отказаться. (Примерно к началу 2000-х GOTO в программе практически не осталось).
Но главное - нам как-то повезло с самого начала выбрать довольно удачную архитектуру программы. Вместо одного монстра, который одновременно выполняет функции СУБД, обработки рядов и их визуализации, мы с самого начала строили пакет, состоящий из множества отдельных программ, каждая из которых решает одну небольшую задачу, и интерактивной среды, которая позволяет удобно строить конвейер из этих базовых процедур. Это оказалось очень удобным в плане дальнейшего развития пакета и расширения его функций. Позже, когда на рынке появились такие программы статистического анализа временных рядов, как Мезозавр и Эвриста, мы неожиданно обнаружили, что наш пакет - это не просто "на безрыбье рак - рыба", а что он намного мощнее и удобнее этих пакетов - во всяком случае, для наших задач.
Надеюсь, что вам было не скучно прочитать эту историю ;-) Конечно, я мог бы еще рассказать про основные этапы рефакторинга (за 30 лет из было немало), про переход с PDP на IBM PC в DOS, а затем миграцию в Windows, и прочее... но там уже трудно избежать специфических для фортрана подробностей, которые сейчас вряд ли кому-нибудь актуальны ;-)
у меня вот лаба в институте была на 10к строк, это не показатель ничего, в день можно от нескольких десятков до нескольких тысяч нагенерить
Лайк не читая. А почему нет ссылки на стим версию? Добавьте пожалуйста, пусть люди знают.
Time is subjective
Какой ваш любимый баг и что его вызывало?
Мне вот больше всего запомнился баг с гоблинами (и другими существами), варящимися заживо в собственной крови и жировой прослойке, когда обновили анатомию существ и немного не учли теплопроводимость кожи.
711 тысяч строк кода, 20 лет, один разработчик: как создавалась Dwarf Fortress