Pull to refresh

Comments 45

Поэтому Microsoft начала с нуля, без гарантий обратной совместимости.
На самом деле, не совсем с нуля: у Microsoft уже были некоторые важные части, такие как редактор Monaco в браузере.

Эм, они же просто взяли готовый Atom.
Пишут что monaco.
По «отзывчивости» студия оставляет Atom далеко позади, выглядит так, будто действительно разные редакторы там.

«взять Election» != «взять редактор Atom целиком»

Интересно что дальше с Trello будет… Сейчас в Jira кабан доски полный писец. Кстати сейчас пользуем Yougile, весьма неплохая штука.
Веб версия последний раз в 2017 году обновлялась судя по новостям. А там полно ещё есть чего поправить.
Вы должны помнить, что долгое время Microsoft предлагала «всё или ничего». Если вы использовали Visual Studio, то обязательно работали в .NET, и наоборот.
Не должны. Что значит «обязательно работали в .NET»? Если студия для себя тянула .NET для своих целей, то это вовсе не значит "мы обязательно работали c .NET". Это как неявня зависимость функций. Тут важно, что можно было спокойно делать работу, например, в C++, совершенно не задаваясь вопросом про .NET и даже про то, что установлен ли он вообще на машине.

С VSCode всё, конечно, хорошо, если не учитывать тот факт, что это не IDE. Из аббревиатуры не хватает "Integrated". По сути это редактор, общающийся по LSP с независимыми языковыми серверами, каждый из которых является "вещью в себе". В итоге, если вам нужно из расширения к VSCode получить информацию по дотнетному солюшену, то брать её попросту неоткуда. В итоге невозможно сделать нормальный плагин для поддержки чего-то типа Nemerle, который бы работал с остальными дотнетопроектами. И подобных ограничений куча.


А так да, блокнот с поддержкой внешних плагинов автокомплита и подсветки синтаксиса хороший получился, годный.

Была такая замечательная среда разработки CooCox CoIDE, для микроконтроллеров на основе архитектуры ARM. Основной её фишкой, на мой взгляд, был удаленный репозиторий с кодовой базой разбитой на категории и все это прямо из среды. Нужен код драйвера определенного экрана — держите, нужен код для управления микросхемой часов реального времени — пожалуйста. Не нашел что-то — пожалуйста, напиши и выложи в общий доступ в этот репозиторий. Кодовая база росла, популярность IDE тоже.
Но в один прекрасный день кто-то решил переписать продукт, в итоге старая база кода стала практически недоступной, поиск по новой базе был ужасен. Наверное можно было бы это исправить, но выпуск новых версий почему-то прекратился, форум продукта опустел, а потом и вовсе его заполонили боты с которыми никто уже не собирался бороться. А жаль, хороший был продукт с большой перспективой.
По всем этим примерам можно сделать один вывод: неудачники останавливали разработку старого продукта и начинали создавать новый с нуля. Те же, кто стал успешным, создавали новый продукт параллельно со старым, не бросали поддержку и развитие предыдущего, и выкатывали новый, когда он уже был готов к употреблению и имел уникальные фичи.
Поэтому изначальный постулат Джоэля, в общем то, вполне верный. И если у вас нет средств на параллельное развитие двух веток продуктов, развивайте лучше старый.
Но не всё из Inbox перенесли в Gmail: например, люди настолько привыкли к «режиму паузы» (snoozing), что без него сейчас буквально физически страдают.
[...]
Думаю, для многих переход дался бы гораздо проще, если бы перед закрытием Inbox все его функции интегрировали в Gmail.


1. Inbox ещё не закрыли. Его обещают закрыть только в марте.
2. Функция Snooze уже есть в Gmail. На моём личном ящике она появилась в прошлом году, на корпоративном — где-то полтора месяца назад.

UFO landed and left these words here
Многочисленные написанные быдлокодом проекты лучше переделывать, потому что любое большое изменение — это риск перехода из управляемого хаоса в неуправляемый.

Во всех таких случаях нужно сесть и думать, чем чреваты подобные переделки. Если вам в спину дышат конкуренты, а вы остановите развивать свой быдлокодовый проект, и выкатите новый красивый внутри и внешне, но более бедный по функциям, чем конкуренты на тот момент, ваш бизнес умрёт. Если ваш новый проект не будет иметь возможности лёгкой миграции со старого, и при этом не будет превосходить конкурентов, ваш бизнес умрёт. Если новый проект поломает сложившийся user experience, и при этом не будет превосходить конкурентов, ваш бизнес умрёт. В общем, нюансов много. Понятное дело, что в каждом кейсе могут быть свои нюансы, но в общем случае переделка с нуля даже самого паршивого говнопроекта, уже имеющего бизнес-историю — ходьба по краю. Тем более что почти всегда есть возможность постепенного улучшения того, что под капотом, без революций.
UFO landed and left these words here
Бывает и так, но я склоняюсь к тому, что подавляющее большинство более-менее успешных проектов всё-таки написаны не бездарями через полную задницу, а обычными программистами, с костылями, но терпимо.
UFO landed and left these words here

Я чаще видел, как проект превращался в адское создание, когда мамкины идеалисты начинали каждую неделю менять архитектуру на более красивую и правильную. А потом картинно уходили в закат сетуя на то что опять ничего не вышло.

UFO landed and left these words here
Три дня! На то, чтобы с таким методом разобраться, может три месяца уйти легко, и то еще может не хватить.
UFO landed and left these words here
Вот кто будет платить, пусть и принимает стратегическое решение — разбираемся с тем что есть, или переписываем с нуля.
Это все очень загадочно. Ибо вообще неясно кто в здравом уме может выбрать Jira этого лидера рынка.
Грань между глубоким рефакторингом и переписыванием с нуля зыбкая. Пусть у нас есть программа со 100 функциями. Потом допустим мы создали 10 классов и куда засунули видоизменившиеся 100 функций? Это ещё рефакторинг или переписывание с нуля. А если эти 100 функций по выдаваемому результату такие же, как старые 100 функций, но по коду у них совсем другой? А если у нас некоторые новые функции заменяют две старых? В любом случае, когда мы используем какие-то знания о старой логике программы, то это уже не «с нуля». А если не используем, то есть риск на те же грабли наступить.

отличие в том, что при рефакторинге вы можете выкладывать изменения инкрементально "почти" без потерь, а при "разработке с нуля" вам перед выкладкой надо как минимум догнать уже существующий функционал "старого" продукта и только потом можно начать выкладываться.
При этом конечный результат при рефакторинге может быть достигнут гораздо позже, чем при "с нуля", но он будет растянут во времени, при котором пользователи продолжали работать с вашим продуктом. Удобство пользователя важнее удобства разработчика

Но это уже практически не имело значения, потому что за три года, что Netscape стоял на месте, Internet Explorer захватил всю оставшуюся долю рынка:
Ну вообще по графикам явно видно, что переписывание тут ни при чем. Уже два года Нетскейп серьезно терял позиции и начало переписывания никак не сказалось на тенденциях
Многие факторы, влияющие на целесообразность переписывания с нуля не рассмотрены (тут уж Гедель в помощь). К примеру, в вопросе о Нетскейп не учтен фактор войны браузеров. Многие вздохнули свободнее, когда не стало нужно поддерживать особенности парсинга Нетскейп, категорически не стекающегося с ИЕ буквально повсюду. Есть и многие другие причины, например, использование чужих модулей и фреймворков, система которых начинает трещать после слишком большого расхождения между ними или когда что-то перестало поддерживаться, или версии более не согласуются с текущим кодом сайта и т.п. Все в жизни бывает сложнее чем как бы очевидные правила типа “Никогда не следует делать так”.
Хорошим (с точки зрения иллюстративности) примером переделок может послужить история мобильной винды. Переходы WM 6.5 — WP 7.0-7.5-8.0-8.1-WM 10 включают в себе 1 переписывание полностью, 1 почти целиком и ещё одно примерно наполовину. Совместимость при этом была такая себе. Это и привело к нынешней ситуации.

Майкрософт сейчас судя по слухам делает аналогичный процесс поддержания старой системы и написания нового ядра системы с нуля, Windows Core OS. Это больше походит на рецепт успеха из статьи выше, но предсказать пока результат затруднительно.
Интересно, реально починить игровой движок Беседки не переписывая его заново и не порождая новых багов? С каждым следующим продуктом ситуация все удивительнее…
Visual Studio — тяжеловесный продукт во всех смыслах

Ну не назвал бы платформу Electron идеалом легковесной платформы.

И вообще вся попытка притянуть VSCode к Visual Studio выглядит как «за уши».
Первое редактор (пусть и специализированный), а второе IDE.

И как на нем MS планировала делать бизнес, заменив VS на VSCode?
Разве что для имиджа фирмы полезен.
Первое редактор (пусть и специализированный), а второе IDE.

Ну чего? VSCode — абсолютно честная взрослая IDE. Там же есть всё — отладчики, средства автодополнения кода, интеграция с СУБД, инструменты сборки и т.д.

И как на нем MS планировала делать бизнес, заменив VS на VSCode?

Значительно расширяя круг разработчиков, которые затем будут пользоваться Azure и прочими сервисами MS, и потом продавать их вместе со своими решениями своим клиентам.
Правда? Прям сразу в VS Code есть отладчик, например, для плюсового кода, без необходимости подключать всякие gdb/lldb? Даладна. А как же это:

Note: The C/C++ extension does not include a C++ compiler or debugger. You will need to install these tools or use those already installed on your computer.

? Ну и «средства автодополнения кода» там точно так же не будут адекватно работать без сторонних штук типа clang или gnu global. Блокнот — он и есть блокнот.
Правда? Прям сразу в VS Code есть отладчик, например, для плюсового кода, без необходимости подключать всякие gdb/lldb? Даладна. А как же это:

Скажите, а что, черта между IDE и блокнотом проходит в том, как плагины с инструментами разработки поставляются, в одном дистрибутиве, или из онлайновой репы? Если в дистрибутиве, то IDE, если надо через репозиторий доустанавливать, то блокнот?
Ни Visual Studio, ни даже Delphi образца 1997 года без подключаемых модулей не обладают возможностью ни автодополнения кода, ни отладки, ни визуальной разработки. Это всё — такие же плагины, как и в VS Code. Ну разве что от одного вендора, и в установочном скрипте прописаны.
Разница между IDE и блокнотом проходит по букве I — «integrated». В VS Code, в отличие от «взрослой» Visual Studio, нет этой самой буквы I. И плагины сами по себе там не помогают, они не работают без кучи сторонних toolchain'ов, которые надо устанавливать и настраивать вообще отдельно, и даже с этими toolchain'ами они работают с кучей ограничений, вон выше kekekeks привел хороший пример. Не дотягивает VS Code до «честной взрослой IDE», никак не дотягивает. Это как если бы я в Visual Studio поставил «поддержку C++», а она мне и говорит человеческим голосом — сорян, парень, cl.exe не входит в мою комплектацию, иди куда хочешь и ставь откуда хочешь. И какой-нибудь парсер для IntelliSense где-нибудь отковыряй, а то у меня будет только автодополнение в стиле Notepad++. И отладчик какой-нибудь заодно не забудь прихватить. Правда, как я со всем этим буду потом работать, и буду ли работать вообще — не могу обещать.
В чужой монастырь со своим уставом не ходят. CLion, в котором всё очень прилично интегрировано и всякие рефакторинги в наличии — тоже требует сторонний toolchain и отладчик. Просто потому что так на Linux принято.

На всякий случай предлагаю вспомнить что Netscape 4 обладал движком со статическим рендером страниц т.е. после первоначальной загрузки страницы размеры / позиции элементов рассчитывались и уже не могли меняться. Для всякой динамики существовали такие вещи как <layer> / <ilayer>. Поэтому вряд ли там вопрос решился бы рефакторингом, возможно переписывание было правильным решением.


Прекрасно помню своё "WOW!" когда я увидел первую бету NS6 которая динамически перестраивала layout страницы при ресайзе окна браузера, это выглядело настоящим волшебством :)

С точки зрения «вау-фактора» это, конечно, крутно — а вот с точки зрения выживания компании — это было катастрофой. Так как было с самого начала заявлено, что "<layer> — это тупик"… но ничего не было предложено взамен. То есть несколько лет разработчиков «кормили завтраками» то бишь демками).

Если бы, вместо этого, они всё это время развивали свою статическую модель — то не факт, что мы вообще получили бы тот ужас, который мы, в результате, получили.

Ибо всё это «волшебство» — оно, увы, небесплатно. Сильно небесплатно. А вот востребованность — весьма ограниченная. Даже сейчас. А уж в те времена, когда Netscape решила побить горшкивсё переписать — и подавно.
Оба продукта по-прежнему активно разрабатываются, и нет никаких признаков того, что Microsoft намерена закрыть Visual Studio.

А с чего бы им его вообще закрывать? Эти продукты вообще разного класса, Visual Studio — это мощнейшее IDE, включающее в себя весь инструментарий, необходимый для разработки приложений, от и до, а VS Code — это блокнот (да к тому же еще и на Электроне), стильно-модно-молодежно.
UFO landed and left these words here
И при этом VS 2010 Express потребляла на моем тогдашнем Lenovo T420 примерно столько же ресурсов (по крайней мере в режиме дизайна и редактирования кода), сколько сейчас на этом же T420 потребляет Skype, написанный на Электроне. Electron is Cancer ©.
UFO landed and left these words here
На строке «Fog Creek построил бизнес вокруг счастья разработчиков. Это отразилось как на продуктах компании, так и на её внутренней «операционной системе»» вспомнился мне Дин Бернетт.
Цитата:
«Как ни цинично звучит, но счастливые работники приносят больше прибыли.
Есть немало доказательств, что у счастливых работников производительность труда на 37 процентов выше. Если у вас работают сто человек, и все они счастливы, они могут выполнить работу 137 человек и при этом не нужно идти на дополнительные расходы.
Производительность труда несчастливых работников снижается на 10 процентов. Добавьте к этому, что у счастливых людей крепче здоровье, они реже жалуются, и вам станет ясно, что руководство компаний действительно хочет, чтобы работники были счастливы,
даже если видит в них всего лишь бездарных батраков»…

Рискую уехать в какую-нибудь метафизическую фигню, но похоже, что тут тоже есть над чем подумать…
>>Netscape Navigator, IPO на $3 млрд
Жесть конечно, даже по нынешним меркам. $3млрд за браузер! При стоимости за копию $49 планировалось продать его минимум 61 миллион раз, чтобы окупить компанию.
AOL вообще лидер по покупке за огромные деньги известных бизнесов, но по которым видно что скоро им хана, либо из-за снижения популярности, либо по вине AOL. Netscape, ICQ, Winamp. Такое ощущение, что во всех таких сделках была коррупционная составляющая со стороны AOL и возглавлявших его менеджеров.

История с МакДермента вообще показывает как он хотел нагнуть венчурных инвесторов и перетащить клиентов в новый продукт.
Жесть конечно, даже по нынешним меркам. $3млрд за браузер!

А почему жесть? Что смущает в возможности продать 61 миллион копий программы, которая стоит $49, на рынке, на котором в 1996-м году было порядка 70 млн пользователей, который рос по 50% каждый год, при этом достойных альтернатив у этой программы на тот момент практически не было, ни бесплатных, ни платных? Кроме того, я подозреваю, продали они где то миллионов 100 экземпляров до того, как он стал бесплатным.
Там как раз не было переписывания с нуля. Но да, пример похожий. На переход ушло 10 лет и всё это время поддерживались обе версии.
Sign up to leave a comment.

Articles