«Корабль в гавани безопасен, но корабли созданы не для этого».
- Джон А. Шедд

Заявление об отказе от ответственности: это НЕ оригинальная идея для сочинения. Многие люди использовали эту цитату в качестве предисловия к жизненному совету. Я просто использую его, чтобы рассказать о своем личном опыте и подходе. Это не совет. Просто я говорю о моем любимом предмете: о себе.

META: Это перепечатка с моего личного веб-сайта.

Во-первых, это ужас

Я не умею делать почти каждый проект, за который берусь.

Первая фаза обычно представляет собой приятный раунд паники и бормотания ужаса.

«Он слишком большой! Слишком амбициозно! »

«Это никогда не сработает!»

«Я слишком глуп, чтобы сделать это!»

«Я даже не знаю, с чего начать!»

«О чем я ДУМАЛ?»

и т. д. до тошноты.

«Наслаждаясь» этим какое-то время, я вытираю глаза, высморкаюсь, закатываю рукава и приступаю к работе.

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

Вот колбасная фабрика

«Те, кто уважают закон и любят сосиски, не должны смотреть ни на что».
- Марк Твен

Мой процесс ужасен. Я никогда не занимался парным программированием, но не вижу, чтобы мой партнер был в восторге от моих выходок.

Я называю это въезжать в сорняки или врезаться в ограждения. Я просто пробую разные вещи, подбрасываю соломенных людей, делаю ужасные предположения, просматриваю документы, создаю наивный, беспорядочный исследовательский код, смешиваю свою модель с моим контроллером и редко записываю что-то чертовски. Я постоянно ищу в Google даже самые простые алгоритмы, и Stack Overflow - мой лучший друг.

Поверьте мне; вы были бы в ужасе.

Но я работаю БЫСТРО, и мои конечные продукты всегда безупречны, с богатым, удобным пользовательским интерфейсом, исключительно высоким качеством, встроенной локализацией, безупречной полировкой, отличной документацией и очень небольшим техническим долгом.

Черновая это

Меня учили как художника, и до того, как я начал свое обучение, я использовал ручку, считая каждую строчку. Я очень гордился своей работой.

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

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

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

Осторожная растяжка - ключ к успеху

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

Мне также нужно управлять масштабом. Я хорошо знаю, сколько я могу сделать за определенный промежуток времени, и довольно хорошо умею оценивать общую картину (за годы неудач). Мне нужно посмотреть на свои ресурсы и временные рамки. Я обычно предполагаю, что моя оценка, вероятно, слишком оптимистична примерно на 50% (общепринятое мнение - 100%, но я использую 50%, если работаю в одиночку, и 150%, если работаю в команде - НИКОГДА не недооценивайте накладные расходы команды. ).

Итак ... растягивайтесь, но растягивайте осторожно.

У всех моих проектов есть срок годности и безумное качество

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

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

Каждый проект, над которым я работаю, предназначен для отправки

"Мы то, что мы постоянно делаем. Итак, совершенство - это не действие, а привычка ».
- Аристотель

Неважно, просто ли это «экспериментируем» или я имею в виду конкретное место для сдачи.

Я пишу ВЕСЬ свой код так, как будто он будет предметом аудита и теста «белой перчатки».

Даже у моих тестовых жгутов есть значки приложений. У каждого репо есть значок и изображение главного героя (карточка социальной сети), а также каталог документации, в котором находится сайт GitHub Pages.

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

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

Это также помогает мне сосредоточиться на практических вопросах и поощряет подход, «ориентированный на реальные результаты».

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

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

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

В большинстве моих проектов суть кода довольно проста. Ничего особенного или конфиденциального. Здесь не на что смотреть, ребята. Двигайтесь дальше .

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

Прежде чем начать, я разбиваю проект на подсистемы

Чтобы уменьшить подавляющий характер моего нового пугающего проекта, я обычно разбиваю его на блоки разработки. Они могут быть основаны на функциональном составе, структуре backend / frontend / API или даже Это страшно. Это не так уж и страшно . Я рисую свой« набросок на салфетке и применяю шаги, которые я вкратце опишу, к каждой подсистеме.

Мне нравится, чтобы график и план проекта были как можно более расплывчатыми; с уточнением, поступающим «точно в срок» по мере продвижения проекта. Я просто предполагаю, что меня бросят много кривых. Это вдвойне верно, если я планирую взяться за проект, который еще не умею делать.

Я начинаю с написания того, что работает; Может быть, не очень

Первое, что я делаю, это убеждаюсь, что мои данные / операция происходят правильно. Иногда я могу делать вещи TDD и писать неудачные тесты, но чаще я начинаю писать пустые тесты, когда начинаю новую функциональность, с целью, чтобы они конкретизировались по мере того, как я разрабатываю функциональность. Я считаю, что важно как можно скорее активно протестировать код.

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

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

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

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

Я также часто буду добавлять комментарии и настраивать заголовки в стиле Jazzy. Даже простые разделители для заголовков функций лучше, чем ничего. Они помогают при визуальном сканировании текстового файла. Рекомендуется использовать комментарии // MARK: для выделения функциональных блоков.

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

Затем я начинаю его уточнять

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

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

Поскольку мы говорим об Apple, я часто пытаюсь проверить, смогу ли я получить исходный файл Swift для компиляции с помощью только «import Foundation». Это не критично, но помогает подготовить код для повторного использования в будущем.

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

Если я все же решу разбить подсистему, я могу приостановить проект и создать отдельный проект для подсистемы. Недавним примером (на момент написания) является проект RVS_PersistentPrefs, который был извлечен из проекта RVS_MediaServer. Я приостановил выполнение проекта RVS_MediaServer примерно на неделю, так как создал проект RVS_PersistentPrefs. Это действительно означало, что проект RVS_MediaServer занял больше времени, чем мог бы, если бы я просто использовал исходные встроенные настройки, но работа окупилась почти сразу после того, как я вернулся к проекту RVS_MediaServer. Проект RVS_IPAddress также был разложенным инструментом, как и проект RVS_ParseXMLDuration. Они пришли с моей работы в ONVIF.

Оптимизация не для всех

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

«Конечно, оптимизация необходима! Разве кислород не нужен? " ты говоришь.

Да… не совсем. Особенно, если вы делаете много кода пользовательского интерфейса. Стабильность, полезность и оперативность - главные факторы. Отзывчивость может быть решена путем оптимизации, но я считаю, что пересмотр дизайна часто является лучшим способом. Использование таких вещей, как многопоточность, привязка KVO и / или наблюдение за свойствами может помочь приложению быть достаточно быстрым; гораздо больше, чем динамичная оптимизация внутреннего цикла. Стандартная бритва Оккама.

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

Я также ищу вещи, которые повторяются снова и снова. Посмотрите, можно ли их кэшировать или объединить. Стандартный низко висящий фрукт.

Полностью уменьшить количество бетонных галош

Это, наверное, самая важная часть моего личного процесса. Я здесь про« бетонные калоши писал». Очень важно снизить коэффициент окостенения проекта. Это то, что записывается или становится окаменевшим. Некоторые из них очень необходимы, но многие можно отложить.

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

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

Я люблю учиться

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

Я не люблю, когда меня опекают

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

Я научился просто прикусывать язык / убирать руки от клавиатуры и «позволять им побеждать». Я здесь «нарушитель». Это «их» домен, и велики шансы, что я просто пройду через него. Это просто вежливо - постараться не наделать слишком большого шума. Они должны там жить; Обычно я этого не делаю.

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

С этим не поспоришь. У меня есть отличный рецепт скромного пирога. Хорошо сочетается с Crow и Egg-On-Face.

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

Все это делается вместе, чтобы корабль оставался на плаву

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

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

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

Я считаю, что это круто и делает жизнь интереснее.