Максимы

Аркадий Морейнис, 1995 год, журнал КомпьютерПресс

«При планировании разработок нужно учитывать три переменные: цель, деньги и сроки. Если известны цель и деньги, отпущенные на разработку, то неизвестно, сколько времени она потребует. Если известны цель и сроки, то неизвестно, сколько денег потребуется для завершения работ. Если известны срок и количество денег, то непонятно, что получится в результате. Если известны все три составляющие, то эта задача вообще не относится к сфере разработок.» — Один из законов Мерфи

То, что вы будете сейчас читать — не совсем статья. Скорее это набор некоторых высказываний, которые я повторял окружающим меня разработчикам настолько часто, что выучил их наизусть. Источник появления всех этих высказываний понятен — программирование в общем отличается от промышленного программирования точно так же, как отличается бег трусцой от спринтерского забега. В одном случае важен процесс, а в другом результат.

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

Если ты знаешь, все операторы языка программирования, если ты помнишь наизусть все системные (включая недокументированные) вызовы операционной системы, если ты можешь простучать в отладчике любую защиту — запомни, не это определяет твою квалификацию как программиста. Твою квалификацию определяет умение выполнить поставленную задачу точно и в срок.

Задачи условно делятся на три категории — соответственно квалификации. Низшая — ты можешь запрограммировать предложенный кем-то алгоритм Средняя — по предложенной спецификации функции или программы ты можешь предложить алгоритм ее реализации и запрограммировать его. Высшая — ты можешь предложить способ решения задачи, написать спецификацию программы, ее решающей, и запрограммировать ее.

Кстати, есть еще и самая высшая степень: понять, какую именно задачу стоит решать.

Умей искать информацию и умей ее понимать. Для того чтобы предложить способ решения задачи — ты должен его знать. От тебя никто не требует, чтобы ты был гением во всех отраслях человеческого знания. От тебя требуют того, чтобы ты знал, где или как это решение можно найти. Если же решения в явном виде не существует — ты должен уметь быстро освоить доступные по этой теме материалы для того, чтобы предложить свой способ решения на базе тех решений, которые уже известны.

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

Hе отказывайся от работы, пусть даже она тебя поначалу и не вдохновляет. К программистам относятся так же, как и к разведчикам: «С этим я в разведку пойду, а с этим — нет». Умей оценивать время, нужное тебе для выполнения работы.

Умей оценивать время, нужное другим для выполнения составных частей твоей работы. Программистское руководство редко спрашивает: «Почему так медленно?», чаще всего оно спрашивает: «Когда же, наконец?».

Имей широкий кругозор. Причем речь идет не только о программировании, но и о практически любых областях человеческого знания. Никому не известно, что может тебе помочь при решении очередной задачи. Кроме всего прочего, ты можешь набрести на свежую идею. Кстати, это вовсе не означает, что целыми днями ты должен ползать по Интернету, интересуясь всем на свете. Не забывай — у тебя всегда есть конкретная задача, которую ты сейчас решаешь.

Программирование — это тяжкий труд. Ты должен привыкнуть к тому, что ты будешь сидеть, не вставая со стула по 12 часов в день, вырисовывая бесконечные макеты диалогов, отлаживая программу под разнообразными конфигурациями операционной системы, ища ошибку в своей программе годичной давности, а также занимаясь другими столь же не вызывающими восторг занятиями. Программирование сродни гению — это 5 процентов таланта и 95 процентов усидчивости.

Программа не может быть практически готова. Она может быть либо готова, либо нет. Опыт показывает, что между практически готовой программой и готовым продуктом может пройти и полгода, и год.

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

Умей структурировать задачу. Одна причина состоит в том, что все более или менее простые функции ты можешь передать кодировщику. В противном случае тебе придется кодировать все это самому. Другая причина в том, что выполнение неструктурированной задачи невозможно ускорить. Возможна ситуация, при которой ты станешь бутылочным горлышком для всего проекта безо всякой возможности помощи со стороны, даже от коллег той же квалификации.

Читай документацию. Есть реальный шанс узнать много нового, а также найти ответ на мучивший тебя давно вопрос.

Не пиши программы красиво — пиши просто. Твоя задача состоит не в том, чтобы родить самый, красивый код, а в том, чтобы написать надежную, простую в исправлении и модификации программу.

Как известно, в любой программе есть хотя бы одна ошибка. Поэтому шанс на то, что тебе придется влезать в свою — в лучшем случае свою — программу не один раз после ее выпуска, достаточно высок. Не удивляйся, если ты напрочь забудешь к этому времени, как она устроена. Не усугубляй эту неприятность тем, что тебе придется решать свои собственные головоломки.

Hе гонись за теоретической эффективностью. Эффективность программы определяет пользователь – и это эффективность практическая. Если программа работает с достаточной для реакции пользователя скоростью — остановись на этом. Занятия ползучим улучшизмом могут затянуть появление конечного продукта на непредсказуемое время.

Hе изобретай велосипед. Hе пиши в очередной раз процедуру пересылки файлов по локальной сети. Возьми этот код у коллеги, который прописывал аналогичную вещь полгода назад. Со своей стороны выделяй в отдельную библиотеку все те процедуры, которые могут понадобиться другим. Кстати, это упражнение способствует развитию способности структурировать задачу.

Отлаживайся. На всех компьютерах, при всех конфигурациях операционной системы, в условиях недостатка памяти, на очень больших файлах, и т.д. На это стоит потратить время, иначе в течение следующего полугода или года после выпуска программы тебе придется разбираться в ошибках. Наиболее часто практикуемый способ разбирательства с ошибками — дистанционный, когда неудовлетворенный пользователь звонит тебе с другой стороны Уральского хребта. В процессе отладки нелишне вспомнить, что пользователь а) практически никогда не читает документацию, поэтому может выполнять все совсем не в том порядке, который описан в инструкции, б) способен на все, поэтому он может загнать программу в любые условия жизнедеятельности и в) не будет разбираться ни в чем, поэтому если программа не будет при всем этом работать, то это программа плохая.

Работай постоянно. Просто удивительно, как много времени для своего завершения требует работа, которую никто не делает.

© Аркадий Морейнис
amoreynis@gmail.com