Pull to refresh
25
0
Голованов Владимир @Colwin

Senior Java Developer

Send message

SMART предназначена для формализации и достижения реалистичных целей. В частности, для повышения эффективности.

OKR предназначено для создания вектора к достижению амбициозных целей за счет повышения мотивации.

Цели подходов разные, акценты - тоже разные, и, соответственно, результаты тоже будут существенно различаться :-)

Я бы сказал, что OKR должно определять направление, а SMART помогать эффективно по нему идти.

Кстати, в русском языке когда прочитаешь эту комбинацию, невольно усмехнешься )
На собеседование — долго ) нужно тогда его сократить раза в три.
Не прокатит ) разве что придумать уникальные для каждого — а это задачка уже посложнее самого решения, IMHO ))
По личному опыту, проблемы TDD следующие:
Очень трудно внедрить TDD на legacy-проекте. Перед тем, как это сделать, придется существенно отрефакторить большую кучу кода, что чревато. Имеется в виду модификации старого кода или написание нового кода в интеграции или по аналогии со старым (единообразие часто бывает важнее красивости и каноничности).
— Через TDD неудобно писать сценарные тесты. Кто-то может возразить, что сценарные тесты должны быть интеграционными, а не unit-тестами — это предмет отдельного разговора. Важно то, что если мы хотим фиксировать сценарии и пишем для этого сценарные тесты, то делать это по TDD — значит, противоречить одному из его основных положений, — движению маленькими шагами. Я не говорю, что это невозможно, нет — это вполне возможно. Но неудобно.
— TDD не гарантирует качественной архитектуры (хотя некоторые фанаты почему-то думают иначе). Если не брать во внимание дальнейшую компонентную структуру системы, то все рискует развалиться, и никакой TDD не спасет.

Но я лично рекомендую всем, кто против TDD для каких-либо целей, попробовать его вначале на меньших масштабах и понять, когда его стоит использовать, а когда — нет. В частности, написание кода по TDD учит разработчиков думать о тестировании и API с другой стороны, и в дальнейшем их код становится намного лучше. Учиться нужно на практике.
Причем этот старый код часто бывает не покрыт тестами, и часто его даже нельзя покрыть без рефакторинга… А рефакторинг не безопасен. Порочный круг legacy :-)
И еще: иногда мощная IDE экономит до 80% времени разработки — и тут уже быстрота IDE становится не самым важным фактором, т.к. инструменты более мощной IDE гарантируют (до некоторой степени) корректность многих операций — а это многого стоит.
Мощь и скорость могут и сочетаться — такое бывает, хотя и редко. :-)
Прежде чем публиковать, нужно из частного технического решения вычленить общую часть и формализовать алгоритм. Это не самая простая задачка, IMHO, требующая времени и усилий.
Насчет алгоритмов… Хороший разработчик, в отличие от посредственного, обладает одной важной чертой. Нет, это не знание алгоритмов — это добро всегда можно найти и реализовать. В программировании наиболее важной является другая черта — учесть все вариации входных данных. Ключевое слово — "все". Хороший программист способен разбить все множество входных данных на классы эквивалентности, учтя при этом технические реалии (конечную память, ограничения на размеры структур данных, численные переполнения и т.д.), аккуратно их расписать, собрать одинаковые части вместе, и уже после этого написать код, который будет правильно работать для всех этих случаев.

Да, это сложно. Но только тот, кто это может и делает, достоин звания "инженер-программист", которое у многих значится в названии должности. :-)
А теперь небольшое слово про отладку.
Отладка нужна тогда, когда по коду кажется, что все должно работать, но оно почему-то не работает.
Забыли какой-то сценарий, и не можем быстро понять, какой именно. Как правило, ошибка при этом содержится в данных, а не в логике кода, а причина находится довольно далеко от неверно работающего кода. И в этом случае stack trace позволяет однозначно выцепить ветку, в которой происходит ошибка, выкинув все побочные варианты. Анализировать все варианты в голове просто дольше.
Т.е. дебаггер — это просто средство экономии времени для таких сложных случаев. И как показывает практика, чаще ошибку проще найти путем анализа кода, ведь для дебага нужно поднять соответствующее окружение, а это часто дороже, чем анализ всех веток.
Одна из целей ООП — избежать модификации существующего кода, заменив ее наследованием.
Это актуально при использовании всяких framework'ов, и обычно мы используем эту мощь даже не задумываясь о том, что без ООП это бы просто не работало.

В части написания компиляторов множество классов — это более простой путь в части поддержки, т.к. это позволяет не забыть добавить обработку для всех возможных типов узлов.
switch просто писать, но очень легко пропустить обработку нового узла, и компилятор тебе не поможет. Это можно нивелировать другими практиками (наличие default-ветки с Exception'ом + полное покрытие тестами), но не все это делают, сами понимаете. :-)

В любом случае, ООП предназначен для вполне конкретной цели: уменьшить сложность понимания логики кода. Если при использовании ООП у вас сложность только повышается — вы не правильно используете ООП, или используете его там, где он не нужен.
IMHO, автор не понимает всей сущности автотестов.
Что даст автотест на класс Words?
Тестирование маленькой функции с вполне определенной семантикой.
Это всегда просто, обычно как раз такие тесты и пишутся.

Проблема в том, что в реальном ПО чаще всего нужно покрывать тестами более сложные вещи, иначе это теряет смысл.

Например, возьмем простой проект — калькулятор (имитирующий реальный калькулятор с памятью, это важно!). Написать тесты на сами функции — тривиальная задача. А в чем здесь наиболее вероятны ошибки? Например, в таких последовательностях нажатий кнопок: "5", "+", "=", "=" (для тех, кто не знает — попробуйте на калькуляторе Windows или на реальном). И тестировать здесь нужно не отдельные операции, а их связки.
Если посмотреть на любой объект со стороны теории, то он выглядит как конечный автомат. И вызовы его методов меняют внутреннее состояние, после чего вызовы методов могут поменять принцип своей работы. Следовательно, нужно тестировать не отдельные вызовы, а сценарии.

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

Вот так-то.
Бинго — 7 из 7 правильно :-)
Все, кроме 3, ответил корректно.
Уже потом про P в HEX-формате вспомнил )
6 из 10 верно, еще на двух пролетел по невнимательности :-)
На этот раз правильно ответил на 3, 4, 5, 6, 7, 10.
Или под IE6-11, чтобы везде более-менее одинаково было. :-)
Ваш P.S. мне сильно напоминает мой стиль. :-)
Я некоторые игры начинал с начала раз пять, прежде чем прошел до конца.
А некоторые надоедали намного раньше, что даже удалял до прохождения — слишком однообразный принцип прохождения получался.
Все сходится к идее, что в ВУЗ студентов нужно пускать после пары лет работы по специальности :-)
А это уже вопрос организации процесса обучения.
Если учить ставят людей, которые не разбираются в предмете, все заканчивается плачевно.
P.S. Фишка в том, что "предмет" со стороны ученых и со стороны работодателя несколько различаются...

Information

Rating
Does not participate
Location
Новосибирск, Новосибирская обл., Россия
Date of birth
Registered
Activity