Это довольно долго и несколько однообразно. В этом и заключается идея – показать, где несколько плохих решений или структур будут всплывать повсюду, снова и снова.
Фон
В детстве я увлекался BASIC и Comal 80 на Commodore 64. Следующим компьютером был 23-килограммовый 286, который управлял Win 3.x поверх DOS и научил меня пакетному написанию сценариев, затем появились другие и я немного изучил C, HTML и Linux перед старшей школой. Там меня немного обучили Java, C++ и другим веб-разработкам, включая стандартный SQL и JavaScript. Создавалось впечатление, что школьное образование было ужасно плохим и что взрослые ничего не знали о компьютерах, тем более, что моя “диссертация”, проект, состоящий из небольшого движка OpenGL в конце средней школы, оценивался исключительно по документации, потому что учителю не удалось получить компилятор C++ и запустить его.
Поэтому я поклялся никогда не зарабатывать на жизнь программистом и использовать свой интерес к компьютерам только во зло. Вместо этого я поиграл с небольшим взломом и большим количеством вредоносного ввода в веб-приложения в течение следующих лет, в какой-то серой шляпе, не очень законной манере.
Перенесемся на восемнадцать лет вперед и я передумал. В университете я немного изучал теологию и юриспруденцию, но так и не получил ученую степень, в свободное время я изучал Python, Common Lisp, Clojure, а затем перешел на более непонятный язык пост-ЛИСПА picolisp. Это привело к предложению, от которого я не мог отказаться, эмигрировать на юг Европы и работать с модернизацией устаревшего PHP в бизнесе, связанном с зависимостями.
Не имея никаких этических проблем с получением прибыли от полуобязательного поведения, я бы тоже не отказался от Твиттера, и, желая получить опыт, я ухватился за предложение и переехал. В то время я также обнаружил, что моя родная страна становится странной и опасной для левых, поэтому было привлекательно уехать и наблюдать за ней издалека. Это оказалось очень весело, абсолютно страшно и очень ценный опыт.
Организация
Когда я приехал, я оказался в группе примерно из двадцати разработчиков, включая двух боссов, в одной комнате, где менеджеры из других подразделений компании считали добродетелью участвовать в микроуправлении разработкой. Результатом стал интересный, фрагментированный процесс разработки, в котором спецификации и анализ пользовательского интерфейса казались запретными, более или менее замененными расплывчатыми инструкциями, такими как “перенесите это” и “добавьте эту функцию”, и много молчания после вопросов и предложений.
Понаблюдав за тем, как один босс пару дней интегрировался со сторонним API, я начал получать задания и работать над ними. Недели проходили без конструктивной обратной связи, и выяснилось, что проверка кода не была частью регулярной работы по разработке, а также что разработчикам было явно запрещено проверять среди коллег.
Вместо этого была проведена своего рода проверка кода после того, как один из боссов переехал в другую страну и начал работать удаленно. Тем не менее, это было сделано путем просмотра фрагментов commitdiff и комментирования конкатенации строк или рекомендации отказаться от плохих методов кодирования. Иногда эти методы применялись вместо нынешнего, более адекватного решения, чтобы избежать трений или конфликтов.
Поскольку каждый разработчик работал в одиночку, практически не контактируя между собой, боссам также приходилось часто повторяться, рассказывая одно и то же разным людям, что казалось мне неудобным и расточительным.
Отсутствие структурированного планирования означало, что крайних сроков не существовало, это была скорее культура разработки, основанной на быстрых решениях, и поэтапного проектирования. Отсутствие сплоченности в команде параллельно с небольшой сплоченностью в выводе кода, также это интересный выбор управленческой доктрины.
Результатом этого стало то, что кодовые базы были довольно нерегулярными. Одному человеку очень нравились бородавки на ногах, и больше никому не нравились. Другой считал, что PHP не хватает веб-шаблонов, и изобрел некоторые из них на PHP, возможно, наиболее широко распространенном в мире языке веб-шаблонов. Один из них годами терпел неудачу в создании REST API:s и вместо этого принял GraphQL и, таким образом, заставил других сделать то же самое. Некоторым нравился красноречивый, в то время как другие предпочитали передавать строки в Fluent QB для необработанного выполнения, а другие писали пользовательский слой на небольшом количестве того и другого.
Когда впереди было увольнение и увольнение, это было очевидно, но об этом не говорили, казалось, боссы думали, что остальные из нас ничего не замечают. Это означало довольно странные настроения среди некоторых коллег и множество распущенных слухов, когда кто-то там больше не работал. Возможно, в этом и заключалась идея, мне было трудно сказать.
Прошло несколько месяцев, прежде чем мне впервые дали приватную беседу о проблемах и производительности, где я высказал опасения по поводу этого и некоторых SQLi: s, которые я нашел. Мне сказали кое-что о политике компании и о том, что мы склонны исправлять такие уязвимости, когда они были обнаружены.
Лидерство, основанное на страхе, тревоге и отчуждении, может быть прибыльным, но только в тех секторах, где качество не является проблемой, где машины являются производителями, а люди используются для управления рычагами или чем-то подобным. Похоже, это не очень хорошо соотносится с искусством программирования.
Полученные знания
Если ваш босс больше впечатлен результатами или послушанием, чем качеством кода и способностью рассуждать об этом, начните искать другую работу, потому что, когда это станет проблемой, вас скорее уволят, чем повысят
Если каждая ветвь в репозитории имеет свой собственный стиль, вы многому научитесь, но это также сильно замедлит поиск ошибок, если только вы не написали код
Если нет конструктивной обратной связи о вашей работе, у вас возникнут проблемы с хорошей работой
У менеджера есть право на платежную ведомость, в то время как у вас есть право на доверие, поэтому у вас будет больше шансов быть уволенным, если ваши коллеги начнут доверять вам больше, чем своим менеджерам
Не работайте сверхурочно без оплаты, и если вы все равно это сделали, обязательно сообщите об этом своему начальству, чтобы они знали, что они должны вам больше, чем они думали
Сталкиваясь с несвязными кодовыми базами, последовательно пишите в своем собственном стиле в меру своих возможностей и старайтесь убедиться, что результат будет хорошим, а не спрашивать об этом начальство или коллег
Внимательно прислушивайтесь к тому, что ваши коллеги говорят о прошлых сотрудниках и о том, что привело к тому, что они там больше не работают, это может помочь избежать внезапных изменений в вашей работе
Код
То, что я думал, будет модернизацией устаревшего кода, в конечном итоге оказалось сохранением и включением его во все новые и новые проекты. Базовым приложением была старая издательская платформа, переписанная в деталях на протяжении многих лет, но так и не переработанная. Термин, который случайно использовался как синоним “изменения существующего кода”, а не общепринятого технического значения на этом рабочем месте. Поначалу это очень сбивало с толку.
Это ядро было написано в процедурном стиле с некоторой помпой сверху, обдумывалось в течение многих лет и имело высокую степень взаимосвязи между файлами и функциями. Результирующая сложность оказалась в виде больших красных кругов в PhpMetrics и довольно сложной для любого, независимо от предыдущего опыта. То, что было описано как микросервисная архитектура, представляло собой скорее обертку громоздких фреймворков вокруг новых или старых экземпляров этого.
В какой-то момент при разработке нового программного обеспечения необходимо принять некоторые стратегические решения о том, для каких программистов вы хотите писать код. Если вы единственный в компании, кто ценит функции более высокого порядка и каррирование как способ решения проблем, вам следует избегать этого и вместо этого создавать серию классов и интерфейсов.
По этому вопросу я не нашел руководства и довольно долго боролся, выясняя, что это была моя проблема и что я должен был попытаться предсказать, кто может прочитать мой код позже. Отсутствие общего представления о том, каким магазином программного обеспечения должно стать это место, по-видимому, плохо сказывается на производительности. Вместо этого среда была такой, в которой устаревший для i < count (ввод) i++ был жизнеспособным шаблоном, даже несмотря на то, что foreach был введен в PHP 4, а комментарий к обзору кода мог состоять из унизительного комментария об образовании и ссылки на руководство PHP по строкам. Потому что, по-видимому, проблема с вставкой непроверенных входных данных в запросы базы данных заключается в том, выполняется ли это в одинарных или двойных кавычках.
В то время как отсутствие стратегического обсуждения и рецензирования кода на основе коллег в сочетании с разработкой, ориентированной на быстрое исправление, делает необходимым для младшего специалиста быстрое изучение новых инструментов и шаблонов кода, также кажется, что в долгосрочной перспективе это имеет некоторые издержки, поскольку победоносная отладка становится зарезервированной для безжалостного, нельзя просто назначить кого-либо на билет, не рискуя, что они проведут неделю в кругах.
Все чаще я становился лучше в быстрой оценке кода и находил все более и более серьезные проблемы для добавления в мою личную базу данных ошибок. По какой-то причине общего не было. Эти находки встревожили меня все больше и больше, так как я считал слишком рискованным запускать некоторые из них в производство. Однако, когда я забил тревогу, меня встретили с безразличием, которого я не ожидал, и позже я узнал, что некоторые из них были известны в течение многих лет и что те, кто постоянно поднимал шум, были уволены.
Полученные знания
Столкнувшись с бессвязным кодом, расслабьтесь и мысленно повторяйте выполнение снова и снова, пока не поймете это и почему результат такой это
Мышление в бессвязном коде требует больших усилий, никогда не пропускайте обед, потому что в последние часы дня вы ничего не добьетесь
Если вы не получаете хорошей критики своего кода, вам нужно изобрести его самостоятельно
Чем хуже код, тем больше мощности требуется для вашего инструментария, а также для глубокого понимания сценариев командной строки
Кодирование – это искусство, поэтому нечувствительные комментарии по этому поводу обязательно повредят, используйте это с умом и вниманием
Не прекращайте поиск ошибок до тех пор, пока вы не потратите достаточно времени на то, чтобы творчески взламывать приложение
Выводы
Я настоятельно рекомендую всем, кто хочет заниматься PHP, но не имеет опыта работы, устроиться на работу в место, которое наймет вас всего за несколько строк дерьмового кода и расскажет о знаниях в областях, которые не имеют ничего общего с бизнесом, которым они занимаются.
Вы будете быстро учиться, многому научитесь и увидите вещи, которые в противном случае никогда бы не поняли, как многого вам нужно избегать, пока вы сами не совершите ту же ошибку и не испортите все. И это очень ценно, невозможно выучить самостоятельно (возможно, вы могли бы подхватить кое-что в OSS dev) и будет с вами до конца вашей жизни в качестве программиста.
Далее я буду более полезен и покажу набор инструментов, с которым мне удобно работать.
Оригинал: “https://dev.to/cess11/notes-on-my-first-php-job-7dl”