В России отдельные действия властей тоже относятся к форс-мажорным обстоятельствам. Правда, речь идёт только об изменении законодательства, но в такой формулировке, как я написал в первом предложении, звучит лучше ;-)
Ну сколько можно уже писать одно и то же? Да, при рождении его звали Ким Шмитц, но потом он _официально_ сменил фамилию на Дотком. И даже его жена, выходя за него, сменила фамилию на Дотком.
Т.е. я правильно понимаю, что задачи не фиксируете, и никак не проверяете точность их выполнения, равно как и вообще сам факт выполнения? И если предположить, что какая-то из клейких бумажек отвалится с монитора и будет выброшена уборщицей — вы сможете установить факт этого только случайно?
Если один коммит несёт в себе множество изменений, заявленных как рефакторинг, но при этом таких, что они могу сделать модуль несовместимым, то первое, что я сделаю — это объясню закоммитевшему смысл слова «рефакторинг» (внесение изменений, не меняющих поведение и при этом улучшающих структуру программы или модуля). Второе, что я сделаю — это объясню, что каждый коммит должен быть минимальным (и, разумеется, не нарушающим целостность программы и при этом имеющим отдельную ценность). При этом любые рефакторинги должны идти отдельными коммитами, равно как и исправления стиля, опечаток и т.д.
Нет, речь немного о другом — как вы составляете список задач, как отслеживаете их выполнение, как убеждаетесь, что никакие задачи не забыли выполнить и что они выполнены правильно?
If you cannot change your job — change your job. В том смысле, что от вас в организации процесса тоже очень многое зависит. А если вы никак не можете (именно «не можете», а не «не пробовали») повлиять на рабочий процесс, и он вам не нравится — валите из этого места.
Однозначно лучше первое. Программы пишутся не для компьютеров, а для людей, и основным приоритетом должна быть поддерживаемость кода. Ну, по крайней мере в реальных коммерческих проектах это так.
Не очень понимаю постановку вопроса. Чем кода больше, тем он менее понятен (если качество кода не меняется). Мне кажется это очевидно — чем больше объём информации, тем человеку сложнее её понять.
А у меня наоборот — гораздо больше проблем с оптимизацией там, где изначально пытались «оптимизировать». А вот там, где код простой и понятный — и оптимизируется гораздо легче, причём точечных оптимизаций хватает за глаза.
Преждевременная оптимизация плоха тем, что она ухудшает понимаемость кода, и достаточно часто — очень сильно ухудшает. Мой опыт в профилировании и оптимизации показывает, что гораздо лучше сначала написать красивый, целостный, концептуально чистый и _понятный_ код — а уже потом профилировать его и ускорять узкие места. По факту узкие места почти всегда оказываются не там, где бы ты подумал изначально, и уж точно всегда их можно оптимизировать проще, чем писать изначально «оптимизированный» код.
Разумеется это не относится к выбору базовых алгоритмов и архитектуры (т.е. к таким вещам, которые потом будет сложно переделать).
2Гис кроме России начинает выходить в Казахстан (уже есть Алматы) и в Италию (есть Венеция и Падуя).
Разумеется это не относится к выбору базовых алгоритмов и архитектуры (т.е. к таким вещам, которые потом будет сложно переделать).