Уроки, извлечённые из опыта разработки программного обеспечения. Хоть список правил больше касается разработки ПО, это будет полезно почитать каждому новичку.

Разработка

1. Начинайте с небольших вещей, затем расширяйте их.

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

Мне нравятся эти слова Джона Галла: «Любая достаточно сложная система, которая работает, так или иначе в своё время эволюционировала из простой системы, которая работала».

2. Изменяйте что-то одно за один раз.

Если при разработке программа начинает проваливаться на каком-то тесте или некоторая функция перестаёт работать, то гораздо проще найти причину, если вы поменял код только в одном месте. Другими словами, лучше использовать небольшие итерации, чем пытаться сделать всё и сразу. Сделайте что-то одно, убедитесь, что это работает, повторите.

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

3. Добавляйте логирование и обработку ошибок на ранних стадиях.

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

Примерно то же самое и с обработкой ошибок — раз уж исключений всё равно не избежать, и они будут кидаться на протяжении всей жизни проекта, то почему бы не начать обрабатывать их систематически уже в самом начале?

4. Каждая новая строчка кода должна быть выполнена хотя бы один раз.

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

Иногда может быть сложно воспроизвести нужные условия, чтобы зайти во все ветки кода. К счастью, у вас есть возможность немного смухлевать, не обязательно стараться воспроизводить полностью боевые условия. К примеру, отлов ошибок базы данных можно проверить специально допустив ошибку в написании названия колонки. Или можно временно инвертировать условие внутри if, тогда случай «ошибка произошла» поменяется местами со «всё прошло корректно». Это полезно для ошибок, которые в принципе происходят очень редко и их сложно сымитировать.

Иногда мне попадаются баги, которые показывают, что определённая строчка кода вообще никогда не должна работать. Она может выглядеть вполне нормально внешне, во время code-review, но всё равно не работать так, как должна. Вы избежите таких ситуаций, если примете за правило всегда выполнять хотя бы один раз каждую новую строку.

5. Тестируйте по частям прежде, чем проверять весь проект на работоспособность.

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

6. Абсолютно всё занимает больше времени, чем вы думаете.

Особенно в программировании. Оценить, сколько времени уйдет на реализацию той или иной задачи, действительно трудно, даже если всё идет гладко. Но когда речь идет о разработке ПО, необходимо брать в расчет тот факт, что могут возникнуть неожиданные проблемы: в самое простое слияние может закрасться баг, обновление фреймворка вызовет необходимость изменить некоторые функции, или вызов API даст непредсказуемый или неверный результат.

Похоже старик Хофштадтер был прав, когда формулировал свой закон: «На любое дело требуется больше времени, чем казалось в начале, даже если вы учитывали при этом закон Хофштадтера».

7. Сначала поймите, что делает данный код.

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

8. Читайте и запускайте код.

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

Отладка

9. Ошибки будут всегда.

Мне не очень нравится подход «Сделать всё с первого раза». Не имеет значения, сколько усилий вы потратите, ошибки будут всё равно («Мы об этом не подумали…»). Гораздо продуктивней запустить приложение и исправлять баги по мере поступления.

10. Реагируйте на отчеты об ошибках.

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

11. Воспроизводите проблему.

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

12. Исправьте известные ошибки и смотрите, что останется.

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

13. Совпадений не бывает.

Не верьте в совпадения, когда занимаетесь тестированием или отладкой. Вы поменяли значение таймера, и система стала перезагружаться чаще? Это не совпадение. Вы добавили новую функциональность, и другая функция стала работать медленнее? Исследуйте!

14. Учитывайте временны́е метки.

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

Сотрудничество

Живой диалог не заменят видеоконференции, чат, звонок или электронная почта. Удивительно, насколько лучше становятся идеи и решения, если обсудить их с коллегами.

16. Резиновый утенок.

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

17. Спрашивайте.

Чтение и запуск кода — отличный способ понять, как он работает. Но если у вас есть возможность спросить кого-нибудь компетентного (автора программы, к примеру), используйте её. Возможность задать вопрос и получить на него ответ, а затем, исходя из ответа задать дополнительные вопросы, позволит вам получить информацию за несколько минут вместо нескольких дней.

18. Признавайте заслуги других.

Говорите, напимер: «Маркусу пришла в голову замечательная идея …», вместо: «мы попробовали …». Старайтесь упомянуть всех, кто вам помог.

Разное

19. Экспериментируйте.

Если вы не уверены, как работает та или иная особенность языка, вы можете просто написать маленькую программу, которая продемонстрирует это на примере. Тот же самый метод применим и когда вы тестируете сложную систему. Что случится, если я передам -1 в качестве аргумента? А не упадет ли сервис, когда я перезагружу машину? Исследуйте, как что работает — вы наверняка обнаружите какие-то ошибки, и кроме того, глубже поймете систему.

20. Поспите.

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

21. Меняйтесь.

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

22. Учитесь.

Самая лучшая особенность ИТ — всегда есть, куда расти, есть, чему учиться. Пробуйте разные языки и инструменты, читайте книги, проходите онлайн-курсы. Маленькие улучшения, накапливаясь, значительно укрепят ваши навыки.

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

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

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

· Каждое законченное действие оформляется в виде подпрограммы.. Размер подпрограммы может быть разным, это зависит от конкретного действия, но желательно, чтобы ее тело помещалось на один-два экрана: одинаково сложно разбираться в программе, содержащей несколько необъятных функций, и в россыпи из сотен подпрограмм по несколько строк каждая. Если какая-либо последовательность операторов используется хотя бы дважды, ее также нужно оформить в виде подпрограммы.

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

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

· Величины, используемые только в подпрограмме, следует описывать внутри нее как локальные переменные. Это упрощает отладку программы. Использовать глобальные переменные в подпрограммах нежелательно, потому что их изменение трудно отследить.

· Имена переменных должны отражать их смысл. Правильно выбранные имена могут сделать программу в некоторой степени самодокументированной. Неудачные имена, наоборот, служат источником проблем. Сокращения ухудшают читаемость, и часто можно забыть, как именно было сокращено то или иное слово. Общая тенденция состоит в том, что чем больше область видимости переменной, тем более длинное у нее имя. Перед таким именем можно поставить префикс типа (одну или несколько букв, по которым можно определить тип переменной). Для счетчиков коротких циклов, напротив, лучше обойтись однобуквенными именами типа i или k.

· Следует избегать использования в программе чисел в явном виде. Константы должны иметь осмысленные имена, заданные в разделе описания const. Символическое имя делает программу более понятной, а, кроме того, при необходимости изменить значение константы потребуется изменить программу только в одном месте. Конечно, этот совет не относится к константам 0 и 1.

· Для записи каждого фрагмента алгоритма необходимо использовать наиболее подходящие средства языка. Например, ветвление на несколько направлений по значению целой переменной более красиво записывается с помощью оператора case, а не нескольких if. Для просмотра массива лучше пользоваться циклом for. Оператор goto применяют весьма редко, например. для принудительного выхода из нескольких вложенных циклов, а в большинстве других ситуаций лучше использовать другие средства языка, такие как процедуры break или exit.

· Программа должна быть «прозрачна». Если какое-либо действие можно запрограммировать разными способами, то предпочтение должно отдаваться не наиболее компактному и даже не наиболее эффективному, а такому, который легче для понимания. Особенно это важно тогда, когда пишут программу одни, а сопровождают другие, что является широко распространенной практикой. «Непрозрачное» программирование может повлечь огромные затраты на поиск ошибок при отладке.

· Не следует размещать в одной строке много операторов. Как и в русском языке, после знаков препинания должны использоваться пробелы:

· Вложенные блоки должны иметь отступ в 3-4 символа, причем блоки одного уровня вложенности должны быть выровнены по вертикали. Форматируйте текст по столбцам везде, где это возможно.

· Помечайте конец длинного составного оператора.

· Для организации циклов пользуйтесь наиболее подходящим оператором. Цикл repeat применяется только в тех случаях, когда тело непременно потребуется выполнить хотя бы один раз, например при проверке ввода. Цикл for используется, если число повторений известно заранее и параметр имеет порядковый тип, цикл while - во всех остальных случаях. При записи итерационных циклов (в которых для проверки условия выхода используются соотношения переменных, формируемых в теле цикла) необходимо предусматривать аварийный выход по достижении заранее заданного максимального количества итераций. Чтобы цикл легче читался, надо стремиться объединять инициализацию, проверку условия выхода и приращение в одном месте.

Несколько советов по записи операторов ветвления:

· Более короткую ветвь if лучше поместить сверху, иначе вся управляющая структура может не поместиться на экране, что затруднит отладку.

· Бессмысленно использовать проверку на равенство true или false.

· Следует избегать лишних проверок условий.

· Если первая ветвь оператора if содержит передачу управления, использовать else нет необходимости:

if i > 0 then exit; { здесь i <= 0 }

· Необходимо предусматривать печать сообщений в тех точках программы, куда управление при нормальной работе программы передаваться не должно.

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

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

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

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

Имена переменных и подпрограмм должны быть информативными, т.е. такими, чтобы, глядя на них, другой программист мог догадаться о назначении переменной или подпрограммы. Плохо подобранное имя, дезориентирующее читателя, даже хуже, чем неинформативное имя, например X или A. Имена переменных должны состоять из букв нижнего регистра, кроме букв, с которых начинается второе или последующие слова, входящие в имя, например taxRate или numberOfCars . Имена подпрограмм должны начинаться с буквы верхнего регистра.

Имена объектов, свойств и методов должны начинаться с букв верхнего регистра.

Имя каждого компонента должно начинаться с префикса, состоящего из трех букв нижнего регистра и обозначающего тип компонента. Например, имя формы содержит префикс frm , поля ввода – edt , кнопки – btn и т.д. Буквы после префикса описывают назначение или содержание компонента. Например, поле ввода edtLastName содержит фамилию.

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

Не следует опасаться того, что программа слишком вырастет в длину, так как реальные программы и без того настолько длинны, что несколько «лишних» страниц (или даже десятков страниц) не меняют общую ситуацию. Выигрыш же в понимаемости с избытком покрывает увеличение длины.

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

4.2. Правила разработки программ

У всех вещественных констант цифры должны быть как слева, так и справа от десятичной точки, например 0.15, а не.15.

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

Для преобразования вещественного значения в строку и обратно используйте процедуры Str () и Val (), а для целых значений в языке Object Pascal – функции StrToInt () и IntToStr () соответственно.

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

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

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

1. Перед началом каких-либо операций проверьте существование всех нужных файлов, папок и переменных. Например, если файл не будет найден, то вы его сможете создать и избавиться от ошибок.
2. Проверяйте все входные данные, которые передаются по форме. Например, если в переменной должна прийти дата - проверьте являются ли пришедшие данные датой. Даже если в форме предлагается выбор этих самых дат. Помните, форму всегда можно сохранить локально и поправить ее на свое усмотрение.
3. Проверяйте входные данные, чтоб они были только в пределах диапазона, указанного вами. Например, если вы поставили ограничение на 1000 символов в сообщении, а вам написали 2000.
4. Длина слов и другие, так как в простую форму можно вести очень много символов, из которых вам нужно будет всего лишь 3-4 десятка с начала, то на форму лучше всего тоже поставить ограничение.
5. Длина слов и другое. Если ввести слов 20 без пробела, то на странице это будет выглядеть некрасиво, а вам это не надо, поэтому либо запрещайте ввод таких длинных слов, либо разделяйте длинные слова самостоятельно, либо укорачивайте слова и другое
6. Вы знаете, что в поле имени (скрипты: гостевые книги, форумы…) пользователь может ввести что угодно, в том числе и ваше имя. Но так как в интернете не все честные, то некоторые, подписавшиеся вашим именем могут наговорить много всего нехорошего. Чтобы подобного не произошло, создайте список с запрещенными именами и проверяйте не совпадает ли имя пользователя с именем из этого списка.
7. Никогда не показывайте в форме пароля его текущее значение. Помните о том, что в этом случае пароль может попасть остаться в компьютере в так называемом каталоге временных файлов Интернета. А если это общественный компьютер? Тогда следующий кто сядет за него может легко узнать пароль. Кроме того форму с паролями обязательно отправляйте по методу POST.
8. В вашем скрипте обязательно должно быть предусмотрено модерирование. Согласитесь, гораздо проще и удобнее зайти на сайт, зайти в на страницу модерирования и нажать на пару кнопок и заполнить пару форм, чем заходить по FTP на сайт, открывать нужную страницу и ковыряться в HTML коде.
9. Кавычки. Заменяйте в получаемых данных все кавычки на ESCAPE - последовательность. Например, кавычку ["] на [\"]. Данные в форму можно ввести так, что при отображении может много чего натворить с вашей страницей. Например, можно вставить скрипт на Java, изменить оформление. Кроме того если это у вас форум или гостевая, можно заменять два пробела на пробел, для того чтоб количество пробелов отображалось верное.
10. Храните пароли в закодированном виде. Ведь если какой-нибудь пользователь и сумеет скопировать себе этот файл с паролями, то он пароль не сможет расшифровать. Если пользователь забыл пароль - меняйте его на абракадабру и отправляйте на Email. При этом обязательно выдавайте вначале ссылку для подтверждения, чтобы никто не узнал пароль.
11. Всегда заменяйте метки и разделители, которые вы используете для сохранения информации или отображения, на что-то подобное. Иначе имеется какой-то шанс, что его пользователь введет в форму ваш разделитель и на странице появится целый список ошибок.
12. Никогда не забываете ставить error_reporting (0) в начало страницы, благодаря этому параметру все ошибки, если они будут, не будут отображаться на странице и злоумышленник не сможет узнать слабое место в вашем скрипте.
13. При подгрузке какого-нибудь файла сначала удостоверьтесь в его существовании, а если он и вправду существует, то подгружайте его с помощью функции require, а не include, потому что в 1 случае если будет ошибка то файл совсем не будет подгружаться, а во 2 он подгрузится с ошибками.
14. Проверяйте откуда пользователь пришел. Потому что пользователь может сохранить форму ввода у себя на компьютере и подправить ее, но если он попытается отправить через нее данные, то ничего не получится, так как он его запрос придет не с той страницы, с которой нужно.

Лет 5-7 назад я сформулировал свод правил, которым руководствовался при работе над проектами (в основном автоматизация управления предприятиями), ну и плюс в этом же духе пытался учить подчинённых (в роли прожект менеджера). Сегодня вот наткнулся на эти правила, почитал, пустил слезу:) Со временем взгляды меняются и с некоторыми правилами я уже не совсем согласен, что лишний раз говорит о том, что составлять подобные списки — дело неблагодарное. А ещё, когда находишься внутри предметной области (напомню — автоматизация предприятий), сталкиваешься с ежедневными ошибками проектирования, то эти правила вполне разумны, понятны и применимы на реальных ситуациях. А с точки зрения непрограммиста или программиста из другой отрасли, некоторые из правил наверняка звучат пафосно, банально или бессмысленно. Так что не уверен, что все поймут, но всё же опубликую.

Первое правило программиста

Разделяй и властвуй.
(© предположительно Гай Юлий Цезарь)

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

Второе правило программиста

Лучше день потерять, зато потом за пять минут долететь.
(© Орёл из м/ф «Крылья, ноги, хвосты»)

Признак хорошего программиста — автоматизация собственной деятельности.
(© ibigdan)

Никогда нет денег и времени, чтоб сделать всё как надо. Но на то, чтоб потом переделывать, и время и деньги находятся.
(© Закон Хеопса)

Смысл: недостаточно успешно закончить задачу, нужно выйти из неё с новым багажом. Создавай не только конечные решения, но и методы + инструменты — всё это пригодится в этом и в следующих проектах. Делай это, даже если поджимают сроки, потому что если ты не растёшь — ты отстаёшь. Заказчику и начальнику на это плевать, тебе нет.

Третье правило программиста

Read The Fucking Manual
(© отчаявшийся сисадмин)

Знание некоторых принципов легко компенсирует незнание некоторых фактов.
(© Гельвеций)

Воображение важнее знания. Знание ограничено. Воображение охватывает весь мир.
(© А.Эйнштейн)

Смысл: вы должны уметь взлетать высоко и нырять глубоко. Уметь увидеть задачу в целом и уметь разобрать её до мельчайших деталей. Без системного мышления и аналитического склада ума в программировании делать нечего.

Четвёртое правило программиста

Зри в корень.
(© Козьма Прутков)

Не так много сущностей, как взглядов на них. Сущность — основа решения, взгляд на неё — доработка под конкретную задачу.
(© ibigdan)

Смысл: например «директор» — это не человек, это должность, которую может занимать человек (а может никто не занимать). И «Иванов Пётр Сидорович» — не человек, а фамилия, имя и отчество, то есть атрибуты человека. Человек — это тело, живое или мёртвое, с кучей атрибутов:) Обычно до таких нюансов при проектировании не опускаются, поэтому большинство автоматизированных систем управления очень негибкие.

Пятое правило программиста

Правильно назвать — значит правильно понять.
(© неизвестный автор)

Ответь на вопрос «что это?» — получишь термин. Ответь на вопрос «зачем это?» — получишь смысл. Возможно на вопрос «как лучше это сделать?» отвечать уже не придётся.
(© ibigdan)

Суть программирования в том, что бы разобрать предметную область на мелкие куски (анализ) и воссоздать её в компьютере в виде работающей модели (синтез).
(© ibigdan)

Смысл: всё программирование сводится к чередованию анализа и синтеза. Причём анализ может быть математическим, функциональным, объектным — любым. И язык синтеза тоже значения не имеет. Важно только понимание и грамотное выполнение этих двух этапов.

Шестое правило программиста

Не плоди сущностей сверх необходимого.
(© В.Оккам)

Пусть это будет просто: просто, как только можно, но не проще.
(© А.Эйнштейн)

Совершенство достигнуто не тогда, когда нечего добавить, а когда нечего удалить.
(© неизвестный автор)

Дублирование и избыточность — признак неправильного понимания предметной области.
(© ibigdan)

Смысл: если сущность появляется в автоматизированной системе более одного раза, значит вы серьёзно накосячили при проектировании. Пример: «Иванов Пётр Сидорович, должность: врач, место работы: урологическое отделение». Потом у него случается инфаркт и опа! — объект номер два: «Иванов Пётр Сидорович, пациент, кардиологическое отделение». На самом деле это один и тот же человек, но в системе числится как два разных, не связанных между собой. Причём это типовая и элементарная ошибка проектирования, а есть куда более запутанные. Большинство АСУП состоят из таких ошибок более чем полностью.

Седьмое правило программиста

Сложные проблемы всегда имеют простые, лёгкие для понимания, неправильные решения.
(© айтишный фольклор)

Если маленький простой предмет увеличить в 100 раз, то он станет большим и сложным.
(© ibigdan)

Когда мы пытаемся вытащить что-нибудь одно, оказывается, что оно связано со всем остальным.
(© Закон Мура)

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

Восьмое правило программиста

Программный продукт, моделирующий некую предметную область, физически не может быть проще этой предметной области.
(© ibigdan)

Следствие: универсальный программный продукт на несколько порядков сложнее специализированного, поскольку охватывает группу взаимосвязанных областей.
(© ibigdan)

Следствие: программный продукт который может всё — бесконечно сложен, а значит невозможен в принципе.
(© ibigdan)

Смысл: увы, никто не выделит вам ресурсы на поиск ответа на «главный вопрос жизни, вселенной и ваще». Ищите компромиссы между желаемым и возможным.

Девятое правило программиста

При автоматизации организационного управления на основе использования ЭВМ следует помнить, что главным залогом ее успеха является коренное изменение традиционной технологии организационного управления.
(© В.М.Глушков)

Автоматизация не самоцель, а инструмент оптимизации деятельности предприятия. Если автоматизация не оптимизирует, то в ней нет никакой необходимости.
(© ibigdan)

Смысл: нет большего идиотизма, чем автоматизировать бумажный документооборот, создавая его точную копию в компьютере. Некоторые программисты так хотят сделать «привычный пользователю» интерфейс, что рисуют на экране бумажные листы, размещают на них строчки и таблички в том же виде, в каком они были на бумажных накладных и т.п. С маркетинговой точки зрения это оправдано, но только вот к автоматизации это отношения не имеет — раньше был хаос на бумаге, теперь хаос в компьютерной сети. Не нужно забывать, что документ — не сущность, а «бухгалтерский взгляд» на неё, сущность — это товары, перечисленные в накладной, вот реальный объект, операции с ним и нужно автоматизировать. Бумажный документооборот — это всего лишь попытка «автоматизации», которую произвели за сто лет до вас и до появления компьютеров, не нужно её автоматизировать, нужно её заменить. Это был пример, таких моментов полно в любой области.