Чем больше выбора, тем он сложнее: как обновления мешают работе JavaScript-программистов

Возврат к списку

Чем больше выбора, тем он сложнее: как обновления мешают работе JavaScript-программистов

26.09.2018     

Java и Javascript стали самыми популярными промышленными языками программирования, следует из исследований аналитической компании Cloud Foundry Foundation. Эксперты опросили корпоративных разработчиков и руководителей IT по всему миру.

Несмотря на популярность, у Java и Javascript есть и свои спорные стороны. Например, постоянное обновление инструментов для разработчиков, которое не позволяет специалистам сконцентрироваться на одном направлении. Чтобы труд оставался актуальным, приходится все время учиться новому. 

Мы уже рассматривали влияние использования JavaScript на индексацию сайтов в поисковых системах. В этой статье постараемся детальнее рассмотреть будни и боли JavaScript программистов.

Ветер перемен

Изучение языка – только часть становления программиста. Чтобы написать ПО, требуется целый набор инструментов: от самого кода до выполняющих его облачных вычислений.  

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

Сложившаяся закономерность – следствие постоянного обновления инструментов, призванных облегчить жизнь разработчиков. Поэтому разнообразие и новизна оказываются двоякими: с одной стороны, появляется возможность выбрать идеальный инструмент для написания кода, а с другой – он может быстро устареть.

Программисты часто опираются на инфраструктуру приложений и пакетные программы. В начале 2015 года самой распространенной платформой для JavaScript была Backbone. К концу 2015-го первенство взяла библиотека React. В 2018 году, Backbone скатилась на 5-ое место рейтинга, уступив новым платформам, таким, как upstart Vue.

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

Почему это так сложно?

Первоначально JavaScript использовался для создания интерактивных веб-страниц. Но в наше время перед разработчиками часто стоит задача писать сложные приложения, которые работают прямо в браузере: например, Trello или Workplace Slack.

Эти задачи требуют, чтобы команды программистов работали совместно, обновляли и исправляли код, когда пользователи находят ошибки. Развитие инструментов JavaScript должно упростить работу, освободив специалистов от повторного создания общих функций с нуля.

С середины 1990-х годов программисты ищут идеальный набор инструментов для создания ПО, но чаще всего лишь копируют друг друга. Из-за этого  некоторые компании отказываются от использования инструментов для разработки, созданных аутсайдерами.

Нестабильность может усугубляться другими тенденциями. Например, применение «функционального программирования» зачастую усложняет код в одной части программы ради изменений в другой.

Каковы перспективы?

Тем не менее библиотеки вроде React с открытым исходным кодом для разработки пользовательских интерфейсов становятся нормой. Специалисты говорят, что при выборе технологий рассматривают размер сообщества, стоящего за новым инструментом. Даже если высококлассную «обновку» разработал один программист, доверие к инструменту снизится. Ведь один человек мог и не предусмотреть все ситуации.

Чтобы справиться с непредсказуемостью, нужно сосредоточиться на создании прочных основ программирования, особенно в JavaScript. Часто HR-менеджеры предпочитают нанимать кандидатов со знанием современных тенденций.

Конечно, большинство разработчиков не останутся без работы за одну ночь. Многие компании имеют программное обеспечение, основанное на Backbone и подобных библиотеках, которые нужно поддерживать. Подобные ситуации позволяют оттачивать навыки и изучать другие инструменты. Но на практике это значит, что новые инструменты придется изучать в свободное от работы время.



Источник: https://infostart.ru/journal/news/zhizn/chem-bolshe-vybora-tem-on-slozhnee-kak-obnovleniya-meshayut-rabote-javascript-programmistov_910612/
Автор:
Сергей Кравченко Обозреватель


Какой язык программирования вы считаете самым сложным?


1С (23.44%, 15 голосов)
23.44%
Java (17.19%, 11 голосов)
17.19%
Javascript (3.13%, 2 голосов)
3.13%
Python (1.56%, 1 голосов)
1.56%
Scala (10.94%, 7 голосов)
10.94%
Swift (1.56%, 1 голосов)
1.56%
Objective C (18.75%, 12 голосов)
18.75%
Go (1.56%, 1 голосов)
1.56%
Rust (4.69%, 3 голосов)
4.69%
Другое (в комментарии) (17.19%, 11 голосов)
17.19%

Комментарии
Избранное Подписка Сортировка: Древо
1. CyberCerber 217 26.09.18 15:55 Сейчас в теме
К опроснику: Brainfuck очень сложный язык.
Jestery; Reaper_1C; DoctorRoza; dimisa; Kochergov; +5 Ответить
4. Darklight 14 26.09.18 16:08 Сейчас в теме
(1)Согласен, но это чисто академический почти абстрактный язык - не применяющийся на практике - просто некое почти бесполезное достижение для Книги рекордов Гиннесса, так же как и поедание хотдогов на скорость! Засорять опросник этим вариантом не стоит - ибо и так понятно, что те, кто о нём знает - выберет именно его, ибо данный язык действительно мозгодробительно сложен. Не отдав голоса за какой-то практический вариант.

Лично мне очень не нравится "Objective C" - он ломает моё сознание! Странно что нет языка "Perl" - тот ещё уродец. Хотя Python, мне тоже не "зашёл". На их фоне языки Java, JavaScript и 1С - вполне красивые и простые языки. Хотя мне больше нравится Scala - хоть это далеко не самый простой в освоении язык! Kotlin бы ещё добавить - как один из самых молодых и быстрорастущих языков на платформе Java Runtime и JavaScript.

И, я считаю, жаль в среде 1С практически нет библиотек (кроме БСП), упрощающих жизнь программистам. И нет никакой конкуренции - а то бы голосовалку на эту тему было бы интересно тоже сделать было бы.... лично мне БСП не нравится - очень громоздкая, постоянно кардинально меняющаяся, плохо документированная, трудно разделяемая на отдельные части - кодохрень! Но, пользы от БСП всё же гораздо больше, чем от если бы её не было :-)
TreeDogNight; Gureev; vrednyi_glavred; uri1978; +4 1 Ответить
18. Поручик 4153 26.09.18 20:49 Сейчас в теме
(4) В веб я начинал именно с Perl'a и он мне никогда не казался уродцем или сложным. Очень мощный язык.
27. herfis 261 27.09.18 10:57 Сейчас в теме
(18) Perl на какой-то момент был "наше все" в качестве скриптового языка общего назначения. Потом эту нишу занял python (и сейчас пока занимает).
2. cerrenesi 26.09.18 15:59 Сейчас в теме
3. katenok86 243 26.09.18 16:05 Сейчас в теме
Самый сложный тот который не знаешь)
TreeDogNight; JohnConnor; darkmessiahan; alex-l19041; A_Max; Krio2; Interrupted; Gang031; protexprotex; Kochergov; +10 Ответить
5. Darklight 14 26.09.18 16:12 Сейчас в теме
(3)Речь как раз про освоение языков. Какие-то осваиваются легче, какие-то труднее. Так же как и с разговорными языками. Английский - учить легко. Китайский - крайне сложно. А, вот, на каком языке будут чаще говорить и писать через 100 лет большинство людей планеты - ещё вопрос: простом английском, или сложном китайском. А может на арабском? Но это уже совсем другая история...
Gang031; Kochergov; +2 Ответить
6. biz-intel 628 26.09.18 16:26 Сейчас в теме
Я бы написал статью, как беспринципные обновления типовых конфигураций 1С мешают работе программистов 1С:)
Gureev; akimych; Gang031; acanta; +4 Ответить
9. protexprotex 155 26.09.18 16:49 Сейчас в теме
(6) Как раз к теме - пишу сейчас на 1С в конфигураторе - сохранил все. Проверил. Все работает. Класс. Вышел из конфигуратора. Потом еще раз зашел чтобы еще кое-что поправить. Бац! - а всего того, что я написал уже в конфе и нет. Вот так вот. Так что 1С - это самый сложный язык - т.к. не всегда то, что ты написал даже сохраняется :-) - тут удача нужна. Ну и этот .... кеш та еще приставка.
TreeDogNight; darkmessiahan; Gureev; tindir; igo1; Gang031; +6 Ответить
11. starik-2005 1419 26.09.18 17:18 Сейчас в теме
(9)
Потом еще раз зашел чтобы еще кое-что поправить. Бац! - а всего того, что я написал уже в конфе и нет.
Ни разу не сталкивался с такой ситуацией, а вот был у нас разработчик один - сталкивался постоянно. Видимо не особо хотелось ему работать.
12. herfis 261 26.09.18 17:29 Сейчас в теме
(11)
Ни разу не сталкивался с такой ситуацией, а вот был у нас разработчик один - сталкивался постоянно. Видимо не особо хотелось ему работать.

Вполне возможная ситуация при наличии сбойного кэша и динамических обновлениях. Возможно, товарищ просто не соблюдал гигиену при разработке :)
13. starik-2005 1419 26.09.18 17:32 Сейчас в теме
(12)
Возможно, товарищ просто не соблюдал гигиену при разработке
Так вроде даже по стандартам разработки все пилят в тестовой базе на тестовом хранилище, при изменениях деплоят в него, а потом уже накатывают на продуктовую базу. Если кто-то разрабатывает что-то в магазине продуктов на окраине населенного пункта с численностью населения в районе 2к, то, конечно, можно и прямо в базу писать, только и динамических обновлений там быть не должно.
Kochergov; +1 Ответить
15. protexprotex 155 26.09.18 17:57 Сейчас в теме
(12) Да нет. В том - то и дело, что это было не динамическое обновления. Разработка велась в копии базы - там не было других пользователей. Самого такое чудо удивило. Причем, только у одного клиента такое у меня было - уже второй раз. Насколько я понимаю, это из-за отложенного сохранения на диск в винде - глюк какой - то.
21. agent00mouse 176 27.09.18 07:54 Сейчас в теме
(11) Три конфигурации в тестовых базах. Доработки вносятся +- равномерно во все, но у одной базы с завидной постоянностью (раз в месяц - полтора) уходит кеш. Может базе работать не хочется , а не программисту?
29. a30v 27.09.18 12:55 Сейчас в теме
(9) Знакомая история с пропажей кода. При чем, бывало, код удалишь, а он все равно выполняется ))
7. acanta 44 26.09.18 16:29 Сейчас в теме
Хирургу всегда мешают лишние движения пациента.
8. herfis 261 26.09.18 16:35 Сейчас в теме
Одно дело языки, другое дело - реальное промышленное программирование на этих языках.
Те же java и javascript - что в них сложного?
А вот инфраструктура реальных современных проектов на них - уууууу...
tindir; Kochergov; +2 Ответить
10. starik-2005 1419 26.09.18 17:17 Сейчас в теме
Какой язык программирования вы считаете самым сложным?
Серьезно куча народа на Инфостарте считает, что самым сложным языком является 1С? Или они вопрос не прочитали и ткнули сразу на знакомое? )))
TreeDogNight; neikist; Kochergov; +3 Ответить
23. Darklight 14 27.09.18 09:54 Сейчас в теме
(10)По-моему это просто стёб, судя по комментариям
14. DoctorRoza 26.09.18 17:55 Сейчас в теме
Не хватает кнопки - Посмотреть результат! ))
16. protexprotex 155 26.09.18 17:58 Сейчас в теме
17. Infactum 265 26.09.18 18:07 Сейчас в теме
Отличное голосование "от гуманитария". Критерий сложности какой?
Из субъективного - C++. И не потому что на нем трудно "просто что-то написать" - в такой нише полно разной эзотерики. Это именно язык, который трудно действительно знать. Одна только спецификация более 1000 страниц чего стоит.
Evil Beaver; Kochergov; +2 Ответить
19. CheBurator 3563 27.09.18 01:02 Сейчас в теме
ну если описание языка 1С порсмотретьсейчас - то на скольо страниц потянет?
ну а Perl - очень даже няшный! когда веб только из штанишек вырос - от нечего делать накропал текстовую базенку и генерил сайт перловым скриптом ... до сих пор на просторах валяется http://tomba.rasc.ru
26. Darklight 14 27.09.18 10:53 Сейчас в теме
(19)Само описание языка программирования (без встроенных функций) 1С можно уложить в несколько десятков страниц. В худшем случае - в 100 страниц! Синтаксис языка очень простой. Описание встроенной библиотеки функций и прикладных объектов - это уже не совсем язык - но потянет ещё где-то на пол тысячи страниц.

Но вообще-то я ранее встречал сравнение языков по сложности - их сравнивают совсем по-другому: описывают синтаксис языка в какой-то единой форме, наиболее популярная форма "Бэкуса-Наура". И сравнивают число слов в таком описании - чем слов больше, тем язык сложнее в освоении. Конечно это тоже спорное решение, ведь тот же ассемблер не так уж богат на синтаксические конструкции. А вообще тут правильно был задан вопрос: а сложность чего измерять то?

Варианты:
1. Сложность освоения/изучения
2. Сложность интерпретации мыслей желаемого результата в элементы синтаксиса языка и его встроенные функции
3. Сложность восприятия и понимания написанного чужого (да и своего) кода и восстановление исходной логики (мыслей желаемого результата)
4. Сложность отладки и поиска ошибок (без учета помощи со стороны IDE)
5. Сложность, определяемая скоростью превращения мыслей реального результата в рабочий вариант в элементах синтаксиса языка (с учетом помощи IDE)
6. Сложность написания эффективных программ (производительных и надёжных)
7. Сложность тех или иных библиотек и фреймворков, написанных для языка, и напрямую влияющих на сложность итоговых программ
8. Сложность, определяемая объёмами различных терминов и синтаксических паттернов языка, которые необходимо запоминать и не путать

Язык 1С очень прост в освоении, в терминах и паттернах; средне сложен в интерпретации мыслей, отладке и анализе чужого кода. И сложность повышаться, когда речь заходит об эффективности написания надёжных и производительных программ. А когда речь заходит о фреймворках, то даже встроенная в платформу объектная модель 1С уже далеко не проста (начиная с редакции 8.3 всё усложняется и усложняется), а если заговорить о БСП - то там уже давно "чёрт голову сломит" и тоже, с каждым годом, всё усложняется и усложняется. Как растёт и сложность типовых конфигураций. И тут, на мой взгляд, проблема уже как раз в ограниченности и излишней простоте синтаксиса 1С и доступных встроенных операциях.

Когда язык не обеспечивает необходимый уровень инструментов для лаконичного выражения современных тенденций в структуре написания алгоритмов - то сами эти структуры начинают излишне обрастать сложными конструкциями и мусором, чтобы обойти эти ограничения и дать рост эффективности конечного результата, который требуется в погоне за мировой тенденцией и конкуренцией! Язык 1С уже безбожно отстал от современного уровня программирования.

Поэтому в мире периодически возникают новые языки, которые учитывают опыт развития более древних языков и новые требования к эффективности программирования - и повышают эту эффективность на новый уровень - без лишних усложнений, без груза старых подходов - только то, что нужно современным разработчикам. Например, когда-то таким языком стал Си или Pascal, или Бейсик - пришедшие на смену Алголам, Фотранам, Адам и Ассемблеру (и дали толчок к развитию более новым - ещё более продвинутым языкам). Или языки C#, Scala пытавшиеся вытеснить Java и C++. Сейчас - появился язык Kotlin - конкурирующий с Java и JavaScript. Это хорошо и для старых языков - это конкуренция заставляет их тоже развиваться.

У языка 1С сейчас нет прямой конкуренции (OneScript пока не в счёт) - язык застрял в начале нулевых в своём развитии, лишь IDE и фреймворк немного развивались - но и их уровень сейчас остался ещё где-то в нулевых годах XXI века. К концу 20-х годов всё это окончательно моральна устареет. В 2030 году будем смотреть на 1С8 так, как сейчас смотрим на 1С7, а то и ещё хуже.

И вряд ли компания 1С за ближайшие 10 лет "выкатит" что-то кардинально новое и свежее во вопросах построения программной архитектуры, даже появление, так не любимой Наралиевым, ООП модели и действительно асинхронного многопоточного программирования - это лишь медленный бег за уходящим в даль поездом, правда если к этому ещё добавить глубокую интеграцию с функциональным стилем и что-то на подобии асинхронного LINQ (из C#), то это могло бы хоть выглядеть как рьяная попытка угнаться за поездом мирового уровня написания программного кода, который через 10 лет умчится ещё дальше).

Ну, или компания 1С попросту откажется от своего собственного языка программирования и перейдёт на какой-то мировой. Например на любимый ими Java (хотя лицензионный скандал компании Google c Oracle тут должен как раз отпугнуть). Тогда выбрать путь компании Google - и перейти на язык Kotlin, сохранив runtime модель Java машины, через механизм трансляции LLVM - в случае чего - это легко поможет сменить и runtime модель в будущем. Но это всё очень кардинально.

Это всё явно не для поколения 1С8 это уже 1С9. А для разработки нового поколение платформы - нужно ого-го как много времени - тут тоже 10 годами уже не отделаешься, вон - 1С 8.4 уже более 3-х лет пилят - и всё никак не забрезжит "свет в конце туннеля" в виде, даже, анонса бета версии. А 1С 8.4 вряд ли станет последней редакцией в поколении 1С8 (такими темпами ждать 1С 8.5 надо где-то к 2025 году, 1С 8.6 выйдет уже после 2030 и только затем будет анонсирована 9-ка, которая выйдет ещё лет через 10 в качестве бета версии).

Но, вероятно, компания 1С уже сейчас, заранее, прощупывает почву дальнейшего развития языка и платформы - серьёзные изменения требуют серьёзной подготовки и сбора аналитических данных. Может и этот опрос - лишь часть этой аналитической работы ;-)
28. starik-2005 1419 27.09.18 11:10 Сейчас в теме
(26)
а сложность чего измерять то?
С точки зрения современных реалий выбора, сложность - это время, которое нужно потратить на то, чтобы начать на этом зарабатывать. Если из этого исходить и взять полностью не умеющего программировать человека, то уже можно примерно оценить сложность того или иного инструмента (языка программирования) для создания приложений.

Если говорить вообще о том, сколько нужно времени, чтобы начать зарабатывать на 1С, то для человека с нуля нужно примерно три месяца. За это время можно научиться писать выражения на любом языке (т.е. "А = 1 + 2 ..." - присваивание), научиться булевой алгебре ("Если А > 10 Тогда ... Иначе ...") и определиться с тем, как меняются объекты (лайф-цикл объекта конфигурации). Также можно освоить простое конструирование запросов (выборки из одной таблицы, соединения, группировки) и научиться строить отчеты с помощью СКД (на уровне простых реестров с отборами).

Т.е. за три месяца при правильном подходе к развитию компетенций можно получить вполне вменяемого разработчика начального уровня (Junior). Дальше уже человек может развиваться самостоятельно, осваивая алгоритмы из того же списка минимализмов Ильдаровича, предварительно обучившись принципиальным методам обхода коллекций, деревьев и преобразования строки. Ну и все. Дальше уже нюансы СУБД и объектных блокировок. За три года можно вполне достичь компетенций эксперта по технологическим вопросам и иметь овер 200к. С другими языками так вряд ли получится.
30. Darklight 14 27.09.18 13:09 Сейчас в теме
(28)По-моему слишком радужно всё расписываете, особенно в конце. Хотя да, соглашусь с тем, что такой путь возможен, но не более 1-2 новичка из сотни пройдут его примерно за 3-4 года и уж тем более получат после овер 200. Ну и я не спорю, что 1С простой язык. С непростыми фреймворками.

Но я не понимаю тех, кто голосует за 1С как за сложный язык! Это больше на стёб похоже.
31. starik-2005 1419 27.09.18 13:16 Сейчас в теме
(30) производительность труда зависит от трех факторов: квалификации, процессов и мотивации. Эффективность обучения зависит в основном от мотивации. Если человек решил для себя, что это ему надо - он сможет за три года освоить весьма глубоко именно 1С и сопутствующий devOps, чтобы стать экспертом по технологическим вопросам. Но это если человек умный, если он способен мыслить и задавать правильные вопросы (в частности - себе), качественно интерпретировать ответы на них и продолжать работать над собой. Если же человек не очень умный и, соответственно, не очень хочет разбираться в нюансах платформы и devOps'а, то он вполне может пойти в РП - вертикальный рост, но для этого тоже нужно поработать над собой, но уже с другой стороны. Таким образом даже не особо умный человек, познакомившийся с платформой, может через 3 года зарабатывать в этой нише вполне хорошие деньги.

Все меняется, когда человек ленив. Тут кроме экзистенциального кризиса ему никто не поможет.
32. Darklight 14 27.09.18 15:14 Сейчас в теме
(31)Имхо - чаще плох тот программист, кто не ленив. Обычно волосы дыбом встают наблюдая что они своим неуёмным рвением генерят! Но, это большинство. Они, конечно же, не есть 100% всех активных трудоголиков - среди них и вполне адекватные программисты есть, готовые, к тому же, не просто качественно код строчить, но и развиваться - но их очень мало!
33. starik-2005 1419 28.09.18 11:13 Сейчас в теме
(32)
Имхо - чаще плох тот программист, кто не ленив.
Я не о программисте говорю, а о человеке, который встал на желтые рельсы и отправился в путь.

А по поводу того, что там генерят неленивые (про "умность" Вы, как я понял, пропустили), то наличие функционала отличается от его отсутствия кардинально. Лучше пусть будет что-то, что работает, пусть и неоптимально, но реализует требуемый функционал, чем не будет ничего. Может быть умный и ленивый программист сделает достаточно сложный продуманный и поддерживаемый код за то же время, за которое неумный трудоголик запилит свой неподдерживаемый простой спагетти-код, но в рамках сложности кода первого для его поддержки уже будет необходим еще один умный, а их мало.
34. herfis 261 28.09.18 11:29 Сейчас в теме
(33)
Лучше пусть будет что-то, что работает, пусть и неоптимально, но реализует требуемый функционал, чем не будет ничего.

Увы, но далеко не всегда. Только если "выбросить" эту реализацию в последующем будет стоить дешево. Другими словами - если не придется менять внешние интерфейсы. В противном случае переделка может стоить настолько дорого, что гораздо дешевле было бы обождать с реализацией. Конечно же, сильно зависит от сроков на "обождать" и ценности функциональности.
35. starik-2005 1419 28.09.18 11:44 Сейчас в теме
(34)
В противном случае переделка может стоить настолько дорого, что гораздо дешевле было бы обождать с реализацией.
Пример можно?
36. herfis 261 28.09.18 11:57 Сейчас в теме
(35) Переделать кривой отчет - очень дешево. У него вообще нет внешних зависимостей.
Переделать криво заложенную архитектуру подсистемы (пусть даже небольшой) на базе которой начали строиться новые инструменты и выстраиваться бизнес-процессы - гораздо дороже.
37. starik-2005 1419 28.09.18 12:05 Сейчас в теме
(36)
Переделать криво заложенную архитектуру подсистемы
А пример будет? Конкретный.
38. herfis 261 28.09.18 12:13 Сейчас в теме
(37) Остаточный регистр с незакрываемыми измерениями, например. Или еще конкретнее?
39. starik-2005 1419 28.09.18 13:02 Сейчас в теме
(38) а в чем проблема закрывать измерения? Сделать регламент - пять минут.
40. herfis 261 28.09.18 13:11 Сейчас в теме
(39) Вы так ловко расправились с самым простым примером, который я смог придумать, что не вижу смысла продолжать спор. С более сложными примерами вы расправитесь еще ловчее. Фрактальное подпирание подпорок конечно же работает. До какой-то степени. Только лучше без меня.
41. starik-2005 1419 28.09.18 13:53 Сейчас в теме
(40)
Фрактальное подпирание подпорок конечно же работает.
Все зависит от удовлетворенности клиента. Если система работает так, как должна работать, то заказчику важно не то, как это сделано, а то, сколько времени на это потребовалось.

Вряд ли можно накосячить в архитектуре так, чтобы все состояло из подпорок. Не отрицаю, что существуют гении, но не уверен, что они будут способны просидеть на одном месте достаточное для этого количество времени.
43. herfis 261 28.09.18 15:47 Сейчас в теме
(41)
Если система работает так, как должна работать

Это очень лукавая формулировка. Потому что требования к бизнес-приложениям динамичны. Зачастую ОЧЕНЬ динамичны. Гораздо динамичнее адекватного срока эксплуатации системы. Естественно, мы не обсуждаем ситуации, когда заказчика все устраивает. Проблемы возникают, когда за очередную доработку ему выкатывают неадекватный по его ощущениям ценник или когда система резко начинает тормозить и глючить при начале параллельного ввода данных или появлении пары филиалов. Он-то подразумевал что платит деньги за адекватно масштабируемую систему, а не за автоматизацию одного рабочего места с тремя кнопками для ввода трех документов в неделю отныне и на веки вечные, хотя изначально его все устраивало.
Вряд ли можно накосячить в архитектуре так, чтобы все состояло из подпорок. Не отрицаю, что существуют гении, но не уверен, что они будут способны просидеть на одном месте достаточное для этого количество времени.

Гении или нет, но скорость нарастания технического долга обратно пропорциональна квалификации разработчиков. А уже появившиеся подпорки провоцируют появление новых и скорость нарастания технического долга увеличивается - я не зря вспомнил про фракталы. Потому что всегда проще впиндюрить еще одну подпорку, чем пытаться обосновать внезапные немаленькие трудозатраты на рефакторинг. Тут даже грамотный специалист может оказаться в ситуации, когда деваться некуда - переступит через себя и рыдая втулит костыль под костыль. Потому что еще не факт, что трудозатраты на рефакторинг окупятся. Но технический долг при этом вырастет и потенциальная стоимость будущего рефакторинга возрастет. Чем больше технический долг - тем выше совокупная стоимость владения системой. Стоимость поддержки и развития будет постоянно расти, скорость разработки - постоянно снижаться. В конце-концов система превратится в такого толстокожего монстра, что станет дешевле его пристрелить и вложиться в сложный и дорогой переход на новую систему. Квалифицированные разработчики способны значительно отодвинуть этот момент и сэкономить предприятию кучу денег.
Ессно нет смысла пыхтеть над идеальной архитектурой, если более простое и быстрое решение обеспечит приемлемый срок нормальной эксплуатации или гарантирует быстрый рефакторинг в случае необходимости. Проблема в грамотном отделении мух от котлет. А тут, к сожалению, только опыт, сын ошибок трудных.
44. starik-2005 1419 28.09.18 15:59 Сейчас в теме
(43)
костыль под костыль
Помню как раз на прошлом месте занятости было несколько костыльных механизмов, которые разработали франчи. И только один в итоге я перепилил полностью, при этом тот мой полный перепил еще раз перепилили.

Т.е. ничто не защищает архитектуру от модернизации - даже качественная идея в ядре, т.к. изменения могут коснуться и принципиальных моментов.

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

А та часть технического долга, которая оказалась в надежном банке, - да, будет однажды востребована кредиторами, и на нее будет выделен соответствующий ресурс. И даже при этом новая архитектура не будет гарантировано без костылей. Я, например, видел крайне мало решений, где явные костыли отсутствовали. Зато концепций о безкостыльности от теоретиков слышал немало. Это такие вот "Аркаши" из одной публикации гражданина из ОкноСофта - они могут бесконечно вылизывать архитектуру, а требования - они ограничены временными рамками терпения заказчиков.

-----------------

Вообще, существует такая штука, как CMM - зрелость процессов организации, разрабатывающей софт. Там есть пять уровней. Так вот на последнем уровне как раз зрелость процессов достигает уровня, при котором и бюджет, и сроки соблюдаются, и технологии последние самые используются. Для подобного уровня характерны такие вещи, как ревью кода, парное программирование, постоянное повышение квалификации сотрудников и прочие моменты. В большинстве компаний, внедряющих 1С своими силами или силами франча о таких вещах никто не знает. Большинство франчей повышает квалификацию разработчиков и РП-ников только на уровне сертификации в 1С, которая и сама далека от CMM 5 - дай Боже на 3-ку у них там дела обстоят.
45. herfis 261 28.09.18 16:48 Сейчас в теме
(44) Отчасти соглашусь, отчасти нет. Те же системы уровня предприятия переписываются нечасто, это не интернет-стартапы. Слишком дорого. Потому и "кровавый энтерпрайз". В кровавом энтерпрайзе технический долг - это настоящий бич. Его мало не бывает. И бог знает, сколько лишних денег платят предприятия за толкание этого воза. Тут уж явно экономия на квалификации разработчиков выйдет боком. Квалифицированный и опытный разработчик априори генерит в разы меньше технического долга, чем неквалифицированный. Причем зачастую при тех же трудозатратах. Он просто предвидит наиболее вероятные сценарии развития функциональности и выбирает те варианты реализации, которые лучше в них впишутся при необходимости.
20. insurgut 185 27.09.18 06:34 Сейчас в теме
Ассемблер, бедный, все про тебя забыли :(
Shef_zeon; darkmessiahan; Неопределено; +3 Ответить
22. DoctorRoza 27.09.18 09:32 Сейчас в теме
(20) Да статью-то гуманитарий писал. Не упамянул Clojure, а это уже функциональное программирование и т.д.
24. Darklight 14 27.09.18 10:03 Сейчас в теме
(22)В статье заведомо только императивные языки. А вот С++ да, забыли. Про ассемблер лучше не вспоминать - да, конечно на нём и сейчас пишут, но это, всё-таки язык из совсем другой ниши, чем языки из голосования. Хотя, я, наверное, понимаю по какому принципу отобраны языки - по принципу того, что они являются либо скриптовыми, либо используют виртуальную машину или компилируются в исполняемый байт код через LLVM (из этого принципа, наверное, только "Objective C " выделятся; хотя может ещё Go - не знаю, зачем он тут вообще, лучше бы Groovy привели; ну и C# тогда тоже забыли).
25. returnigor 27 27.09.18 10:16 Сейчас в теме
Haskell на мой взгляд сложный.
42. starik-2005 1419 28.09.18 14:08 Сейчас в теме
ЗЫ: Вообще, всегда есть два пути: искать причины и искать возможности.
Оставьте свое сообщение

См. также