Правила выживания в крупной конторе

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

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

1. Говорят, что современные школьники физически не способны воспринимать текст, не разбитый на абзацы не больше 10 строк. Теперь - верю в это безоговорочно. Потому что у современных программистов точно такая же проблема - не могут воспринимать код длиннее 10 строк. Любой код, превышающий эти самые 10 строк, должен разбиваться на отдельные подпрограммы. Независимо от функциональности. То, что в результате такого разбивания выполняется куча не нужных команд, ряд действий выполняется многократно вместо одного раза, а обработка пакета данных, которую можно выполнить за один цикл, будет прокручиваться в циклах несколько раз - это несущественно. Вопросы на эту тему встречают искреннее непонимание и недоумение: а почему бы и нет? Оптимизация? Мы же не для 8086 пишем, а для современных компьютеров! (цитата точная).

2. Просто разбивать код на минимально возможные куски недостаточно. Эти самые куски необходимо растащить как можно дальше друг от друга. Обязательно - в разные модули в разных файлах. Крайне желательно - чтобы они были связаны не непосредственно, а через последовательный вызов еще десятка функций (разумеется, тоже расположенных в разных файлах). Это значительно улучшает читаемость кода и делает его проще и понятнее. Чтобы просто поверить в то, что это говорят всерьез - мне понадобился почти год. Выражать сомнение в этой аксиоме крайне нежелательно - не поймут-с.

3. SQL - зло. Он слишком сложный, запутанный, непонятный и трудночитаемый. И да, это тоже всерьез. Это тоже говорят с абсолютной уверенностью и на таких серьезных щах, что я уже было сам засомневался - а может это я дурак и всю жизнь чего-то не понимаю?

4. Исходя из предыдущего пункта становится очевидно, что просто необходимо использовать ОРМ. Вместо 50 строк такого сложного и непонятного кода SQL получается одна простенькая строчка вызова соответствующего метода ОРМ - красота! То, что в результате, на выходе в БД передается уже не 50, а 100 строк сгенерированного ОРМ SQL запроса, при этом сгенерированного предельно криво - это совершенно нормально. Мы же этого не видим - значит этого нет. А, да, чуть не забыл - обращаться к ОРМ тоже нужно соответственно. Чтобы вместо операции, требующей одного запроса к БД - последовательно выполнялось штук 5 запросов на чтение, а потом еще три на запись. Зачем? См. выше про современные быстрые компьютеры и не задавай глупых вопросов.

5. Подход к организации структуры базы данных должен быть соответствующим. Нужно создавать как можно больше таблиц со связями 1 к 1. Просто потому, что большие таблицы некрасиво выглядят на экране. Хотя стоп. Программист вообще не должен ничего знать о структуре БД. Программист должен работать с ОРМ и заглядывать в базу ему незачем (цитата точная). Да, и использовать метод ОРМ, позволяющий посмотреть, что именно он оправляет в БД - крайне не рекомендуется. Такое нездоровое любопытство вызывает всеобщее осуждение и непонимание.

6. Перед тем, как написать какую-нибудь функцию или метод, нужно выяснить, нет ли подходящей в какой-нибудь из стандартных библиотек. Если есть - однозначно, грузи библиотеку в несколько десятков метров, когда нужна одна-единственная функция на 10 строчек. Это совершенно нормально. Нужна еще одна функция - грузи еще одну библиотеку, не вопрос. И так далее, столько, сколько нужно. Помните, что существует только то, что мы видим - наш код стал на 10 строчек меньше! Если нужной функции нет в стандартных библиотеках, а есть похожая, но не совсем подходящая (или почти совсем неподходящая) - тоже не беда, ведь гораздо лучше натянуть сову на глобус, чем что-либо написать самому.

7. Обязательно задействуй по максимуму все доступные strict режимы. И не забудь задействовать систему code-critic, загрузив все, какие только существуют, наборы правил. И придумай еще пачку своих, чем неадекватнее - тем лучше. Какие-нибудь неочевидные и редко используемые возможности языка программирования - это для слабаков! Ты попробуй написать код, уложившись только в официально одобренные методы. Разумеется, систему автоматического тестирования (у нас - селеноид) нужно настроить максимально параноидально, чтобы каждый прогон выполнялся не менее 6 часов. Садо-мазо? Ну что вы...

8. Переходим к самому главному. Самое важное в коде - ЭТО ЕГО ВНЕШНИЙ ВИД! Все остальное - сугубо вторично. Код может быть сколько угодно кривым и неоптимальным (см. выше про современные быстрые компьютеры и не задавай глупых вопросов), но он обязан выглядеть красиво! И даже пробелы - гораздо важнее, чем какие-то там функции и операторы. Ну ладно мы же все-таки современные люди, не дикари какие-нибудь, поэтому задействуем систему tidy, автоматически расставляющую пробелы в коде. Но ты все-таки сам запускай ее каждый раз на каждом файле перед тем, как запостить в гит. Ведь пробелы - это очень важно. Uber alles.

9. Исходя из предыдущего пункта очевидно, что кодревью должен быть максимально вахтерским. И не в плане функциональности кода (см. выше про современные быстрые компьютеры и не задавай глупых вопросов), а в плане косметики. Необходимо каждый раз возвращать код на доработку, когда в каком-нибудь комментарии запятая стоит не на своем месте. И да, помним про селеноид - каждое чисто косметическое изменение в коде, абсолютно никак не влияющее на функциональность, должно снова 6 часов крутиться на тестировании, прежде чем вернуться в ревью. Повторить N раз. Ситуация, когда исправление какого-нибудь важного бага, затрагивающее в коде 5 строчек, полностью готовое и протестированное на работоспособность живыми тестировщиками, больше месяца не может добраться до релиза из-за полировки косметики - совершенно нормальная рабочая ситуация. А чо, программист спит - зарплата идет. И да, написать ( B + A ) - неправильно, нужно писать ( A + B ). Постарайся запомнить, от этого зависит твоя работа. Все остальное - фигня.

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

Вывод:

Я понял, что программисты не работают в крупных компаниях. В крупных компаниях работают пользователи, умеющие кодить. С исключительно потребительским подходом к разработке. Конечный результат не волнует абсолютно никого. Работа разработчика в крупной компании заключается в том, чтобы сделать свою работу проще и приятнее.

Чему я научился:

а) Я больше не удивляюсь, почему современный софт, по функциональности не намного отличающийся от "Hello, World", весит десятки гигов, требует самые новые процессоры и не менее 16Гб памяти, ухитряясь при этом безбожно тормозить и глючить. Я теперь точно знаю, почему это так.

б) Если мне когда-нибудь на какой-нибудь работе понадобится саботаж - я теперь точно знаю, что делать. Любой проект теперь могу превратить в полное говно так, что внешне все будет идеально. Начать с внедрения ОРМ - и дальше по списку.