Подробнее я писал, например, тут: netch80.livejournal.com/17832.html
И, разумеется, архитектура должна быть продумана изначально, хотя бы для первой версии. Никакие предварительные тесты не покроют отсутствие архитектуры и её придумку на ходу. Не обязательно реализовывать всё из запланированного по архитектуре, многое может дорисовываться на ходу, но надо иметь хотя бы в голове (а лучше на бумаге) общий план кампании.
Правильнее всего обеспечить выделение доли времени на тесты и жёстко его соблюдать, покрывая тестами 1) все основные сценарии и применения (включая те, что вытекают из спецификаций — это уже BDD) и 2) все подозрительные с точки зрения программиста места и случаи (маргинальные значения параметров, внесценарные повторные вызовы методов, etc.)Сколько времени — определяется по возможностям — но это не менее 20%, а в соседних ветках рекомендовали 50%. Этого должно гарантированно хватить на доведение до рабочего состояния. Ну и см. выше про архитектуру.
Чем он отличается от других средств continuous integration?
Так не бывает. У разных схем и задач распределения практически нет ничего общего, кроме самого факта выполнения чего-то не на одном процессоре.
Хехе, не зря я убил из почты предложение работы от некоей Marina Kopytova. Может, компания и приличная, но пока в ней такие сотрудники — её стоит обходить за километр.
P.S. Не рассказывайте сказки, что ничего не посылали:)
Ну и пусть себе хотят дальше:)
Вот на тему глубокого дебага — как раз проверка выполнения контракта является нормальной там, где разработчики или слишком ленивы, чтобы сидеть в отладчике (привет Луговскому), или не в состоянии, например, потому что софт выполняется на далёком сервере и обрабатывает в реалтайме сотни параллельных сущностей (как на моих работах). Реализуется это уже способом, специфичным для языка, платформы и обстановки: где-то это просто assert, где-то вывод в лог, где-то увеличение счётчика... главное, чтобы проблема была известна и опознавалась (хотя бы до такого уровня, чтобы в следующей версии плавно углубиться в неё). Фактически, я отладчик как инструмент не запускал на своих задачах уже... мнэээ... лет 10:) Вижу его только у дочки на задачах по информатике (когда задача тривиальна, но требуется понять, что именно нужно).
К ссылке про контракты в Аде — оно очень похоже выглядит в Erlang. Например, если функция foo должна получать на входе список, достаточно записать её определение в виде
foo(L) when is_list(L) ->...
вместо простого
foo(L) ->...
и рантайм автоматически проверит (точнее, он будет искать подходящее определение, но для foo(X) с X не списком он его не найдёт и будет исключение типа function_clause).
Подозреваю наличие аналогичных средств в других ФЯ, но не видел.
Схожие средства я применял в случае особо тяжело понимаемого кода, например, если я знаю, что функция должна вернуть record(nns), пишу
NewNNS = #nns{} = process_message(Message, OldNNS)
и в рантайме выполняется соответствующая проверка.
Для статических компилируемых языков, конечно, больше подходит статический анализ кода. Многие из подобных средств позволяют описать контракт для кода (что на входе, что на выходе, для промежуточных точек) и анализатор по каждому пункту может сказать выполняется // не выполняется // не может проверить.
Это я чуть пробежался по теме «мысью по древу», она значительно обширнее, но описал практически важные «в среднем по больнице» вехи. Главное — не бойтесь форсировать в коде проверку выполнения условия конкретного контракта, по крайней мере в отладочных сборках; это поможет не только отладке, но и чтению.
> И, кстати, эйчары не набирают людей на работу.
На практике они существенно влияют на набор людей на работу, и, насколько я вижу, в основном не лучшим образом.
А что эти две? Как приколы у них песни отличные, развеять голову от засушенного кода:)
Никакой Си не даст результат, что "5"-3==2, но "5"+3=="53″. И точно так же никакой Си со своим синтаксисом не даст того, что если после слова return перевести строку, то выражение за ним проигнорируется в ноль. Это всё PHP’шные выбредки.
... и от необходимости трезво, связно и чётко излагать мысли.
Ключевое слово — «разумная». Хотя кому-то и APL слишком многословен.
Самый ненавистный многими язык программирования, а зря,
Не зря, потому что более хреново разработанного языка с таким количеством wtf’ов на единицу кода ещё надо поискать, местами он переплёвывает по количеству диверсий даже PHP (что надо было особо постараться). Лет через 5, если его не исправят, начнётся движение за введение чего-то получше в веб (точнее, то, чем веб станет).
Я бы всё-таки советовал подумать о том, что и инженеры могут что-то знать о психологии.
И как они борются, например, с множественностью форм нормализации?
Ну требования законодательства плюс низкий уровень языка в ширнармассах могут дать и не такой эффект.
то и вакансия должна на нем публиковаться
Иногда так и делают. Хотя это уже чисто стилизация.
А вообще Вы показали сейчас классический пример применения паттерна Imago, хоть в учебник вставляй.
Так что не надо приписывать чужим свою логику на основании заведомо кривых аналогий.
Коллега, Вы традиционно чрезмерно радикальны на ровном месте. Я вижу постинги с этим дисклеймером от безусловно адекватных людей с заметными успехами на работе и в личной жизни. Они знают, что чисто формально такие объявления не имеют смысла, но всё равно считают нужным поддержать эту волну. И я в случае решения вопроса, кто же дурак, выберу никак не их. Ничего личного.
(Что никак не относится к time_t, %username%)