Десять правил программиста
Главная » Анекдоты, цитаты, девизы » Десять правил программистаПросмотров: 3393
Лет 5-7 назад я сформулировал свод правил, которым руководствовался при работе над проектами (в основном автоматизация управления предприятиями), ну и плюс в этом же духе пытался учить подчинённых (в роли прожект менеджера). Сегодня вот наткнулся на эти правила, почитал, пустил слезу :) Со временем взгляды меняются и с некоторыми правилами я уже не совсем согласен, что лишний раз говорит о том, что составлять подобные списки — дело неблагодарное. А ещё, когда находишься внутри предметной области (напомню — автоматизация предприятий), сталкиваешься с ежедневными ошибками проектирования, то эти правила вполне разумны, понятны и применимы на реальных ситуациях. А с точки зрения непрограммиста или программиста из другой отрасли, некоторые из правил наверняка звучат пафосно, банально или бессмысленно. Так что не уверен, что все поймут, но всё же опубликую.
Первое правило программиста
Разделяй и властвуй.
(© предположительно Гай Юлий Цезарь)
Смысл: дели большую задачу на маленькие и решай их по очереди. Однако помни о задаче в целом: все маленькие решения должны в конечном итоге вести к решению большой задачи.
Второе правило программиста
Лучше день потерять, зато потом за пять минут долететь.
(© Орёл из м/ф «Крылья, ноги, хвосты»)
Признак хорошего программиста — автоматизация собственной деятельности.
(© ibigdan)
Никогда нет денег и времени, чтоб сделать всё как надо. Но на то, чтоб потом переделывать, и время и деньги находятся.
(© Закон Хеопса)
Смысл: недостаточно успешно закончить задачу, нужно выйти из неё с новым багажом. Создавай не только конечные решения, но и методы + инструменты — всё это пригодится в этом и в следующих проектах. Делай это, даже если поджимают сроки, потому что если ты не растёшь — ты отстаёшь. Заказчику и начальнику на это плевать, тебе нет.
Третье правило программиста
Read The Fucking Manual
(© отчаявшийся сисадмин)
Знание некоторых принципов легко компенсирует незнание некоторых фактов.
(© Гельвеций)
Воображение важнее знания. Знание ограничено. Воображение охватывает весь мир.
(© А.Эйнштейн)
Смысл: вы должны уметь взлетать высоко и нырять глубоко. Уметь увидеть задачу в целом и уметь разобрать её до мельчайших деталей. Без системного мышления и аналитического склада ума в программировании делать нечего.
Четвёртое правило программиста
Зри в корень.
(© Козьма Прутков)
Не так много сущностей, как взглядов на них. Сущность — основа решения, взгляд на неё — доработка под конкретную задачу.
(© ibigdan)
Смысл: например «директор» — это не человек, это должность, которую может занимать человек (а может никто не занимать). И «Иванов Пётр Сидорович» — не человек, а фамилия, имя и отчество, то есть атрибуты человека. Человек — это тело, живое или мёртвое, с кучей атрибутов :) Обычно до таких нюансов при проектировании не опускаются, поэтому большинство автоматизированных систем управления очень негибкие.
Пятое правило программиста
Правильно назвать — значит правильно понять.
(© неизвестный автор)
Ответь на вопрос «что это ?» — получишь термин. Ответь на вопрос «зачем это ?» — получишь смысл. Возможно на вопрос «как лучше это сделать?» отвечать уже не придётся.
(© ibigdan)
Суть программирования в том, что бы разобрать предметную область на мелкие куски (анализ) и воссоздать её в компьютере в виде работающей модели (синтез).
(© ibigdan)
Смысл: всё программирование сводится к чередованию анализа и синтеза. Причём анализ может быть математическим, функциональным, объектным — любым. И язык синтеза тоже значения не имеет. Важно только понимание и грамотное выполнение этих двух этапов.
Шестое правило программиста
Не плоди сущностей сверх необходимого.
(© В.Оккам)
Пусть это будет просто: просто, как только можно, но не проще.
(© А.Эйнштейн)
Совершенство достигнуто не тогда, когда нечего добавить, а когда нечего удалить.
(© неизвестный автор)
Дублирование и избыточность — признак неправильного понимания предметной области.
(© ibigdan)
Смысл: если сущность появляется в автоматизированной системе более одного раза, значит вы серьёзно накосячили при проектировании. Пример: «Иванов Пётр Сидорович, должность: врач, место работы: урологическое отделение». Потом у него случается инфаркт и опа! — объект номер два: «Иванов Пётр Сидорович, пациент, кардиологическое отделение». На самом деле это один и тот же человек, но в системе числится как два разных, не связанных между собой. Причём это типовая и элементарная ошибка проектирования, а есть куда более запутанные. Большинство АСУП состоят из таких ошибок более чем полностью.
Седьмое правило программиста
Сложные проблемы всегда имеют простые, лёгкие для понимания, неправильные решения.
(© айтишный фольклор)
Если маленький простой предмет увеличить в 100 раз, то он станет большим и сложным.
(© ibigdan)
Когда мы пытаемся вытащить что-нибудь одно, оказывается, что оно связано со всем остальным.
(© Закон Мура)
Смысл: несколько смыслов. Не спеши радоваться найденному решению, возможно оно учитывает сущности, но не учитывает связи. Старые решения могут не работать на новых задачах другого масштаба. Вообще о проблемах масштабирования лучше Джоела Сполски не расскажешь.
Восьмое правило программиста
Программный продукт, моделирующий некую предметную область, физически не может быть проще этой предметной области.
(© ibigdan)
Следствие: универсальный программный продукт на несколько порядков сложнее специализированного, поскольку охватывает группу взаимосвязанных областей.
(© ibigdan)
Следствие: программный продукт который может всё — бесконечно сложен, а значит невозможен в принципе.
(© ibigdan)
Смысл: увы, никто не выделит вам ресурсы на поиск ответа на «главный вопрос жизни, вселенной и ваще». Ищите компромиссы между желаемым и возможным.
Девятое правило программиста
При автоматизации организационного управления на основе использования ЭВМ следует помнить, что главным залогом ее успеха является коренное изменение традиционной технологии организационного управления.
(© В.М.Глушков)
Автоматизация не самоцель, а инструмент оптимизации деятельности предприятия. Если автоматизация не оптимизирует, то в ней нет никакой необходимости.
(© ibigdan)
Смысл: нет большего идиотизма, чем автоматизировать бумажный документооборот, создавая его точную копию в компьютере. Некоторые программисты так хотят сделать «привычный пользователю» интерфейс, что рисуют на экране бумажные листы, размещают на них строчки и таблички в том же виде, в каком они были на бумажных накладных и т.п. С маркетинговой точки зрения это оправдано, но только вот к автоматизации это отношения не имеет — раньше был хаос на бумаге, теперь хаос в компьютерной сети. Не нужно забывать, что документ — не сущность, а «бухгалтерский взгляд» на неё, сущность — это товары, перечисленные в накладной, вот реальный объект, операции с ним и нужно автоматизировать. Бумажный документооборот — это всего лишь попытка «автоматизации», которую произвели за сто лет до вас и до появления компьютеров, не нужно её автоматизировать, нужно её заменить. Это был пример, таких моментов полно в любой области.
Десятое правило программиста
Если рассмотреть проблему достаточно внимательно, то вы увидите себя как часть этой проблемы.
(Аксиома Дучарма)
Смысл: а вот не скажу :) Это правило из тех, до которого нужно дойти самому, своими ножками, иначе его не понять. Но вот когда дойдёте до него, будете удивлены тем, как можно решить нерешаемые проблемы простым, но очень необычным способом.
Источник: http://ibigdan.com/2012/01/04/10-pravil-programmista/
Друзья! Приглашаем вас к обсуждению. Если у вас есть своё мнение, напишите нам в комментарии.
