В этой заметке я продолжу делиться удивительными открытиями в отношении разработки программного обеспечения, жизни, ее смысла и вообще. Предыдущую часть вы найдете здесь .
Наша программа достаточно хороша
Мы не будем занимается оптимизацией этой функции, потому что на данный момент она работает достаточно быстро. В этом модуле редкостный говнокод, но он хорошо работает уже больше года и никому до сих пор не приходилось менять логику в нем, так что мы не будем его трогать. Никто не пишет модульные тесты, но если выкатить программу в бой на 15 минут, багрепорты от юзеров помогут обнаружить и исправить ошибки намного быстрее, чем если бы мы писали тесты. Всем пофиг, если один из 100 000 запросов будет возвращать пятисотку. Мы посмотрим логи и исправим ошибки в следующем релизе.
Идеальный код — это миф. Баги, говнокод и зоопарк технологий были и будут всегда. Незачем править баг, если он проявляется один раз в полгода без каких-либо серьезных последствий. Использование однобуквенных переменных может быть вполне ОК, если время жизни переменной невелико. При разработке любого сайтика вам понадобятся зоопарк как минимум из HTML, CSS, JavaScript и SQL. Также нельзя не отметить, что говнокод бывает разным и мнения программистов о том, что называть говнокодом, могут разниться.
Наша программа недостаточно хороша
Часто возникает соблазн решить проблему при помощи небольшой подпорки. Вы делаете небольшую подпорку здесь, маленький костыль с щепоткой копипаста там, добавляете пару особых случаев в соответствии с текущей бизнес-логикой… В итоге ваш код становится так сложно поддерживать, что ежедневно после работы вы выпиваете по три литра пива, чтобы ненадолго забыть весь этот ужас, а еще через несколько месяцев ваши нервы не выдерживают, и вы увольняетесь .
Понятно, что бизнес ничего не хочет знать о рефакторинге, написании тестов, замене библиотеки А на более подходящую библиотеку Б, и так далее. Но ничто не мешает вам заниматься этими вещами «в фоновом режиме». Если вам нужно исправить некоторый код, сделайте заодно и его рефакторинг. Спокойно пишите тесты, ведь в конечном счете это приведет к экономии вашего времени . Сделайте задачи, запланированные на этот спринт, а оставшееся время посвятите оборачиванию библиотеки Б в интерфейс библиотеки А.
Не беспокойте бизнес своими проблемами. У него и без вас дел хватает.
Я не хочу этого знать
В последнее время я стал замечать, что ко мне в голову попадает много ненужной информации. Я отписался от Хабра, большинства e-mail рассылок, а также от десятков бложиков, авторы которых пишут интересные, но, к сожалению, мало полезные для меня вещи. Я давно не слушаю никаких подкастов. Когда коллега из соседнего отдела начинает предложение со слов типа «сейчас я объясню алгоритм, используемый в одном из моих модулей», я произношу волшебную фразу «спасибо, но, кажется, я не хочу этого знать». Я сплю лучше, представляя программы, в разработке которых я не участвую, в виде черных ящиков с некоторыми интерфейсами.
Пришло осознание, что я не могу знать всего обо всем. Мне больше не интересно, какие новые библиотеки на C++ появляются, насколько крута Scala и чем акторы в Erlang отличаются от акторов в Akka. Когда в книге мне попадается трудный для восприятия параграф, я не вчитываюсь в него, а напротив — как можно быстрее пробегаю его глазами. Все равно я не могу во всех деталях запомнить содержание целой книги. Помнить не саму информацию, а только то, где ее можно найти, не менее полезно, зато намного проще.
Небольшая доза пофигизма не повредит
Нет смысла спорить о вещах в стиле «сколько пробелов должно использоваться в отступах» или «какое имя для данной функции будет более удачным». Согласиться с неуступчивым коллегой, внести эти мелкие изменения и выкатить тестовый билд займет несколько минут, а спор может затянуться на часы. Не беспокойтесь о таких мелочах. У вас есть куда более важные дела.
Бывает, что проблемы решаются сами собой. Вы второй час пытаетесь разобраться в причинах возникновения некого бага, но все еще не преуспели в этом. Вы решаете отложить задачу в сторону и заняться другими вещами. Следующим утром по пути на работу к вам совершенно неожиданно приходит озарение. Знакомая ситуация?
Случается, что заказчик понимает, что уже не хочет хотелку, которую он так сильно хотел вчера. В комнату может зайти коллега из соседнего отдела с идеей, которая решит половину проблем, над которыми вы работаете. Сделав кофе-брейк и обсудив с коллегами, кто над чем сейчас работает, можно продвинуться дальше, чем за день усердной работы. Оптимизация одной части системы может существенно ускорить работу совершенно другой части. Может оказаться, что требуемый функционал уже реализован в библиотеке, написанной кем-то другим.
Проверенные временем решения лучше новых игрушек
Обкатанные, стабильные решения — наше все. Нужно бороться с желанием поиграться с RabbitMQ , MongoDB , Hadoop, новыми языками программирования и так далее. Потому что у любой технологии есть подводные грабли, о которых узнаешь, только наступив на них. Начиная использовать новую технологию, вы непременно пройдетесь по всем ее граблям, поскольку вы еще не знаете, где они лежат. Нередко эти грабли выстреливают сами собой в боевом окружении по воскресеньям.
Однако это не означает, что всего нового нужно бояться. Переход с CVS на Git (да-да, CVS до сих пор где-то используется, инфа 100%), с PHP на Erlang или с MySQL на PostgreSQL может быть вполне оправданным. Не нужно путать случаи, когда некая технология способна решить вполне конкретную проблему, и когда вам просто хочется попробовать новую игрушку за чужие деньги.
Возможно, вам тоже доводилось делать подобного рода «открытия». В этом случае непременно поделитесь ими в комментариях!