Программировать без лишней боли

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

Правильный код легко сделать быстрым

Но не наборот. Есть еще одно хорошо известное выражение на эту тему - “Преждевременная оптимизация - корень зла!” (Дональд Кнут). Снова и снова, в самых различных проектах, программисты делают системы, которые бы выдерживали нагрузку в сотни тысяч пользователей. Зачастую эти усилия отвлекают их от того, чтобы делать проект функциональным, простым, способным к быстрым изменениям. В результате они не набирает и тысячи пользователей онлайн и весь высоконагруженный код можно выкинуть. Мы сами сполна испили из этой чаши, когда делали Рисоваську - инвестор настаивал, чтобы бета-версия выдерживала очень большую нагрузку. Мы создали довольно сложный масштабируемый сервер на Erlang’e, чтобы через месяц после запуска понять - весь продукт должен быть иначе устроен, а соответственно и сервер должен быть совсем другим.

Читабельность кода очень важна

Дима Смолин пишет в отчете по GDD 2009:

Пара слов о Java и XML. Меня преследует ощущение, что работа с этими вещами негативным образом влияет на живые организмы. Люди, которым приходится часто иметь с этим дело, выглядят уставшими и куда менее счастливыми, чем те, кому повезло немного больше. И чем глубже человеку приходится в это окунаться, тем заметнее влияние. На конференции подобные ощущения были очень сильны. Питониста видно в толпе разработчиков, вокруг него нет фигурных скобок. :-)

40 строк в одном файле без лишних скобок и кавычек - читабельнее, чем 6 разных файлов с boilerplate code и прочим синтактическим мусором. Код, который можно прочитать вслух и получается осмысленный текст - лучше пусть даже компактного, но замудреного кода.

Глубокое понимание процессов

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

Делать то, что приносит удовольствие

Лично я начинал заниматься программированием, потому что мне было очень-очень интересно! В восьмом классе ездил через весь город, чтобы полтора часа пописать на MSX-Basic’e, потом упоительно писал первые относительно большие программы на Pascal, C++ и ассемблере, первая программистская работа радовала тем, что я получаю деньги за то, что готов делать бесплатно. Сегодня, когда мне нужно содержать семью, можно забыть ради чего я пишу код и решить, что это просто работа, за которую я получаю деньги. И опять же кажется, что работодатель хочет, чтобы просто работало, пусть все и некрасиво, и неоптимально, и не в ту степь. А раз это просто работа, то сделаю как он хочет. Так получаются очередные серые проекты, увеличивающие энтропию вселенной.

Нужно делать то, что приносит удовольствие и … постараться не умереть при этом с голоду :)))) Только так можно создавать такие продукты как Linux, Ruby/Python, RoR/Django.

Заключение

Я пишу этот пост, чтобы напомнить себе, что не обязательно торопиться, пыхтеть и страдать, чтобы создавать действительно хорошие продукты. Скорее наоборот.

comments powered by Disqus