Неспособность рассуждать о коде

«Рассуждать о коде» значит понимать порядок исполнения инструкций («исполнять программу в голове»), зная, каково предназначение кода.

Симптомы

• Наличие «волшебного», «вуду» кода или кода, который не имеет никакого отношения к целям программы, но всё равно тщательно поддерживается (например, инициализация переменных, которые никогда не используются, вызов функций, не имеющих отношения к цели, создание выходных данных, которые не используются, и т.д.).
• Многократные вызовы идемпотентных функций (например, вызов save() по нескольку раз, «чтобы уж точно»).
• Исправление ошибок написанием избыточного кода, который замещает данные, полученные при исполнении неисправного кода.
• «Йо-йо код», который конвертирует значения в различные представления, а потом конвертирует их обратно ровно в то же представление, с которого начинали (например, преобразование десятичного числа в строку, а потом обратно в десятичное число, или padding строчки с последующим trim'ом).
• «Бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще (высокая когезия).

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

Если вы на самом деле подумаете об этом, запуск нового бизнеса — удел дураков. У меня нет конкретной статистики, но, я бы сказал, что минимум 70% всех стартапов закрываются через 5-7 лет. И даже если вы достаточно успешны, вы должны обладать устойчивостью к стрессам и способностями быстро восстанавливаться после неудач. Статистика работает против вас — вы просто обречены на провал. Зашел ли я слишком далеко и обидел ли я этим всех с кем я работаю как венчурный капиталист? Не думаю. На самом деле, я люблю работать с дураками и никогда всерьез не верил в статистику.

Во время dot com бума мы с друзьями основали стартап, где я был техническим директором. Мы разработали систему управления знаниями. Это была комбинация блогов, wiki, системы управления документами, социальных закладок. Мы начали в 1999, что было несколько рановато для wiki и блогов (Movable Type вышли на рынок в 2001). Социальные закладки, по сути, были точно такими же, как станет впоследствии Delicious. Помимо этих новых и замечательных идей (по крайней мере для 1999 года) у нас было три отличных особенности:

• Всему можно было присвоить метки (tags): навыкам, людям, ссылкам, документам, постам в блогах, страничкам в wiki. Что-то, что теперь называется фолксономия. Метки могли соотноситься с другими метками и формировать онтологии. Метки могли ссылаться на другие документы, посты, людей.
• Всему можно было поставить свою оценку от 1 до 5.
• У нас был умный нечёткий поиск, основанный на метках и оценках. Например, при поиске «люди со знанием Oracle» в выдачу также попадали специалисты по SQL Server'у — например, чтобы укомплектовать команду, если не было свободных гуру Oracle.

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

Раз за разом я вижу отблески самого себя в «молодых» программистах. Они сражаются с теми же концепциями, что и я когда-то, попадают в те же ментальные ловушки и, в общем-то, делают те же ошибки. Написав пост 4 wrong ways, я задумался, насколько распространены эти ошибки, и можем ли мы их категоризировать. Я попадался в каждую из этих ловушек хотя бы раз, в некоторые по нескольку и видел те же ошибки у других.

Иногда возникает необходимость кэширования результатов исполнения методов. Одно из возможных решений для java описано здесь. Всё, в принципе, тривиально: EHCache, Spring AOP для перехвата вызовов, немножко кода.

Рассмотрим, как мне кажется, более элегантное решение на scala.

Я совсем недавно начал изучать Scala. Для тех, кто еще не в курсе, что это за язык, небольшая выдержка с официального сайта:

Scala — лаконичный, элегантный и статически типизированный язык программирования, который сочитает в себе возможности обьектно-ориентированного и функционального языка. Scala полностью совместима с Java.

Сегодня я хотел бы показать вам, как, используя богатые выразительные способности этого языка, решить проблему, актуальную для любого более-менее крупного проекта, а именно работу с зависимостями компонентов или dependency injection. Последние несколько лет я использовал spring ioc для решения этой проблемы, однако у этого фрэймворка есть несколько недостатков, самый очевидный из которых это сборка приложения из компонент в runtime и наличие xml-дескрипторов (да, конечно можно использовать и autowiring и аннотации, но и у этих возможностей есть свои серьезные проблемы).