среда, 15 октября 2014 г.

Как программировать правильно. Полезные советы




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

Пункт № 0 — Цель Программирование — не цель, а средство, если бы можно было решать проблемы выстругивая квадратные палочки и выкрашивая их в зеленый цвет так бы и делали. 
Пункт № 1 — Предназначение Людей интересуют они сами, их проблемы и немного другие люди. Все остальное их не колышет. Это помогает осознавать, что если можно сделать за 2 человеко-месяца, не надо растягивать на 50 человеко-лет, ваш заказчик не такой дурачок, он быстро смекнет что к чему и свалит, раструбив на весь мир что ваша фирма — куча муд*ков, вам с вашим эгоизмом может быть пофигу, но если ваше имя засветиться в black-list-е, потом не найдете работу. 
Пункт № 2 — Результат Результат — главное, все остальное не имеет значения. На каком языке/томкате/сборки и что вы делаете, если результата нет — получите лучи гнева в свой адрес, в худшем не выплатят часть денег и поверьте, менеджер с вас не слезет после этого. Не выпендривайтесь перед заказчиком/ихним менеджером умными словами если результата нет. Сравните это поведение с поездкой в автосервис когда вам машину не починили, но вылили на голову ведро умных слов.
Пункт № 3 — Код Код должен делать то, что от него ожидается, ничего другого он делать не должен. Никаких методов про запас, никаких закомментированных кусков. Если вдруг в вашу сторону что-то полетит тяжелое — значит это вы создали getter, который допустим «заодно» подчищает объекты в базе, никаких побочных эффектов. Метод 1000+ строк с 20-ю блоками if-else и циклами 14-го уровня вложенности осилить невозможно. 
Пункт № 4 — Подход Пишите как можно проще, я не призываю на все наплевать и получить сложность O(n*n) где можно обойтись O(1) или O(log(n)), то что вы напишете кто-то должен понимать и поддерживать. Код должен нормально читаться и восприниматься.
Пункт № 5 — Отраслевые стандарты Почитайте, освойте и ПРИМЕНЯЙТЕ отраслевые стандарты по использованию VCS, форматировании кода, деплоя, именования всего и вся, составления документации, создания тасков. Понятно что каждая кухарка мнит себя королевой, но блин вы не представляет как задолбал каждый раз новый flow в JIRA на одни и те же проекты, как задолбало форматирование в 2 пробела в Java коде, задолбал деплой через ж*пу подкидыванием файликов по одному на тестовый сервак. Задолбали отчеты в 4 места по UI-таску. Посмотрите как делаются проекты в Apache и не позорьтесь своими «ноу-хау».
Пункт № 6 — Выпендрежу и закидонам нет места Если бы заказчики почитали хотя бы 10% DOU, они бы вывели большую часть проектов с Украины. Потому что программисты в большинстве своем ведут себя, мягко говоря, неадекватно. Переписать код с Java на Хаскель потому что Хаскель — «тру», а Java — «не тру», линукс — «тру», винда — «не тру», абстрактные фабрики и монады для вывода 5 строк на консоль — «тру», конкатенировать 5 строк 1 раз — «не тру», адское шаманство JVM/среды разработки/инструментальных средств — «тру», чистый билд на Jenkins — «не тру». Задолбали, честное слово. Поймите, заказчику до фонаря, он привык сидеть в IE8 и готов ввалить в вас несколько лимонов долларов, чтобы вы поддерживали этот IE8, задумайтесь — миллионы долларов, его все устраивает и он готов заплатить за этот и тут вы с этим идиотизмом. Так что закройте рот и молча фиксите IE-баги. Если потребуется новые фичи, например полноценные CSS3 — вежливо и развернуто подскажите, что мы бы рады, но IE8 не поддерживает, давайте повысим версию? 
Пункт № 7 — Уважайте коллег по работе На работе в основном занимайтесь работой, а не херней. Не отвлекайте коллег по пустякам, не врубайте музыку на всю комнату, не тролльте и не подкалывайте просто так, особенно в релиз. Не ведите себя как стадо обизян, не устраивайте кукольный театр в опенспейсе в рабочее время. Не разрисовывайте офис целую неделю. Не используйте масляные краски в непроветриваемом помещении и вообще в помещении и вообще рисуйте, с*ка, на дому. 
Пункт № 8 — Документирование Пишите, бл*, комментарии на сложные методы, модули и в коммитах что это делает. Не пишите, бл*, что метод возвращает boolean или бросает проверяемый Exception, я это и так вижу по его сигнатуре. Поверьте 100500 х //TODO в коде не радует и хочется кому-то дать в морду. Составьте wiki как вашего франкенштейна поднять, если не хватает ума сделать скрипт в одну команду. 
Пункт № 9 — Пожелания Делайте работу качественно, с любовью или хотя бы с достоинством, спустя рукава и лишь бы отсидеть и затянуть 2-х дневный таск(на расслабоне) на 4 недели — не надо, пожалуйста. Не стоит делать видимость работы, все прекрасно понимают что к чему и рано или поздно вас «сдадут» ли вы сами сядете в лужу.

1 комментарий: