Как вы развиваетесь на работе?
При этом забивать на изучение чего-то нового нельзя, так как можно оказаться в неприятной ситуации, когда ты твоя платформа разработки устарела, и твой опыт стал нерелевантен на рынке труда.Только щас в программирование столько технологий и знаний, что даже ботая по часу в день что-то новое с вероятностью 95% ты это не будешь использовать в дальнейшем.
Новые задачи будут требовать тех знаний которые с большой вероятностью ты не будешь знать, ботая хоть в час в день.
Поэтому лучше ботать либо под задачу, либо то что нравиться.
Ботать из принципа, надо знать - пригодиться может быть. В программировании глупо,
Лучше ботать другое. К примеру тот же английский
Только щас в программирование столько технологий и знаний, что даже ботая по часу в день что-то новое с вероятностью 95% ты это не будешь использовать в дальнейшем.Не согласен, за последние 15 лет никаких новых технологий для мейнстримного программирования не появилось. К тому же есть такой эффект, что чем больше знаешь, тем быстрее осваиваешь новое.
Не согласен, за последние 15 лет никаких новых технологий для мейнстримного программирования не появилось.ты до сих пор на паскале пользуешся чтоли?
будет у тебя задачи, для ее реализации тебе нужно знать:
x1, x2, x3
а ты будешь знать y1, y2, y3
и не совпадение твоих знаний будет 95%
Да даже если ты 200 лет будешь упарывать программирование.
Тебе всеравно придеться читать доки средств x1, x2, x3
"Я учусь для того чтобы , после я мог быстрее учуcь" - клевая логика, лол
Это и есть цель жизни наверно )
и не совпадение твоих знаний будет 95%это означает, что ты новичок, который вообще ничего не знает.
ps
Алгоритмы и структуры данных от времени слабо меняются.
Архитектурные решения тоже слабо меняются.
Основные подходы тоже одни и те же. gui что на tcl/tk, что на html/javascript строится из одних и тех же блоков. Потоки управления они и в Африке потоки управления.
Меняется только api библиотек, и растут языковые возможности.
Алгоритмы и структуры данных от времени слабо меняются.ну тогда круто
Архитектурные решения тоже слабо меняются.
Основные подходы тоже одни и те же. gui что на tcl/tk, что на html/javascript строится из одних и тех же блоков. Потоки управления они и в Африке потоки управления.
я это все знаю
Побочные проекты стараюсь делать на самых современных технологиях
Ищу ответы на хитрые вопросы на stackoverflow.
Периодически делаю до уровня прототипа всякие "невозможные" вещи.
Ищу ответы на хитрые вопросы на stackoverflow.
Периодически делаю до уровня прототипа всякие "невозможные" вещи.
я это все знаютогда не понятно откуда взялась оценка различия на 95%
Архитектурные решения тоже слабо меняются.15 лет назад не было такого засилья NoSQL-я
15 лет назад не было такого засилья NoSQL-я15 лет назад sql особо не было (даже тот же dbf читали без sql так что можно считать, что тогда и так был NoSql.
уже были Oracle 8 и SQL Server 7.0
15 лет назад не было такого засилья NoSQL-яДумаю, 15 лет назад больше nosql было (IMS, MUMPS). В википедии написано что есть система на MUMPS которая выполняет 12 млрд транзакций в день, а внедрена она как раз была в то время. В наши дни новые проекты скорее на оракле начинают.
В такой ситуации разработчик, который наебывал своего работодателя, может быстро адаптироваться, а тот, кто тянул на себе продукт, делая грязную работу, оказывается никому не нужен.Если качать скил наёбывания, то, да, скорее всего, зарабатывать будешь. Мошенники всегда были и будут.
Несправедливо, что самые тяжелые проекты, на устаревших технологиях и с большим техническим долгом, оказываются самыми непрестижными и хуже всего выглядят в резюме.
А вот этот вывод звучит странно...
Наоборот, замечательно, что в обществе возникает причина, которая отталкивает программистов от проектов с большим техническим долгом. Долги надо отдавать. Например, кто программисту мешает технический долг преобразовать в денежный, запросив зп на 20% больше, и уходить на 2 месяца в год в отпуск за свой счет для изучения релевантных технологий?
Я когда кота выгуливаю, читаю референсы языков программирования.
Вперемешку с книгами, правда.
Вперемешку с книгами, правда.
уже были Oracle 8 и SQL Server 7.0но ими пользовалась только часть рынка. Средние проекты, скорее ими не пользовались, чем пользовались.
та же 1с переползла на sql server не так уж давно.
ps
для текущей школоты стандарт: php + mysql, а тогда это был delphi + paradox (без sql-я) или VB + access (без sql-я)
Ботать имеет смысл фундаментальные вещи: алгоритмы, теория, книжки классиков. Изучение очередного NoSQL проекта - бесполезная трата времени.
Кстати, Coursera в этом плане очень интересные курсы предоставляет.
Кстати, Coursera в этом плане очень интересные курсы предоставляет.
имеет смысл фундаментальные вещи: алгоритмы, теория, книжки классиковКаков этот смысл?
Гы. Пожалуй, для придумывания изощренных функиональщин на сишарпе - и правда, никакого 
Зачем учить то, что в жизни не используешь? Как будто человек - это компьютер, который один раз взботнул и все на всю жизнь запомнил. Реально память очень быстро стирается, а всякий хлам, который видел один раз в жизни, исчезает еще быстрее. Т.е. ты фактически проебываешь этот час впустую.
Гы. Пожалуй, для придумывания изощренных функиональщин на сишарпе - и правда, никакогоа просто без подъебок слабо написать каков смысл?
Пока я вижу, что смысл читать "фундаментальные вещи: алгоритмы, теория, книжки классиков", в том, чтобы быть таким: лучше посчитаю, что собеседник тупое быдло сишарпер, чем подумаю над вопросом и отвечу или просто молча пройду мимо.
а просто без подъебок слабо написать каков смысл?Смысл такой, что фундаментальные вещи практически не устаревают, в отличие от технологий. Это как бы даже в МГУ студентам объясняют.
Смысл такой, что фундаментальные вещи практически не устаревают, в отличие от технологий. Это как бы даже в МГУ студентам объясняют.почему/зачем надо учить не устаревающие вещи?
завтра вот проснешься, откроешь хаскер-ньюз,
а там: "Майкрософт придумала Ъ#, который на полшишечки чем-то лучше, чем С#,
так что С# идет лесом и никому не нужен"
сначала зарубежом, а через год-два и в России
при этом разработчики Ъ# - это будут именно те, кто ботал IT как науку,
а те которые выучат его - просто консьюмеры и модные хипстеры
я вот изучаю с++ (именно не учу, а изучаю) и фунд. вещи
так что готов даже к ядерной войне
а там: "Майкрософт придумала Ъ#, который на полшишечки чем-то лучше, чем С#,
так что С# идет лесом и никому не нужен"
сначала зарубежом, а через год-два и в России
при этом разработчики Ъ# - это будут именно те, кто ботал IT как науку,
а те которые выучат его - просто консьюмеры и модные хипстеры
я вот изучаю с++ (именно не учу, а изучаю) и фунд. вещи
так что готов даже к ядерной войне
почему/зачем надо учить не устаревающие вещи?Почему это "надо"? Никто не заставляет. Но если уж есть желание и время обучаться, лучше его потратить с толком.
Ты знаешь, я сначала стал писать серьезный ответ, от примеров, что пригождалось лично мне, до примеров, чего бы не появилось в мире, если бы не алгоритмы.
А потом подумал - какого черта я трачу свое время, чтобы объяснить очевидные вещи человеку, который и так сам все понимает, но почему-то хочет поспорить с этим. И просто ограничился подъебкой.
Если тебе правда хочется поговорить об этом, то, я думаю, разумно будет перейти сразу к твоей аргументации. С чего ты решил, что это все бесполезно?
А потом подумал - какого черта я трачу свое время, чтобы объяснить очевидные вещи человеку, который и так сам все понимает, но почему-то хочет поспорить с этим. И просто ограничился подъебкой.
Если тебе правда хочется поговорить об этом, то, я думаю, разумно будет перейти сразу к твоей аргументации. С чего ты решил, что это все бесполезно?
завтра вот проснешься, откроешь хаскер-ньюз,Так и происходит, Хельсберг выпускает TypeScript, он мне также нравится как и C#. И заботать его не проблема. Дело ж не в конкретном языке, конкретный язык это реализация некоторых общих принципов. Ботать общие принципы без применения конкретных реализаций также плохо, как и не обладать знаниями об общих, фундаментальных принципах.
а там: "Майкрософт придумала Ъ#, который на полшишечки чем-то лучше, чем С#,
так что С# идет лесом и никому не нужен"
сначала зарубежом, а через год-два и в России
при этом разработчики Ъ# - это будут именно те, кто ботал IT как науку,
а те которые выучат его - просто консьюмеры и модные хипстеры
теория и книжки классиков тру, когда они показывают как надо делать, и как надо писать код.
Но зачем, например, упарываться по алгоритмам сортировки, если в своей работе далек от этой темы, я хз.
Но зачем, например, упарываться по алгоритмам сортировки, если в своей работе далек от этой темы, я хз.
Но зачем, например, упарываться по алгоритмам сортировки, если в своей работе далек от этой темы, я хз.Упарываться и не нужно. Но, например, будет очень полезно понимать, что при реализации алгоритма Дейкстры вместо сортировки на каждом шаге лучше пройти массив, а вместо обхода массива лучше использовать кучу (в последнем случае даже кода меньше, чем в любом из двух предыдущих).
99% программистов используют не те коллекции, которые нужно было бы использовать в конкретном месте программы. Конечно, всё время слышны отмазки о том, что здесь никогда не будет много элементов. Да и вообще всё быстро работает, а этот метод вызывается редко, лучше повысить читаемость, написать код попроще. И machine cycles are cheap. А в результате у кого-то "тормозит Java".
Но зачем, например, упарываться по алгоритмам сортировки, если в своей работе далек от этой темы, я хз.Наверное, незачем. Мне вот интересна тема информационной безопасности, а на работе она мне нах не нужна. Более того, коллеги надо мной ржут и прикалываются, когда узнают, что я прохожу бесплатный курс по криптографии.
А в результате у кого-то "тормозит Java".В .Net с коллекциями проще, поэтому упарываться, действительно, не надо. Надо знать пару/тройку правил и для практического применения этого хватает в подавляющем большинстве случаев.
Упарываться и не нужно. Но, например, будет очень полезно понимать, что при реализации алгоритма Дейкстры вместо сортировки на каждом шаге лучше пройти массив, а вместо обхода массива лучше использовать кучу (в последнем случае даже кода меньше, чем в любом из двух предыдущих).Можешь написать какая от этого польза?
Можешь написать какая от этого польза?Не еби мозг читателям и писателям этого раздела, как овца себя ведёшь.
В .Net с коллекциями проще, поэтому упарываться, действительно, не надо.Говорили об алгоритмах и структурах данных, а не про .NET. Но раз уж зашла речь, то разработчики .NET спокойно умудряются запутаться и в том мизерном количестве, которое им предлагают.
разработчики .NET спокойно умудряются запутаться и в том мизерном количестве, которое им предлагают.откуда ты это знаешь?
откуда ты это знаешь?Откуда ты знаешь, что это не так?
Можешь написать какая от этого польза?Всякая разная. Если не знаешь тонкостей того, какие действия скрывают используемые методы, алгоритмы, структуры данных, и что в конкретном случае оптимальнее применить, то рано или поздно наткнешься на то, что прога без очевидных причин вдруг начнет дико тормозить или вообще не делать того, что требуется. Какая сложность метода - линейная или константная, в каких случаях происходит выделение памяти, используется ли стек или куча, как вообще работает управляемая куча в том же .NET, имеет ли место упаковка и распаковка - только ясно осознавая это и многое другое, можно не бояться подводных камней. А они могут резко снизить производительность не только программы, но и самого программиста.
Польза такая, что ты такой раз, садишься, и пишешь A*, который строит маршруты через всю землю в онлайне с мильенами пользователей.
Или, в более близком нам масштабе, такой раз, садишься, и за вечер пишешь хрень, которая эксепшены из гигабайтов логов выгрепывает, классифицирует, аннотирует, и шлет Васе по почте - мол, ты сегодня вот закоммитил кусок кода, а из-за твоего коммита такой вот процесс стал сыпать вот такими эксепшенами.
Или такой садишься и пишешь бота, который на ауке д3 арбитражит.
Стандартная отмаза - типа, вот когда мне идея в голову придет - тогда я и нагуглю как эту проблему решать.
Так вот как показывает практика, хрен тебе идея в голову придет. Ну то есть, идея то может и придет, но будет отложена как нерешаемая или сложнорешаемая. А другой чувак, с менее раздутым эго и более уважительным отношением к алгоритмам, просто сядет и за час напишет реализацию.
Можешь еще вот тут и тут почитать.
Или, в более близком нам масштабе, такой раз, садишься, и за вечер пишешь хрень, которая эксепшены из гигабайтов логов выгрепывает, классифицирует, аннотирует, и шлет Васе по почте - мол, ты сегодня вот закоммитил кусок кода, а из-за твоего коммита такой вот процесс стал сыпать вот такими эксепшенами.
Или такой садишься и пишешь бота, который на ауке д3 арбитражит.
Стандартная отмаза - типа, вот когда мне идея в голову придет - тогда я и нагуглю как эту проблему решать.
Так вот как показывает практика, хрен тебе идея в голову придет. Ну то есть, идея то может и придет, но будет отложена как нерешаемая или сложнорешаемая. А другой чувак, с менее раздутым эго и более уважительным отношением к алгоритмам, просто сядет и за час напишет реализацию.
Можешь еще вот тут и тут почитать.
Why? Because the first step to applying mathematics is problem identification. If you have a problem to solve, and you have no idea where to start, it could take you a long time to figure it out. But if you know it's a differentiation problem, or a convex optimization problem, or a boolean logic problem, then you at least know where to start looking for the solution.
используется ли стек или кучаа это важно? Я вот помню под линукс народ пишет без оглядки на стек. Когда я пытался скомпилить что-то из зависимостей mplayer под винду, то пришлось быстренько написать патч, который выделение массивов переносит в кучу. Из чего я заключаю, что проблемы стек-куча платформеннозависимые
Или такой садишься и пишешь бота, который на ауке д3 арбитражит.Я вот немного знаю алгоритмы, но я вообще не знаю, что такое "ауке д3 арбитражит". Мне надо дальше ботать алгоритмы, чтобы узнать это? Или из твоего поста получилось обратное, надо знать конкретные вещи?
С логами и api для карт ситуация похожая.
...Гораздо чаще "прога начнет тормозить или вообще не делать того, что требуется + снизить производительность самого программиста" по причине использования ORM или ООП. Кстати, вопрос, ORM и ООП описаны в книжках классиков?
начнет дико тормозить или вообще не делать того, что требуется
...
Какая сложность метода - линейная или константная, в каких случаях происходит выделение памяти, используется ли стек или куча, как вообще работает управляемая куча в том же .NET, имеет ли место упаковка и распаковка - только ясно осознавая это и многое другое, можно не бояться подводных камней. А они могут резко снизить производительность не только программы, но и самого программиста.
Why? Because the first step to applying mathematics is problem identification. If you have a problem to solve, and you have no idea where to start, it could take you a long time to figure it out. But if you know it's a differentiation problem, or a convex optimization problem, or a boolean logic problem, then you at least know where to start looking for the solution.Вот пускай и думают ученые, как решить problem identification без заботывания ВСЕХ алгоритмов.
В Диабло3 есть аукцион вещей. На этом аукционе можно так или иначе покупать/продавать шмот за реальные деньги. Есть шмотки, которые стоят сотни баксов за штуку. Много народа не в теме, и когда им такая фигня дропается, выставляют ее на аук на порядки дешевле феир прайса. Соответственно, самый простой способ заработка - "арбитражить" такие штуки.
Этим занимаются все кому не лень, написаны боты, етц. Сейчас, чтобы что-то зарабатывать, нужна какая-то экспертная модель, которая учится сама, а не работает по вшитым в нее куцым правилам.
С логами и картами что тебе непонятно?
Этим занимаются все кому не лень, написаны боты, етц. Сейчас, чтобы что-то зарабатывать, нужна какая-то экспертная модель, которая учится сама, а не работает по вшитым в нее куцым правилам.
С логами и картами что тебе непонятно?
я вот изучаю с++ (именно не учу, а изучаю) и фунд. вещиФортрана в списке нет, не готов.
так что готов даже к ядерной войне
В Диабло3 есть аукцион вещей. На этом аукционе можно так или иначе покупать/продавать шмот за реальные деньги. Есть шмотки, которые стоят сотни баксов за штуку. Много народа не в теме, и когда им такая фигня дропается, выставляют ее на аук на порядки дешевле феир прайса. Соответственно, самый простой способ заработка - "арбитражить" такие штуки.а что не сразу биржевого робота писать?
Этим занимаются все кому не лень, написаны боты, етц. Сейчас, чтобы что-то зарабатывать, нужна какая-то экспертная модель, которая учится сама, а не работает по вшитым в нее куцым правилам.
Написать ты можешь что угодно, главное - чтобы оно дело делало.
В Диабло3 есть аукцион вещей. На этом аукционе можно так или иначе покупать/продавать шмот за реальные деньги. Есть шмотки, которые стоят сотни баксов за штуку. Много народа не в теме, и когда им такая фигня дропается, выставляют ее на аук на порядки дешевле феир прайса. Соответственно, самый простой способ заработка - "арбитражить" такие штуки.Ты не понял моего предыдущего поста. Для того, чтобы пришла идея надо знать Диабло3 (хотя бы о ее существовании). Если продолжить мысль и немного утрировать, то идеи приходили Стиву Джобсу, а реализовывал Стив Возняк.
Этим занимаются все кому не лень, написаны боты, етц. Сейчас, чтобы что-то зарабатывать, нужна какая-то экспертная модель, которая учится сама, а не работает по вшитым в нее куцым правилам.
С логами и картами что тебе непонятно?
Стив Джобс не знал алгоритмов, зато прослушал в колледже курс о начертании шрифтов в полиграфии.
Здрасьте приехали. Причем тут откуда тебе пришла идея? Ку-ку. Разговор идет про _способность реализации_ идей и роль алгоритмов в этом.
Ты прикидываешься, что не понимаешь, нафига алгоритмы. Типа, ты и так, видимо, способен любую идею без алгоритмов реализовать. Вот я тебе и накидал список идей, с посылом - ну давай, реализуй это без релевантных знаний.
Полагаю, ты свято уверен, что тот же Возняк не знал электродинамики. Рассыпухи накидал там у себя в гараже, по мануалу развел, и вуаля.
Ты прикидываешься, что не понимаешь, нафига алгоритмы. Типа, ты и так, видимо, способен любую идею без алгоритмов реализовать. Вот я тебе и накидал список идей, с посылом - ну давай, реализуй это без релевантных знаний.
Полагаю, ты свято уверен, что тот же Возняк не знал электродинамики. Рассыпухи накидал там у себя в гараже, по мануалу развел, и вуаля.
Гораздо чаще "прога начнет тормозить или вообще не делать того, что требуется + снизить производительность самого программиста" по причине использования ORM или ООП.И ещё чаще она начинает тормозить при использовании функциональщины в языке, который для этого не предназначен. Передавай привет O(N^2)
в языке, который для этого не предназначен.Таких не бывает.
^_^Таких не бывает. ^_^Увы, это как раз случай C#
Я бы сформулировал определение функционального языка как "язык, в котором есть замыкания". C, например, ими не обладает, и пытаться их там смоделировать то еще удовольствие.
Неужели в C# их нет?
Это какой-то C♭.
Неужели в C# их нет?
Это какой-то C♭.
Я бы сформулировал определение функционального языка как "язык, в котором есть замыкания".Ну щас КОНТРА придёт и тебе всё объяснит, моё дело маленькое...
похоже, намекает на то, что в .net-а маловато оптимизаций заточенных под функциональную парадигму.
Например, не хватает следующего:
1. развертывание хвостовой рекурсии (в каком-то виде может уже и появилось)
2. агрессивное выкидывание функций из исполнения, если их результат не используется
3. автоматическое преобразование иммутабельного кода в мутабельный для исполнения
Например, не хватает следующего:
1. развертывание хвостовой рекурсии (в каком-то виде может уже и появилось)
2. агрессивное выкидывание функций из исполнения, если их результат не используется
3. автоматическое преобразование иммутабельного кода в мутабельный для исполнения
1. развертывание хвостовой рекурсии (в каком-то виде может уже и появилось)Че все так привязались к рекурсии.
Либо хвостовые вызовы есть, либо их нет. Большое одолжение в виде самовызова не может считаться.
, похоже, намекает на то, что в .net-а маловато оптимизаций заточенных под функциональную парадигму.Скорее, похоже, сам не понимает (зовет Контру) и поэтому боится непонятной штуки "функциональщина". Например, его заявление о O(N^2) отношение к функциональному программированию не имеет, это лишь один из строхов -а.
Например, не хватает следующего:в Javascript этого тоже всего нет
1. развертывание хвостовой рекурсии (в каком-то виде может уже и появилось)
2. агрессивное выкидывание функций из исполнения, если их результат не используется
3. автоматическое преобразование иммутабельного кода в мутабельный для исполнения
Скорее, похоже, сам не понимает (зовет Контру) и поэтому боится непонятной штуки "функциональщина". Например, его заявление о O(N^2) отношение к функциональному программированию не имеет, это лишь один из строхов -а.Я хочу сохранить этот пост как великолепный пример поверхностных знаний Шуреска.
в Javascript этого тоже всего нетjavascript уж точно не является примером хорошего языка.
javascript уж точно не является примером хорошего языка.Ну уж получше Java.
3. автоматическое преобразование иммутабельного кода в мутабельный для исполненияЧто это значит?
Ну уж получше Java.А Java получше C#. Тогда получается, что JavaScript получше C#, с чем я не готов согласиться.
Что это значит?когда, например, код вида (пример утрированный):
var s1 = GetS;
s2 = new S(s1.x, s1.y, s1.z + 5);
class S
{
public S(int x, int y, int z){this.x = x; this.y = y; this.z = z;}
public readonly int x;
public readonly int y;
public readonly int z;
}
преобразуется в код следующего вида (при условии, что s1 больше нигде не используется)
var s2 = GetS;
s2.z += 5;
А Java получше C#.едва ли.
скорее все-таки так: C# лучше, чем Java. а Java framework лучше, чем .net framework
едва ли.Ты не понял глубинный смысл моего поста.
скорее все-таки так: C# лучше, чем Java. а Java framework лучше, чем .net framework
Интересно. В реализациях каких языков такое есть?
Например, я слышал, что затраты на копирование памяти (коллекций, в основном) - бич производительности в эрланге, там это есть?
Например, я слышал, что затраты на копирование памяти (коллекций, в основном) - бич производительности в эрланге, там это есть?
Интересно. В реализациях каких языков такое есть?Ну вероятно, во всех чистых языках, где GC настолько хитрый и жадный, что способен сразу же доказать, что транзиентный объект больше не будет использоваться, и подсказать имплементации, что его место можно тут же использовать под объект того же типа, переиспользуя структуру, не?
> 3. автоматическое преобразование иммутабельного кода в мутабельный для исполнения
Что это значит?
Это как здесь:
http://github.com/munificent/vigil
"When a Vigil program is executed, Vigil itself will monitor all oaths (implorations and swears) that have been made. If an oath is broken, the offending function (the caller in the case of implore and the callee in the case of swear) will be duly punished.
How?
Simple: it will be deleted from your source code."
Ну вероятно, во всех чистых языках, где GC настолько хитрый и жадный, что способен сразу же доказать, что транзиентный объект больше не будет использоваться, и подсказать имплементации, что его место можно тут же использовать под объект того же типа, переиспользуя структуру, не?Назови хоть один язык, где это реализовано. Кроме разве что уникальных массивов в Clean. C записями там теоретически такой трюк возможен, но на практике не использовался.
Назови хоть один язык, где это реализовано.А какой сейчас год?
After enough runs, Vigil promises that all remaining code meets its oaths.Подозрительное какое-то заявление.
ты забыл ещё сравнить jvm и виртуальную машину .net. Как-то стрёмно писать на языке, зная, что в один момент твой код может превратиться в тыкву, когда какой-нибудь беглый системный администратор ЦРУ расскажет что и для них MS для встроила бэкдор в виртуальную машину.
Подозрительное какое-то заявление.если оно оказывается неправдой, то vigil делает сеппуку и удаляет свой код с гитхаба
Why? Because the first step to applying mathematics is problem identification. If you have a problem to solve, and you have no idea where to start, it could take you a long time to figure it out. But if you know it's a differentiation problem, or a convex optimization problem, or a boolean logic problem, then you at least know where to start looking for the solution.Хорошее объяснение. Систематизация знаний может существенно уменьшить объем усилий (йопт, я реально это объясняю на форуме МГУ?). Знаешь B*-дерево -> знаешь любую СУБД.
йопт, я реально это объясняю на форуме МГУ?Во-во, меня тоже не покидает это же ощущение.
Мне кажется, это у 'а какой-то неудачный день троллинга был.
если оно оказывается неправдой, то vigil делает сеппуку и удаляет свой код с гитхабаНу вот следует ожидать. Бросается на меч.
И у всех, кто его скачал, удалится.
Или нет, обреет голову и поступит в услужение к пхп.
Бросил читать примерно на середине, а вообще - хотелось бы услышать, чем плох "Refactoring based developement" - ты знаешь алгоритмы, но не идеально, знаешь паттерны, но не досконально и просто неплохо владеешь общим IT-оглавлением. Ты пишешь продакшн проект в соответствии со своими представлениями об этом жестоком мире, после чего проходишь по нему тайм-профайлером и находишь бутылочное горлышко. В этот момент у тебя есть рафинированная постановка задачи по оптимизации, которую ты за день, с гуглом в помощь, проводишь.
По совокупным временным затратам это почти всегда превосходит изначальный perfect code. И дает результат, уступающий этому перфекту на какие-то проценты (пусть даже десятки процентов) времени, но решающий текущую задачу.
Так вот, данный подход ведет к тому, что тебе даже толком не надо видеть задачи - их постановки появляются сами в процессе итеративных оптимизаций, а от тебя лишь требуется знать "оглавление" - то, что те или иные задачи вообще человечеством решались и, вероятно, к их опыту можно проаппелировать в этом случае.
Чем это плохо?
Я вот считаю, что язык программирование, это в первую очередь его сообщество - набор инструментов, предоставляемых не чистым языком, а задач решенных другими людьми и созданных грамотных решений. И его знать( быть в курсе в удовлетворительной степени) - нужно, многие такие модули вкупе с убеждением "это было в симпсонах" реально увеличивают твою эффективность и дает больше времени на perfect code для души.
What's wrong?
По совокупным временным затратам это почти всегда превосходит изначальный perfect code. И дает результат, уступающий этому перфекту на какие-то проценты (пусть даже десятки процентов) времени, но решающий текущую задачу.
Так вот, данный подход ведет к тому, что тебе даже толком не надо видеть задачи - их постановки появляются сами в процессе итеративных оптимизаций, а от тебя лишь требуется знать "оглавление" - то, что те или иные задачи вообще человечеством решались и, вероятно, к их опыту можно проаппелировать в этом случае.
Чем это плохо?
Я вот считаю, что язык программирование, это в первую очередь его сообщество - набор инструментов, предоставляемых не чистым языком, а задач решенных другими людьми и созданных грамотных решений. И его знать( быть в курсе в удовлетворительной степени) - нужно, многие такие модули вкупе с убеждением "это было в симпсонах" реально увеличивают твою эффективность и дает больше времени на perfect code для души.
What's wrong?
Чем это плохо?На седьмом месяце аптайма узнаешь.
Когда 24/7-сервис упадет.
Неизвестно почему.
Продакшн проект с релизом раз в две недели и околомиллионным DAU, живой уже три года как.
Для "внезапных падений" - есть QA и автотесты.
А падения, которые этим не покрылись локализуются через лог и агреггированные стэктрейсы и убираются.
Опять же, локализация задачи.
Соседний отдел, который пишет perfect core - до сих пор его пишет... пишет ... пишет...
Для "внезапных падений" - есть QA и автотесты.
А падения, которые этим не покрылись локализуются через лог и агреггированные стэктрейсы и убираются.
Опять же, локализация задачи.
Соседний отдел, который пишет perfect core - до сих пор его пишет... пишет ... пишет...
локализуются через лог и агреггированные стэктрейсы
есть QA и автотесты.О, я тут недавно смотрел код, который пять лет назад прошел все QA.
До сих пор хожу и прошу, чтобы кто-нибудь вырвал мне глаза.
Да, я могу тебя понять я сегодня от одного куска кода мучительно захотел курить. Но это же и есть RDD - время от времени проходиться по коду и переписывать его получше.
Все равно это в сумме быстрее, чем perfect code, еще хотя бы и потому, что срок фиксации требований у нас что-то около одной недели и большая часть этого совершенного кода будет просто невостребована и выброшена. Выбрасывать неделю легче, чем месяц.
Все равно это в сумме быстрее, чем perfect code, еще хотя бы и потому, что срок фиксации требований у нас что-то около одной недели и большая часть этого совершенного кода будет просто невостребована и выброшена. Выбрасывать неделю легче, чем месяц.
Чем это плохо?какой получается срок от получения пожелания заказчика до внедрения (при условии, что пожелание требует изменения сложившейся архитектуры ПО)?
Для "внезапных падений" - есть QA и автотесты.Не решают.
Кстати perfect code тоже не решает.
Не решают.Сие правда, поэтому есть команда быстрого реагирования, цепочки телефонных номеров ответственных постоянной доступности.
Время на изменение с затрагиванием архитектуры? Очень не конкретно звучит. У нас в основе лежит PureMVC. Стоимость внедрения функционала относительно высока. Но устойчивость к постоянно меняющимся требованиям просто феноменальная.
Ну да речь не о том - мне просто действительно интересно, имел ли кто на форуме еще опыт работы с refactoring-driven developement - и как они считают - устойчивая ли это концепция? Способная ли она к поддерживанию на плаву действительно масштабных проектов?
Ну да речь не о том - мне просто действительно интересно, имел ли кто на форуме еще опыт работы с refactoring-driven developement - и как они считают - устойчивая ли это концепция? Способная ли она к поддерживанию на плаву действительно масштабных проектов?Сам по себе рефакторинг вещь хорошая. Но ведь это не development, а лишь его часть. Он не добавляет новый функционал.
Мартин фаулерз в своем "рефакторинге" пропагандирует оч. Мол, сначала пишете левой ногой, лишь бы работало, а потом по возникновению запроса - рефакторите. Главное, чтобы заказчики были в курсе такого подхода.
а потом по возникновению запросаОткуда запрос-то возникает? Кто и как решает, нужно ли рефакторить? А самое интересное КАК.
Вообще, кстати, понимаю, что во многих случаях я не прав. Работать с клиентскими приложениями и с внутренними приложениями - это разные штуки.
Если для клиентских приложений естественны частая изменчивость требований и прочая ересь, то они, как минимум спокойно принимают, если приложение стало работать на 10 процентов медленнее - а это как раз маркер для нас, тот самый запрос. Еще запросом можно считать, что какая-то новая функциональность внедрялась с некоторым поскрипыванием. Зато клиенты ну вообще не терпят, если их больше какого-то срока оставить без новой функциональности, им по большому счету плевать на perfect и требования к 24/7 хоть и жесткие, но мягче, чем во внутренних системах.
Во внутренних же системах, наобоот, будет повыше требования к безопасности и устойчивости. Зато, как правило, там срок фиксации требований значительно больше. Так что там можно себе позволить и более спокойную разработку с более качественным на первой итерации кодом.
P.S. Есть конечно еще какие-то сверхвысоконагруженные интернет сервисы, но это таки совсем другая история. Если в твоей команде есть миддлы и джуниоры - все равно время от времени за ними надо подчищать, если же в твоей команде собрались сплошь высокоуровневые ребята, то можно себе позволить даже в проекте следовать заветам товарища Александреску без особенного страха..
Если для клиентских приложений естественны частая изменчивость требований и прочая ересь, то они, как минимум спокойно принимают, если приложение стало работать на 10 процентов медленнее - а это как раз маркер для нас, тот самый запрос. Еще запросом можно считать, что какая-то новая функциональность внедрялась с некоторым поскрипыванием. Зато клиенты ну вообще не терпят, если их больше какого-то срока оставить без новой функциональности, им по большому счету плевать на perfect и требования к 24/7 хоть и жесткие, но мягче, чем во внутренних системах.
Во внутренних же системах, наобоот, будет повыше требования к безопасности и устойчивости. Зато, как правило, там срок фиксации требований значительно больше. Так что там можно себе позволить и более спокойную разработку с более качественным на первой итерации кодом.
P.S. Есть конечно еще какие-то сверхвысоконагруженные интернет сервисы, но это таки совсем другая история. Если в твоей команде есть миддлы и джуниоры - все равно время от времени за ними надо подчищать, если же в твоей команде собрались сплошь высокоуровневые ребята, то можно себе позволить даже в проекте следовать заветам товарища Александреску без особенного страха..
я может не совсем понял посыл, refactoring противопоставляется совершенному коду? Один из признаков совершенного кода — он хорошо рефакторится. На то он и совершенный.
Код это не объект, это процесс (со своей жизнью).
Код это не объект, это процесс (со своей жизнью).
Один из признаков совершенного кода — он хорошо рефакторится.Под рефакторингом я понимаю процесс преобразования кода, приводящий к тому, что он становится более читаемым, легче изменяться, etc...
Глупая человеческая логика говорит мне что
а. Если к совершенному коду хорошо применить рефакторинг, он останется совершенным, но при этом улучшится по некоторым метрикам
б. Имеет место инвариант, значит количество таких шагов ограниченно.. И после последнего - код перестает быть совершенным?
Или имеется в виду рефакторинг с целью добавить что-либо?
Я не противопоставляю - я скорее говорю, что не весь код должен стремиться к совершенству, так как метрика "время, за которое это было сделано" тоже должна учитываться и в некоторых случаях быть приоритетной и несдвигаемой. То есть - не делать какие-то вещи до того, как на них поступил запрос.
Или имеется в виду рефакторинг с целью добавить что-либо?чем отличается "добавление чего-либо" от "улучшения по некоторым метрикам" из пункта (a)? Вроде как, второе частный случай первого, нет?
Вероятно тем, что улучшение чего-то это, например, косметический рефакторинг с целью более точного соответствия SOLID, etc
А добавление функционала - это рефакторинг в том месте, где происходит интеграция новой функциональности, потому что T(рефакторинг + написание функционала) < Т(просто написание функционала например, либо потому что написание нового функционала требует дублирование существующего кода и потому делается рефакторинг, вынося это в какую-то более удобную схему - и много других почему.
А добавление функционала - это рефакторинг в том месте, где происходит интеграция новой функциональности, потому что T(рефакторинг + написание функционала) < Т(просто написание функционала например, либо потому что написание нового функционала требует дублирование существующего кода и потому делается рефакторинг, вынося это в какую-то более удобную схему - и много других почему.
Когда я говорил "он хорошо рефакторится", я в первую очередь имел ввиду тот вид рефакторинга, который идет в связке с написанием функционала.
Косметический рефакторинг может имеет предел, а может не имеет. Ответ на этот вопрос разве интересен?
Зачем проводить разделение на два вида рефакторинга: косметический и рефакторинг в связке с добавлением функционала? По сути и там и там преобразования кода по тем же правилам.
Косметический рефакторинг может имеет предел, а может не имеет. Ответ на этот вопрос разве интересен?
Зачем проводить разделение на два вида рефакторинга: косметический и рефакторинг в связке с добавлением функционала? По сути и там и там преобразования кода по тем же правилам.
Потому как изначальный вопрос состоял в посыле:
Написание изначально совершенного кода влечет за собой проведение косметических рефакторингов (или закладывание оных на первой же итерации + проведение их сразу же по мере возникновения) "на случай если это понадобится, да и просто хорошо это, православно!" а RDD - не в такой степени.
Вопрос, как и раньше, в том что "Рыба бывает только одной свежести - первой, она же и последняя" - и есть код и говнокод
или RDD предоставляет более менее устойчивый алгоритм, помогающий удержаться между этими крайностями?
Написание изначально совершенного кода влечет за собой проведение косметических рефакторингов (или закладывание оных на первой же итерации + проведение их сразу же по мере возникновения) "на случай если это понадобится, да и просто хорошо это, православно!" а RDD - не в такой степени.
Вопрос, как и раньше, в том что "Рыба бывает только одной свежести - первой, она же и последняя" - и есть код и говнокод
или RDD предоставляет более менее устойчивый алгоритм, помогающий удержаться между этими крайностями?
Совершенный код - это не бинарный показатель (да, код совершенен; нет, код не совершенен). Совершенность(несовершенность) кода - это составной показатель, который можно рассчитать с помощью той или иной агрегирующей функции из первичных показателей:
- трудоемкость оценки возможности рефакторинга N
- трудоемкость самого рефакторинга N
- процент вноса ошибок в процессе рефакторинга N
- процент успешности рефакторинга
При разработке ПО рефакторинг всегда сопряжен с добавлением нового функционала. В текущее время последовательность шагов (добавление функционала/рефакторинг)* приводит к экспоненциальному падению показателя совершенность кода от объема добавленной функциональности.
Slicing (или другие варианты или аналоги АОП) обещают линейное падение совершенности кода. За это их и любят, и пытаются реализовать (или хотя бы исследовать пути реализации) в своем коде.
- трудоемкость оценки возможности рефакторинга N
- трудоемкость самого рефакторинга N
- процент вноса ошибок в процессе рефакторинга N
- процент успешности рефакторинга
При разработке ПО рефакторинг всегда сопряжен с добавлением нового функционала. В текущее время последовательность шагов (добавление функционала/рефакторинг)* приводит к экспоненциальному падению показателя совершенность кода от объема добавленной функциональности.
Slicing (или другие варианты или аналоги АОП) обещают линейное падение совершенности кода. За это их и любят, и пытаются реализовать (или хотя бы исследовать пути реализации) в своем коде.
Вопрос в сторону из любопытства. Ты на каком языке пишешь, если не секрет?
- спасибо за такой ответ.
Основной - Objective-C.
Основной - Objective-C.
Оставить комментарий
luna89
Расскажите, как вы развиваете свои профессиональные скиллы?Я, например, трачу каждый день в районе часа на чтение каких-нибудь мануалов или написание мелких демо-проектов на незнакомых технологиях. Это довольно сильно отвлекает от основной работы и заметно ей вредит.
Если работодатель использует почасовую слежку за исполнением задач, то приходится хитрить, чтобы наебать, например, забивать на собственное развитие, когда есть много мелких задач, чтобы потом, получив большую, записать в нее потраченное на себя время.
Вариант что-то изучать в свободное время я не рассматриваю, так как голова не резиновая.
При этом забивать на изучение чего-то нового нельзя, так как можно оказаться в неприятной ситуации, когда ты твоя платформа разработки устарела, и твой опыт стал нерелевантен на рынке труда. В такой ситуации разработчик, который наебывал своего работодателя, может быстро адаптироваться, а тот, кто тянул на себе продукт, делая грязную работу, оказывается никому не нужен. Несправедливо, что самые тяжелые проекты, на устаревших технологиях и с большим техническим долгом, оказываются самыми непрестижными и хуже всего выглядят в резюме.