Проблема должна быть хорошо продумана перед тем, как она сможет быть решена

Эти правила посвящены весьма реальным проблемам и во многих отношениях являются самыми важными правилами в этой книге.

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

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

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

Используйте для работы соответствуюший инструмент

Данное правило является спутником правила «Не путайте привычность с читаемостью», представленного ниже, но, скорее всего, больше касается проблем руководства. Мне часто говорят, что студентам не разрешается использовать некоторые аспекты С или С++ (обычно это указатели), потому что они «нечитабельны». Обычно это правило навязывается руководителями, знающими ФОРТРАН, БЕЙСИК или какой-то другой язык, не поддерживающий указатели, и их не очень-то заставишь изучать С. Вместо того, чтобы признать изъяны в своих знаниях, такие руководители будут предпочитать калечить своих программистов. Указатели превосходно читаются программистами на С.

И, наоборот, я видел ситуации, где руководство требовало, чтобы программисты перешли с языка программирования типа КОБОЛ на С, но не желало оплачивать переподготовку, необходимую для перехода. Или еще хуже, руководство платило за переподготовку, но не предоставляло времени, необходимого для действительного изучения материала. Переподготовка является занятием, требующим всего рабочего дня. Вы не можете одновременно выполнять «полезную» работу, а если попытаетесь, то ваши деньги будут выброшены на ветер. Так или иначе, после того, как руководители видят, что их штат не был превращен в гуру программирования на С++ после 3-дневного краткого курса, они реагируют наложением ограничений на использование некоторых компонентов языка. Фактически они говорят: «Вы не можете использовать ту часть С++, которая не похожа на язык, который мы использовали до перехода на С++». Естественно, что окажется невозможным эксплуатировать ни одну из прогрессивных особенностей языка (которые прежде всего и являются главной причиной его использования), если вы ограничите себя «простейшим» подмножеством особенностей.

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

Разлагайте сложные проблемы на задачи меньшего размера

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

В качестве примера программирования возьмем прошитое бинарное дерево, отличающееся от нормального дерева тем что указатели на узлы-потомки в конечных узлах на листочках указывают на само дерево. Фактическим преимуществом прошитого дерева является то, что его легко просмотреть нерекурсивно при помощи этих дополнительных указателей. Проблема заключается в том, что сложно выйти из алгоритмов просмотра (в особенности при обратном просмотре). С другой стороны, имея указатель на узел, легко написать алгоритм поиска последующего элемента в обратном порядке. Путем изменения формулировки с «выполнить просмотр в обратном порядке» на «начав с самого отдаленного узла, искать последующие элементы в обратном порядке, пока они не закончатся» получаем разрешимую задачу.

Мы знаем, что компьютеры могут смотреть на мир и определять, что видят, с помощью программного обеспечения, распознающего изображения. Они могут воспринимать объекты и людей и даже различать отдельные лица и эмоции. Но что они на самом деле видят? Этот вопрос был поднят исследователями искусственного интеллекта и распознавания образов. Ученые из Университета штата Вайоминг и Корнельского [...]

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

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

Для визуализации информации решили использовать карту мира и разместить все отзывы прямо ней. Это показалось нам наиболее удобным для восприятия – если в одном городе несколько отзывов с разными оценками, то по ним выводится средний балл. И в целом сразу визуально видно, какие регионы наиболее комфортны для жизни. Читать дальше →