Этот пост является продолжением: Иллюзия эффективной разработки: управление
Все мы учились программированию, практически все из нас проходили стадию задания вопросов на форумах, в конференциях, бывало и в коллективе. Условно всех отвечающих можно разделить на 2 группы: те, которые знают ответ на ваш вопрос и те, которые знают как правильно. Они — пророки стандарта, они — апостолы правого дела, они и только они смогут безбожно затянуть ваш проект, прикрываясь совершенной архитектурой и вылизанностью кода. Они — мировая закулиса мира ИТ, которая, сама того не ведая, определяет, что будет в тренде в следующие несколько лет.
Если вам надоело читать, то просто скажу, что суть этого поста в том, чтобы вы думали своей головой. Или думали своей головой и держали мысли не высказанными, если планируете долго и продуктивно работать на текущем месте. Всем остальным добро пожаловать под кат.
Церковь имени Совершенного кода
Проблема стара как мир — использование идеи без понимания ее смысла. В нашем случае все начинается тогда, когда с передовыми методиками проектирования знакомится человек, не имеющий достаточного опыта, чтобы понять зачем они нужны, или же не имеющий достаточно знаний, чтобы сформулировать связь между типовыми задачами отрасли и подходами, излагаемыми в книге. Результат один — предлагаемые идеи принимаются на веру. А ввиду непонимания области применения, идет применение этих идей там, где они неприменимы.
Мир IT хорош тем, что те, кто не учится, тот не задерживается в нем надолго. И постепенное понимание того, зачем на самом деле нужно ООП, паттерны и т.д. таки приходит к таким программистам. Тех же, кто так ничего и не понял, очень легко определить по безапелляционности суждений в пользу какого-либо подхода и готовности признать людьми второго сорта всех тех, кто такого подхода не придерживается. И если это тимлид во главе индусского полка, то такое поведение еще можно как-то объяснить, а в остальном, я считаю, что таким тимлидам стоит многому научиться у киногероя бессмертного творения Светланы Басковой, призывающего всех быть людьми.
Не переставайте каждый раз задавать себе вопрос, почему тот подход, который вы используете стоит применить в конкретном случае. Отдавайте себе отчет в том, какие проблемы такой подход решает. Убедитесь, что эти проблемы существуют в вашем проекте. Если в результате этой простой процедуры вы пришли к конечным обоснованиям вида «это хорошая практика», а то и «моя вера сильна», то, возможно, это косвенный признак того, что выбранный подход в данном случае не подходит.
От бумажного самолетика к шаттлу
Ум каждого порядочного молодого web-программиста будоражит вопрос: со скольки соединений начинается highload? Ум же каждого порядочного архитектора занимают два вопроса: каков минимальный уровень абстракции сделать в проектируемой системе, чтобы дальнейшее расширение не превратилось в ад, а также — насколько высокий уровень абстракции можно сделать в оной, чтобы разработка и поддержка не превратились в ад. Вопросов таких много, но сводится все к тому, какие именно паттерны и архитектуру использовать для проекта определенного масштаба. Проблема усложняется тем, что нередко представления о перспективах развития или о посещаемости проекта весьма расплывчаты, при этом решать проблему сразу и основательно не позволяют сроки и бюджет. При этом от архитектора все равно требуется создать нечто, что соответствует всем противоречивым требованиям.
Разные люди решают эту проблему по разному. Кто-то решает не заморачиваться со структурой, считая что если проект взлетит, то найдутся деньги переписать с нуля, а если не взлетит, то и незачем тратить усилия. Кто-то, проектируя систему, которая сможет все, начинает наводить пушку на воробья, но к моменту наведения, несмотря на филигранную точность расчета, оказывается, что воробей улетел, а сроки и бюджет превышены вдвое. Кто-то просто спивается от безысходности, уходя таким образом от решения проблемы. А кому-то может посчастливится угадать требования к системе, которые поставит время, и тогда получается отличный продукт с замечательной архитектурой. А кто-то проектирует по текущим требованиям или с небольшим запасом из расчета потерять немного времени, но хотя бы оставить возможность дальнейшего расширения. Как правило, наиболее жизнеспособными оказываются первый и последний подходы.
На мой взгляд, сегодня еще не существует четких методик определения того, начиная с какого момента оправдано применение такого-то архитектурного подхода. Т.е. сборники подходов есть, описаны случаи применения, но вот та граница, где начинается такой случай не описана нигде. Обычно понимание того, когда что применять приходит с опытом, однако передать подобный опыт словами — задача непростая. Специфика отрасли такова, что почти каждая новая архитектура отличается от уже имеющихся, ровно на столько, чтобы советы по новой архитектуре человеку, не имевшему дела со старой, были бесполезны.
Просто помните, что насколько бы изящен не казался паттерн в книге, насколько бы не была привлекательна идея покрыть весь код тестами, насколько бы не было здорово иметь архитектуру «про запас», все это может в итоге оказаться для вашего проекта обузой, а не подспорьем. Решайте сами, что вам нужно и чем ради чего вы готовы пожертвовать — далеко не всегда пренебрежение вещами, без которых, как считается, нормальный код немыслим, низвергнет вас на девятый круг ада.
Велосипед для езды по стенам
Сегодня мы имеем множество замечательных проектов вида github.com, sourceforge.net и т.п., не говоря уже репозитариях кода для конкретных языков. И именно их наличие сыграло немалую роль в плане насаждения убеждения о том, что велосипеды это плохо, и что всегда есть готовое решение. Безусловно, если вы решите писать свой gui-тулкит для windows или же шаблонизатор для php, то я бы бросил все незаконченные дела, встал, застегнул штаны и пошел бы прочь с вашего поля, выражая при этом мнение большинства.
Но как только мы возьмемся за что-нибудь чуть более нетипичное, чем указанные выше вещи, как перед нами в полный рост встанет проблема качества тех библиотек, которые кажутся такими доступными. Под качеством я подразумеваю 3 вещи:
- функциональность — необходимо самолично прочувствовать тот момент, когда обнаруживается, что в выбранной библиотеке отсутствует 10% функционанала, на котором будет держаться 90% вашего проекта. Разработчики — такие же люди как и вы, и обычно в эти очень нужные 10% входят самая грязная работа за которую никто не хочет браться.
- документация — плохая документация просто бич всех молодых проектов, а без нее добро пожаловать в код
- качество кода — определяет возможность расширения и или даже изучения API в случае плохой и отсутствующей документации
Если смотреть на качество библиотек трезво, то можно все-таки допустить вариант когда вам придется писать аналог самому. Просто потому что так будет проще. Так будет быстрее и эффективней. Так будет неправильно. А еще ваш велосипед правда может быть особенным — в том плане, что даже при мнимом изобилии решений ни одно из них не подойдет вам в полной мере. Хотя вы можете получить индульгенцию за это святотатство, выложив свой вариант на github. Чтобы другие погорели на нем или написали свой. А еще время развертывания приложения прямо пропорциональна количеству библиотек, которые необходимо развернуть вместе с ним.
Отдельно выступает проблема выбора между новым проектом или развитием уже существующего решения. Наиболее это выбор тяготеет над web-программистами — львиная доля проектов в web довольно типовые, для которых существуют движки cms, web-магазинов, соцсетей и пр. На первый взгляд всегда кажется, что логично доделать уже существующее решение до требований ТЗ, чем писать свой велосипед с нуля. Особенно логичным это кажется после того, как на одном и том же движке подряд выполняется несколько проектов, причем быстро и изящно. Однако же можно и погореть, упершись в ограничения архитектуры или в причудливую верстку, или даже в скорость, с которой все будет работать после того как работа будет закончена. Для себя я вывел эмпирическое правило — если проект занимает по моим прикидкам более месяца, то лучше писать с нуля или на фреймворке общего назначения. Ну как лучше — мне лучше, а вам придется выводить свои правила в зависимости от того, с чем вы работаете.
Просто помните, что бывают случаи, когда парсинг xml регулярными выражениями будет предпочтительнее, чем использование байндинга к libxml, а написание простенького на первый взгляд интерент-магазина будет более простым на Yii, чем на основе PrestaShop. Все, безусловно, уже придумано до нас, но не все это воплощено в коде в том виде, чтобы этим можно было удобно пользоваться.
На передовом рубеже технологий
Одним из самых простых способов заработать авторитет в мире ИТ является следование трендам. Чем скорее вольетесь в тренд, тем лучше. Будете думать и проверять насколько тренд эффективен в действительности — не успеете в первые ряды, и почетного звания senior-bleeding-age-developer вам не видать. Я вовсе не говорю, что новое — это плохо, я даже верю в то, что применение новых технологий может как-то помочь вам обойти конкурентов(но я все-таки считаю, что хороший менеджер продаж или отличный юзабилити дадут вам на порядок больше шансов завоевать первенство, чем грамотная архитектура). Я лишь хочу заметить, что перед тем как выбрать для своего проекта новомодный фреймворк неплохо быть уверенным в том, что:
- в этом фреймворке присутствует хотя бы часть реально необходимого для вашего проекта функционала
- этот функционал правда можно будет применить — ну т.е. взять и использовать, я не плясать с бубном, чтобы это хоть как-то заработало
- вы настолько уверены в себе и своих подчиненных, что знаете, что если наткнетесь ошибку, из-за которой вся разработка может встать, то вы сможете путем дебага и копания во внутренностях фреймворка устранить ее
- у вас есть время на реализацию предыдущего пункта
Опять-таки, отдавайте себе отчет в том, для чего вы выбрали новую технологию Y, при наличии технологии X, которая уже хорошо оттестирована, имеет коммьюнити и вообще используется повсюду.
Теория и практика
Я долго думал, что написать тут, но как-то получалось, что слишком объемно или слишком конкретно, из-за чего многие бы подумали, что я являюсь идейным противником каких-то технологий и подходов. Поэтому я ограничусь пятью пунктами:
- Не принимайте за истину выкладки теоретиков(этой статье, например) или чужой опыт, если не уверены, что он получен на основании создания решения очень близкого к вашему.
- Насколько бы убедительны не были примеры в документации, помните, что они зачастую синтетические
- Вообще любая концепция придумывается для решения какой-то задачи или класса схожих задач, нет никакой гарантии, что ваша задача гармонично вписывается этот класс
- Сложные на первый взгляд концепции применительно к вашей задаче могут обернуться выкладкой в пару строчек, понятных большинству сельских учителей информатики
- Очень осторожно относитесь к концепциям «не для всех» или «опередившим свое время», которые годами остаются уделом небольшой группы людей — они могут оказаться чрезмерно сложными в применении, но зачастую просто практически бесполезными
Вот и понимайте их как хотите. И помните о разнице между олимпиадным и промышленным программировании.
Только бы не ошибиться
Опыт — сын ошибок трудных. А что делать когда опыта нет, а ошибок хочется избежать? Тут в ход идут книжки по пикапу. А в случае программирования всякие best practices. Начитавшись такого и хотя бы зазубрив набор правил хорошего кода, можно писать код так, чтобы потом никто не посмел упрекнуть в том, что что-то написано не так. Это здорово. При этом упускается тот факт, что за все приходится платить. До тех пор пока вы сами не дойдете до необходимости методик(кроме простейших), они не смогут быть эффективно использованы и будут по большей части отнимать ваше время. Если вчерашний студент, успешно создающий сайты на php десятками, прочитает «Совершенный код» и будет пытаться использовать все это на практике, то скорее всего его работа встанет, хотя качество кода местами и улучшиться. И так будет до тех пор, пока он самолично не пройдется по граблям в каком-нибудь крупном проекте, пока абстрактные построения из книжек не найдут соответствия из реальной практики. Только тогда придет понимание того, что, когда и зачем использовать.
Но не надо уходить от корней — множество тех же студентов, набравшись опыта за несколько лет, начинают считать, что копипаст и процедурное программирование относятся к словам разряда Тех, которые нельзя называть. Причина все та же — боязнь ошибиться. К сожалению, сейчас сообществом более приемлемо использование правильных решений, а не поиск инструмента под задачу.
Просто не бойтесь ошибаться. Если уверены, что это не будет стоить вам потери репутации и работы.
Тимлид — наш царь, отец и бог
Признаться вся эта статья была навеяна тем фактом, что мне приходилось работать в командах с разными тимлидами, у каждого из которых были свои представления о том, как нужно писать код правильно. Все они были в деталях правы, но беда в том, что эти детали у каждого из них весьма сильно расходились. Более того, я рискну предположить, что если всех их свести за одним столом в питейном заведении, а после перевести беседу в русло сравнения императивного и функционального программирования или же об отличиях Dependency Injection от старой доброй Factory, то без вмешательства охраны не обойдется.
Все тимлиды тоже люди, все они имеют свои убеждения и знания, полученные на основе выполнения каких-то своих проектов. Иногда такие убеждения соответствуют реальности, иногда — нет. Иногда последнее может вам казаться из-за того, что вы еще не сталкивались с задачами, которые бы привели вас к пониманию того, почему делать нужно именно так. В любом случае, воспринимайте все, что скажет тимлид как его требования, а не как реально хорошие вещи. Если его советы пройдут проверку практикой — замечательно, а если нет, то переубеждать человека в такого рода ошибках обычно бесполезно.
Заключение
Не существует универсальных правил хорошего тона в разработке. Существуют правила, которые могут принести пользу в какой-то ситуации. Даже если таких ситуаций много, это не значит, что вы не столкнетесь с другой, когда правила, когда-то помогавшие, окажутся бесполезными. И не забывайте задавать себе вопрос, почему вы выбрали именно это решение проблемы, а не другое.
Автор: PerlPower
