[prog.work.thoughts] Опыт в программировании: переход от решения задачи к ее формализации

По сути, данная заметка является продолжением недавней сентенции о собственной способности прохождения собеседований с логическими задачками. Мысли сии не покидают голову, изрядно досаждая и, отчасти, теребя нервы и портя кровь ;) Плюс к тому, в обсуждениях собеседований и задачек для них зачастую проскакивают фразы о том, что опыт в программировании мало чего значит и, к тому же, очень быстро обесценивается.

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

Речь вот о чем. Когда заказчик говорит “все должно работать при повторных запросах” – это еще не формализация. Даже когда речь заходит о более конкретных вещах, скажем, “если на запрос X мы получаем ответ Y или Z, то спустя какое-то время мы можем повторить запрос X и вы должны его корректно обработать, как будто он пришел впервые”, то это все еще не формализация (хотя для того, чтобы преобразовать первую формулировку во вторую уже нужен изрядный опыт, имхо).

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

Например, “если на запрос X мы получаем ответ…” может быть преобразован в набор правил:

• информация о запросе X сохраняется в БД при условиях…;
• информация о запросе X хранится в БД до наступления условий…;
• повторный запрос X в условиях … должен приводить к …;
• в остальных случаях повторный запрос X обрабатывается как …;
• и т.д.;

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

Ну а если при воплощении системы правил в коде понадобиться обращать односвязный список… То тут да, возможны казусы. Особенно, если под рукой не найдется реализации reverse в стандартной библиотеке. Тупить с реализаций собственного варианта reverse лично я мог бы довольно долго. Отвык уже :)