1. Друзья, в это тяжёлое и непонятное для всех нас время мы просим вас воздержаться от любых упоминаний политики на форуме, - этим ситуации не поможешь, а только возникнут ненужные ссоры и обиды. Это касается также шуток и юмора на тему конфликта. Пусть войны будут только виртуальными, а политики решают разногласия дипломатическим путём. С уважением, администрация Old-Games.RU.

    Скрыть объявление
  2. Если Вы видите это сообщение, значит, вы ещё не зарегистрировались на нашем форуме.

    Зарегистрируйтесь, если вы хотите принять участие в обсуждениях. Перед регистрацией примите к сведению:
    1. Не регистрируйтесь с никами типа asdfdadhgd, 354621 и тому подобными, не несущими смысловой нагрузки (ник должен быть читаемым!): такие пользователи будут сразу заблокированы!
    2. Не регистрируйте больше одной учётной записи. Если у вас возникли проблемы при регистрации, то вы можете воспользоваться формой обратной связи внизу страницы.
    3. Регистрируйтесь с реально существующими E-mail адресами, иначе вы не сможете завершить регистрацию.
    4. Обязательно ознакомьтесь с правилами поведения на нашем форуме, чтобы избежать дальнейших конфликтов и непонимания.
    С уважением, администрация форума Old-Games.RU
    Скрыть объявление

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

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

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

    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Гб памяти, ухитряясь при этом безбожно тормозить и глючить. Я теперь точно знаю, почему это так.

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

Комментарии

  1. Maelstrom
    Чет с бюрократией прям перебор.
    А как идея дробить код на маленькие кусочки и растаскивать его по всяким щелям аки белочка, сочетается с "красивым внешнем видом кода" - никогда не понимал.
    1. Ardash
      Так проще поручать задачу на исправление определенного блока даже джунам, дабы у тех не возникло возможности "починить" что-то рядом. Особенность современных методов разработки, когда текучий личный состав отвечает сразу за все и ни за что конкретно.
    2. Maelstrom
      Если человек любит самовольничать и "чинить" что-то рядом просто так - его надо побить по голове немного.
      А растасканный по разным местам сильно раздроблённый код куда хуже воспринимается, чем длинная, но монолитная функция. "10 строк для функцию" - это миф якобы хорошего стиля разработки, на деле скорее вреден.
    3. rusty_dragon
      Бессмысленный и беспощадный корпоративный подход по-американски.
  2. GreenEyesMan
    "Правила работы на большие компании:"

    Правило первое - не работать на большие компании.
    Правило второе - никогда не работать на большие компании. :)

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

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

    С другой стороны, крупная компания дает возможность выпускнику хоть какой-то опыт получить. Если повезет и будет толковый руководитель отдела. Но такое - редкость.
  3. A National Acrobat
    Мне кажется или мир как никогда близко подошёл к тезису: "Программист - вымирающая профессия"?
    1. Helmut
      Это циклический процесс.
      Кризис в индустрии порождает сильных программистов.
      Сильные программисты порождают фреймворки.
      Фреймворки порождают слабых программистов.
      Слабые программисты порождают кризис индустрии.

      Мы сейчас где-то между п. 3 и 4.
    2. rusty_dragon
      Учитывая, что таких слабых программистов специально вырастили, и именно такую квалификацию подбирают на работу - речь скорее не о естественном процессе, а дело в конкретных головах.
  4. Sintakens
    У меня сегодня схожая истерика была.
    Попросили позаниматься с двоюродным братом - помочь тест по информатике решить. Учебника у него типа нет. Выражение лица максимально незаинтересованное. На попытки заставить ответить на вопросы теста самостоятельно - пассивное недовольство, мол, чего пристали. Мельком проскользнула в речи фраза про одноклассника, которому все уроки мама делает, а он класса с третьего (сейчас в восьмом) сам за тетради не садился.
    В процессе "разбора полётов" выяснилось, что учитель им рассылает сканы фрагментов учебника с нужными для ответа разделами. 80% ответов на вопросы теста - прямой текст оттуда, читай - не хочу. Видимо всё-таки "не хочу"...
    Я так не могу, блин, как будто я просто так понадоедать пришёл, а не помочь.
      пз18 и compart нравится это.
    1. ВелоВояджер
      Мне пришлось недавно отучить одного из младших родственников пользоваться "ГДЗ" (готовыми дом. заданиями из интернета). Он говорит: "А зачем мне делать самому, если можно списать из инета?". Я отвечаю: "Ну, во-первых, все эти знания тебе понадобятся после школы - тогда кто за тебя будет думать? Во-вторых, в этих ответах куча ошибок, т.к. печатают их в интернете двоечники и троечники". И показываю ошибки в ответах - их оказалось по несколько В КАЖДОМ "готовом ответе".

      А насчёт чтения учебника - да и раньше так было тоже: почти по всем предметам вопросы в контрольных работах только по тому, что можно найти в учебнике. Достаточно всего лишь читать его перед занятиями, чтобы сделать её на четвёрку как минимум. Домашние же задания подразумевают не только чтение учебника, но и понимание, как можно применить знания на практике. И всегда надо прочесть всего несколько страниц. Но многие ученики ленятся сделать даже это.
      Сейчас, с точки зрения взрослого, всё это легко понять. И многим взрослым непонятно, зачем школьники сами себе делают хуже - сначала не занимаются, а потом в конце четверти хватаются за голову и срочно пытаются исправить оценки. Но я ещё неплохо помню, как в школе и лет 15 назад было то же самое - хотелось полениться и отдохнуть, а учиться поменьше. Особенно подросткам в 7-8 классе. Кто-то себя пересиливал, а кто-то нет. Мне, например, нравились олимпиады, и благодаря им интерес к учёбе продолжался.
      На мой взгляд, главное - заинтересовать. Показать, как знания, полученные на уроках, могут пригодиться в реальной жизни, на практике. Из собственного опыта, например. Мне при встречах со знакомыми школьниками это помогает.
      compart нравится это.
  5. ВелоВояджер
    Именно поэтому я никогда не буду пробовать работать программистом. Конечно, кое-что я знаю, но способностей к программированию нет (т.к. пробовал, но не получается ничего сложнее "уровня пользователя", мозги на другое заточены). Лучше заниматься тем, что умеешь и любишь.
    Какой смысл создавать тяп-ляпную фигню на нелюбимой работе - непонятно. Видно, в таких "крупных конторах" работают те самые люди, которые повелись когда-то на заманивания "у программистов зарплата - во! Иди туда, не прогадаешь!".
    1. Просмотреть предыдущие ответы...
    2. ВелоВояджер
      @Helmut, я имею в виду то, что надо работать только тогда, когда умеешь делать то, что надо делать на этой работе. Если не умеешь - надо научиться, а потом работать (если научиться сможешь). А не пытаться кое-как сделать то, чего не умеешь.
    3. Helmut
      @ВелоВояджер, Я понял. Раз я умею писать только логичный и оптимизированный код, мне сперва надо было научиться делать кривой говнокод, а потом идти работать (если научиться смогу).
    4. Kseraks
      так учится же надо, как ни крути
      к этому не может быть предрасположенности, это же не хирургом работать, где необходима невероятная выдержка и точность
  6. Kseraks
    >SQL - зло. Он слишком сложный, запутанный, непонятный и трудночитаемый. И да, это тоже всерьез. Это тоже говорят с абсолютной уверенностью и на таких серьезных щах, что я уже было сам засомневался - а может это я дурак и всю жизнь чего-то не понимаю?
    это уже походит на абсурд :)
    1. Sintakens
      Ну всё зависит от задачи. Я по работе разве что писал код для отправки запросов в MySQL и MS SQL (майкрософтовская версия, оказывается, чуть отличается в коммандах), мне это особо трудным не показалось. Но БД с нуля я не подниму, это 100%.
  7. drugon
Чтобы оставить комментарий просто зарегистрируйтесь и станьте участником!
  1. На этом сайте используются файлы cookie, чтобы персонализировать содержимое, хранить Ваши предпочтения и держать Вас авторизованным в системе, если Вы зарегистрировались.
    Продолжая пользоваться данным сайтом, Вы соглашаетесь на использование нами Ваших файлов cookie.
    Скрыть объявление