Теперь у меня левел-ап, я уже по-минимуму пользуюсь теми самыми плагинами, упрощающими жизнь, я их пишу :) Теперь в списке моих задач - написание велосипедов, которые при надобности должны взлетать и еще уметь готовить яичницу на всякий случай.
Теперь у меня новая проблема: мне надо объяснить моим коллегам, что когда нужна какая-либо функциональность, не нужно страдать синдромом not invented here, нужно взять готовую либу и, если нужно, добавить недостающую функциональность. И, блин, не унаследовав от базового класа, а используя композицию!
Когда я вижу простыню из 900 строк, у меня возникает желание сделать вот так:
Когда я вижу код, в котором вместо стандартных решений использован собственный костыль, у меня вот эта реакция:
и обязательно ищу в нем баг, чтобы получилось вот так:
Вы не поверите, в 90% я его нахожу :)
Честно, не надо придумывать заново колесо, не надо проявлять фантазию в именах переменных, пользуемся готовыми паттернами, реюзаем код. Проще говоря, для себя вывел следующие правила:
- Используем единый стиль форматирования, желательно тот же самый, что используется внутри общества, в котором вы живете. Потому что если вы пишете иначе, то вам сложно понять код других программеров, а другие будут плеваться на ваш код. Это все равно как русскому туристу в Китае на рынке договориться о скидке.
- Самое сложное - придумывать названия (переменным, классам). Это правда. Вот не ленимся переименовать кнопку c ButtonX на MessageButtonBehaviour, anotherTemp на что-либо более подходящее. Я уж молчу о переменных типа ttt, secondVar, var5 (я не шучу - сегодня видел в боевом проекте).
- Юзаем паттерны, а не изобретаем их! И не надо делегат называть адаптером(привет андроид!), не надо хвалиться, что придумал новое супер решение, не прочитав шестую страницу банды четырех.
- Не забываем, что паттерны паттернами, но принципы KISS и YAGNI игнорировать нельзя. Вообще, сначала применяем здравый смысл, а потом бегите за стереотипным решением.
- Изучаем алгоритмы и структуры данных не для того, чтоб победить на топкодере и получить новую футболку, а чтоб знать внутренности структуры данных и алгоритмов, уметь применять на практике и если нужно, написать самому.
- И да, если знаем алгоритм или структуру, то применяем готовое решение, а не пишем собственный мегабыстрый класс! Сегодня рыдал от строчки типа такого: public List<string> itemsStack = new List<string>();. Угадайте, что это за структура данных? Угадайте, как автор этого шедевра делал push, pop, top? И это было в файле объемом 900 строк!!!!!1111 Я рискнул рефакторить, но позже понял, что это было плохой идеей, потому что этот гребанный стек применялся еще где-то и передавался ref-ом в какой-то левый класс, который зачем-то использовал его по-своему как список(linkedList)!
- И да, не боимся пользоваться плагинами, не ходим грудью колесом аля "я все умею!", все самое лучшее уже давно написано за нас. Мы жмотимся на плагин стоимостью 100 баксов, но сами в течение пяти дней готовы допиливать собственный говнокод, почти выполняющий функции того плагина.
- Не забываем развиваться, изучать новые фичи своего инструмента. Поверьте, вопреки распространенному мнению, обновление - это фикс багов и добавление новых фичей, а не наоборот! И если в языке X появилась штука, которая позволяет в одну строчку написать то, что вы писали в сорок - то даже дурачок Боб, не сумеющий написать свое имя наоборот(с), поймет, что надо юзать эту штуку!
Я очень рад, что в лкш ввели ручную проверку кода. Прикиньте, сколько бы еще можно было родить алгоритмических монстров, способных написать соптимизированную регекспу, но не способных разобраться в лапше из кучи классов. Надеюсь, они вряд ли столкнутся с теми проблемами, c которыми сталкиваюсь я.
P.S. На проекте у нас два программиста: коллега и я. Сегодня произошел священный спор по поводу египетских скобок. Я сторонник египетских скобок, аргументировал так:
- меньше ненужного пространства при той же читабельности
- большинство проектов (включая исходные коды юнитеков), написано с применением данного стиля, то есть он стандарт де-факто.
Он аргументировал это так:
- египетские кнопки это плохо
- я привык писать по bsd стилю, по-другому не умею.
- весь мир неправ.
В общем, это был священный спор и каждый остался при своем мнении. Вдруг кто считает иначе, велкам :)
Прочитал эту статью и предыдущую. Проанализировал. Но отвечу только здесь.
ОтветитьУдалитьРустам, к сожалению данная тема, которую ты затронул, болезнь в любой, абсолютно любой сфере.
Человек, который не хочет развиваться, не хочет сотрудничать и думающий, что он самый самый, ни когда не признает свою ошибку. Он будет придумывать и изготавливать свои "костыли". Будет винить всех и вся. Будет считать, что его работа самая лучшая, а работа других просто ****
Поэтому любой мало-мальски соображающий руководитель вводит стандарты. Именно эти стандарты позволяют легко и непринужденно находить общий язык.
Если помнишь, в институте всегда требовали, что бы твоя печатная "макулатура" (рефераты и курсовые и пр.) выглядела по стандарту. Это очень сильно помогает в будущем.
НО закончив институт, устроившись на работу, понимаешь, что здесь не введены стандарты, здесь бардак. И поражаешься, как это до сих пор работает! Так много лишних действий и т.д.
Это и есть "говнокод" нашей жизни.
Помыкавшись, находишь другое место, где все стандартизировано, и упорядочено. Но и тут есть НО. Ты НЕ СМОЖЕШЬ изобрести (обновить) ту телегу, на которой едет фирма. Так как стандарты не позволяют тебе делать что либо лишнее.
Отсюда вывод: в крайностях правды нет. Может ты помнишь такую фразу "сыйратль-мустакыйм". Т.е. Правильный путь (либо можно перевести средний путь).
Именно поиску такого пути и следованию по нему стоит уделить больше внимания, чем на представителей "крайностей".
P.S. Ты наверное помнишь, что такое "нормальное распределение", оно, кстати, применимо ко всему в нашем мире ;-)