Судя по комментариям, я придерживаюсь какой-то непопулярной точки зрения — я просто не понимаю актуальности этой проблемы. Мне кажется, что в настоящее время проблема «железо vs. оптимизации» слишком преувеличивается по инерции. Я вокруг себя вижу такую картину.
1. Пилим фичи A, B, C.
2. Нагрузка вырастает, поднимаем новые машины (или запускаем более мощные вместо старых).
3. Через некоторое время приходит финансово заинтересованная сторона и говорит: «Мужики, в этом периоде чек вырос, надо чото делать»
4. Временно откладываем фичи D и E, идем уменьшать чек.
При чем тут админы или программисты — не понимаю, честно говоря, вообще. Уверен, что они не должны иметь отношения к данному выбору.
Мне неповезло (или повезло, хз) быть как-раз одним из таких. Ничего страшного, в принципе, нет. Главное заставить себя сделать хоть не идеально, но сегодня. А то, что мысли об идеальном переносятся на завтра — это в некотором роде даже хорошо.
Очень спорно, я считаю. Подход «мокать все и везде» возник тоже не на пустом месте. Лично по моему опыту, поддерживать полное тестовое окружение (с базами данных, очередями и прочими непотребностями) бывает гораздо более болезненно, чем усложненную архитектуру, предполагающую тесты в изолированном окружении.
Мне вот кажется, что от TDD-подохода «утром тесты, вечером стулья код» можно отказаться лишь тогда, когда у проекта есть не очень большое количество разработчиков и одновременно работа проиходит в 1-5 бранчах. А головняк с поддержкой кучи разных несовместимых версий окружения того не стоит.
Спасибо. Сегодня проснулся с мыслью разобраться с Paxos и Raft, и тут — эта статья. Оказывается, ничего страшного в нем нет. Было бы классно почитать что-то подобное про Raft.
Всегда была интересна причина этого явления. Софт, поставляемый с железом, чаще всего, убог до невозможности. Особенно угнетают звонилки, которые поставляются вместе с usb-модемами. Складывается впечатление, что из разработчики устроили какое-то негласное соревнование — кто сделает страшнее и корявее.
Это называется жадный алгоритм — выбор локально-оптимального решения. Подтвердили существование этой хреновины — все супер, часть нестыковок состыковались. Потом несколько новых открытий, и опять ничо непонятно. Но уже из-за того, что приняли теорию с бозоном, а не без него, в которой (а вдруг?) все могло бы уложиться, если бы ее прорабатывали сильнее. Просто, интересуюсь, может ли быть такой вариант?
Я не физик, а следовательно не в теме, но:
>>Зато Хиггс отбрасывает множество других теорий без подобного бозона в систематике частиц.
А допустимо, вообще, отбрасывать другие теории из-за его существования? (просто я, вообще, не в курсе всего этого)
Угу. Мне только на днях один похапешник рассказывал, что главная проблема PHP досталась ему от С. Угадаете какая? Конечно! Динамическая типизация! Не иначе, этот спец из С вышел.
1. Пилим фичи A, B, C.
2. Нагрузка вырастает, поднимаем новые машины (или запускаем более мощные вместо старых).
3. Через некоторое время приходит финансово заинтересованная сторона и говорит: «Мужики, в этом периоде чек вырос, надо чото делать»
4. Временно откладываем фичи D и E, идем уменьшать чек.
При чем тут админы или программисты — не понимаю, честно говоря, вообще. Уверен, что они не должны иметь отношения к данному выбору.
Мне вот кажется, что от TDD-подохода «утром тесты, вечером
стульякод» можно отказаться лишь тогда, когда у проекта есть не очень большое количество разработчиков и одновременно работа проиходит в 1-5 бранчах. А головняк с поддержкой кучи разных несовместимых версий окружения того не стоит.Нововведение полезное, я считаю.
А нужно
Ну, либо класс объявлять sealed и не городить огород с перегузкой Dispose.
Простите, подходящего по габаритам подо что? Под чиновничью задницу?
>>Зато Хиггс отбрасывает множество других теорий без подобного бозона в систематике частиц.
А допустимо, вообще, отбрасывать другие теории из-за его существования? (просто я, вообще, не в курсе всего этого)