… или эффективность отказа: YAGNI
Работа в качестве разработчика программного обеспечения имеет несколько особенностей, которые отличают ее от других рабочих должностей: она по-настоящему абстрактна, требует предельной ясности ума и сосредоточенности, доводит решение проблем до сути, — пожалуйста, добавьте сюда свою любимую линия тоже — .
Но помимо интернет-культуры, капюшонов, наклеек и мелочей, я думаю, есть много глубоких и ценных вещей, которые должен уметь делать профессиональный программист. Большинству из них не учат в школе, они передаются от старших к младшим, распространяются в блогах или в Интернете… Так что я надеюсь, что так и будет. И вот я амбициозен: я хочу, чтобы эта история была чтением как для программистов, так и для людей.
Экстремальное программирование
Подобно революции сборочных линий или автоматизации промышленных процессов, в эпоху программирования так называемые гибкие методологии помогали и до сих пор помогают программистам определить простой способ управления своим рабочим процессом. В обычном процессе поиска и чтения, который делает любой разработчик, после нескольких лет кодирования я наткнулся на Экстремальное программирование и принцип ЯГНИ.
Основная концепция атомарна, проста и в то же время настолько неземна, что ее можно полностью понять: Вам это не понадобится. Я думаю, это озадачивает людей, не являющихся разработчиками; например: «Подождите, вы говорите, что должны установить правило, чтобы не делать что-то?» - "Точно". Мы все стараемся быть эффективными во время работы, и границы делают нашу работу повседневной: если вы официант, вы записываете заказы, разносите еду к столу и т. д.; если вы печете хлеб, вы делаете — ну, хлебобулочные изделия не такие уж и опытные, хе-хе — . Наверняка никто из этих профессионалов не станет готовить больше теста, чем хлеба, который они собираются испечь, или отправлять на кухню больше, чем заказали клиенты за столом. Очевидно, что они не нужны.
Но давайте перейдем к сложной части. Если клиенты не заказывали чипсы, нужно ли их добавлять? Если приближается Хэллоуин, стоит ли испечь особый хлеб в форме тыквы? Эти моменты более тонкие, обе вещи явно не нужны, но у всех нас есть ключ к пониманию, что они могут быть желательны.
А вот и горячая часть: когда вы что-то проектируете, есть некоторые ошибки, которые так болезненно исправлять, что вы хотите, чтобы они были как-то предвидены. Это, особенно при разработке программного обеспечения, означает, что вы начинаете заранее продумывать дюжину функций, которые вам могут понадобиться. Суть в том, чтобы попытаться предугадать то, что вам может понадобиться, сразу же разработать это ("о, да ладно, мы уже пишем эту услугу, давайте добавим еще эту фичу" ), чтобы работать быстрее и эффективнее, поскольку вы избегаете накладных расходов, связанных с повторным выполнением работы через две недели, открытием нового PR или просто потому, что вы уверены, что вам это понадобится.
Это более вредно, чем неправильное проектирование вещей. А объяснение простое-легкое: существует конкретная вероятность того, что вы просто тратите время впустую, и это помешает вам завершить дело. Действительно, плохо иметь программу с ошибкой, продукт с изъяном. Но угадайте, что хуже: не сделать этого. Я сама жертва синдрома бесконечных проектов. Много раз это происходит (или, по крайней мере, усугубляется) из-за того, что вы не фокусируетесь на том, что действительно необходимо. По крайней мере, это звучит так, как если бы вы получили свой чизбургер холодным, потому что официант ждал чипсы, которые вы не заказывали.
Тебе это не понадобится
Мантра смертельно проста: «вам это не понадобится». Я люблю перефразировать это «если это не нужно, не кодируйте это», это звучит менее амбициозно и более прагматично, но принцип тот же. Но как распознать эти ситуации перед запуском в производство? Типа "Да ладно, приятель, это очень полезно, и мы должны кодировать в этой ветке, чтобы, когда нам это понадобится, это уже было там"
Мне иногда удобно останавливать своих коллег на собраниях команды программистов и бросать вопрос «Ребята, это действительно нужно?». И красота этого вопроса заключается в его эффективности: если ответ основан на возможности, а не на утверждении, тогда бинго, это то, что нужно вырезать (или, по крайней мере, считать неважным). Несколько модных словечек, за которыми нужно следить:
Завтра
Если что-то станет полезным завтра, то есть будет полезно, когда вы будете разрабатывать что-то еще, отложите это. Если вы решите никогда не делать этого, вы только что создали висящий бесполезный код, который так или иначе требует вашего времени (и, надеюсь, также имеет тестовое покрытие). Большинство завтрашних проблем — для завтрашних разработчиков. Замечательным следствием этого принципа и чаще всего решающим аргументом является "можем ли мы быть уверены, что ЭТО является тем, что нам нужно?": легко, мы не можем . Только завтра мы точно будем знать, что нам понадобится. Так что кодируйте его, когда вам это нужно.
Может случиться так, что...
Бывает или нет? Если ответ да, то ок. Если ответ отрицательный, то не делайте этого (очевидно). В противном случае найдите время, проанализируйте материал, а затем решите четко, да или нет. Острый.
Мне это не нравится…
О, ладно, дорогая, у тебя есть свои предпочтения, и у меня тоже, но если серьезно, если что-то пахнет, давайте назовем это плохой практикой, или если вы подозреваете появление ошибки, найдите время, проанализируйте ее и воспроизведите ошибку. Будьте объективны.
Это неэффективно, если…
Ну хорошо, это сложно, но хотя бы первая версия, пусть работает. Нет (n²) против (nlogn) мыслей и т. д. Бонусный момент, если алгоритм интуитивно понятен, его легче отлаживать (а также младший коллега может сделать это, не тратя на это время старшего ниндзя). Вы всегда можете улучшить его позже. Или перепроектировать его. Очевидно, что если эффективность является главной целью, то пришло время взглянуть ей в лицо и работать над ней.
Сила отказа
Одна из частей моей очень личной точки зрения заключается в том, что даже если это может быть проблемой, разработчики программного обеспечения большую часть времени пишут ненужные вещи, потому что они действительно думают, что они достойный. Кроме того, в программном обеспечении присутствует сильное чувство эстетичности, и мы действительно чувствуем дискомфорт, когда не реализуем что-то, что, по нашему мнению, может понадобиться завтра. Короче говоря, один из ключей к повышению эффективности — сосредоточиться на коде, который оказывает непосредственное и объективное воздействие. Откажитесь от всего остального. Вы найдете больше времени, чтобы делать то, что, по вашему мнению, необходимо (покрытие тестами?).
Имейте это в виду, завтра придет!
Последнее слово по этой теме: имейте в виду, что всегда есть место для рефакторинга, улучшения и новых функций! Итак, я предлагаю выбрать одну небольшую атомарную тестируемую (достаточно ли?) функцию за раз и использовать ее. Глядя на сделанное, вы можете даже изменить свои взгляды или приоритеты, не тратя время и усилия.
